Forensic Files: Cerber Ransomware Distribution using Office DOTM files

The start of a series

This blog entry is the first in a new series featuring reports from Check Point SandBlast Agent Forensics. The concept is quite simple: we run a malware sample on a PC in our malware lab, with all protections turned off, and let SandBlast Forensics automatically analyze it.

SandBlast Forensics identifies, summarizes and highlights all the elements related to a security incident. The elements comprising the incident are automatically extracted from raw forensics data, which are then input into a focused incident model by our patent pending algorithms. Once the model has been built, the interactive forensics report presents concise actionable intelligence that allows an incident responder to determine the context, scope and potential business impact that occurred during the incident.

Figure 1. Forensics Overview Screen

Background

In June, Check Point partner Avanan published a blog discussing a Cerber ransomware infection delivered through a “.dotm” Microsoft Office File. As Avanan explained in the blog, the attack was delivered through a dotm file that was sent to multiple users via a phishing email. A dotm file is basically a template file for Microsoft Word that allows for macros. Introduced in Office 2007, it uses the OpenXML format and zip compression. Following is a brief summary of the forensics report for the malware.

Forensic Analysis Summary

Figure 2. Incident Tree, red nodes here are malicious processes, blue and grey nodes windows processes, and chrome.

Figure 2. displays a zoomed out view of the entire incident tree built after the malware has finished encrypting the files on the system. Note the number of processes in light blue and grey, as these are unmodified Windows Operating System Processes being used by the malware to execute its attack. This highlights the fact that most modern malware use legitimate processes in order to achieve their goals.

On opening the document, the user is asked to enable editing and enable content. Without enabling content the macro does not execute, and as a result the infection does not continue.

Figure 3. Macro causing execution of CMD.exe

As seen in Figure 3, if the macro does execute, it launches a command line (cmd.exe PID 1272 in the report) with a very large argument, which includes Visual Basic Script (vbs) code. The command line also drops a vbs file (28156.vbs seen in the report either under file ops creations or under suspicious events: Dropped Script).

Figure 4. Creation of tmp file by wscript

The command line then executes wscript (wscript.exe PID: 1432) with the dropped vbs file (28156.vbs), which in turn downloads the first Cerber Ransomware malicious file (Fig. 4) (272730.tmp) while accessing the following sites:

• Solidaritedeproximite[.]org/mhtr.jpg
• 92.222.104[.]182/mhtr.jpg

Once 272730.tmp is created, it is launched via another command line with PID 3068 and thus begins the Cerber infection. The launching of a file with a “tmp” extension as a process is considered to be highly suspicious (272730.tmp PIDs: 128 and 2152) and flagged as the suspicious event: Unusual Process Extension. This version of Cerber is not drastically different than the one shown in our earlier blog titled Cerber Ransomware Targets U.S., Turkey and the UK in Two Waves.

Figure 5. Making a copy and deleting the original tmp executable

The process 272730.tmp with PID 128 then launches a copy of itself with PID 2152. The process with PID 2152 then makes another file copy of itself in the “appdata” folder called raserver.exe. This is highlighted by the suspicious event “Executable Copies”. It then starts a process of raserver.exe with PID 1432. Subsequently, it launches a command line with PID 2592 to delete the original 272730.tmp file. This is accomplished by calling taskkill.exe to kill the process 272730.tmp and then calling ping to add some time to let the process die, so the file can then be deleted. Again all this is captured by suspicious events in the graph in Figure 5.

Figure 6. UAC Bypass Attempts

In MalwareBytes blog titled Cerber Ransomware – New, But Mature, researchers provide details on how Cerber was attempting to bypass User Access Control (UAC) in order to elevate the privileges of processes involved in the attack. In particular, they explain that Cerber attempts to start its own instance of Windows explorer and then injects into this instance code that allows it to use Microsoft Windows Operating System processes to bypass UAC.

All the runs of Cerber in our lab, however, did not succeed in bypassing UAC and instead we got the UAC message. In fact, every time the bypass failed, we received new UAC message. This would cause Cerber to launch a new instance of explorer with a different Windows OS executable as shown in Figure 6. Process raserver.exe with PID 2212 in this incident was attempting to bypass UAC. Our malware reverse engineering team noted that the executables used to attempt the bypass had manifests with the following information:

<autoElevate>true</autoElevate>

<requestedExecutionLevel level=”requireAdministrator”/>

Figure 7. Example UAC Message appearing when UAC bypass fails

We clicked yes to all the UAC messages after waiting a while, and this is why you see 4 instances of explorer being called in the report. Also, seen in Figure 7, rarserver.exe with PID 2540 now has higher privileges (indicated by the red arrow), which allows the process to now begin the actual encryption attempt on the user’s document.

Figure 8. Data Ransom, Shadow Copy Deletion, Boot Tampering etc.

Figure 8 shows the process raserver.exe with PID 2540 running with elevated privileges launching a copy of itself with PID 4688. It is the process with PID 4688 that does all the encryption of the user’s documents. In addition, this process also attempts to do shadow copy deletion (a common ransomware tactic) via vssadmin.exe and wmic.exe. Finally, it attempts boot tampering through the use of bcdedit.exe.

Figure 9. Ransom Message saved as desktop background

Finally, while we saw several persistent events (Seen in Suspicious Events: Persistence). It seems that all the malicious executables were deleted by Cerber after it determined that all the users’ files were encrypted. So on reboot, we do not see the infection continue. However, the background message (shown in figure 9) remains.