Paste your Google Webmaster Tools verification code here
Select Page

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.

TargetInject File
Table 1: Campaign 27 targeting list

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.

Figure 1: Injects send function
Figure 2: ContentGrabber/tform construction and submission
Figure 3: Example of a targeted web page

Looking at Figure 3, it’s easy to see how a victim would have trouble discerning any differences between their actual banking page and one with injected JavaScript designed to steal their credentials. DanaBot has always used, and continues to use, Zeus-style web injects.

Figure 4: Continued use of Zeus-style web injects

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.

DanaBot’s Loader

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.

Figure 5: RSA public key 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.

Figure 6: IDA Python script used to decode RSA public key

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.

Figure 7: Public Key BLOB struct
Figure 8: RSAPUBKEY struct

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
Figure 9: DanaBot’s Hardcoded RSA Public Key BLOB struct

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).

Figure 10: VirusTotal Graph of the Resilient Command and Control Servers,,,

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.

Figure 11: Initial packets sent by DanaBot’s loader component

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.

Figure 12: 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.

Figure 13: Decrypted RSA public key generated by the loader

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.

Figure 14: Shodan output of a DanaBot command and control server

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.

Figure 15: Decrypted Hello packet

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.

Figure 16: Second set of communications Get Module List

Third Packet – Request Module List (or Main Bot not shown)

Figure 17 shows the decrypted version of the bot’s query modules/configs.

Figure 17: Decrypted get module list request

The server will return a list of modules and configuration files for the loader to download.

Module NameModule / Config Hash
Table 2: Common modules/hashes

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.

Figure 18: Module/config request


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.

Binary Artifacts

  • E:\Merzadenio\Sniffer\ics\OverbyteIcsMsSslUtils.pas
  • E:\Merzadenio\Sniffer\ics\OverbyteIcsWndControl.pas
  • E:\Merzadenio\Sniffer\ics\OverbyteIcsWSocket.pas
  • E:\Merzadenio\Sniffer\UProxyServer.pas
  • E:\Merzadenio\Units\System.Zip.LZMA.pas
  • E:\Merzadenio\Builds\Admin\32x\MRTTest\Morff\source\dcu32\closely4.dpr
  • E:\Merzadenio\Builds\Admin\32x\MRTTest\Morff\source\dcu32\disappointed5.dpr
  • E:\Merzadenio\Builds\Admin\32x\MRTTest\Morff\source\dcu32\tight2.dpr
  • E:\Merzadenio\Builds\Admin\32x\MRTTest\Morff\source\dcu64\cheek5.dpr

Indicators of Compromise

On Port 443:


Loader Hashes

  • 5247ad7451535c65d813ed0d1e656053  
  • f27196dee345b7732a7a33a142a415b4  
  • cdbbcd6e5eccbdbb64d850e866a6ba16  
  • 22bc9aabe9d3098ca7145c48ea0fd371  
  • 73844313919b13cb0ba17ebe2e0834cf  
  • f9caeb90ef5946a213d502d69bca4ec8  
  • bf8cfc89780334ad41b50bf3a9037d82  
  • 4a32f0cbf507752f7223d97825dcf754  
  • fd4a89ee95ab9ee46f3b8de83446427d  
  • dda85c4ce007b8cf5221b786ccc285df  
  • e02bb3ceaa8d2644c70d91475de56364  
  • e9d33632290f70376850007e88226193  
  • 46f5822a1f8dc0e35e23bd90b47d67f5  
  • 2e929e31926269399076f3d6c6c23bb2  
  • e78fb907fd7bde700dce329084933c6d  
  • 1597976c1a00801840631a8445a3dad5  
  • 5604577844fb0d475618cc414a52c3e5  
  • 1ff8be8d2e341118d2645c5a39178035  
  • 58dbc58e7ce40cfdc742f6b5be9715a1  
  • 49fb9da8eaf87b7b2eb88fee4f051bdb  
  • 90f4cb97a196f3e7522bfcc66bc07a7c  
  • f4fbba4f3b52a8d43c766bcf3806b9eb  
  • aa69370b6fb8e45cb739bf1b0fc27a55  
  • 64a7cce31c258f464cd2b564f8bd0331
  • 287803a5b3689c1646d120dc350b3cd6  
  • 7e5f61f00dea0c1e03b0feb7b2005c45  
  • afba059ebd08c7026d781f09a35a7c98  
  • 78e300466035fc04d49f4abc73646fbd
  • d6be7424340671bdd7cbb1413272412a
  • c02bcd6452443d8d523c21fd3eaa8ff3
  • 6def80e82b2b2675b379f0b68fe39f80
  • 66fbc6206efabb1431f675748fd43ae5  
  • da0ed5b73e120253e18b80f1fc03b889  
  • 84888a4f792fd81b2f085f8f94b60a29  
  • 09d13e0ecf89b72cdd121822fb611a5b  
  • 070ba4b6493753f06ba8fbc871491865  
  • 6f4057989d68a5295a7c2818bc381ff1  

Module Hashes

  • 1A5B955F0CF2B7874BEC596C4340B495 Tor
  • B1770C73C7FCB0ACB8DD9098227431DF Stealer
  • 788C5BCF2C23BF6BF78CCDBCDAD19551 Proxy
  • 135C6729419CAA33C8563C2E6E21FB8F Main x86

Additional Malware Delivered

  • 55389ec0683ee7e7f49f39975e585313
  • f40f4338cf5cf6e71fbb54a6583d5e23