Rootkit (4)

Rootkit itself is also a type of Trojan backdoor or malicious program, but it is special. Why? Because you cannot find it. Like the rules in nature, the most popular virus has the least damage to biology, for example, a common cold, but the least popular virus is the most desperate. Rootkit Trojans are AIDS in the information world. Once infected, it is difficult to eliminate them by General means because they do the same thing as they do in nature, undermining the integrity of the system's own detection-it may be hard to understand the description of the term, but it can be imagined that AIDS has damaged the human immune system, leading to white blood cells (a friend who has been in front of the computer for a long time must exercise, otherwise the body will be late
If the problem occurs early, the problem is caused by radiation, and you need to maintain your health !) There is nothing to do with it. You can only watch the human body become slowly damaged. The computer system does not have the immune function, but it provides the relevant detection function for its own environment-enumeration process, file list, level permission protection, etc, most anti-virus software and Process Tools depend on the system's built-in test function to operate, and Rootkit Trojans need to destroy these functions.

To understand the principles of Rootkit Trojans, we must start with the system principles. We know that the operating system consists of the Kernel and Shell, the kernel is responsible for all practical work, including CPU task scheduling, Memory Allocation Management, device management, and file operations. The shell is an interface based on the interaction functions provided by the kernel, it is responsible for instruction delivery and interpretation. Because the kernel and shell are responsible for different tasks and their processing environments are also different, the processor provides multiple different processing environments, which are called the running level (Ring ), the Ring reduces the number of computer resources that can be accessed by program commands step by step to protect computers from Accidental damages-the kernel runs on the Ring
Level 0, with the most complete and bottom-layer management functions, and to the shell part, it can only have three levels of Ring, this level can operate on very few features, almost all commands need to be passed to the kernel to determine whether the command can be executed. Once it is found that the command may cause damage to the system is passed (for example, memory read/write beyond the specified range ), the kernel returns an "unauthorized" flag, and the program sending this command may be terminated, which is the origin of most common "illegal operations, the purpose of this operation is to protect the computer from damages. If the shell and the kernel run at the same level, a casual click may damage the entire system.

Due to the existence of the Ring, except for programs loaded by the system kernel, the general programs called by the shell can only run at the Ring Level 3, that is, all their operation commands depend on Kernel authorization. General process viewing tools and anti-virus software are no exception. Due to the existence of this mechanism, the process we can see is actually "seen" in the kernel and commands through the relevant interfaces (remember the API ?) Feedback to the application, so that there is an inevitable data channel. Although it is difficult to be tampered with in general, it cannot avoid unexpected occurrence, rootkit is an unexpected program like "Manufacturing. Simply put, Rootkit is essentially an application that is "Beyond authorization". It tries to make itself run at the same level as the kernel, or even enter the kernel space, in this way, it has the same access permissions as the kernel.

Therefore, you can modify the kernel commands. The most common is to modify the APIs of the kernel enumeration process so that the data they return always misses the information of the Rootkit process, generally, process tools cannot "see" Rootkit. More advanced Rootkit also tamper with more APIs, so that users cannot see the process (process API is blocked) or files (file read/write API is blocked ), you cannot see the opened port (netstat-an check port. I believe you are familiar with port 8000 !) (The Sock API of the network component is intercepted), and the related network packets (the ndis api of the network component is intercepted) are not blocked. Fortunately, the data indication of the network device is not controlled by the kernel. Otherwise, I am afraid
Rootkit should not be highlighted! The system we use runs with the support of kernel functions. If the kernel becomes untrusted, can the programs that depend on it run trust it? This concept was written three years ago. In today's online world, more and more Trojans and backdoors are wiped out under the Suppression of Anti-Virus products, just as they are invested in five poisonous insects in a sealed box, let them kill each other, no matter what the outcome is, there will always be a tenacious survival, and the surviving poison worm is the strongest and most terrible,, anti-Virus products do not always survive, but non-Virus products that survive must be Rootkit.

