DanaBot gets “multi-stage” packages for Christmas
The DanaBot got for Christmas something only a hacker could love – A new botnet, delivered in lots of little “multi-stage” packages, that can make time fly.
The recent DanaBot malspam campaign revealed some interesting facts about the delivery mechanisms of its banking Trojan. To avoid detection for as long as possible while they build a new botnet, the bad guys are dividing their malware delivery into a series of stages. And if one stage goes down the wrong chimney – say in the wrong country or into a security researcher’s malware analysis platform – they will speed up time to put the suspect recipient on their “No Go” list. It’s a great Bad Santa strategy.
Lots of little gifts
Breaking down the malware deployment process into a series of specially crafted stages might seem more problematic than delivering their payload in one single package. But this strategy is an effort to leave a minimal footprint on the targeted disk – especially in a special, virtual-machine sandboxed environment. Researchers – Avira included – use a variety of automated malware analysis platforms to do their initial classification of incoming samples and the bad guys know that. By encumbering researchers’ ability to obtain new and complete samples, the bad guys’ goal is to keep detection rates as low as possible for present and future versions of their work.
That first package is just for you
The first package is a spear-phishing email with an attachment that consists of a VBS script enclosed in an archive. These emails have targeted people in Poland and then Italy, Germany, Austria, France, Finland and possibly other European countries.
Beyond the localized language, each recipient receives a distinct, obfuscated variation of this script which nevertheless has the same functionality:
The second package is from the C&C server
The link to the second-stage payload, which also leverages the Visual Basic scripting language, is done by dynamically executing batches of statements received from one of the C&C servers. The attackers seem to have registered a lot of cheap domain names for this purpose with TLDs like “.club” or “.science” and opted for hosting the backend infrastructure on compromised servers and/or fraudulently purchased ones.
The second-stage delivery seems to be contingent on several variables such as the recipient’s geo-IP and an IP address range check against their list of banned IPs. Delivering If the C&C does not “like” the originating IP address, it will yield either a Sleep statement or some other garbage. The calling wrapper method is properly handling this via the “On Error Resume Next” statement):
Location matters for the third-stage package
If we are “calling” from Germany, Austria, or Italy, we also get the third-stage payload:
Execution of this payload leverages a User Account Control bypass method by tampering with the Windows registry and launching a High Integrity Level process: eventvwr.exe (which in turn tries to open evenvwr.msc by calling the ShellExecute function).
The registry write operations target the shell open command associated with the msc file type. This is supposed to be opened by mmc.exe (Microsoft Management Console). However, here the attackers switch to rundll32.exe in order to load and execute with elevated privileges the malicious payload enclosed in the dropped dll:
The first interesting fact about the dll used as the third-stage component is that the f1 function executed by rundll32.exe is missing from the PE exports directory structure:
This is later patched at runtime in the DllMain routine, in order to be found by the rundll process when calling GetProcAddress:
Decoding the Eastern connection
The first thing that f1 does is to parse the command line and to delete a specific file which can be passed as an optional argument: rundll32.exe [path to dll], f1 [path to file]
This points back to a legacy component, a PE dropper linked to an older malspam campaign allegedly targeting Ukraine. If we look at the corresponding first-stage component used back then (a JS dropper), we notice an interesting fact: it was designed to run only if the current month is September. This oddity means that it won’t infect other systems at this moment. It seems that the bad guys were experimenting this way of delivery and they apparently abandoned it.
The next step is system fingerprinting, by obtaining timestamp related info associated with the windows shell(explorer.exe) and querying a few registry values under HKLM\HARDWARE\DESCRIPTION and HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion:
– HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId
– HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate
All this information is concatenated – the character strings are joined together end to end – and a series of 3 MD5 Hashes are calculated with the CryptHashData API. The first hash is calculated based on the original concatenated string, while the others are the MD5 correspondent of the previous one. These are used as part of a custom protocol for communicating with the C&C server:
433 is the preferred Port of Call
One other interesting aspect about the communication with the C&C infrastructure is that connection attempts are made to random IP addresses on port 443. This port is regularly used by HTTP over TLS (HTTPS), but here we are dealing with a special customized communication protocol. They are likely using this port because it is not blocked by most firewall outbound connection rules.
Taking into account that a Remote Desktop Protocol plugin was added to DanaBot starting in September 2018 and that all of the successfully contacted hosts seem to be Windows hosts having this RDP port open, there is evidence to believe that a peer-to-peer botnet is taking shape. Instead of the usual set of C&C servers, it seems that the main payload and its plugins are delivered from other infected machines that are not behind a router / NAT firewall.
The bad guys can make time fly
The icing on the cake regarding the delivery mechanism is in the way it avoids deploying the payload when ran in a sandboxed environment (such as a malware analysis platform), by exploiting a component responsible for automation and behavior tracking feature called time acceleration.
It does so by first by hooking the winsock 2 API send:
The hooked send first restores the original unpatched bytes and then calls WSAIoctl with a SIO_KEEPALIVE_VALS control code.
Meanwhile, the main thread calls the original send. Anticipating that the backend will be correlated with the sleep call, the closesocket will be called earlier when in a sandboxed environment where time acceleration takes place (that is, the sleep call takes much less time). As a result, the backend will be notified with a RST TCP segment – and also have the opportunity of adding the sent hardware ID to a banned list of hardware ID’s – thereby banning the sandbox from getting any future “updates.”
Our findings show that the attackers behind DataBot are carefully building their delivery infrastructure, possibly partnering with actors from other malware families. Avira detects and blocks all components part of this distribution framework under the detection names listed in the following IOC section: