In Win9x, you only need to register the process as a system service to be invisible from the process viewer.
Winnt is completely different. No matter how clever a Trojan can hide itself from a port or Startup File
Spoofing winnt's task manager, so many friends asked me: Is it true that Trojans can no longer be hidden in winnt?
Hiding your own processes? This article attempts to explore several common hidden process methods of Trojans in winnt to reveal
Trojan/BackdoorProgramHidden methods and search methods in winnt.
We know that in windows, executable files are mainly EXE files and COM files, which are running
They all have one thing in common and will generate an independent process. Finding a specific process is one of our methods to find a Trojan.
(Both manual and 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)
When the trojan is detected, the software detects the port and process at the same time. We basically think that the trojan is completely hidden.
All failed (using psychological factors rather than non-technical means to spoof users' Trojans is not within our scope ). In NT
Under normal circumstances, user processes are visible to the system administrator. To hide the Trojan process, there are two
The first is to make the system administrator invisible (or turn a blind eye) Your process; the second is not to use the process.
To make the system administrator invisible to the process, you can perform process list spoofing to learn how to see the process.
First, we need to know how to see the process: there are multiple methods in Windows to see the existence of the process: P
SAPI (Process status API), PDH (performance data helper), toolhelp API, such
If we can trick users and intrusion detection software into viewing the functions of the process (for example, intercepting the corresponding API calls, replacing
For the returned data), we can completely hide the process, but we do not know the user and the intrusion software.
What method is used to view the process list, and if we have the permission and technology to implement such spoofing, we
You can use other methods to hide processes more easily. (For example, you can replace the DLL or hook the API
The hidden process is not directly used 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, you need to know another kind of "executable files" in Windows-DLL, which is dynamic link library (
DLL file is the basis of windows, because all API functions are implemented in DLL
. A dll file has no program logic and is composed of Multiple Functional functions. It cannot be run independently.
Program loaded and called. (You and you, didn't you say you didn't need a process ?) Don't worry. Let me hear it:
The DLL file cannot run independently, so no DLL is displayed in the process list. Suppose we have compiled a Trojan
DLL, and run it through other processes, no matter whether it is the intrusion detection software or the process list
The current process does not contain trojan dll. if the process is a trusted process (for example, resource manager explo
Rer.exe, no one will doubt that it is a trojan ?) Then, the DLL we compiled as part of that process will also
Become a trusted member and do whatever you want.
Rundll32.exe is the easiest way to run a DLL file. rundll/rundll32 is provided by windows.
The dynamic link library tool can be used to execute a function in the dynamic link library under the command line, where rundll is 16
While rundll32 is 32-bit (the 16-bit and 32-bit DLL files are called respectively), the use of rundll32 is as follows:
Rundll32 dllfilename funcname
For example, we have compiled a mydll. dll, which defines a myfunc function in the dynamic link library.
You can use rundll32.exe mydll. dll myfunc to execute the myfunc function.
What is the relationship between this and the Trojan process hiding? Of course, let's assume that we have implemented
Can we run this trojan through rundll32? In the view of the system administrator
Rundll32.exe is added in the process, instead of a Trojan file. This is a simple form of Trojans.
Fraud and self-protection tips (You cannot delete rundll32.exe? Find the DLL from the rundll32 Process
Ma is still a little troublesome)
Using rundll32 to hide a process is easy to understand. (Although it will be difficult to kill
A little annoying) the more advanced method is to use the trojan dll. the working principle of the trojan dll is to replace the common
Use the function forwarder to forward normal calls to the original DLL, intercept and process specific messages. Example
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, replace the original wsock32.dll (rename the original DLL file as wsockol
D. dll) Our wsock32.dll only does two things. First, if we encounter unknown calls, we will forward them directly to ws.
Ockold. dll (use the function forwarder forward); second, decode and
Processing. In theory, as long as the trojan writer remotely enters a certain number of signals through the socket, wsock3 can be controlled.
2. dll (trojan dll) for any operation. The trojan dll technology is a relatively old technology, so Microsoft has also done this
Quite precaution: There is a dllcache directory under the System32 directory of Win2k, which stores a large number
DLL files (including some important EXE files). This is a magic weapon that Microsoft uses to protect the DLL.
When 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 (for example, you can change the backup in the dllcache directory before modifying the DLL
File, or use the knowndlls key value to change the default startup path of the DLL .)
Be more careful with protecting important DLL files. At the same time, due to the fact that the trojan dll method itself has some vulnerabilities (such
Methods such as installing, installing patches, updating the system, and checking the digital signature may cause the failure of the trojan dll ),
Therefore, this method is not the best choice for DLL Trojans.
The highest level of DLL Trojan is the dynamic embedding technology.CodeEmbedded in Operation
Technology in the process. Theoretically, every process in Windows has its own private memory.
The process of is not allowed to operate on this private space (private territory, do not enter), but in fact, I
You can still use various methods to access and operate the private memory of the process. In Multiple Dynamic embedding technologies (window Ho
OK, hook up API, remote thread), my favorite is remote thread technology, this technology is very simple, as long as there is a base
This online and dynamic link library can be easily embedded. Next we will introduce the remote connection
Thread Technology.
Remote thread technology refers to entering the memory of that process by creating a remote thread in another process
Address space. We know that in the process, we can use the createthread function to create a thread and a new line to be created.
The shared address space and other resources of the thread and the main thread (that is, the thread automatically created when the process starts)
Source. But few people know that using createremotethread can also create new lines in another process.
The created remote thread can share the remote process (Remote Process !) Address space, so,
In fact, we use a remote thread to enter the memory address space of the remote process.
Process equivalent permissions. For example, to start a DLL Trojan inside a remote process
A dll Trojan is meaningless. In fact, we can tamper with the data of the 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,
Therefore, embedding cannot be performed, which is often caused by insufficient permissions. The solution is to improve the performance through various means.
Local process permissions)
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
Sufficient permissions (process_create_thread, vm_operation, and vm_write ).
Then, we can establish the loadlibraryw function thread to start our DLL Trojan, loadlibra
The RYW function is defined in kernel32.dll to load the DLL file. It has only one parameter, that is, the DLL file.
(That is, the full path File Name of the trojan dll),
It is called in a remote process, so we need to copy the file name to the remote address space first. Otherwise
The 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 ");
Okay, everything is ready. We established the address pfnstartaddr when the remote thread was created (actually loadlibrar
YW entry address) and the passed parameter pszlibfileremote (in fact, we copied the entire trojan dll
Path file name) 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 compile
Write 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 "1208" confirmation box is displayed in the test DLL, and you can also see it using the PS tool.
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 of other processes.
In this way, you can not only hide yourself, but also better protect yourself.
At this time, we can say that we have implemented a real Trojan, which not only deceives and enters your computing
Server, or even inside the process. In a sense, this trojan already has many features of the virus,
For example, if one day, a Trojan with all the virus characteristics (
It's not a worm, it's a traditional parasitic virus.) I don't think I will be surprised.
Why is it so late.
DLL Trojan Detection and Removal
If this is my articleArticleAt this end, it becomes the DLL Trojan Writing Teaching: P, in fact, we know about the DLL
The ultimate goal of the Trojan principle is to better defend against it. So, let's discuss the DLL Trojan detection and removal.
The DLL Trojan is hidden in the Process Manager, so we can neither use the Process Manager to find it, nor directly
We can directly kill the host process by stopping and running the slave.
However, if the Trojan horse enters the system process (IIS) such as inetinfo.exe through the Elevation of Privilege and limit, then
Even the administrator 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 Trojan running in
Some processes), as mentioned earlier, there are many ways to view the process/memory module in windows, including psapi, PDH
And toolhelper API. I used psapi to write a tool like this, and the Child e of butian wrote a more enhanced tool with PDH.
A large process viewer that allows you to view the remote host status (if you know the system administrator password ).
Sort and release.
You can download the pstool at the following address:
Http://www.patching.net/shotgun/ps.zip
In fact, due to the complexity of the Windows system, even with the above tools, finding the DLL Trojan is still very complicated.
Difficult: Only administrators who have a good understanding of the system structure can find the abnormal one from countless DLL files.
You can use the PS tool to upload a DLL file at ordinary times. This is simple, and ps.exe/A/m> P
S. log.
2. Port process associated software:
Software related to ports and processes is also an important tool. Although DLL Trojans are hidden in other processes, there are many
There may be few exceptions. The powerful fport is an excellent process Port Association software.
Download to: (I wrote one myself, but it is not easy to use fport, so I won't show it ugly.
)
Http://www.foundstone.com/rdlabs/termsofuse.php? Filenamefpfportng.zip
3. sniffer:
The sniffer helps us find abnormal network communication, which causes our vigilance and attention. The principle of the sniffer is very simple.
Single, you can accept all IP packets by setting the NIC to the hybrid mode, and the sniffing program can choose the value
The rest is to decode the protocol according to the RFC document. On the home page of the Population Day, I placed
A command line Sniffer In Win2k, any interested friends can download the source code and rewrite it as needed
Tool:
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 (where to find a ratio in Windows)
What makes the registry more complex and suitable for hiding Trojans ?) The difference is that DLL Trojans are not limited to run and Ru.
Nonce, a well-known sub-key, has more options. For example, knowndll
S sub-key is a good hiding place, in the Registry's HKEY_LOCAL_MACHINE \ SYSTEM \ controlset0
01 \ Control \ Session Manager \ knowndlls sub-key stores the default paths of some known DLL. Assume that
When a DLL Trojan modifies or adds a key value, the trojan dll can be silently loaded when a process loads a well-known DLL.
Wait to replace the original DLL file into the process. There are a lot of registry protection software, and lockdown2000 is built in like this
Function, In addition, sysinternals regmon is also very good ,:
Http://www.nttoolbox.com/public/tools/ntregmon.zip
V. File Protection:
In addition to the registry, the file is also the startup tool for the DLL Trojan.
It can smoothly Replace the default DLL loaded when any application starts, and the trojan dll is endless.
The Filemon produced by sinternals can be used to protect files:
Http://www.nttoolbox.com/public/tools/ntfilmon.zip