Proofpoint first identified DanaBot in May of 2018. Armed with basic Trojan and info stealing functionality, DanaBot works to gather sensitive banking information from unsuspecting users for fraud and other criminal activity. Since its inception, the Trojan has worked on adding affiliates, increasing its geotargeting, and expanding its functionality through modularity. In this blog, I’m going to review DanaBot’s web injects/targeting scheme, along with its communication protocol/command and control infrastructure.
While DanaBot primarily targeted Australia in its early 2018 campaigns, it has continually expanded its targeting since then to include various new regions. Each geographical region is associated with a campaign ID within the bot, which ensures that the respective web injects/targets for the desired region are delivered post-infection. DanaBot has continued to target Australia, North America, and parts of Europe, and we are now seeing reports of new campaign IDs for new regions, such as the previously unreported ID 27 targeting Germany. The targets of campaign ID 27 and their associated inject scripts are below in Table 1.
In the following screenshot (Figure 1), you can see extracts from the injects. In some cases, DanaBot performs browser and operating system fingerprinting to ensure the victim sees the most believable fake website possible. Retrieving DanaBot’s injects offers further insight into how stolen information is transferred.
In addition to DanaBot’s continued expansion of its affiliates list and geo targeting, it has been adding further modules. Some of the other modules typically delivered with the proxy module (used for injects) include a stealer module and tor module. Additionally, while we haven’t encountered this particular module during our research, Checkpoint reports having observed and detailed a ransomware module being delivered after infections of campaign ID 7 late in April of this year.
While the loader’s communication protocol has not changed since it was last detailed in February, we will take a deeper dive into the protocol and the commands it uses. DanaBot’s loader comes with an encoded RSA public key used for encrypting communications with the command and control. Figure 5 shows an excerpt from a decompiled DanaBot loader where the key BLOB is being XOR decoded.
Finding the RSA public key buffer in any loader binary is accompanied with a one-byte XOR key. This makes decoding the public key simple using a similar IDA Python script to the one in Figure 6.
DanaBot’s loader continues to use the same RSA public key, which it shares with its control panel. The Python script above will XOR the RSA public key, which is stored as a public key blob struct. This allows the DanaBot developers to import the key as-is after it is decoded in memory.
The structs above help us understand the RSA public key BLOB struct found below.
- In red, SigAlgID and HashAlgID
- In blue, the RSA magic value, the bitlen (1024), and the public exponent
- In green, the n value associated with the RSA key
Command and Control Communications
DanaBot’s communication protocol has been well documented by researchers since the modifications it underwent earlier in 2019. Below, I’ll dissect the protocol further to extract additional information.
Although DanaBot will regularly cycle out its command and control servers, several servers seem to persist through most bot configs. The most resilient of these mainstay command and control servers are in the following VirusTotal graph (Figure 10).
Upon infection, the loader will reach out to download subsequent modules and configuration files. The initial packets sent to an alive command and control sever look like the example in Figure 11.
First Packet – Key Exchange
The first packet sent contains an RSA public key generated by the client which is subsequently AES encrypted. When running the sample locally, we can recover the AES BLOB used for (per) packet encryption and can thus retrieve the RSA public key first sent to the command and control. When reviewing the second half of a decrypted first packet we get the following AES BLOB.
At offset 0x04 the algorithm identifier (Alg ID) specified is CALG_AES_256. This is particularly interesting because DanaBot isn’t passing a key back to its command and control but, rather, is passing a key BLOB struct. When reviewing the RSA public key generated by the loader below, we see a similar BLOB structure to what we reviewed earlier.
This information leads us to believe that DanaBot’s command and control infrastructure is hosted on Windows® VPSs and the custom server application running on port 443 is making use of Windows crypt APIs. Conducting further reconnaissance on the c2s further confirms this belief.
The output in Figure 14 above is what Shodan returns when you enter one of DanaBot’s mainstay command and control IPs.
Second Packet – Hello
We know how the server application handles and serves data; coupling that with the protocol format, communications can be re-implemented to query and pull modules for different affiliate IDs. The first half of the second packet is the “hello packet”. The hello shown below consists of various fields, including bot ID, campaign ID, command ID, and various checksums/values.
The second set of communications from the loader to the server can vary, either the main module will be requested or the loader queries for a list of modules/configs.
Third Packet – Request Module List (or Main Bot not shown)
Figure 17 shows the decrypted version of the bot’s query modules/configs.
The server will return a list of modules and configuration files for the loader to download.
|Module Name||Module / Config Hash|
Fourth Packet – Request Module
Upon receiving a list of modules and configs, the bot requests what it needs to finish infecting the victim. Figure 18 shows that the second checksum value has been replaced with the hash of the requested file. That is the only major change between the structure of packets when requesting files from the command and control.
Following its recent second birthday, the financially motivated DanaBot Trojan has matured into a very profitable modular crimeware project. It continues to evolve its geo targets as more affiliates get added, and has branched out to test ransom functionality. This change in tactics certainly aligns with other shifts we’ve observed in which criminals are performing more recon upfront to profile a victim’s worth before executing ransomware from a domain controller. Threat actors are effectively reducing the quantity of attacks in favor of quality when they choose to profile their victim’s worth. Dridex/Bitpaymer and Trickbot/Ryuk have been leading the charge in these types of recon activities, and it seems like DanaBot may be catching up.
Indicators of Compromise
On Port 443:
- 1A5B955F0CF2B7874BEC596C4340B495 Tor
- B1770C73C7FCB0ACB8DD9098227431DF Stealer
- 788C5BCF2C23BF6BF78CCDBCDAD19551 Proxy
- 135C6729419CAA33C8563C2E6E21FB8F Main x86
Additional Malware Delivered