Theory about hiding processes by rootkits (DKOM)
In this article we will try to consider in theory one of the most serious methods of hiding information by rootkits, namely direct kernel object manipulation (DKOM ), used to conceal processes from the operating system as a whole. If you are a script kiddie , then read “we are hiding processes in Windows!”. Start over:
In our case, the rootkit is a kernel module (in the case of Windows , a driver) used to expand the capabilities of managing the operating system (after all, root and kit). We will not distinguish whether the administrator or the attacker uses it. The rootkit runs on the zero ring (the so-called ring0 ) of the operating system. In the case of Windows, it requires correct (not necessarily documented methods) installation in the system, which, as a rule, requires administrator rights. Note that by objects we mean in-memory structures that describe one process in the operating system (I will shift the blame for the confusion in terms to the documentation from Microsoft). In RAM, information about running processes is stored in a doubly linked list of these very objects.
Closer to the code
Actually for WinXP, on the rest that are older than NT, I think the same.
And so, we are already in ring0 (how we got here is another story). We are a processor based on the code of the implemented driver and we got into the function of hiding the process with one argument - pid using DKOM. To get to the legendary doubly linked list of processes, we need to find at least one item from this list. Search by brute force is not rational, especially when we can find a pointer to our own process. Let's see how we do it. In the course of the code, we encounter the PsGetCurrentProcces function. Fortunately, we are a processor and we know that this is nothing more than
In the fs register at offset 0x124, nothing more than the current flow ETHREAD structure, in which at offset 0x44 there is a pointer to the structure of the process that owns this thread. This way we get a pointer to our process. Then everything is simple. In each structure there is a pointer to the previous and the next process in the process chain. Run over the signs to the process with the required pid. When executing a trivial manipulation of pointers, excluding the process from the doubly-connected list makes the OS forget about the existence of the process (at least while it is watching with its ordinary methods). Ares on the hidden process, you can remember, in case we want to return it to the system.
Anticipating the question, I answer: the hidden process continues to function normally because the OS allocates processor time not to processes but to threads.
')
Conclusions
In principle, the detection of this fraud is not an impossible task. However, most antiviruses arrive in peace of mind, both when contemplating the driver itself and during its execution.
This is not the only method of hiding processes by rootkits. But DKOM stands out among them as one of the most imperceptible (probably not for long it will be), since it works directly on the processed data, and not on the means of processing it. Also note that DKOM is relevant not only for processes.
PS
Everything is rather abstracted in order to bring information to the widest possible circle. It would not be nice to load with technical details not for everyone, but for those who are interested, they can easily be naked.
I thought for a long time which blog I should take, I chose between system programming and this. But the topic of programming here is almost not disclosed, so I chose this one as information about how it happens ...
If it will be interesting, I will tell about other popular methods.
In our case, the rootkit is a kernel module (in the case of Windows , a driver) used to expand the capabilities of managing the operating system (after all, root and kit). We will not distinguish whether the administrator or the attacker uses it. The rootkit runs on the zero ring (the so-called ring0 ) of the operating system. In the case of Windows, it requires correct (not necessarily documented methods) installation in the system, which, as a rule, requires administrator rights. Note that by objects we mean in-memory structures that describe one process in the operating system (I will shift the blame for the confusion in terms to the documentation from Microsoft). In RAM, information about running processes is stored in a doubly linked list of these very objects.
Closer to the code
Actually for WinXP, on the rest that are older than NT, I think the same.
And so, we are already in ring0 (how we got here is another story). We are a processor based on the code of the implemented driver and we got into the function of hiding the process with one argument - pid using DKOM. To get to the legendary doubly linked list of processes, we need to find at least one item from this list. Search by brute force is not rational, especially when we can find a pointer to our own process. Let's see how we do it. In the course of the code, we encounter the PsGetCurrentProcces function. Fortunately, we are a processor and we know that this is nothing more than
mov eax, fs:0x00000124
mov eax, [eax + 0x44]
retIn the fs register at offset 0x124, nothing more than the current flow ETHREAD structure, in which at offset 0x44 there is a pointer to the structure of the process that owns this thread. This way we get a pointer to our process. Then everything is simple. In each structure there is a pointer to the previous and the next process in the process chain. Run over the signs to the process with the required pid. When executing a trivial manipulation of pointers, excluding the process from the doubly-connected list makes the OS forget about the existence of the process (at least while it is watching with its ordinary methods). Ares on the hidden process, you can remember, in case we want to return it to the system.
Anticipating the question, I answer: the hidden process continues to function normally because the OS allocates processor time not to processes but to threads.
')
Conclusions
In principle, the detection of this fraud is not an impossible task. However, most antiviruses arrive in peace of mind, both when contemplating the driver itself and during its execution.
This is not the only method of hiding processes by rootkits. But DKOM stands out among them as one of the most imperceptible (probably not for long it will be), since it works directly on the processed data, and not on the means of processing it. Also note that DKOM is relevant not only for processes.
PS
Everything is rather abstracted in order to bring information to the widest possible circle. It would not be nice to load with technical details not for everyone, but for those who are interested, they can easily be naked.
I thought for a long time which blog I should take, I chose between system programming and this. But the topic of programming here is almost not disclosed, so I chose this one as information about how it happens ...
If it will be interesting, I will tell about other popular methods.
Source: https://habr.com/ru/post/118483/
All Articles