Dridex’s Bag of Tricks: An Analysis of its Masquerading and Code Injection Techniques
- A new variant of Dridex observed in July 2019 masquerades as legitimate Windows system processes to avoid detection.
- The variant uses five code injection techniques during its infection lifecycle: AtomBombing, DLL order hijacking, process hollowing, PE injection and thread execution hijacking.
- The code injection techniques were used against legitimate Windows executables. An incremental integer value is supplied to the command line to the suspended process to perform specific tasks.
Since the lull in Emotet activity at the beginning of June 2019 and AZORult, Dridex and ransomware campaigns have become more prominent. In July 2019 we observed a phishing campaign delivering the Dridex banking Trojan. The payload was isolated by Bromium Secure Platform and captured the malware, which helped us to analyse its infection chain and to understand how the attack worked. In this blog post, we go through the stages of its infection chain to showcase how Dridex uses five code injection techniques to masquerade itself as legitimate Windows processes (MITRE ATT&CK technique T1036) to avoid detection.
Before jumping into the behavioural analysis, we will first demonstrate the execution of this latest Dridex sample within a micro-VM and how Bromium safeguards the end user by isolating the attack and maintaining the integrity of the system.
Dridex’s Encounter with Bromium
Here’s what the video shows:
- Bromium Secure Platform opens each document in separate micro-VM.
- Bromium Live View shows a list of active micro-VMs.
- We can see in Live View that the invoice.doc file is opened in a micro-VM.
- When the file is closed, the micro-VM is destroyed, along with any malware.
- Forensic evidence is captured from the threat, including any behaviour mapped to the MITRE ATT&CK framework.
- A detailed view of high severity alerts raised during the lifetime of the micro-VM helps security teams to investigate the actions of the malware so that the motivations of the attacker can be understood.
Please note that the video does not feature audio.
- Filename: Invoice.doc
- Size: 75.5 KB (77312 bytes)
- MD5: 0fe77bc5e76660ad45379204aa4d013c
- SHA1: c338882c64eb012855096e73edfec3c733ea9053
- SHA256: 72da2959520e824a617a5a174b1bc1a8bd6d83daf83eabb5937640f1efa37bcd
Figure 1 – Dridex infection lifecycle observed in July 2019.
Stage 1 – Downloader
The Dridex downloader arrived as a Microsoft Word 97-2003 document (.DOC) that was encrypted with the password 123. It contained two Visual Basic for Applications (VBA) macro subroutines, Document_Open and main. To view the content of the macro code, you can open it in Microsoft Word’s VBA Editor within Bromium Secure View.
Although both subroutines were mildly obfuscated, numerous strings revealing how the downloader works were identifiable without debugging the code. One can see on the left side of figure 3 that the macro project contains a user form named a0woxm. Inside the form there an embedded text property contains an Extensible Stylesheet Language (XSL) script. The main subroutine creates an object called aXtIkN from the form and assigns its text property to the string variable aHwPzG. Later, it passes aHwPzG along with the variable agvpx to the method adWspA8. String variable agvpx contains the path of the XSL file (C:\\Windows\\Temp\\aXwZvnt48.xsl). Method adWspA8 creates a TextStream object from Scripting.FileSystemObject and calls the CreateTextFile method to write data from aHwPzG to the file aXwZvnt48.xsl.
To evade static detection, the subroutines contained reversed strings that reference Windows Management Instrumentation Command line (WMIC) commands. The StrReverse function is used to reverse these strings during the macro’s execution. The variable a5rk9 contains the value “wmic os get /format:” which is combined with the variable agvpx to build the shell command:
- wmic os get /format:”C:\\Windows\\Temp\\aXwZvnt48.xsl”
XSL is a language similar in function to CSS that is used for expressing how XML documents are formatted. Crucially, it supports scripting languages including JScript and VBScript, allowing an attacker to use the language to execute malicious code. Typically, XSL scripts are run using Windows Script Host, but they can also be executed using WMIC.
Here the downloader uses WMIC to execute an XSL script containing JScript that downloads the Dridex payload. This technique falls within Microsoft’s taxonomy of fileless threats as a Type III attack and showcases MITRE ATT&CK technique T1120. WMIC can process and execute locally and remotely hosted XSL scripts in memory, a technique commonly known as SquiblyTwo. Using WMIC, attackers can execute JScript embedded inside an XSL file, even if Windows Script Host is disabled on the system.
The XSL script contains two functions. Function aawg1 creates an XMLHTTP object to send a HTTP GET request to download the Dridex executable from the URL hxxps://carmelavalles[.]com/site/wp-admin/chrome.bin. It then creates an ActiveX stream object (ADODB.Stream) and sets the buffer to the response body received from the earlier HTTP request. Next, it retrieves the method name SaveToFile from function axas5v9 by specifying the fifth element in the array. Afterwards, it calls the SaveToFile method, specifying the filename as “c:\windows\temp\awMiOFl[.]exe” and option 2 (adSaveCreateOverWrite). This option means that the stream object will overwrite the destination file if a file with the same name already exists. After saving the file on disk, the XSL script deletes itself.
A quick analysis of dropped payload in pestudio shows indicators that it is malicious including the use of blacklisted sections names .rdata3, .qdata, aei, and CODE2.
We then compared it against another dropped Dridex payload and found that both have the same numbers of sections. Except for the .text section, all sections have the same raw file size. This indicates the possibility that a polymorphic loader is used to deliver Dridex.
The dropped payload awMiofl.exe, on execution, unpacks itself in memory and enters a loop for almost nine minutes. In each loop, a call to OutputDebugStringW is made with the string “Installing…” or “Installed” followed by a call to the Sleep function for 10 milliseconds.
After exiting the loop, the following registry keys are enumerated to collect basic information about the system, including the CurrentBuild, CurrentVersion, InstallTime and InstallDate.
- \Registry\Machine\Software\Microsoft \Windows NT\CurrentVersion
Stage 2 – Process Injection using AtomBombing
Next, awMiofl.exe opens and injects code into explorer.exe using a technique discovered by enSilo in 2016 called AtomBombing. It works by exploiting Windows global atom tables and Async Procedure Calls (APCs) to inject code into a remote process.
Afterwards, awMiofl.exe iterates through the C:\Windows\System32 directory and calls the FindFirstFileA API with the filename C:\Windows\System32\*.exe. The filename includes a wildcard to match against all .exe files within the System32 directory. For each match, it opens the file and reads its dependent dynamic-link libraries (DLLs). If it matches against a list of DLLs then it spawns a process in suspended mode and terminates. We suspect that Dridex does this in preparation for a type of code injection, but in the sample we analysed Dridex terminated the processes.
Stage 3 – DLL Hijacking
After that, it creates a randomly-named directory at location %APPDATA%. Once the directory is created, it copies to the folder the legitimate system executable from C:\Windows\System32 and a malicious 64-bit DLL that matches executable’s library dependency in its Import Address Table (IAT). A popular DLL hijacking technique is to abuse Window’s load order of DLLs. By default, the DLL load order looks for the required DLL in the order of the directories listed below if SafeDllSearchMode is disabled:
- The directory path of the loaded application.
- The current directory.
- The system directory.
- The 16-bit system directory.
- The Windows directory.
- The directories that are listed in the PATH environment variable.
Since awMiofl.exe copies a malicious DLL to the same directory as the legitimate executable, when executable is run, it will load the malicious DLL in the Roaming folder instead of the legitimate one from System32.
Stage 4 – Persistence using Scheduled Tasks
Afterwards, awMiofl.exe achieves persistence by creating a scheduled task called Bpnayitifvdws which is configured to run C:\Users\[Redacted]\AppData\Roaming\RC17zE\EhStorAuthn.exe every hour.
Stage 5 – More DLL Hijacking
Explorer.exe creates a batch file x3un.cmd in the user’s %TEMP% directory and drops a malicious DLL NqE850.tmp. It then launches cmd.exe and runs x3un.cmd. X3un.cmd contains the command to copy dropped DLL file NqE850.tmp and a legitimate Windows binary systemreset.exe from the System32 directory to the newly created directory in the user’s Roaming folder, C:\Users\[Redacted]\AppData\Roaming\0l78l.
Explorer.exe repeats this step several times to copy different malicious DLLs and legitimate Windows binaries.
Using DLL hijacking, malware can fool antivirus and endpoint, detection and response tools because the process launched is signed by Microsoft. We checked VirusTotal and none of these dropped DLLs were known by hash due to their polymorphism. If an antivirus scan during DLL load turns out clean, AV will not flag it, until it scans process memory.
Explorer.exe creates a registry key called Fetkovwkmarbx under the Run key with the value C:\Users\[Redacted]\AppData\Roaming\0l78l\systemreset.exe. This means Dridex is launched each time Windows starts, allowing the malware to persist after a reboot.
Stage 6 – Creation of Suspended Processes
Explorer.exe spawns several legitimate Windows binaries from the C:\Windows\System32\ directory in suspended mode to perform remote process code injection and process hollowing.
Folder Name Masquerading
Dridex attempts to evade application whitelists by creating a directory with a trailing whitespace (“C:\Windows ”). This technique abuses the way Windows APIs process MS-DOS style paths with trailing whitespaces. When processing a MS-DOS style path, Windows APIs call a helper function called RtlGetFullPathName_U that removes any trailing whitespaces from the path.
Explorer.exe creates a directory “C:\Windows \System32” and copies the legitimate whoami.exe program from the real System32 directory along with a malicious DLL called Version.dll. It then launches it with the command line:
- “C:\Windows \system32\whoami.exe” 1188 21993FF418 1
You can try this yourself by running the commands below in Command Prompt, which will create a Windows directory in C:\ but with a trailing space:
- md “\\?\C:\Windows ”
- rd /s /q “\\?\C:\Windows ” (Note the trailing whitespace.)
If Dridex is left running on the system it eventually launches processes from C:\Windows\SysWOW64 in suspended mode, which it uses to inject code into. The argument passed to the process increments by one, indicating it to perform specific tasks. It also modifies and triggers scheduled task Bpnayitifvdws with a new binary path after regular intervals.
Based on the events captured from micro-VM, we can see that Dridex performs at least five different types of code injection:
- DLL order hijacking
- Process hollowing
- PE injection
- Thread execution hijacking
Indicators of Compromise (IOCs)
The following IOCs were collected as part of this blog post.
|SHA256(invoice.doc [Document-Word.Trojan.Encdoc] )||72da2959520e824a617a5a174b1bc1a8bd6d83daf83eabb5937640f1efa37bcd|
|SHA256( F43A883A.doc [Document-Word.Trojan.Encdoc])||72da2959520e824a617a5a174b1bc1a8bd6d83daf83eabb5937640f1efa37bcd|
|SHA256( awMiOFl.exe [Win32.Trojan.Cridex])||c690c1e72bfe665f364cbb61c363f291f725b469e55a4c0a703cd729a5e29009|
|SHA256( FireFox.exe [Win32.Trojan.Kryptik])||08a00c9be7dd2e64e9b0f6ea85f159275c913faf0aad51884a1eeab3822af246|