# Daxin Backdoor: In-Depth Analysis, Part Two

**[symantec-enterprise-blogs.security.com/blogs/threat-intelligence/daxin-backdoor-espionage-analysis](https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/daxin-backdoor-espionage-analysis)**

Threat Hunter TeamSymantec

## 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.](https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/daxin-malware-espionage-analysis)
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.
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.
Using Wireshark, we captured traffic between two backdoor instances, one running on “AlicePC” 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?


-----