Welcome to the VMRay Malware Analysis Report Recap. Every month our Research Team provides a recap of the malware analysis reports posted to the VMRay Twitter account. This past December, our team analyzed a variant of Globeimposter ransomware, a Windows Script File (WSF) that downloads a payload to set-up a server to accept incoming connections and an RTF document that takes advantage of the CVE-2017-11882 vulnerability. Click the links below to jump to a specific report:
Date Released:
December 5, 2017
SHA256:
7a18bffd01eeab08a3f88d35ba5d09106690ea62d01e43d950b6b842ab6c4e76 This variant of Globeimposter ransomware was downloaded and executed by a malicious Visual Basic script. The script most likely was sent by the Necurs Botnet as an email attachment. The first action of the script is to contact its C&C (command and control server). From the Network Behavior tab of the report, we can see that the C&C was located in Houston, TX (Figure 1). After downloading the payload, the Globeimposter ransomware is executed.
Figure 1 Network Behavior tab showing the C&C where the payload is downloaded
Globeimposter then proceeds to encrypt the user’s files and leaves a ransom note with payment instructions. The ransom note is called “Read_ME” and is left on the desktop (Figure 2).
Figure 2: Globeimposter Ransom Note
The cybercriminals offer free decryption of a single file as proof they have working decryption keys. Like other ransomware, Globeimposter deletes snapshots created by the Volume Shadow Copy Service to make it more unlikely that the user will be able to restore the encrypted files if there are no other backups.
Date Released:
December 13, 2017
SHA256:
2999babb0c6ca9fcc1aa03ad5606043d70f45a1495820c7a22250a584d371d70 The Windows Script File (WSF) downloads and executes a malicious file from a blacklisted URL (Figure 5). The payload uses common techniques like process injection (Figure 4) and writing itself into the Windows startup for persistence. All of the detected threats can be seen in the VTI tab of the report (Figure 3).
Figure 3: Detected Threats from WSF-Script and the dropped payload
What stands out in this analysis is that it executes several processes. Shown in Figure 4, it adds Chakmcat.exe to the Windows startup folder for persistence (surviving a reboot). The malware injects into explorer.exe and runtimebroker.exe, which starts a local TCP Server on a dynamic port.
Figure 4: Process graph showing the malware injecting into several processes
Figure 5: WSF-Downloader Connects to Blacklisted URL to Download the Payload
Upon the initial post of this report, Twitter user @markwo responded to our Tweet asking why we show a TCP server listening on port 0.
This is not incorrect behavior. In our analysis, you can see all necessary information: [0082.882] socket (af=2, type=1, protocol=0) returned 0xd60 [0082.882] htonl (hostlong=0x7f000001) returned 0x100007f [0082.882] bind ( s=0xd60 , addr=0x59df808*(sa_family=2, sin_port=0x0 , sin_addr=”127.0.0.1″), namelen=16) returned 0 [0082.882] listen ( s=0xd60 , backlog=1) returned 0 [0082.882] socket (af=2, type=1, protocol=0) returned 0x2108 [0082.882] getsockname (in: s=0xd60 , name=0x59df818, namelen=0x59df800 | out: name=0x59df818*(sa_family=2, sin_port=0xc116 , sin_addr=”127.0.0.1″), namelen=0x59df800) returned 0 [0082.882] connect (s=0x2108, name=0x59df818*(sa_family=2, sin_port=0xc116, sin_addr=”127.0.0.1″), namelen=16) returned 0 The bind API call uses sin_port=0x0 to let the OS choose an appropriate port for the socket from the dynamic client port range (value between 49152 and 65535). Later, the getsockname API call is used to get the port that has been assigned to the socket (sin_port=0xc116 = 49430). But as a response to @markwo’s question, we’ve updated our reports to include the actual port that the OS chooses for the socket rather than displaying ‘0’. You can see the updated report below.
F igure 6: Updated VTI Information with the actual Port Number
Date Released:
December 20, 2017
SHA256:
1c0a1a7c695d5e1a7497b7fa4f75cf83f12265eaca2297b3d72461d110fcb079 The CVE-2017-11882 vulnerability exploits a 17-year-old component of Microsoft Office, the Microsoft Equation Editor. The Process Graph in Figure 7 shows the Equation Editor (eqnedt32.exe) which is exploited by the RTF Document. The Equation Editor is an attractive process for attackers because CVE-2017-11882 is easily exploitable due to the lack of enabled exploit mitigations like ASLR and DEP in the Equation Editor.
Figure 7: Equation Editor (eqnedt32.exe) exploited by the RTF document
The RTF Document’s payload uses typical malware techniques like process injection and anti-analysis to try to detect an attached debugger as seen in the Detected Threats section in the VTI tab (Figure 8). The exploit’s shellcode downloads a known malicious file (lambdoidtegument.exe), drops it and then executes it.
Figure 7: RTF document downloads and executes a known malicious file (lambdoidtegument.exe)