The technology used by the only surviving drug worm quickly became the focus of everyone's research and learning. Therefore, rootkit stepped down the mysterious stage in just a few years and became more and more "common, the Network has finally become a new "AIDS village". In such a "civilian" atmosphere, rootkit finally has its "civilian" Name: Drive Trojan, drive Trojan,

A Trojan with a drive, such as a Trojan, is also abbreviated as "rk". It is often used for communication between high people. Ordinary Internet users are completely unaware of the existence of such things, or they are limited to a vague concept ...... When other types of Trojan and backdoor technologies can be easily annihilated, Rootkit Technology becomes the main force in this competition. Therefore, in order to survive, different branches of development are also emerging to drive the horse, when ordinary netizens are not aware of it, they have already "muttered" different factions ......

The beginning of everything: ssdthook(ssdt.exe) a long time ago, some users suddenly felt that their machines were abnormal and were often monitored, so they used anti-virus software for a full scan, the answer is no, so the user trusts anti-virus software and uses it with confidence. One day, the "gray pigeon" Trojan went viral on the Internet, the user hurried to download the latest exclusive killer tool, which frightened the user: When was my infected gray pigeon? For the first time, ordinary netizens deal with the "invisible Trojan", which is nothing more than the "gray pigeon" incident. But why can't the "gray pigeon" be found by the task manager and anti-virus software at that time, or even manually search for it, is it a success? This is because the gray pigeon uses the original Rootkit Technology: ssdt hook. Then, some malicious rogue software that is still in its infancy began to play "stealth", and users were unaware of it. Unless some malicious programs were too arrogant, even so, they still cannot find the basis for exceptions. There is no task manager, no search file, or even the Registry monitoring software, and no response ......

What are the causes of these phenomena? Because of the gray pigeon and later malicious programs, the interactive interfaces they use are not the standard Win32 APIs on the Ring 3 user layer, but through various means, such as drivers, go to the Native API on the Ring 0 kernel layer. "Native API" (Native API) is an API that really works in the Windows NT architecture system. As we all know, Windows is a system that implements program functions through a large number of API functions. However, because Windows supports the POSIX standard (Portable OperatingSystem Interface), this means that apart from running standard Windows platform programs (namely
In addition to Win32 programs, a small number of programs running on other platforms are also supported, such as OS/2. Because of the differences in implementation methods of program functions on different platforms, the system must provide corresponding interface functions for each program that complies with the POSIX standard, if we develop a large and complete interface function call based on this idea, it is too impractical. Therefore, in the NT architecture system, developers have designed two different API interfaces, called "user-state APIs", including common Win32 APIs and POSIX APIs, these APIs run on the Ring3 user layer to form today's Windows world. The other is called "Native" APIs, which are real system APIs, it usually runs in the kernel state to realize the real call of the core functions of the system. To implement POSIX, developers also designed Sub
System) technology to distinguish different System environments. Normally, from the System to the desktop, we are in the "Win32" subsystem, at this time, the function is naturally the Win32 API. The thousands of Win32 APIs that programmers usually access are actually implemented through several hundred nativeapis in different encapsulation forms. System vendors seldom provide public documentation for these Apis because they are more difficult to apply than common functions and may change. When programmers use Win32 APIs, the final execution process is sent to the Native API for processing after a series of complex transformations such as compatibility check, error handling, and parameter option separation.
The API is the main body that truly executes and feedbacks the running results. The user-layer API call is only an encapsulation form, such as fopen and createfile Win32 functions, their real execution functions are native ntcreatefile, Which is why rootkit can make general process tools unable to discover themselves, because it directly interferes with the native API execution results.

Because the API has such a complicated story, malicious programs have transformed into rootkit programs to maximize their permissions and "hook" these native APIs, to achieve the same level of security detection tools and Anti-Virus products, we have done the same thing to achieve the same effect, there is no difference between security products and malware in the execution process. The only difference is the impact on the user and system environment. Since everyone has to control the native API layer, do they have something in common? The answer is yes. windows, as a standard system, must have a standard interface between the native API and the user-layer API for data transmission, and restrict the user to use other unknown operations for the purpose, this interface is named "NTDLL. DLL is responsible for the dynamic link library file. All user-layer API processing is implemented by calling the relevant API entries in this DLL file, however, it is only an interface that provides a jump from the user layer to the kernel layer. It is not the final execution body. When
After an API call is converted to an API function in Ntdll, the system will return a function called "ssdt" (System Service descriptor handler. This process is called by the system service. For example, if a shell program needs to run a new process, it will call the CreateProcess API function exported by kernel32.dll. The next step is the execution process in kernel32.dll, in fact, it only wraps the request again, deformation it into its own parameter, and calls ntdll. DLL Export
NtCreateProcess function, and then ntdll. dll enters the kernel state through an interrupt request int 2Eh (Sysenter), and transfers our initial new process request to the "service number" to the kernel world, under normal conditions, API calls must first be implemented through the transformation of a function address description table. SSDT is the table, which records a large address index, the content is the address location exported by hundreds of native APIs in the kernel. In addition, there are some useful information. In this example, the system determines the function to be used and the position of the function in the kernel based on the service number and function correspondence recorded in SSDT, and finally calls the function, after the function is executed, the result is passed back through the ntdll interface layer by layer until the requesting program receives a status code indicating the processing result. The call process of the system service ends.

Based on the above principle, both malicious programs and Anti-Virus products will give priority to tampering with SSDT content to achieve the effect. Simply put, for example, if a malicious program modifies the native API address in SSDT corresponding to the service number that obtains the process identity to the driver entry at the Ring0 layer, each time the system executes this function, all requests and parameters are logged and tampered with by the third-party module due to the error guidance of SSDT, so a variety of strange phenomena will happen. Taking the rootkit Technology that hides its own processes as an example, the principle is that the native API Service Number of the Process in SSDT is directed to its own module by tampering with the native API Service Number of the process, then, the module will be transferred to the real system service separately (if this operation is not performed or the operation is incorrect, the corresponding system service will be voided or even cause a system crash ), and process the data returned by the real system service. For example, if the data with its own process name is deleted, the final returned data is naturally
"Cannot see" the process.

By manipulating ssdt, the rootkit that uses this technology has been rampant for a while, whether it is a trojan or a rogue plug-in or malware. The authors who earned money behind the scenes also had a solid life-consuming year. However, the good news was not long. The concept of anti-rootkit (Anti-rootkit, that is, "Ark") was proposed, ark tools were also born, such as domestic icesword and super patrol. The operating principles of these Ark tools are very different from those of rootkit. They also put themselves into the system kernel through the driver module, thus achieving a fair competitive position with Rootkit, the main program at the user layer and the driver module that enters the kernel state generate the same query API, for example, enumerating the current
System Process List, etc. Due to the existence of rootkit, the user-Layer Program entity will eventually get less data than the data returned by the driver module-obviously, the Rootkit driver tries its best to hide the user-layer program so that it can be exposed. At the same time, Ark can also find the execution subject behind the function pointed by the current ssdt service number, if the execution subject of the function to which a service number points is not ntoskrnl. EXE (in XP and above systems, some machines are ntkrnlpa.exe), you can determine that the service number is faulty. The super patrol and later Ark directly provided the "one-click recovery" function. With just a few mouse clicks, the hooks mounted by all third-party programs on ssdt were "decoupled ", in a short period of time, the obstacles under rk were removed. Within a period of time, the momentum of rk was quickly overwhelmed. The short-term world was peaceful, short-term, and good.

For ssdt hooks, all current anti-rootkit tools can easily find and remove the hooks (unhook, unhook), such as icesword, rku, and super patrol. To run icesword, first click "process" and check whether there are processes marked in red. If there are any processes, ssdt hook exists in your system, the red process is a file hidden by the underlying driver. Remember its location and terminate it. Click here to go to The ssdt list and you will find some columns marked in red. Remember its "module where the current service function is located". This is the underlying driver file that implements ssdt hook.

Then, use the super patrol to switch to the advanced mode and restore the ssdt to the initial state. All its defenses are removed. Now, you can directly find the file you just recorded and delete it.

Further test: Shadow ssdt hook

The author of rk is unwilling to do so, whether it is a technical struggle or a loss of interest. Anyway, since Ark has made me lose my face or lose my wallet, "One day, longdeshui, let's see the Yangtze river flow back! ", Some people began to try to crack the anti-rootkit tool and vowed to fight against it. Others began a new exploration. In the end, both parties achieved results: first, pjf's masterpiece, icesword, was successfully decompiled. Although it was not the original C language code but the Assembly statement, for those who studied rootkit, assembly was in their eyes, it was just as easy as reading online novels. Soon someone could see the author's detection logic and bypass icesword and other rootkit tools using similar detection methods.
It has begun to monitor the Ark in turn. Once the driver of the corresponding Ark is loaded, the system will immediately start to burn everything-making the user's machine a classic blue screen, and then the user in the unknown several times to look at the blue screen, generally, the blue screen is a result of a deeper problem, which will be mentioned below.

Researchers from another direction also reported that in windows, apart from the ssdt (keservicedescriptortable) that everyone is playing, another hidden data segment similar to the ssdt structure works at the same time. It is called "Shadow ssdt" (ssdt ing ), this "keservicedescriptortab leshadow" function is not exported from the system kernel, but it is visible through the external system-level debugger. Shadow ssdt is similar to ssdt itself, but it mainly provides system service functions based on the graphical user interface (GUI) and saves a list of services identical to ssdt, of course, this is also provided for GUI-based program calls. Shadow
SSDT is arranged in win32k. in sys, it is rarely mentioned in the literature, so it is almost a forgotten corner. The authors of Rootkit soon discovered that controlling it can also achieve a certain effect, because ShadowSSDT also has all the functions of SSDT, but it only requires a few more steps to use it, so RK has a new gameplay. This time, it is ARK dumb's turn, at that time, ARK did not achieve the Shadow SSDT step at all, so it only caught the Rootkit of Shadow SSDT and allowed users to discover how malicious programs can recover SSDT, this type of Rootkit is always not affected!

In this case, the ARK tool with the Shadow SSDT detection function will not end, for example, the well-known RootKit Unhooker (RKU), its powerful SSDT and its Shadow detection decoupling function, helping many people solve these new moles, so the Rootkit authors began to seek new ways to survive. Because of the late appearance of such hooks, many popular arks did not cover this part. Therefore, we can only operate on them using tools such as RKU and.

Run RKU (Rootkit Unhooker). It is an English software, but the operation is very simple. Click "Shadow SSDT". If there is a Shadow SSDT Hook in the system, you will find that "Services/Hooked" in the status bar at the bottom of the software is no longer in the "xxx/0" status, at the same time, in the row displayed by the Hook function, the "Hooked" column is "Yes". Now, write down the location and address of the file and click "UnHooked ALL". Next, delete the file.

 

Approaching peak: Inline Hook

What is the most ridiculous thing in the world? It was a road card that was deliberately messed up and went in the wrong direction. Why didn't I notice a problem? Or have the men's and women's restrooms been replaced by a prank by a friend? If you visit the temple one day and find that there is a pure Taoist chanting in it, you will be amazed. This is ridiculous! In the field of fanatic Rootkit, similar ridiculous elements are being spread, that is, the advanced Hook form-Inline Hook. In the initial operation process, all function operations configured with hooks will eventually be processed in the original function module. After all, third-party program writers are not Windows System writers, in order to ensure the normal operation of the system, the most sensible way is to let the intercepted function requests go through the layer-by-layer detection of Self-compiled modules and find harmless, immediately send the request for normal work to the place where it is working, so that the system can complete the entire workflow. Therefore, everyone is playing the idea of SSDT and other places, it is to put a foot in this road, and strive to trip the passers-by WHO are not pleasing to the eye. But now there are security guards who will cut foot on the road. What should I do? However, meeting the challenge is exactly what every investigator is interested in, so the absurd idea brings out a terrible technology, which is InlineHook.

As a matter of fact, Inline Hook has long existed as an advanced Hook Technology. Some special programs on the user layer, such as game plug-ins, in order to obtain the most complete and reliable data, they no longer use the incorrect path card method to transfer data, because it is likely that the handler set by the program writer for this issue will eventually fail. So how can we make this handler unable to meet the trigger condition? That is, do not hook this program, but if you do not hook the program, how do you obtain the relevant data? In this mode of thinking, a new hook technology was born: although it is playing with hooks, it is not intended to hook the target program, instead, the corresponding API functions in the system are destroyed. Because the author of any common program absolutely trusts the system API, when their program requests to call the relevant API and sends parameters together, the corresponding module providing this API is hooked up, its "prophet"-The proviser gets the data content first, and then it has to look at the author's programming skills to determine the life and death of the program, because the author cannot write the corresponding system functions by himself, he must try to send the data back to the original function execution module. If this step is slightly incorrect, the program that calls this API will crash and exit.

For this reason, InlineHook is a more complex technology than general hooks, unless the author has a deep programming skills and a deep understanding of the system, otherwise, using this technology in large quantities is prone to problems. Not only is it difficult for victims, but attackers cannot obtain the data they need. Since the use of Inline hooks on the user layer (Ring 3) requires such attention, is there anyone who eats crabs in the Rootkit world? The answer is yes. When both SSDT and Shadow SSDT are blocked, Rootkit Technology finally took a step towards Inline Hook.

Imagine that when all the detection tools are at the mark of "Hu Shi SSDT", a Rootkit has already replaced the sensitive functions in the system kernel with its own functions, when the function operation request at the user layer finds the execution subject of the corresponding kernel state function through the normal SSDT, but does not know that the execution subject has been replaced by the Rootkit impersonate, what will happen? Although all the detection tools report normal conditions, the Rootkit has already been installed in the machine. If the Rootkit preset the logic of destructive behavior at a certain time point, the user will wait until the moment the system goes wrong, I still don't know what happened!

The Inline Hook at Ring 0 is very concealed. Unless the investigator has a deep understanding of the system, he cannot find out why he wants to break his head, let alone the concept of killing a process is confusing to common users. However, the use of InlineHook requires a price. Due to the complexity of the kernel, especially because the functions at this layer must be called frequently by all programs, if the hooks are not fully considered, as a result, an InlineHook function is accidentally called directly, causing serious consequences. Therefore, whether the Rootkit using InlineHook can work normally and stably is closely connected to the author horizontally. An immature user-layer Inline
If the Hook program is too big, it will cause a memory error along with the program to be monitored, leading to abnormal exit of illegal operations. That's all, but at the system core layer, there is no error detection module here to ensure that your program will stop before it will cause a kernel crash-this is already the bottom layer, A wrong memory read/write will directly lead to kernel-level crashes, which is commonly known as "BSoD, Blue Screen of Dealth ). As a result, the cost of immature Inline Hook Rootkit is that the system becomes unstable. in the user's opinion, the symptoms displayed by the computer are inexplicably easy blue screens, this is the consequence of the immature Rootkit, but the cost is borne by the affected users.

However, the currently popular Inline HookRootkit has basically appeared after numerous blue screen tests on the developer's machine, users do not frequently use blue screens because of the existence of these Rootkit, and it has become the mainstream technology of the current Rootkit. To deal with the Inline Hook, you can do it either by yijian, RKU, or Wsyscheck. Take xiaojian as an example, click "extended functions" on the main interface of the program, and then click "SSDT check ", you will suddenly feel dazzled, so right-click and choose "filter suspicious items" to display the exception section only (note the SnipeSword. sys, which is the drive of xiaojian itself. Do not make a mistake.) If the system has an exception, related descriptions such as HOOK and Inline-HOOK will be listed in "Hook type, first, right-click and select
"Restore all hooks" and refresh it once. If abnormal projects are still listed, right-click the corresponding project column and choose "Restore selected Inline-HOOK.

Tightly wound parasitic vine: FSD Hook

As the struggle between RK and ARK progresses, the SSDT Hook (including Shadow Hook) road is cleared, and InlineHook is also pulled out, but some users are surprised to find that, they still cannot delete these files that are already exposed under their eyes. Why?

Before explaining this question, let's take a look at some concepts. The operating system has done a lot of work behind the scenes to allow users to directly access the computer world by tapping the keyboard, clicking the mouse, and inserting a USB flash drive, these functions are aggregated at the underlying layer and finally an available operating platform is established. The part responsible for managing disk data and reading and writing files is called the "File System" (file system, FS). Windows operating systems use IOs (input/output supervisor, input/output hypervisor) technology for file system management. It takes over all storage settings, such as hard disks, removable disks, and optical drives.

IOS is a hierarchical management solution that displays the read and write operations of various applications on the user layer, the next layer is followed by the interface layer called "installable File System (IFS)". This layer is the final convergence of the following layers, that is, we can see the disk drive letters, drive letters, USB flash drive letters, Network Disk ing letters, and other icons on the screen and operate on them. After ifs, It is the layer where various file system drivers are located, that is, "FSD" (File System driver, file system driver). This layer is directly connected to IOS, it is used to accept and process data in the task assignment. the next layer of FSD goes directly to iOS, And the next layer of data in IOS begins to develop towards hardware. The goal of this rootkit is to reach the last layer before IOs: FSD.

FSD is the most in-depth area open to programmers in Windows (the driver and hardware vendor provided by the operating system itself, the permissions at this layer are very high. With this level of control, developers can master the most comprehensive file read/write operation control. Therefore, when all the roads were blocked by the An Ti-rootkit tool, the rootkit author began to resist by blocking their tools to directly kill the obtained rootkit.

FSD is not an absolute ban. Before that, anti-virus vendors and Disk Data Encryption vendors have already been dedicated to this layer. Some people are dedicated to writing their own FSD, and more people, FSD Filter Driver (File System Driver Filter) is compiled to analyze their sensitive data for other work. One of the key points of the Filter Driver is to hook FSD, that is, "FSD Hook ". After FSD is mastered by you, you can control others' file read/write requests by manipulating its data. For Rootkit, they can set some sensitive files, such as their own driver files and user-layer related files, to the user layer, which cannot be read and written by programs other than themselves, it is directly reflected that it cannot be edited, renamed, or deleted.

With this technology, the Rootkit authors can smile again, because even if the user finds it by various means and terminates its process, he cannot operate on the protected files. However, hooks are always hooks, and some people always decouple them. After the ARK tool used to restrain FSD Hook Technology appeared, some people gave up on FSD, which is very difficult to operate, this layer can easily cause system instability. However, some people continue.

How can I clear this type of Rootkit?

Take the easiest Wsyscheck as an example. Run Wsyscheck first (you will find an interesting phenomenon: IceSword cannot detect Wsyscheck hooks because it uses Inline and FSD hooks ), click "kernel check", select "FSD check", and check whether there are items marked as "Yes" in "code exception". If Yes, right-click the item on the interface, select "Restore all functions ". The Wsyscheck Process List does not use the IceSword logic. Therefore, do not be too nervous if you see a red list, it only indicates that this program is an application without system signature verification and has special types (such as services and loading drivers). It is not a "bad guy identification" like IceSword ".

Extreme technology: FSD Inline Hook

Rootkit has reached the FSD Hook layer, and the impact on the system is already quite dangerous. However, due to the emergence of confrontation tools that have touched the interests of some people, finally, A famous rogue software eats the FSDInline Hook, which everyone will not touch because of their uneasy conscience. Putting hooks in an important and sensitive FSD environment is a very demanding task. Instead, you can use your own functions to replace the system functions in this minefield, many people think that operations are strictly prohibited. But now, some people take the lead in violating the rule. What will happen in the future?

Therefore, CNNIC's listing all the research objectives of the current rogue software author is not accurate, because CNNIC has a variety of Advanced Technologies