Posted: 5 Min ReadThreat Intelligence

Daxin Backdoor: In-Depth Analysis, Part Two

In the second of a two-part series of blogs, we examine the communications and networking features of Daxin.

This is the concluding part of our in-depth analysis of Backdoor. Daxin, advanced malware that is being used by a China-linked espionage group.

In this blog, we will analyze the communications and network features of the malware.

Communications protocol

In our previous blog, we set up a lab consisting of four separate networks and five machines. Some of the machines had two network interfaces to communicate with different networks, but all packet forwarding functionality was disabled. Each machine ran various network services that were reachable from its neighbors only.

Figure 1. Test setup to illustrate Daxin’s backdoor capabilities.
Figure 1. Test setup to illustrate Daxin’s backdoor capabilities.

In this section we will dissect the network traffic between two backdoor instances running on the separate computers “Alice-PC” and “Bob-PC”. The traffic was initiated by the Daxin backdoor running on “Alice-PC” when it was instructed to create a communication channel to “Dave-PC” passing via two intermediate nodes, “Bob-PC” and “Charlie-PC”, as described previously.

Figure 2. Wireshark capture of traffic between two backdoor instances. The screenshot and examples below are reused from a private report prepared by us that discussed an earlier sample, so certain details may not match.
Figure 2. Wireshark capture of traffic between two backdoor instances. The screenshot and examples below are reused from a private report prepared by us that discussed an earlier sample, so certain details may not match.

Using Wireshark, we captured traffic between two backdoor instances, one running on “Alice-PC” and the other on “Bob-PC”, as shown in Figure 2.

Starting with the key exchange, all backdoor communication is carried out by exchanging messages that follow the same underlying format:

The magic value is always 0x9910 or 0x9911.

The kind value identifies the state transition during key exchange. Then, once the encrypted communication channel is established, it encodes the purpose of each message and determines the formatting of the data that follows the fixed-size header.

The initial message of the key exchange in the Wireshark capture is not encrypted:

It can be decoded as follows:

The fields magic and kind correspond to the first three bytes of TCP data, 0x10 0x99 0x11. On the target computer, in case it is infected with a copy of the malicious driver, this sequence causes the TCP connection to be hijacked, as explained in part one of this blog series.

The target checks that the received message is valid according to the session state machine, ensuring that magic is the expected constant 0x9910 and kind matches any of two supported values: 0x10 or 0x11. Next, it generates a nonce to use when encrypting any future incoming messages. Finally, it sends a response message with the nonce, its own details, and the information about the infected machine.

Parts of the response message are encrypted using a combination of the following algorithms:

The details of this response message are as follows:

The message includes the backdoor login that is recognized during the following key exchange step, and what looks like malware build and version numbers.

Looking at the decoded message, we find references to “XRT” and these reassemble the hardcoded Name “NDISXRPT” that we documented when discussing the NdisRegisterProtocol() call during driver initialization:

The initiator responds with the backdoor login and hashed password:

Want to comment on this post?

We encourage you to share your thoughts on your favorite social platform.