- Winnt's process of hiding Trojans DLL Trojans -
Hidden under the NT system
In WIN9X, you only need to register your process as system service, you can invisibility in the process viewer, but all this is completely different in Winnt, regardless of how Trojans from the port, how to hide themselves on the file, never deceive WinNT Task Manager, is it really unable to hide your own process in Winnt?
We know that under the Windows system, the executable file is mainly an exe and com files. Both files have a common point in runtime, which will generate an independent process, find a specific process is one of the methods we find Trojans ( Regardless of manual or firewall), with the continuous development of intrusion detection software, the associated process and socket have become popular technologies (such as the famous Fport to detect TCP / UDP ports opened by any process), suppose a Trojan is running Testing software simultaneously detects port and processes, we basically think that this Trojan hidden has completely failed (using psychological factors rather than technical means deceived users of Trojans are not within our discussion). The normal situation in NT is visible for the system administrator. If you want to do Trojan's process, there are two ways, the first is to let the system administrator see (or turn it off) your process; Second, do not use the process.
Methods to make system administrators are the process list spoofing, in order to understand how to see how to see the process, we must first understand how to see the process: There are a variety of ways in Windows to see the existence of the process: PSAPI (Process Status API, PDH (Performance Data Helper), Toolhelp API, if we can deceive users and intrusion detection software to view functions of the process (such as intercepting the corresponding API call, replacing the returned data), we fully implement the process hide But let's not know what the user and intrusion software use to view the list of processes. If we have permission and technology to achieve such deception, we must use other methods easier to implement the process hidden . (For example, you can replace the DLL or hook the API to hide the process is not as direct as a wooden horse.)
The second method is not using the process, does not use the process? In order to understand this problem, we must first understand another "executable file" of the Windows system ---- DLL, DLL is the abbreviation of Dynamic Link Library, the DLL file is the foundation of Windows, because all The API function is implemented in the DLL. The DLL file has no program logic, which is composed of multiple functional functions, which cannot be run independently, generally loaded and called by the process. (You do you, do you just say no process?) Don't worry, listen to me slowly: Because the DLL file can not run independently, there will be no DLL in the list of processes, suppose we write a Trojan DLL And run it through other processes, then whether the intrusion detection software is still in the process list, there will be only the process without that process, if that process is a trusted process, (for example, Explorer Explorer. EXE, no one will doubt it is a Trojan?) Then the DLL we have written as part of that process and will become a trusted member.
The easiest way to run the DLL file is to use Rundll32.exe, Rundll / Rundll32 is a dynamic link tool with Windows, which can be used to perform a function in the dynamic link library in the command line, where Rundll is 16 bits and Rundll32 It is 32-bit (twisting 16-bit and 32-bit DLL files), and the RUNDLL32 is used as follows: Rundll32 DLLFileName FuncName
For example, we have written a MyDLL.dll, which defines a MyFunc function in this dynamic link library, then we can perform the functionality of MyFunc functions through rundll32.exe mydll.dll myfunc.
What is the relationship between this and Trojan's process hide? Of course, it is assumed that we realize the function of Trojan in myFunc function, then we can't run this Trojan through Rundll32? In the system administrator, add Rundll32.exe in the process list is not a Trojan file, which is also a simple deception and self-protection method of Trojans (at least you can't delete Rundll32.exe? Want to Rundll32 process finds a DLL Trojan still has a little troubles)
It is easy to use Rundll32 to make progress hidden, which is very easy to know. (Although it is troublesome, it will trouble.) The premium method is to use Troy DLL. The working principle of Troy DLL is to replace the commonly used DLL file using Trojan, and forward the normal call to the original DLL, intercept and process specific news. For example, we know that Windows's socket1.x is stored in wsock32.dll, then we write a WSOCK32.dll file, replace the original WSOCK32.DLL (rename the original DLL file) WSOCKOLD.DLL Our WSOCK32.DLL only two things, one, if you encounter unidentified calls, forward it directly to WSOCKOLD.DLL (using function repeater forward); Second, encounter special requests (in advance) Decode and process. This is theoretically as long as the Trojan writer enters a certain number of codes through the Socket remotely, you can control WSOCK32.DLL (Trojan DLL) to do anything. Troy DLL technology is an older technology, so Microsoft has made considerable precautions, there is a DLLCache directory in Win2K's System32 directory, which exists in this directory (also including some important EXE files) This is Microsoft's magic weapon for protecting the DLL. Once the operating system discovers that the protected DLL file is tampered with (digital signature technology), it will automatically restore this file from DLLCache. Although there are various methods to bypass DLL protection (eg, change the DLL file before changing the backup in the dllcache directory, or change the DLL's default startup path, but the future of the future, Microsoft will be more careful Important DLL files; At the same time, due to the Troy DLL method itself has some vulnerabilities (such as repairing the installation, installing patch, upgrade system, check digital signatures, etc.) may result in Troy DLL failure), so this method cannot be considered the best DLL Trojan. select.
The highest realm of DLL Trojans is dynamic embedded technology, and dynamic embedding technology refers to technology that embeds its code into the process being running. In theory, every process in Windows has its own private memory space, other processes are not allowed to operate this private space (private territory, please do not enter within), but in fact, we can still use all kinds The method enters and processes private memory. In a variety of dynamic embedded technologies (window hook, hook API, remote thread), I like remote thread technology, this technology is very simple, as long as there is basic adverbial thread and dynamic link library knowledge can be easily The embedding is completed, and the remote thread technology is introduced to you. Remote thread technology
Remote thread technology refers to the memory address space of that process by creating a remote thread in another process. We know that in the process, we can create threads through the CreateThread function, the new thread and the main thread (that is, the thread that is automatically established when the process starts) shared address space and other resources. But few people know that by CreateremoteThread can also create new threads in another process. The created remote thread can also share the address space of the remote process (which is a remote process. ", In fact, we pass a remote Threads, entered the memory address space of the remote process, which has the right permission that the remote process. For example, starting a DLL Trojan within the remote process (compared to the inside of the process, starting a DLL Trojan is a little means, in fact we can withdraw the data of the remote process.
First, we open the process we try to embed through OpenProcess (if the remote process is not allowed to open, then embedding can not be carried out, this is often caused by insufficient permissions, the solution is to enhance the right to local processes)
HREMOTEPROCESS = OpenProcess (Process_create_thread | file: // Allow remote creating thread process_vm_operation | file: // Allow remote VM to operate process_vm_write, // Allow remote VM to write false, dwremoteProcessID)
Since we will need to write to the memory address space of the remote process and establish a remote thread, you need to apply enough permissions (Process_create_thread, VM_OPERATION, VM_WRITE).
Then we can build a loadLibraryw function This thread is to launch our DLL Trojan. The loadLibraryw function is defined in kernel32.dll, used to load the DLL file, which only one parameter is the absolute path name of the DLL file, (that is Trojan DLL's full path file name), but because Trojan DLL is called within the remote process, we must first copy this file name to the remote address space: (otherwise the remote thread is not read)
File: / / Calculate the memory space required by the DLL path name INT CB = (1 lstrlenw (pszlibfilename)) * sizeof (wchar); file: // Using the VirtualaLalkEx function to allocate a DLL file name buffer PszlibFileRemote = (PWSTR) VirtualAllocEx (hRemoteProcess, NULL, cb, MEM_COMMIT, PAGE_READWRITE); file: // use WriteProcessMemory function to copy the DLL path name to the remote process memory space iReturnCode = WriteProcessMemory (hRemoteProcess, pszLibFileRemote, (PVOID) pszLibFileName, cb , NULL); file: // computing LoadLibraryW entry address PTHREAD_START_ROUTINE pfnStartAddr = (PTHREAD_START_ROUTINE) GetProcAddress (GetModuleHandle (TEXT ( "Kernel32")), "LoadLibraryW"); OK, everything is ready, we address through the establishment of a remote thread PfnStartAddr (actually the entrance address of LoadLibraryw) and passed Parameters pszlibfileremote (actually we copy the full path file name of the past Trojan DLL) launched our Trojan DLL within the remote process:
File: // Start the remote thread LoadLibraryw, call the user's DLL file through the remote thread HREMOTHREAD = CreateRemoteThread (HremoteProcess, Null, 0, PfnStartaddr, PszlibfileRemote, 0, NULL);
At this point, the remote embedding is successfully completed. In order to test our DLL, it has been running in the remote thread, I have written the following test DLL:
BOOL APIENTRY DllMain (HANDLE hModule, DWORD reason, LPVOID lpReserved) {char szProcessId [64]; switch (reason) {case DLL_PROCESS_ATTACH: {file: // Get the current process ID _itoa (GetCurrentProcessId (), szProcessId, 10); MessageBox ( NULL, SZPROCESSID, "Remotedll", MB_OK;} DEFAULT: RETURN TRUE;}}
When I use the RMTDLL.EXE program to embed this TestDLL.DLL after the Explorer.exe process (PID = 1208), the test DLL pops up 1208 words confirmation box, and can also see the PS tool.
Process ID: 1208 C: /WinNT/Explorer.exe (0x00400000) ... C: /Testdll.dll (0x100000000) ......
This proof TestDLL.dll has been running correctly within the Explorer.exe process.
Whether using Troy DLL or using a remote thread, it is a memory space that makes Trojan's core code running in another process, which is not only very good to hide themselves, but also protect yourself better.
At this time, we can say that there is a truly Trojan, it not only deceives, enter your computer, even enters the interior of the process, in a sense, this Trojan has a lot of characteristics, For example, hidden and parasitic (dying with the host), if one day, there is a wooden horse with all viral characteristics (not a worm, but a parasitic virus in the traditional sense), I think I will not feel strange, fall Will you ask why this day is so late. DLL Trojan's killing
If my article is over, then it turns into a DLL Trojan writing: P, in fact, we understand the ultimate goal of the DLL Trojan's principle or to better defend it, so let us discuss the DLL Trojan. Kill. DLL Troja is hidden for the process manager, so we can't use the process manager to find it directly, assume that the DLL Trojan is embedded in the process of Explorer.exe, we can also kill the host process directly. Drop, but if the Trojan entered the system process (IIS) such as inetinfo.exe by improved permissions, even if the administrator, the operation of the Trojan cannot be directly terminated. (In NT, the system process cannot be directly kill). Therefore, we cannot count on the process manager that comes from NT, and some additional tools are required.
First, Process / Memory Module Viewer:
In order to find the DLL Trojan, we must see the DLL module running in memory (remember? DLL Trojan runs within the existing process), in the previous, watching the process / memory module under Windows, there are PSAPI, PDH and Toolhelper API. I wrote a tool with PSAPI, and the Children who replenished the days wrote a more powerful process viewer with PDH, supporting the remote host status (knowing the system administrator password), I hope to make an early provision.
PS tools can be downloaded to: http://isforce.51.net/down/ps.zip
In fact, due to the complexity of the Windows system, even with the above tools, find the DLL Trojan is still very difficult, only the administrator who knows the system structure can find an abnormality from countless DLL files, so Booking a list of DLL files using the PS tool will be more helpful, the method is simple, ps.exe / a / m> ps.log.
Second, port process association software:
The associated port and process software is also one of an important tool. Although the DLL Trojan is hidden in other processes, there will be some exceptions, and powerful fport is a good process port related software, which can be downloaded to the following address. : Http://isforce.51.net/down/fportng.zip
Third, sniffer:
The sniffer helps us find abnormal network communication, causing our vigilance and attention, the principle of sniffer is simple, by setting the NIC to mixed mode, you can accept all IP packets, sniffing procedures can be selected from it. The partial analysis of interest is analyzed, and the remaining is nothing more than decoding the protocol in accordance with the RFC document. On the homepage of the heaven, I placed a command line sniffing detector under Win2K. Any interested friends can download the source code and rewrite the tools you need:
Code and header file: http://isforce.51.net/down/guniffer.zip compiled program: http://isforce.51.net/down/guniffer.exe four, registry protection software:
You can imagine that the DLL Trojan will continue to use the registry to launch yourself (where to find a more complicated than the registry, more suitable for Trojan hidden places?) DLL Trojan is not only limited to Run, Runonce These well-known sub-keys have more choices. For example, for Troy DLL, the knowndlls subkey is a good hiding, in the registry's HKEY_LOCAL_MACHINE / System / ControlSet001 / Control / Session Manager / KNowndlls subkey, stores some known DLL's default path, assume DLL Trojans modify or add a key value, then the Trojan DLL can replace the original DLL file into the process when the process is loaded with a well-known DLL. There are many functions protected by the registry, and the LockDown2000 has built-in functionality, in addition, Sysinternals's Regmon is also very good, download address: http://isforce.zip
V. File protection:
In addition to the registry, the file is also the startup tool for the DLL Trojan. The DLL transfer of the appname.local file can be successfully replaced with the default DLL loaded when the application starts, Troy DLL is endless, and the Filemon, which is also Sysinternals. Filemon can take files. Protection of protection: http://isforce.51.net/down/ntfilmon.zip
DLL Trojan's killing is very complicated. It is not a day two days. At present, the company is also developing related defense software, hoping to provide you with a simple and fast solution.
Finally, I would like to thank the Lion Hook of Xiqiao to my guidance on the DLL file. At the same time, I would like to thank the ABU, Yagami, Eyas, Sztwww, eagle, big ball and other brothers to discuss the technology of hidden processes. I have learned a lot.
