The infamous Dridex banking Trojan has adopted new tactics and more advanced encryption and obfuscation to better avoid detection and to hinder security analysis, researchers warn.
The malware’s operators have recently started using malicious RTF (Word Document) files that are password protected, with the password included in the email. According to MalwareTech, this approach prevents most automated systems from extracting and scanning the attachment for malicious code, because they don’t handle password extraction or document decryption.
The security researcher notes that the spam message managed to pass the spam filter and says that the malicious document attached to it has been given a new look and padded with 1 px white and light grey text, which would foil attempts to block the document by hash. The attackers also employ delayed execution, and the researcher notes that they might be focusing on the infection of corporate systems with more advanced threat protection rather than home users.
Dridex comes in packed form and the binary is encrypted, but IBM X-Force researcher Magal Baz says that it’s actually fairly easy to unpack the code and have a look at it. However, Baz also notes that important aspects of the code such as API calls and string constants are more heavily obfuscated and that Dridex recently changed the API and strings obfuscation methods.
Older Dridex code revealed obfuscated API calls and API resolvers as authors attempted to hide the function of specific lines of code from security researchers. The names of API functions were kept encrypted, but the resolver was designed to decrypt and return the right function according to a received index.
Now, instead of an index, the API-resolving function receives two DWORDs that stand for Kernel32!SetThreadPriority. The analysis revealed an import table that stored information about API functions already called (so that they won’t be called again), which is custom-made by Dridex’s developers, designed so that another internal function would be called if the search for an API function called for the first time (hence not included in the table) fails.
When looking at the code designed to resolve a string constant, IBM’s researchers observed that it receives three parameters: an integer, an offset in the binary’s .rdata section where an encrypted blob is stored, and an output address. The encrypted blob, they explain, is decrypted in a sequence of three loops, which reveals that Dridex leverages the RC4 stream cipher to encrypt strings.
“The decrypted data is a sequence of null terminated strings. The index that was given as an argument to the resolver is the index of the desired string in the sequence,” the researcher explains. Previously, Dridex used a XOR method to protect secrets, but it appears that its developers have decided to adopt more advanced encryption.
“Why change? Dridex is a constantly evolving project. As such, it moves forward with the times. Does this make the code more evasive and tougher to research? Perhaps temporarily — only until one figures out how the new protections work,” IBM’s researcher notes. Because the RC4 key is stored adjacent to the encrypted data, decryption is not an issue, the researcher concludes.
Mainly distributed by the Necurs botnet, Dridex has been mostly inactive over the past few months and even came to a near stop in June, when the botnet was taken offline for a few weeks. Although Necurs came back online at the end of June, Dridex remained under the radar as its operators focused more on the distribution of the Locky ransomware.
