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.

Behavioural Analysis 

• 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.

Figure 2 – Document_Open and main subroutines.

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. 

Figure 3 – Highlighted sections in the main subroutine which writes an embedded XSL script to a file in the user’s %TEMP% directory.

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” 

Figure 4 – Shell command in main macro, which executes an XSL file using WMIC.

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. 

Figure 5 – Contents of XSL script.

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.  

Figure 6 – Malicious indicators identified by pestudio as part of an initial assessment of awMiOFl.exe.

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. 

Figure 7 – Comparison of file sections with another Dridex sample, indicating the use of a polymorphic loader. 

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. 

Figure 8 – Frequent OutputDebugStringW API calls captured during Dridex’s unpacking routine.

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\CurrentVersion\Policies\System 
• \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. 

Figure 9 – Dridex opens and injects itself into explorer.exe using the AtomBombing code injection technique.

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:

1. The directory path of the loaded application. 
2. The current directory. 
3. The system directory. 
4. The 16-bit system directory. 
5. The Windows directory. 
6. 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. 

Figure 10 – File-write events for a malicious DLL and a Windows binary at the location %APPDATA%\RC17zE.

Figure 11 – Dumpbin output shows the dependency of EhStorAuthn.exe on UxTheme.dll.

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. 

Figure 12 – Creation of a scheduled task named Bpnayitifvdws.

Figure 13 – Execution of the scheduled task Bpnayitifvdws. 

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. 

Figure 14 – Explorer.exe drops malicious DLL and batch file in %TEMP% and then runs the batch file.

Figure 15 – X3un.cmd copies a malicious DLL and legitimate Windows binary to %APPDATA% folder in preparation for DLL hijacking.

Explorer.exe repeats this step several times to copy different malicious DLLs and legitimate Windows binaries.  

Figure 16 – Directory structure within C:\Users\%USERNAME%\AppData\Roaming. Each folder contains malicious DLL and legitimate Windows binary.

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.  

Figure 17 – Dropped DLLs are 64-bit binaries and there is no detection for any of the hashes in VirusTotal even after 15 days.

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.  

Figure 18 – Adds entry Fetkovwkmarbx to the Run key in the registry to persist after reboot and launch after user login.

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. 

Figure 19 – The suspended processes created by explorer.exe from the C:\Windows\System32 directory.

Figure 20 – Explorer.exe perform code injection on a suspended process.

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.)

Figure 21 – Demonstration of creating a directory with a trailing space using the prefix “\\?\”.

Figure 22 – Dridex abuses MS-DOS path processing via Windows API to whitelist path with 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. 

Figure 23 – Legitimate Windows binaries launched from C:\Windows\Syswow64 in suspended mode with the argument 1.

Figure 24 – Legitimate Windows binaries launched from C:\Windows\Syswow64 in suspended mode with the argument 2.

Figure 25 – Processes spawned during Dridex’s infection lifecycle.

Conclusion  

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  
• AtomBombing

Indicators of Compromise (IOCs) 

The following IOCs were collected as part of this blog post. 

The post Dridex’s Bag of Tricks: An Analysis of its Masquerading and Code Injection Techniques appeared first on Bromium.

Recent Articles By Author

• Ransomware Goes Fileless, Uses Malicious Documents and PowerShell to Encrypt Files
• Reawakening of Emotet: An Analysis of its JavaScript Downloader
• Agent Tesla: Evading EDR by Removing API Hooks

More from Ratnesh Pandey

*** This is a Security Bloggers Network syndicated blog from Bromium authored by Ratnesh Pandey. Read the original post at: https://www.bromium.com/dridex-threat-analysis-july-2019-variant/