By Zachary Bailey and Alex Geoghagan, Cofense Phishing Defense Center
TrickBot is a notorious banking trojan that was commonly seen in the last couple of years in tandem with Emotet and Ryuk, and was dubbed a “triple threat” by various security researchers. However, TrickBot is now looking to score a hat trick on SEGs (secure email gateways) by utilizing three new components in its infection chain. This campaign delivers DOCX files that exploit the CVE-2017-0199 vulnerability. Employees are advised to never enable macros when they open Office documents, but this CVE leverages an embedded link that will immediately call out to a DOT payload, bypassing normal security checks. This new file includes a VBS script that will download the final executable.
This threat was first spotted by the Cofense Phishing Defense Center (PDC) in early June, targeting companies in the retail, building materials, manufacturing, insurance and construction industries. Primarily customers using the Microsoft 365 SEGs were affected by this campaign, although other customers implementing Microsoft 365 alongside additional SEGs were also impacted. Both infection URLs in the campaign reference Microsoft 365: “micrsoft365[.]live” and “mcsoft365[.]club”. Utilizing high-profile domains like these for a single campaign suggests a strong focus on the Microsoft SEG.
Figure 1: Email body
In Figure 1, we see that the email template used in this campaign references a W9 form in the subject, but the Word document is named “invoice.” It also gives a random number in the subject as a quote number. The remainder of the message is concise and to the point, concluding with a signature related to the owner of the compromised email.
Figure 2: DOCX template
The Microsoft Word document in Figure 2 takes a different approach from what the Cofense PDC usually analyzes. Microsoft has enforced that Office macros users enable editing so, naturally, the document will have a large banner image walking the user through the steps to disable macros protection. During preview, the user will see a legitimate-looking finance agreement and not the usual templates that raise red flags. However, the “ERR121” message appended to the bottom is interesting because macros do not need to be enabled in the first place to launch CVE-2017-0199.
Figure 3: DOT template
When Microsoft Word downloads a file as an OLE object, in the case of CVE-2017-0199, it is automatically launched. The DOT template seen in Figure 3 is blank, unlike the initial DOCX file. This file does not need a template because the user does not see it, as the prior exploitation opens and closes the file. From here, the Office Macro will create a folder “\Documents\Adobe Help Center” and copy a VBS script over to it. The VBS script will then be launched using Wscript.exe.
Figure 4: Office macros
Most Office macro infections begin with the Auto_Open() function, but this sample utilizes a function that is called when the document is closed. When that occurs, it launches a WScript shell with self-contained VBS code. The document macros also create a new folder called “Adobe Help Center” and place several files in it, including the “HelpCenterUpdater.vbs”.
Figure 5: VBS code being written to file
The macro also begins copying over VBS code to a new text file. Inside this file is a function and rows of encoded values that are passed through it – which are then decoded by WScript as it’s running. Analyzing the code in memory, we immediately see the payload used to get the final executable. Next, several checks are run for analysis tools like Wireshark, Process Explorer, and TCPdump. Finally, WScript will launch the executable.
Figure 6: Payload URL
This VBS script will perform basic checks for tools such as Wireshark as well as cryptographic API files such as “cryptsp.dll” among others. This VBS will also contain the obfuscated functions responsible for continuing the next stage of the attack by reaching out to the payload. These strings can be seen in the Figure 7 reaching out to the “download4[.]club” domain.
Figure 7: VBS code
It can also be noted that these strings dictate where the new payload should be saved by creating Windows shell scripts specifying that it should be placed within the parent directory of the VBS. This results in the VBS storing the payload under the System32 directory.
Figure 8 and 9: TrickBot process in memory
After the VBS code finishes executing, the EXE file from Figure 7 is launched from /Adobe Help Center/ which then launches a new executable named Isass.exe. As seen in figures 8 and 9, this process also creates child processes to wait for a timeout before initiating the network connection. From here, the usual TrickBot routine begins, and it starts calling out to a C2 with “rob” in the URL path. In a reanalysis of this sample, a different payload was pulled that calls out to “mod2” instead.
Figure 10: Wermgr
In Figure 10 it is observed that this wermgr.exe process launches a child process called Svchost, which is a common Windows process. The Wermgr process itself contains the strings responsible for reaching out to the correct C2 locations for the various modules that will be used in the attack. For example, we see in this sample that the memory for Wermgr contains an identifying string that’s sent out to a C2 ending in the path “/mod2/[unique string]/5/pwgrabb64/”. This is likely a password grabber that will run on 64-bit machines, as supported by additional strings referencing locations in the browser for cookies and history.