Hiding and detecting Trojan processes in the NT System)

In Win9x, you only need to register the process as a system service to be invisible from the process viewer, but all this is completely different in winnt, no matter how the trojan cleverly hides itself from the port or Startup File, it cannot fool the WINNT task manager, so many friends ask me: in WINNT, can't a trojan really hide its own process? This article tries to explore several common hidden process methods of WINNT Trojans to reveal the hidden methods and ways of searching for Trojans/backdoors in winnt.
We know that in windows, executable files are mainly EXE and COM files. These two files have one thing in common at runtime and will generate an independent process, finding a specific process is one of our methods to discover Trojans (whether manual or firewall). With the continuous development of intrusion detection software, associated processes and sockets have become popular technologies (for example, the famous fport can detect TCP/UDP ports opened by any process ), assume that a trojan is detected by the software at runtime to detect both the port and process, we basically think that the hiding of this trojan has completely failed (using psychological factors rather than non-technical means to fool the user's Trojan is not within our scope of discussion ). In the normal circumstances of NT, user processes are visible to the system administrator. There are two ways to hide the Trojan process. The first is to make the system administrator invisible (or blind) Your process; second, do not use processes.
To make the system administrator unable to see the process, perform process list spoofing. To learn how to see the process, we must first understand how to see the process: in windows, there are multiple ways to see the existence of the process: psapi (Process status API), PDH (performance data helper), toolhelp API. If we can spoof users and intrusion detection software to view the functions of the process (such as intercepting the corresponding API calls, replacement of the returned data), we can completely hide the process, but we do not know the method used by the user and the intrusion software to view the process list, second, if we have the permission and technology to implement such spoofing, we will be able to use other methods to implement process hiding more easily. (For example, it is better to replace DLL or hook up an API to hide a process as a Trojan .)
The second method is not to use a process. What does not use a process? To understand this problem, we must first understand another kind of "executable files" in Windows-DLL, short for dynamic link library (dynamic link library, DLL files are the basis of windows, because all API functions are implemented in DLL. A dll file has no program logic and consists of Multiple Functional functions. It cannot run independently. Generally, it is loaded and called by processes. (You and you, didn't you say you didn't need a process ?) Don't worry. Listen to me: Sorry, no one will doubt that it is a trojan ?) As part of the process, the DLL we compile will become a trusted member and do whatever you want.
Rundll32.exe is the easiest way to run a DLL file. rundll/rundll32 is a built-in dynamic link library tool in windows. It can be used to execute a function in the dynamic link library under the command line, here, rundll is a 16-bit file while rundll32 is a 32-bit file (the 16-bit and 32-bit DLL files are called respectively). The usage of rundll32 is as follows:
Rundll32 dllfilename funcname
Mydll. dll myfunc can execute the function of myfunc.

What is the relationship between this and the Trojan process hiding? Of course, if we have implemented the trojan function in the myfunc function, can we run this trojan through rundll32? Delete shards? Finding the DLL Trojan from the rundll32 process is still a little troublesome)
Using rundll32 to hide a process is easy to understand. (Although it will be troublesome to kill) the more advanced method is to use the trojan dll. the working principle of the trojan dll is to use the trojan dll to replace the commonly used DLL files, the function forwarder forwards normal calls to the original DLL to intercept and process specific messages. For example, we know that all the functions of socket1.x in windows are stored in wsock32.dll, so we can write a wsock32.dll file and replace the original wsock32.dll (rename the original DLL file as wsockold. DLL) Our wsock32.dll only does two things. First, if you encounter an unknown call, it will be directly forwarded to wsockold. DLL (use the function forwarder forward); second, decode and process a special request (as agreed in advance. In theory, as long as the trojan writer remotely enters a certain dark number through the socket, it can control wsock32.dll (trojan dll) for any operation. The trojan dll technology is a relatively old technology, so Microsoft has also taken some measures against it. In the System32 directory of Win2k, there is a directory of dllcache, this directory stores a large number of DLL files (including some important EXE files). This is Microsoft's magic weapon to protect the DLL, once the operating system detects that the protected DLL file is tampered with (digital signature technology), it will automatically restore the file from the dllcache. Although there are various ways to bypass DLL protection (such as modifying the backup in the dllcache directory before modifying the DLL file, or using the knowndlls key value to change the default DLL startup path ), however, in the foreseeable future, Microsoft will be more careful in protecting important DLL files; at the same time, because the trojan dll method itself has some vulnerabilities (such as fixing and installing, installing patches, upgrading the system, checking digital signatures, and other methods may cause the trojan dll to fail ), therefore, this method is not the best choice for DLL Trojans.
The highest level of DLL Trojan is the dynamic embedding technology, which refers to the technology that embeds its own code into the running process. Theoretically, every process in Windows has its own private memory space. Other processes are not allowed to operate on this private space (private territory, please do not enter it), but in fact, we can still use various methods to access and operate the private memory of the process. Among Multiple Dynamic embedding technologies (window hook, hook api, and remote thread), I like remote thread technology, which is very simple, as long as you have basic online and dynamic link library knowledge, you can easily embed data. The following describes the remote thread technology.
Remote thread technology refers to the process's memory address space by creating a remote thread in another process. We know that in the process, we can use the createthread function to create a thread. The new thread and the main thread are created (that is, the thread automatically created when the process starts) shared address space and other resources. But few people know that using createremotethread can also create a new thread in another process. The created remote thread can also share the remote process (Remote Process !) So, in fact, we enter the memory address space of the remote process through a remote thread, and we also have the permissions of the remote process. For example, if you start a DLL Trojan inside a remote process (starting a DLL Trojan is a little tricky compared to entering the process, we can actually tamper with the data of that remote process at Will)
Let's look at the Code:
First, we use OpenProcess to open the process we are trying to embed (if the remote process is not allowed to open, the embedding will fail, which is often caused by insufficient permissions, the solution is to improve the local process permissions through various channels)
Hremoteprocess = OpenProcess (process_create_thread | // allows remote thread Creation
Process_vm_operation | // allows remote VM operations
Process_vm_write, // allow remote VM write
False, dwremoteprocessid)
Because we need to write the memory address space of the remote process and establish a remote thread, we need to apply for sufficient permissions (process_create_thread, vm_operation, vm_write ).
Then, we can create the loadlibraryw function thread to start our DLL Trojan. The loadlibraryw function is defined in kernel32.dll and is used to load the DLL file. It has only one parameter, is the absolute path name of the DLL file pszlibfilename (that is, the full path File Name of the trojan dll), but because the trojan dll is called in a remote process, so we need to copy the file name to the remote address space first: (otherwise, the remote thread cannot read this parameter)
// Calculate the memory space required by the dll path name
Int cb = (1 + lstrlenw (pszlibfilename) * sizeof (wchar );
// Use the virtualallocex function to allocate the DLL file name buffer in the memory address space of the remote process.
Pszlibfileremote = (pwstr) virtualallocex (hremoteprocess, null, CB,
Mem_commit, page_readwrite );
// Use the writeprocessmemory function to copy the dll path name to the memory space of the remote process.
Ireturncode = writeprocessmemory (hremoteprocess,
Pszlibfileremote, (pvoid) pszlibfilename, CB, null );
// Calculate the loadlibraryw entry address
Pthread_start_routine pfnstartaddr = (pthread_start_routine)
Getprocaddress (getmodulehandle (text ("Kernel32"), "loadlibraryw ");
OK, everything is ready. We established the address pfnstartaddr (actually the loadlibraryw endpoint address) when creating a remote thread and passed the parameter pszlibfileremote (actually the full path File Name of the trojan dll we copied) start our trojan dll in a remote process:
// Start the remote thread loadlibraryw and call the user's DLL file through the remote thread
Hremotethread = createremotethread (hremoteprocess, null, 0,
Pfnstartaddr, pszlibfileremote, 0, null );
So far, remote embedding has been successfully completed. to test whether our DLL is running properly in a remote thread, I have compiled the following test dll:
Bool apientry dllmain (handle hmodule, DWORD reason, lpvoid lpreserved)
{
Char szprocessid [64];
Switch (reason)
{
Case dll_process_attach:
{
// Obtain the ID of the current process
_ ITOA (getcurrentprocessid (), szprocessid, 10 );
MessageBox (null, szprocessid, "remotedll", mb_ OK );
}
Default:
Return true;
}
}
When I use the rmtdll.exeprogram to embed this testdll.dllinto the assumer.exe process (pid = 1208), the test dll will pop up a confirmation box with the words 1208, And the PS tool will also be able to see

Process ID: 1116
C: \ winnt \ assumer.exe (0x00400000)
......
C: \ testdll. dll (0x100000000)
......
This proves that testdll.dllhas been correctly executed in the assumer.exe process.
Whether using a trojan dll or a remote thread, the core code of the Trojan is run in the memory space of other processes. This not only hides itself well, but also protects itself better.
At this time, we can say that a real Trojan has been implemented. It not only deceives, enters your computer, or even enters the process. In a sense, this trojan already has many characteristics of the virus, such as hiding and parasitic (same as the host). If one day, a Trojan with all the virus characteristics (not a worm, it's a traditional parasitic virus.) I don't think it's strange, but I wonder why this day is so late.

DLL Trojan Detection and Removal
If my article ends, it will become a DLL Trojan writing Tutorial: P. In fact, the ultimate goal of understanding the DLL Trojan principle is to better defend against it, let's discuss how to kill a DLL Trojan.
If you are an administrator of a system process such as IIS, you cannot directly terminate the Trojan. (In NT, system processes cannot be killed directly ). Therefore, we can't count on the Process Manager that comes with NT. We need to use some additional tools.
I. Process/memory module Viewer:
To discover the DLL Trojan, we must be able to view the DLL module running in the memory (remember? DLL Trojans run in existing processes). As mentioned above, there are many methods to view the process/memory module in windows, including psapi, PDH, and toolhelper API. I used psapi to write a tool like this. The courier of Tiantian wrote a more powerful process viewer using PDH, which allows you to view the remote host status (when the system administrator password is known ), we hope to organize the release as soon as possible.
You can download the pstool at the following address:

Http://www.patching.net/shotgun/ps.zip

Logs/A/m> ps. log.

2. Port process associated software:
Software for associating ports and processes is also an important tool. Although DLL Trojans are hidden in other processes, there may be more or less exceptions. The powerful fport is an excellent process Port Association software, you can download it at the following address: (I wrote one myself, but it is not easy to use fport, so I won't show it ugly, huh, huh)

Http://www.foundstone.com/rdlabs/termsofuse.php? Filenamefpfportng.zip

3. sniffer:
The sniffer helps us detect abnormal network communication, which leads to our vigilance and attention. The principle of the sniffer is very simple. By setting the NIC as a hybrid mode, we can accept all IP packets, the sniffer program can select a noteworthy part for analysis. The rest is to decode the protocol according to the RFC document. On the home page of Tianji, I placed a command line sniffing tool under Win2k. Any interested friends can download the source code and rewrite it to their desired tools:
Code and header: http://www.patching.net/shotgun/GUNiffer.zip
Compiled program: http://www.patching.net/shotgun/GUNiffer.exe

Iv. Registry protection software:
As you can imagine, the DLL Trojan will continue to use the registry to start itself (in windows, where can I find a place that is more complex than the registry and more suitable for hiding Trojans ?) The difference is that the DLL Trojan is not limited to the well-known sub-keys such as run and runonce, but has more options. For example, the knowndlls sub-key is a good hiding place for the trojan, under the HKEY_LOCAL_MACHINE \ SYSTEM \ controlset001 \ Control \ Session Manager \ knowndlls sub-key in the registry, stores some default paths of known DLL. Assume that the DLL Trojan modifies or adds a key value, the trojan dll can replace the original DLL file to enter the process when the process loads well-known DLL. There are a lot of software for registry protection. lockdown2000 has such a built-in function. In addition, the regmon of sysinternals is also very good ,:

Http://www.nttoolbox.com/public/tools/ntregmon.zip

V. File Protection:
In addition to the registry, the file is also a startup tool for DLL Trojans, using appname. the DLL transfer of the local file can smoothly Replace the default DLL loaded when any application starts. The trojan dll is endless, And the Filemon produced by sysinternals can play a role in file protection:

Http://www.nttoolbox.com/public/tools/ntfilmon.zip

The detection and removal of DLL Trojans is very complex, and they are not available in a day or two. At present, the company is also developing defense software, hoping to provide you with a simple and quick solution soon.
Finally, I would like to thank Xi CI's lion hook for its guidance on DLL file operations, at the same time, I would like to thank Abu, Yagami, eyas, sztwww, big e, and other brothers of butian for discussing the hidden process technology with me, and I have learned a lot.