Hello everyone,
Today I am here with this thread regarding kernel-mode and user-mode rootkits. I will start with kernel-mode rootkits, and then afterwards I will introduce user-mode rootkits. I will also explain the differences between user-mode and kernel-mode/rootkits.
Before I go any further, I will try to make this thread easier by explaining the differences between kernel-mode and user-mode, not all of them, just some basics to make this thread a bit easier to understand:
1). In kernel-mode you have access to all of the memory, and hardware. This is why when a crash occurs in kernel mode, it results in a BSOD crash. Whereas, in user-mode, each process is allocated it's own virtual memory - this is to ensure that if one user-mode process with it's own "virtual memory" crashed, not all the processes would crash and a system restart would not be necessary. A Virtual address for the memory point to the real memory address. If a user-mode process crashes, only that program will crash (e.g. Stopped Responding errors).
2). The lowest level is ring0 (kernel mode). This is where the Operating System Kernel runs (Windows Kernel - hence "kernel mode"). User-mode is ring3, which is where your standard programs like Paint, Calculator, Web Browsers are ran from.
1. What is a rootkit?
If you do not already know what a rootkit is, then do not worry. I will explain to you what a rootkit is; a rootkit is a type of malicious software which has control over the system and where the prescence of it is unknown to the user. The term "root" came from the Unix Operating System, it represents having "root access" to the system. The term "kit" implies that there are a set of tools which can be used as an advantage to execute specific commands on the system. For example, the kit may be the ability to support hiding processes, files and registry keys.
A rootkit can do many things, from hiding processes from process monitoring programs (Task Manager is an example) to hiding files on the hard drive. It's primary task is to have priveleges on the system (power/control over the system), whilst keeping it's prescence unknown to the user. It has to be stealthy and secretive to prevent the user from discovering it's prescence.
2. Kernel-mode rootkits
When it comes to rootkits, you can find some which take advantage of ring0. Ring0 represents what we call "kernel mode", therefore a kernel-mode rootkit uses ring0. How does it use kernel-mode (aka Ring0)? Well, it uses a driver. The driver would be loaded onto the system, and through that it would have control from kernel-mode.
The reason kernel-mode rootkits are loved a lot is due to the fact that one goal of a rootkit (as well as being undetected), is to have "root access"/"priveleges". Since the Windows Kernel executes at kernel-mode, if the rootkit has access to kernel-mode, it will therefore have successed in one of it's goals; having priveleges on the system.
If the rootkit is using ring0, this can be used to the advantage of the rootkit to make life extremely difficult for the user in terms of removal of the rootkit. Firstly, it can protect processes from being terminated - if there is any user-mode malicious software currently executing, it can protect them to prevent the user from terminating them (especially with programs like Task Manager).
If the target user is on a 32-bit system, then the rootkit can take use of something known as SSDT hooking (System Service Dispatch Table) (aka Kernel Patching). When a process calls a function in the WinAPI (like ZwTerminateProcess), since SSDT hooking has taken place, the code in the function the rootkit setup in the driver will be executed. This works by changing the addresses in the SSDT.
As well as this, if you are infected with a rootkit which patches the kernel (changes addresses in the SSDT (hooking)), if the hooking is not cleaned up (malware writers want to do bad, not good, therefore they probably won't even bother with cleaning up their mess), when the driver is unloaded, your system may start throwing up a bunch of BSODs. This would be because a crash occured in kernel-mode; the address in the function which had been hooked by the rootkit in the SSDT would no longer exist because the driver would have been unloaded/removed, therefore it crashes. When a crash occurs in kernel-mode, it results in a BSOD.
32-bit users are actually less protected from rootkits (and bootkits); drivers do not have to be digitally signed to be loaded into kernel-mode, SSDT hooking can occur - this is due to a feature Microsoft called PatchGuard.
On 64-bit systems, drivers must have a digital signature to be loaded into kernel-mode, SSDT hooking is not allowed. In the past, bootkits have managed to bypass PatchGuard, loading a rogue, unsigned driver into kernel-mode (bootkit modifies the Master Boot Record), however Microsoft managed to patch this up.
From Windows Vista and upwards, a driver is required to access and make modifications to the Master Boot Record. However, on a 32-bit system of course, then a rogue driver can be loaded to perform this action. Unlike on a x64 system.
From Kernel-Mode, rootkits can protect themselves (they can do this from ring3, I'll suggest how they do this from ring3 later on in the thread). If the system is 32-bits they can alter the addresses in the SSDT to certain functions: ZwTerminateProcess, ZwOpenProcess, ZwSuspendProcess, ZwAllocateVirtualMemory and block the use to their process. If the system is 64-bit, due to PatchGuard, they cannot use SSDT hooking so they can work with a callback known as ObCallback. They can use this to prevent process termination, process suspension, DLL injection, Code Injection, and other methods to their "protected" process.
If there is ring3 malware currently executing, it can send to the driver (for example, if the ring3 malware wanted to block termination of a process it could send the path to the driver, the driver could terminate the process and then use PsSetCreateProcessNotifyRoutine to montior process execution, blocking that program when it's going to be ran/is ran).
The same applies to the driver sending back to the user-mode process. This can happen, too.
If the rootkit wanted to hide a process from Task Manager, it could hook ZwQuerySystemInformation.
There is actually a very powerful hook a user-mode rootkit could use: KiFastSystemCall. Antivirus/Antimalware software can also use this, though, but for good instead of bad of course. It would be useful for a very useful and effective ring3 security product.
User-mode rootkits
A user-mode rootkit does not run in ring0 (kernel-mode), instead, it takes use of ring3 (user-mode). A popular technique would be DLL injection, the other Code Injection. A technique which is often used is IAT (Import Address Table) hooking. The IAT contains the addresses to all the functions you use in the program, however using IAT hooking, you overwrite the address in the IAT for that program, meaning it will go to your address instead of the original, allowing you to execute code when the function is called.
Rootkits can use this technique from ring3 for all sorts: intercepting file creation/removal, process termination/suspension/opening, registry modifications, and other things. It can be very powerful and effective is used correctly.
I will leave it here for User-Mode rootkits, and now give some examples about uses:
User gets a warning that they have an outdated Adobe Flash Player, and need to update > they fall for the trick and decide to download the fake update > the user runs the fake update with Administrator Priveleges > it's really a Trojan Downloader, and starts downloading more malicious software > the user is wondering why it hasn't shown anything on-screen but they decide to go to the toilet > they return a few minutes later, but what has actually happened is the Trojan Downloader has downloaded a rootkit and loaded it on the system, alongside other malicious software such as: keyloggers, worms. They now have a rootkit, a keylogger (stealing login credentials) and a worm which is spreading across the network and all the drives on the system (including the USB drive with the users work assignments he needed to hand in tomorrow at his workplace). As well as this, the Trojan Downloader adds itself to startup (as do the other malicious software which were downloaded). On startup, when the Trojan Downloader is executed, it decides to download more malicious software (different from the first bunch).
The rootkit (loaded in kernel-mode) is protecting the keylogger and worm host process(es) from being terminated as much as it can. However, it has also hid the processes from Task Manager using a hook. It has also hid it's view from Windows Explorer so the user cannot see the main host executables to the infection (the keylogger and worm), but they continue to work in the background, and the user is not a very advanced user and knows nothing on security, so he has no idea what is causing the slowdown on his PC. The rootkit then sets protection to the host infection processes (keylogger, worm) for the registry (to prevent the startup keys from being removed).
NOTE: The USB (removable device) will make use of autorun to execute when the device is inserted.
Do you see what has happened now? He is in an even bigger mess. The rootkit is stopping him from being aware from the processes and cleaning things out himself if he attempted too since he does not know how to do it properly or even understand what is actually going on, but at the same time, he is logging into his accounts (banking, social networks) and this information is being stolen by the keylogger which is protected by the rootkit.
Extra notes:
- Did you know, Sony once made use of a rootkit? It was to prevent copyright, however it just created more issues. In fact, malware could have actually abused what Sony had done since it created more vulnerabilities for malicious software. After this, I did not trust them that much. The fact that the user was unaware of the prescence of this activity occuring, defines it as a rootkit.
- Rootkits need a loader to operate. If it's a kernel-mode rootkit, it needs a loader to load it's driver. If it's a user-mode rootkit, it needs it's loader to inject DLL/code into a target process/get things going.
Cheers.
Today I am here with this thread regarding kernel-mode and user-mode rootkits. I will start with kernel-mode rootkits, and then afterwards I will introduce user-mode rootkits. I will also explain the differences between user-mode and kernel-mode/rootkits.
Before I go any further, I will try to make this thread easier by explaining the differences between kernel-mode and user-mode, not all of them, just some basics to make this thread a bit easier to understand:
1). In kernel-mode you have access to all of the memory, and hardware. This is why when a crash occurs in kernel mode, it results in a BSOD crash. Whereas, in user-mode, each process is allocated it's own virtual memory - this is to ensure that if one user-mode process with it's own "virtual memory" crashed, not all the processes would crash and a system restart would not be necessary. A Virtual address for the memory point to the real memory address. If a user-mode process crashes, only that program will crash (e.g. Stopped Responding errors).
2). The lowest level is ring0 (kernel mode). This is where the Operating System Kernel runs (Windows Kernel - hence "kernel mode"). User-mode is ring3, which is where your standard programs like Paint, Calculator, Web Browsers are ran from.
1. What is a rootkit?
If you do not already know what a rootkit is, then do not worry. I will explain to you what a rootkit is; a rootkit is a type of malicious software which has control over the system and where the prescence of it is unknown to the user. The term "root" came from the Unix Operating System, it represents having "root access" to the system. The term "kit" implies that there are a set of tools which can be used as an advantage to execute specific commands on the system. For example, the kit may be the ability to support hiding processes, files and registry keys.
A rootkit can do many things, from hiding processes from process monitoring programs (Task Manager is an example) to hiding files on the hard drive. It's primary task is to have priveleges on the system (power/control over the system), whilst keeping it's prescence unknown to the user. It has to be stealthy and secretive to prevent the user from discovering it's prescence.
2. Kernel-mode rootkits
When it comes to rootkits, you can find some which take advantage of ring0. Ring0 represents what we call "kernel mode", therefore a kernel-mode rootkit uses ring0. How does it use kernel-mode (aka Ring0)? Well, it uses a driver. The driver would be loaded onto the system, and through that it would have control from kernel-mode.
The reason kernel-mode rootkits are loved a lot is due to the fact that one goal of a rootkit (as well as being undetected), is to have "root access"/"priveleges". Since the Windows Kernel executes at kernel-mode, if the rootkit has access to kernel-mode, it will therefore have successed in one of it's goals; having priveleges on the system.
If the rootkit is using ring0, this can be used to the advantage of the rootkit to make life extremely difficult for the user in terms of removal of the rootkit. Firstly, it can protect processes from being terminated - if there is any user-mode malicious software currently executing, it can protect them to prevent the user from terminating them (especially with programs like Task Manager).
If the target user is on a 32-bit system, then the rootkit can take use of something known as SSDT hooking (System Service Dispatch Table) (aka Kernel Patching). When a process calls a function in the WinAPI (like ZwTerminateProcess), since SSDT hooking has taken place, the code in the function the rootkit setup in the driver will be executed. This works by changing the addresses in the SSDT.
As well as this, if you are infected with a rootkit which patches the kernel (changes addresses in the SSDT (hooking)), if the hooking is not cleaned up (malware writers want to do bad, not good, therefore they probably won't even bother with cleaning up their mess), when the driver is unloaded, your system may start throwing up a bunch of BSODs. This would be because a crash occured in kernel-mode; the address in the function which had been hooked by the rootkit in the SSDT would no longer exist because the driver would have been unloaded/removed, therefore it crashes. When a crash occurs in kernel-mode, it results in a BSOD.
32-bit users are actually less protected from rootkits (and bootkits); drivers do not have to be digitally signed to be loaded into kernel-mode, SSDT hooking can occur - this is due to a feature Microsoft called PatchGuard.
On 64-bit systems, drivers must have a digital signature to be loaded into kernel-mode, SSDT hooking is not allowed. In the past, bootkits have managed to bypass PatchGuard, loading a rogue, unsigned driver into kernel-mode (bootkit modifies the Master Boot Record), however Microsoft managed to patch this up.
From Windows Vista and upwards, a driver is required to access and make modifications to the Master Boot Record. However, on a 32-bit system of course, then a rogue driver can be loaded to perform this action. Unlike on a x64 system.
From Kernel-Mode, rootkits can protect themselves (they can do this from ring3, I'll suggest how they do this from ring3 later on in the thread). If the system is 32-bits they can alter the addresses in the SSDT to certain functions: ZwTerminateProcess, ZwOpenProcess, ZwSuspendProcess, ZwAllocateVirtualMemory and block the use to their process. If the system is 64-bit, due to PatchGuard, they cannot use SSDT hooking so they can work with a callback known as ObCallback. They can use this to prevent process termination, process suspension, DLL injection, Code Injection, and other methods to their "protected" process.
If there is ring3 malware currently executing, it can send to the driver (for example, if the ring3 malware wanted to block termination of a process it could send the path to the driver, the driver could terminate the process and then use PsSetCreateProcessNotifyRoutine to montior process execution, blocking that program when it's going to be ran/is ran).
The same applies to the driver sending back to the user-mode process. This can happen, too.
If the rootkit wanted to hide a process from Task Manager, it could hook ZwQuerySystemInformation.
There is actually a very powerful hook a user-mode rootkit could use: KiFastSystemCall. Antivirus/Antimalware software can also use this, though, but for good instead of bad of course. It would be useful for a very useful and effective ring3 security product.
User-mode rootkits
A user-mode rootkit does not run in ring0 (kernel-mode), instead, it takes use of ring3 (user-mode). A popular technique would be DLL injection, the other Code Injection. A technique which is often used is IAT (Import Address Table) hooking. The IAT contains the addresses to all the functions you use in the program, however using IAT hooking, you overwrite the address in the IAT for that program, meaning it will go to your address instead of the original, allowing you to execute code when the function is called.
Rootkits can use this technique from ring3 for all sorts: intercepting file creation/removal, process termination/suspension/opening, registry modifications, and other things. It can be very powerful and effective is used correctly.
I will leave it here for User-Mode rootkits, and now give some examples about uses:
User gets a warning that they have an outdated Adobe Flash Player, and need to update > they fall for the trick and decide to download the fake update > the user runs the fake update with Administrator Priveleges > it's really a Trojan Downloader, and starts downloading more malicious software > the user is wondering why it hasn't shown anything on-screen but they decide to go to the toilet > they return a few minutes later, but what has actually happened is the Trojan Downloader has downloaded a rootkit and loaded it on the system, alongside other malicious software such as: keyloggers, worms. They now have a rootkit, a keylogger (stealing login credentials) and a worm which is spreading across the network and all the drives on the system (including the USB drive with the users work assignments he needed to hand in tomorrow at his workplace). As well as this, the Trojan Downloader adds itself to startup (as do the other malicious software which were downloaded). On startup, when the Trojan Downloader is executed, it decides to download more malicious software (different from the first bunch).
The rootkit (loaded in kernel-mode) is protecting the keylogger and worm host process(es) from being terminated as much as it can. However, it has also hid the processes from Task Manager using a hook. It has also hid it's view from Windows Explorer so the user cannot see the main host executables to the infection (the keylogger and worm), but they continue to work in the background, and the user is not a very advanced user and knows nothing on security, so he has no idea what is causing the slowdown on his PC. The rootkit then sets protection to the host infection processes (keylogger, worm) for the registry (to prevent the startup keys from being removed).
NOTE: The USB (removable device) will make use of autorun to execute when the device is inserted.
Do you see what has happened now? He is in an even bigger mess. The rootkit is stopping him from being aware from the processes and cleaning things out himself if he attempted too since he does not know how to do it properly or even understand what is actually going on, but at the same time, he is logging into his accounts (banking, social networks) and this information is being stolen by the keylogger which is protected by the rootkit.
Extra notes:
- Did you know, Sony once made use of a rootkit? It was to prevent copyright, however it just created more issues. In fact, malware could have actually abused what Sony had done since it created more vulnerabilities for malicious software. After this, I did not trust them that much. The fact that the user was unaware of the prescence of this activity occuring, defines it as a rootkit.
- Rootkits need a loader to operate. If it's a kernel-mode rootkit, it needs a loader to load it's driver. If it's a user-mode rootkit, it needs it's loader to inject DLL/code into a target process/get things going.
Cheers.
