Blog Dridex’s Bag of Tricks: An Analysis of its Masquerading and Code Injection Techniques

Technical Blog

July 29, 2019 Category: Threat Research By: Ratnesh Pandey Comments: 0

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 AZORultDridex 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 enuser 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.

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.

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.

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 codeTypically, XSL scripts are run using Windows Script Host, but they can also be executed using WMIC. 

Here the downloader useWMIC 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 file with the same name already exists. After saving the file on disk, the XSL script deletes itself. 

Figure 5 - Contents of XSL script.

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.qdataaeiand CODE2.  

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

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

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.

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.

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 list of DLLs then it spawns process in suspended mode and terminatesWe 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 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 DLLsBy 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 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.

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.

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 %TEMPdirectory and drops 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 legitimate Windows binary systemreset.exe from the System32 directory to the newly created directory in the user’s Roaming folderC:\Users\[Redacted]\AppData\Roaming\0l78l. 

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

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.

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.

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.

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.

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

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

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

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. 

SHA256(invoice.doc [Document-Word.Trojan.Encdoc] ) 72da2959520e824a617a5a174b1bc1a8bd6d83daf83eabb5937640f1efa37bcd 
SHA256( F43A883A.doc [Document-Word.Trojan.Encdoc]) 72da2959520e824a617a5a174b1bc1a8bd6d83daf83eabb5937640f1efa37bcd 
SHA256(aXwZvnt48.xsl [Script-JS.Downloader.Dwb]) 6937b640269ab85594954e029f289a6bdee8b7fc2bee6177098efcb5eca7b40f 
SHA256(chrome[1].bin[Win32.Trojan.Cridex]) c690c1e72bfe665f364cbb61c363f291f725b469e55a4c0a703cd729a5e29009 
SHA256( awMiOFl.exe [Win32.Trojan.Cridex]) c690c1e72bfe665f364cbb61c363f291f725b469e55a4c0a703cd729a5e29009 
SHA256( FireFox.exe [Win32.Trojan.Kryptik]) 08a00c9be7dd2e64e9b0f6ea85f159275c913faf0aad51884a1eeab3822af246 
SHA256(credui.dll) 085ccc35f1a58e74789a24286d6827914b1887f32abed20a5fa4762a83b18c39 
SHA256(UxTheme.dll) ead2d523c00beecc598b496c300fb5aa36424b1fe141c629208bd945bf3b7590 
SHA256(VERSION.dll) 8c21e72971b9233d368694697e83d89950b4a63eadb1d76132814caf46f455da 
SHA256(VERSION.dll) 9edee5db42c9e5e717484ae8e2fb7518dfdbc171ba10c4e71a2c39efda91dc66 
SHA256(XmlLite.dll) 7a15c298817cd26c2078ae3fcec917970fc32d476d07ebc6ef16afd8018895ae 
SHA256(DUI70.dll) 880de8b32751c4cc1cd203f40d1019e363095c476003677907dfcd7f62d1b8ef 

 

About the Author

Ratnesh Pandey

Ratnesh Pandey

Recent Techinical Blog Posts

Categories
2019-07-31T07:05:31-07:00July 29th, 2019|Threat Research|

Leave A Comment

See Bromium in Action

Request a demo and see how Bromium isolation will put an end to malware and attacks once and for all.

Request a Demo
Share
Tweet
Share

By continuing to use the site, you agree to the use of cookies. More information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close