NTT has observed a TrickBot variant exclusively communicating over DNS. This variant is used in a campaign named Anchor_DNS and has been observed to be deployed on targets in the financial sector and high impact servers such as AD controllers. 

In this blog post, we will go through the workflow taken by the actors in order to reach an Anchor_DNS infection, technically analyze the sample and provide recommendations for detection.

For our prior research on TrickBot please read:

TrickBot Group workflow

The deployment workflow of Anchor_DNS begins with the typical distribution methods of TrickBot such as mail-spam and malware droppers. The TrickBot campaigns related to this activity is the commonly seen ones such as tot548, ser501 etc. When an infection has taken place, the actors attempt to move laterally in the network using TrickBot's automated spreading modules or via manual actions.

Our theory is that the actor investigates the newly infected victims and classifies their importance, and if the victim is of high importance the TrickBot operator might decide to migrate this victim to the Anchor_DNS campaign.

If deemed not interesting, the main working group’s standard operating procedure will take place which typically includes activities such as password stealing, bank session hijacking, ransomware, encryption etc.

Tactics behind the actors of Anchor_DNS

The insight into the actors behind Anchor_DNS TTP’s is limited due to the small subset of victims compared to normal TrickBot infections; certain activity has however been observed by NTT.

The actor has deployed remote administration tools such as Metasploit Meterpreter and through them deployed selected malware. The malware type depends on the target but, from what we have seen, ransomware and POS-oriented ones are prevalent.

Based on the above, our theory is that the deployment of tools from the Anchor_DNS C2 is, at least partially, on-request by premium customers of the TrickBot group. We have previously described this type of premium customer relationship in a previous blog post on TrickBot.

Technical analysis 

The following analysis is based on the Virustotal submitted Anchor_DNS TrickBot sample f7278cd22070f0418ac75b599b8bcc524ee9d6adbda4103d149c9484cdaeb4f3 which has submission countries Arab Emirates and Germany: 

Submission countries for an in the wild URL for the executable also has South Korea as submitter: 

Both the KR and the AE submitters occur in the Hacking team database leak released by Wikileaks [2][3] indicating either that the submitters have experienced previous intrusions or that they are part of a widespread products automated Virustotal submissions.


Upon execution, the malware will perform a few steps in order to ensure persistence.

First, the malware copies itself to the first allowed location of:

  • C:\Windows\SysWOW64\
  • C:\Windows\
  • C:\Users\<username>\AppData\Roaming\

The destination filename is each time randomly generated. Examples are:

  • gsmpgyda.exe
  • pwpowcrn.exe
  • mntsbdyh.exe

Once copied, the file at the original path is deleted.

The newly created file is executed with the -i flag which initiates the setup of a scheduled task named "WinRAR autoupdate#83029" which executes the dropped sample with parameter –every fifteenth minute.

The –option will perform standard communication with the C2 server using subdomain names to send data and resolved IPs as receival of data.

Data streams

Anchor_DNS stores key strings for the malware base64 encoded as data streams written to the malware file.

Those are:

  • $FILE: C:\Windows\SysWOW64\mntsbdyh.exe (malware-location)
  • $GUID:  /anchor_dns/DESKTOP-C7FF9D5_W629200.03FCAA33763A8FE5CF0BF6FD99F5D2C/
  • $TASK: WinRAR autoupdate#83029

The $GUID data will be used during the connection towards the C2 server, $TASK is as previously mentioned the task name used for the scheduled task and $FILE is the current location of the malware.

Communication over DNS

C2 communication is performed over DNS which has previously not been seen by TrickBot.

The malware has three communication types, and each are assigned a number:

  • Type 0 (Send data)
  • Type 1 (Prepare for receival of data)
  • Type 2 (Receive data)

Communication base structure

The client sends data using subdomains while the server responds with resolved IPs as response. Subdomains are XOR encoded, observed key is 0xb9:

The three phases of communication all follow a basic structure which consists of the message type and a 16-byte generated UUID:

The generated UUID is unique for each lookup and most likely used only to make sure that messages are only handled once.

In the following three sections, we will discuss the structure and function of each message type.

Sending of data (type 0):

Message type 0 is the sending of data which is structured as follows:

As can be seen, the structure is fairly similar to the URI structure of the normal TrickBot variant which communicates over HTTP, example from Malware Traffic analysis [1]:

Prepare for receival of data (type 1):

The message type 1 is used in connection of message type 2 in order to receive data:

Receive data (type 2):

Message type 2 which is the receival of data looks as follows:

The C2 sends its data through the resolved IP addresses which can be visualized as follows:

The type 2 message will loop over until all data is received and action will be taken.Then it will start over with a type 0 message.

The documentation of this protocol is not complete, and we encourage fellow researchers to analyze it in detail.

Why communicate over DNS?

It is questionable why one would want to have C2 traffic over DNS when the organization already is successfully infected with the regular TrickBot variant. From the attacker's point of view, we see the following potential motivations:

  • Separate C2 infrastructure. If clean-up of the network is made with the help of network forensics, it’s possible that this previously undocumented variant remains undetected.
  • DNS monitoring is lacking in certain organizations
  • Important systems such as AD controllers are often expected to perform DNS requests but not HTTP(S) traffic to unknown destinations.

Has my organization been infected?

Besides having an effective security posture, monitoring for any of the following may help uncover an Anchor_DNS infection:

  • DNS lookups containing the string “anchor_dns” XOR encoded
  • DNS anomalies
  • Endpoint monitoring of among other things, scheduled tasks


At NTT, we are continuously monitoring the actions of the TrickBot authors and their innovations to stay hidden while infecting victims all around the world. This new TrickBot variant has been publicly unknown until now and we hope with this documentation to encourage researchers to further investigate and document its behavior and that potentially targeted organizations will keep this research in mind.

We help our customers detect, prevent and remediate TrickBot infections via NTT's threat detection services delivered from multiple 24/7 SOCs around the world.