“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.
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.
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
Code 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
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.
The following figure shows the 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.
- 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.
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
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.
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.
To collect the above information, it walks through the following registries in the system.
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.
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.
At this point, the malware is about to download the DLL which is implemented for stealing the victim’s login credentials.
- 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.
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
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.
Subject Matter Expert
– Swapnil Patil, Threat Research & Response Team, Quick Heal