Analysis of concealed communication between the trojan client and the server

The implementation of modern Trojans is based on a communication solution that is reliable and hard to be detected by the host. This article describes the implementation methods and reliability of various solutions, security has been discussed theoretically. A thorough understanding of how the client and server of a Trojan are hidden not only helps you understand the principles of network communication, but also provides effective security measures. Based on this, we have compiled this article. Next we will go to the topic.

First, we should make it clear that the trojan program running on the victim's machine is called the server, and that running on the controller is called the client. (In fact, it is hard to say who is the customer for modern Trojans, who is the service, but we still use this method ). In addition, although Windows 9x still has a huge user base, migrating Windows 9x to Windows XP is only a matter of time. Therefore, the discussion here focuses on the NT/2000/XP platform.

1. Use TCP protocol, server listening, and client connection.

This is the simplest, earliest, and most widely used communication solution. If you have used a glacier or been swept by a glacier client, you will not be unfamiliar with this. In this communication scheme, the server opens a TCP port on the host machine and waits for the client to connect. After the client passes authentication, the client can control the server. Because it is based on the TCP protocol, the communication reliability is guaranteed. However, communication security is very problematic. First, tools like fport and tcpview pro can easily find the processes listening on a port and the executable files corresponding to the processes. Second, when the client is connected to the server on a machine installed with the firewall, it is easy to cause firewall alarms.

2. Use the TCP protocol.

The client listens and connects to the server. This is the so-called reverse connection technology. To overcome the disadvantage that the server is easy to discover when listening on a port, the server no longer listens on the port, but connects to a port on which the client is listening. In this way, the server cannot be found by using the common port scheme or fport. To better paralyze the host, the client listens on ports, 80, and 23. Although the server on the machine where the firewall is installed still needs to trigger firewall alarms when connecting to the client, a careless user may ignore "application xxxxx tries to access xxx. xxx. xxx. xxx sends a warning through port 80.

This reverse connection technology solves the problem of how the server finds the client. Generally, clients use dial-up Internet access without a fixed IP address. Therefore, the Client IP address cannot be hard-coded in the server program. Of course, because the IP addresses of dial-up Internet users are generally within a fixed IP address range, the server can also scan this range, and then determine whether it is its own client based on the feedback from the host to be scanned, however, the range of IP addresses scanned by the server is too large. Another method is that the client publishes its own IP address through a third party with a fixed IP address or a fixed domain name. There are many implementation methods, for example, through a public mailbox, through a personal homepage, it depends on how much imagination you have.

3. Use the UDP protocol.

Server listening, client connection, client listening, and server connection. The method and security are similar to the TCP protocol. Note that UDP is not a reliable protocol. Therefore, you must design a reliable packet transmission protocol based on the UDP protocol.

4. Solve firewall problems.

Whether the server listens passively or actively connects to the server, firewall alarms are triggered when the server and client attempt to establish a connection. After all, there are not many users with rough experiences. Therefore, solving firewall alarms is a problem that must be solved by the server. One method is code injection. The server injects itself into a process that can communicate with the outside world legally (such as IE, ICQ, OICQ, TELNTED, FTPD, IIS, etc) or you can run it in the form of a new thread, or just modify the host process to intercept the network system call (WinSock) of the host process ). The implementation of the latter may be troublesome. If it is running in the form of a new thread, it can then passively listen or actively connect.

In either case, firewall alarms are not triggered (of course, not ). But it should be noted that if it is passive listening, such as parasitic in IE, using fport will find IE listening on a certain port, which may cause careful user attention. Therefore, the better way is to actively connect to the client in the new thread, and connect to port 80 of the client; if it is parasitic in OICQ, why not connect to port 8000 of the client. Code injection requires the server to have several privileges. Considering that normal users start NT as Admin, this should not be a problem (if the server is started as a service, ).

5. Publish the Client IP address when the server actively connects.

Publishing Client IP addresses by a third party is not a reliable method. For example, if the client IP address is published through a personal homepage, the server cannot find the client once the personal homepage is canceled by the Home Page provider for various reasons. This kind of personal homepage is likely to be canceled by the Home Page provider. At the same time, the client must expose its own IP address. Therefore, the better way is that the client proactively tells the server its own IP address and port in some way, and then connects the server. This ensures maximum reliability, security, and flexibility.

How does the server receive notifications from the client? One way is to intercept TCP data or UDP packets received by other processes, analyze the intercepted data, and determine whether the client sends a piece of data to report its IP address. Another method is to use RAW socket to listen to the ICMP packet of the echo reply type. The data in the ICMP packet contains the Client IP address. For normal users, such ICMP packets are rarely filtered out because they want to browse the Internet.

6. use ICMP for communication.

Since the client can send an ICMP (echo reply) to tell the server its IP address, why not do all the communications between the server and the client be established on the basis of ICMP? The server sends an ICMP (echo request) to the client, and the client sends an ICMP (echo reply) to the server. Then, you can establish a reliable datagram communication protocol based on ICMP. If you are not bothered, you can create a TCP over ICMP protocol. Generally, these two types of ICMP packets are set to allow without warning. Therefore, this method is highly sensitive.

7. Use custom protocols for communication.

We know that the protocol field of the IP header specifies the Protocol that the IP packet carries data, such as TCP, UDP, and ICMP. We can set this field as our own defined value (> 80) and define our own communication protocol. However, it is estimated that such an IP packet will be filtered out by all firewalls.

8. Hide the Trojan horse communication on the server.

All of the above are for individual users (mostly dial-up users, including Modem, ISDN, ADSL, FTTX + LA, and Cable Modem ). For this type of machine, there is generally no service, and generally a personal firewall is used, and icmp echo reply/REQUEST is allowed, all of which have our above solutions. For the server, at least the HTTP service should be enabled, and it is usually located after a dedicated firewall. This specialized firewall may filter out all the IP packets except the IP packet whose type is TCP and the destination port is 80, let alone all types of ICMP packets. The downward scheme is acceptable. We can try the upward scheme. One way is to inject it into the process space of the IIS service, and then initiate preprocessing when IIS receives a request from the Trojan client, and handle the process when IIS sends data to the Trojan client, however, I don't know how to implement it. I don't know how to implement it.

Another way is to write an isapi ap so that the trojan client sends a http://xxx.xxx.xxx.xxx/backdoor.dll? Cmd = dir + c: The request is sent. Of course, all information is encrypted. In addition to RPC over SMB and RPC over TCP, RPC over HTTP also exists. In fact, QQ's http proxy is a self-defined RPC over http, at least QQ calls it that way. Now we have an rpc over http.

The hidden communication technology is only part of the hidden Trojan technology, but also the most important part. Because he not only needs to protect Trojans, but also the attackers of Trojans, both Trojan writers and firewall writers should pay enough attention to this part.