Uncover the mystery of the Trojan Horse

In Win9x, only to register the process as a system service can be invisible from the process viewer, but all of this in the Winnt is completely different, regardless of the Trojan from the port, the boot file on how cleverly hide themselves, always can not deceive the Winnt Task Manager, So many friends asked me: Under the Winnt is not the Trojan really can no longer hide their own process? This paper attempts to explore several common hidden process means of Trojan horse in Winnt, to reveal the method of hiding the Trojan/backdoor program in Winnt and the way to find it.

We know that under the Windows system, executable files are mainly exe and COM files, both of which have a common in the runtime, will generate a separate process, to find a specific process is one of the main ways we found Trojan (whether manual or firewall), with the development of intrusion detection software, Associated processes and sockets have become popular technologies (such as the famous FPort can detect any process open TCP/UDP ports), assuming that a Trojan is detected at runtime by the software to detect both ports and processes. We basically think that this Trojan has completely failed to hide (using psychological factors rather than technical means to deceive users of the Trojan is not within our scope of discussion). In the normal situation of NT under the user process for the system administrator is visible, to do the process of hiding the Trojan, there are two ways, the first is to let the system administrator can not see (or ignore) your process, the second is not to use the process.

The way to see the process is to cheat on the process, and to understand how to make the process invisible, we first need to understand how to see the process: There are many ways to see the process in Windows: PSAPI (The process Status API), PDH (performance Data Helper), Toolhelp API, if we can deceive the user or intrusion detection software to view the process of the function (such as intercepting the corresponding API call, replace the returned data), we can fully implement the process of hiding, but we do not know the user/ Intrusion detection software is using what methods to view the list of processes, and secondly, if we have access and technology to achieve such deception, we will be able to use other methods easier to implement the process of hiding.

The second approach is to not use the process, and not use the process to use what? To understand this, we must first understand the Windows system's alternative "executable"----Dll,dll is the abbreviation for dynamic link library (DLL), which is the basis of Windows, Because all API functions are implemented in DLLs. DLL files do not have program logic, are composed of several functional functions, it can not run independently, generally by the process load and call. (You, you, you, you didn't just say no progress?) Don't worry, listen to me slowly: Because DLL files cannot run independently, DLLs do not appear in the list of processes, assuming that we have written a Trojan DLL and run it through other processes, both the intrusion detection software and the process list will only show up that process without the Trojan DLL , if that process is a trusted process, such as the resource Manager Explorer.exe, no one will suspect it is a trojan, right? Then we write the DLL as part of that process and will become a trusted member and do whatever it takes.

The easiest way to run a DLL file is to take advantage of RUNDLL32.EXE,RUNDLL/RUNDLL32, the dynamic-link library tool with Windows, that you can use to execute a function in a dynamic-link library at the command line. Where Rundll is 16-bit and Rundll32 is 32-bit (16-bit and 32-bit DLL files are called respectively), RUNDLL32 uses the following methods:

Rundll32.exe Dllfilename FuncName

For example, we have written a MyDll.dll that defines a myfunc function in this dynamic-link library, so we can perform the function of the MyFunc function by Rundll32.exe MyDll.dll MyFunc.

How do I run DLL files and the hidden Trojan process? Of course, if we have implemented the function of Trojan horse in MyFunc function, then we can run this Trojan by Rundll32? In the view of the system administrator, the process list is added to the Rundll32.exe rather than the Trojan file, which is a simple Trojan trick and self-protection method (at least you can not go to the Rundll32.exe delete it? ）

Using the Rundll32 method to hide the process is easy and can be easily detected. (though it's going to be a bit of a hassle) the more advanced approach is to use the Trojan DLL, which works by replacing a common DLL file, forwarding a normal call to the original DLL, and intercepting and processing a particular message. For example, we know that Windows Socket 1. x functions are stored in the Wsock32.dll, then we write a Wsock32.dll file, replace the original Wsock32.dll (to rename the original DLL file to Wsockold.dll) Our Wsock32.dll only do two things, one is if you encounter the tune of not knowing , it is forwarded directly to the Wsockold.dll (using the function forwarder forward), and the second is to decode and process the special request (prior agreement). So in theory, as long as the Trojan creator through the socket remote input a certain password, you can control Wsock32.dll (Trojan DLL) do any operation. Trojan DLL technology is a relatively old technology, so Microsoft has also done quite a bit of defense, in the Win2K system32 directory has a dllcache directory, this directory contains a large number of DLL files (also includes some important EXE files), This is what Microsoft uses to protect DLLs, and once the operating system discovers that a protected DLL file is tampered with (digital signature technology), it automatically recovers the file from the Dllcache. Although it is possible to circumvent this protection by first changing the backup in the Dllcache directory and modifying the DLL file itself, it is conceivable that Microsoft will be more careful in protecting important DLL files in the future, and that the Trojan DLL method itself has some vulnerabilities (such as fixing installation, installing patches, Checking digital signatures and other methods can lead to Trojan DLL invalidation, so this method is not the best choice for the DLL Trojan.

DLL Trojan is the highest level of dynamic embedding technology, dynamic embedding technology refers to their own code embedded in the process of running the technology. Theoretically, each process in Windows has its own private memory space, and other processes are not allowed to operate on this private space (private domain, do not enter), but in fact, we can still use various methods to access and manipulate the process of private memory. In a variety of dynamic embedding technologies (window hooks, hook APIs, remote threads), my favorite is remote threading technology (in fact, I actually do this kind of ...). ), let's introduce the remote threading technology.

Remote threading Technology refers to entering the memory address space of that thread by creating a remote thread in another running process. As we know, in a process, you can create a thread through the CreateThread function, and the new thread that is created shares the address space and other resources with the main thread (the one that was automatically established at the time the process was created). But few people know that the CreateRemoteThread can also create new threads within another process, and remote threads that are created can also share remote processes (NOTE: remote processes!). , so, in fact, by creating a remote thread and entering the memory address space of the remote process, we have quite a few permissions on that remote process: for example, starting a DLL Trojan (starting a DLL is nothing compared to entering the process), We can actually tamper with the data of that process.

Less gossip, let's look at the code:

First, we open the process we are attempting to embed by openprocess (if not allowed to open, then embedding is not possible, often due to insufficient permissions, such as you are trying to open a system-protected process)

hremoteprocess = OpenProcess (Process_create_thread |//Allow remote creation of threads

process_vm_operation | Allow remote VM operations

Process_vm_write,//Allow remote VM to write

FALSE, Dwremoteprocessid);