Report: The Dridex Trojan is Back

“Dridex”, also known as ‘Buget’, is the successor of “Cridex”, a banking Trojan created for stealing victim credentials. After its takedown by the US Government in late 2015, the malware has come up with new versions and techniques. This report aims to provide detailed insights into the infection vector of Dridex, its behavior, work flow and the precautions users must exercise against this malware.

Infection Vector

Dridex infiltrates the victim’s machine via spam emails containing malicious attachments. The attachment is a macro-based .doc or .xls file. As the victim opens the attached file, the embedded macro downloads the next payload without the user’s consent. As Microsoft has disabled macros from Office 2007, the malware provides guidelines to enable the same. Also, the same family uses known vulnerabilities in MS Office like CVE-2012-0158 to spread the infection.

Figure 01 – Spam email with malicious attachment

Structure of the Macro

Malware authors have been increasingly making using of macro to propagate malware due to its high rate of success. Macro used for this purpose are highly obfuscated to evade AV detection and to make its analysis difficult. The images below show some of the obfuscation techniques used by malware.

Code Obfuscation Technique 1

Figure 02 – Obfuscation technique 1 – Uses decimals instead of characters

Code Obfuscation Technique 2

  Figure 03 – Obfuscation technique 2

In this technique, the malware stores the encrypted bytes in an array which is passed to the custom decryption routine. It uses different seed values to decrypt these bytes. After this decryption, it comes with a URL which points to the next downloadable payload of the infection chain.

Format of the URL

Figure 04 – Downloadable URL

Figure 05 – Request header

Once the connection is established, it downloads the file into %temp%/. The file name is present in the macro itself. The downloaded file is the dropper of Dridex.

Hosting Dridex

The following figure shows the Dridex-hosting countries.

Figure 06 – Dridex hosting countries

Workflow of Dridex

Malware authors of Dridex regularly update the internals to evade AV detection and keep the infection persistent. The following figure shows the workflow of Dridex.

Figure 07 – Worklow of Dridex

• Downloaded binary is the dropper of Dridex which is just an obfuscated wrapper. It uses custom logic to decrypt the downloader of Dridex. After decryption, the result is a RtlCompressed downloader binary.
• This downloader contains an encrypted form of information required for C2 communication in last section, which is decrypted using hard-coded DWORD key with XOR operation and then uncompressed with APLib.
• We observed some changes in the configuration files it uses. Figure 08 shows the structure of the configuration file present with old files of Dridex.
• In the new version of the malware this information is stored in .data section in hex format. The malware converts it into decimal value when decrypting it. Figure 09 shows the structure of the new configuration file.

Figure 08 – Configuration file in old version

Figure 09 – Configuration file in new version

Some observed BOT IDs: 120, 122, 200, 220, 222, 301

Looking at the above configuration file, it is clear that the malware uses a non-standard port to communicate. The malware tries to connect these servers and once the connection is established, it uses POST request for further communication with bot server.

Non-standard port: 243, 343, 448, 543, 643, 666, 843, 1143, 1443, 1743, 2443, 2448, 3448, 4143, 4433, 4438, 4443, 4483, 4493, 4538, 5445, 6446, 7443, 7447, 8143, 8443, 8843, 9943

Dissecting Dridex

Let us now take a look at the internal fragments of binary. As discussed earlier, the last section of the file contains an encrypted configuration file. The malware also used the encryption to get the required DLL and API names. The .rdata section contains this encrypted data. Operation to be performed is XOR on QWORD data. Let’s have a look at the structure of .rdata section.

Figure 10 – Encrypted data structure

Once the required DLL’s are loaded in memory, it collects all the information about the victim’s machine like user account name, operating system, and installed software in the following format.

<get_module_Unique=”acc_name-952?840B?_f4bd870915d84616b34abc222bc41032″botnet=”220″system=”23128″name=”bot” bit=”32″/>

To collect the above information, it walks through the following registries in the system.

HKEY_CURRENT_USERVolatile Environment
HKEY_LOCAL_MACHINESoftwareMicrosoftCryptographyMachineGuid
HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionInstallDate
HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionCurrentVersion

The bot sends this information to the servers listed in the configuration file. Before sending this information, it encrypts it with a custom encryption routine.

Figure 11 – Encryption routine

Figure 12 – Data sent to C2 server

The above image shows the data transferred to C&C server for further processing. It sends this data, until POST operation succeeds and if the server doesn’t respond, then it tries the next one in the loop. Once the connection takes place, C2 server responds with a few SSL certificates. The following image shows a few SSL communications.

Figure 13 – SSL communication

Figure 14 – Some SSL certificates

At this point, the malware is about to download the DLL which is implemented for stealing the victim’s login credentials.

Stealing Mechanism

• Earlier version of Dridex used the browser hooking technique while the current version is using a redirection scheme – used earlier by another banking Trojan known as Dyre.
• While Dyre uses a proxy connection to redirect the user to a malicious server on which the malicious page is being hosted, Dridex malware uses the DNS poisoning mechanism to accomplish the same feat.
• It poisons the DNS cache and whenever the victim connects with the specified financial target site, the malware redirects them to a malicious server controlled by the malware author.

Figure 15

Anti Automation Tricks

Dridex malware hibernates in-between its execution in order to evade automation tools which monitor malware behavior for specific periods. After every request to HttpSendRequestW() the malware goes into sleep mode for a long time.

Dridex C&C Distribution

Figure 16

Prevention Against Dridex

• As Microsoft has disabled auto execution of the macros in .doc files from 2007 it is important that you do not enable these macros unless you know them to be trustworthy.
• Your MS Office should be updated with the latest security patches to avoid exploitation of any vulnerability.
• Your security software should always be up-to-date.

ACKNOWLEDGMENT

Subject Matter Expert

– Swapnil Patil, Threat Research & Response Team, Quick Heal

Rahul Thadani