Daxin Backdoor: In-Depth Analysis, Part Two

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.

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.

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:

It also includes its own nonce, like this:

At this point, the peers exchange their nonces and compute two transport keys. Each transport key is used in stream mode to encrypt the TCP half-stream directed towards the side that generated the corresponding nonce.

The peers also combined their nonces into the shared key. This shared key will be used to encrypt the body of each exchanged message, reusing the same key every time.

The final key exchange message confirms that the initiator was successfully authenticated and the backdoor is ready to process instructions:

It can be decoded as follows:

For the messages that follow, the kind field encodes the message purpose. This determines the formatting of the message body. For example, the backdoor instruction to set up new connectivity across multiple malicious nodes uses kind value 6 with the following message body structure:

We could continue to decrypt all the backdoor communication that follows:

For example, the next message in the captured network traffic is:

This instructs the backdoor to set up remaining connectivity across malicious nodes as explained in the “Backdoor capabilities” section in our previous blog:

The most interesting observation about encryption is that Daxin supports two methods for computing the shared key during the key exchange. To select which of the two methods to use, the initiator examines the target message, comparing what looks like build and version numbers against certain hardcoded constants. This could be in order to facilitate upgrading the malicious network in the field without disruption.

Additionally, the current key exchange implementation involves additional obfuscation that is not present in some older samples. It is possible that the attacker was forced to change the algorithm and decided to implement additional measures to protect the details of new logic.

An alternative explanation is that different teams within the attacker organization were sharing the same codebase, where one of these teams implemented the alternative key exchange method and related obfuscations to mitigate against potential compromise due to the other team’s activity, while still sharing some of the communication infrastructure.

External communication

The communications protocol documented in the previous section is how two backdoor instances communicate with each other.

On top of that, the analyzed sample also supports two additional communication methods. These additional methods are well suited for crossing the perimeter of the target organization.

HTTP

One of these additional communication methods uses HTTP messages to encapsulate backdoor communications.

To demonstrate this, we implemented our own client to interact with the backdoor using this method. Our client communicated with the backdoor instance running on “Alice-PC” over HTTP to control a set of infected machines, as discussed in the previous two sections.

On the target computer, in case it is infected with a copy of Daxin, the first HTTP request causes the TCP connection to be hijacked due to the malicious packet filter triggering on the HTTP “POST” method string with URI substring “756981520337” as explained in the “Networking” section of our previous blog.

Daxin then parses HTTP request headers and extracts the request body. The request body is then interpreted using the same logic as already described in the “Communications protocol” section.

The reverse communication is then encapsulated as the HTTP response body. When generating the HTTP response, the malicious driver includes “SID” cookie. The value of “SID” cookie is then used when constructing the URI for the subsequent HTTP request.

“HOST” connectivity

The malicious driver can also be configured to communicate with a remote TCP server for command and control. It then periodically connects to the remote server, performs a handshake that is unique to this connectivity method, and then starts backdoor communication.

This connectivity method is controlled with persistent configuration that can be updated by the remote attacker, as explained in the “Backdoor capabilities” section of our previous blog.

To obtain the details of the TCP server to connect to, Daxin checks the value of the “HOST” configuration item. In case the value starts with “http://”, the TCP server details are retrieved from the remote web server, as described below. Otherwise, the configuration value is interpreted as the TCP server address and port.

In order to retrieve the TCP server details from the remote web server, the analyzed sample contacts the provided URL and scans the received HTTP response, including HTTP headers, for magic strings. Whenever it finds “f8xD4C01” followed later by “d7C6x12B”, it attempts to interpret any data immediately following the first marker as a hexadecimal string. The data obtained by decoding the hexadecimal string is then decrypted using the following algorithm:

The decrypted data are interpreted as the TCP server address and port to use.

Whenever the analyzed sample connects to the TCP server, it sends the following sequence of bytes as its handshake:

The tags_value parameter is the value of the “TAGS” configuration item. We suspect that the remote server uses the tags_value for tracking specific infections.

The analyzed sample then expects to receive the following hardcoded sequence of bytes from the remote server:

This should be followed by the usual key exchange as described in the “Communication protocol” section, where the remote server acts as initiator.

Conclusion

This concludes the second and final part of our technical analysis of Backdoor.Daxin.