Cybercrime Fantastic Rootkits

[Andy Ful]

I skipped the technical details in this thread. The link to the full article:

Fantastic Rootkits: And Where to Find Them (Part 1)

Introduction In this blog series, we will cover the topic of rootkits — how they are built and the basics of kernel driver analysis — specifically on the Windows platform. In this first part, we...

www.cyberark.com

...
From the mid-2000s until the mid-2010s, rootkits were extremely popular; this era is considered to be the golden age of rootkits.

Examples such as Rustock, TDSS (aka Alureon), ZeroAccess, Sinowal and more have roamed freely on infected systems around the world without notice.

These rootkits were cyber crime-operated rootkits for financial gain and not nation-state sponsored, as one might think today.

Since there were no mitigations, such as patch guard or code integrity in Windows XP x86 and Windows 7 x86, rootkits could have made whatever change to kernel structures they wanted.

One of the techniques used by those rootkits of old (x86 era) was Hooking the System Service Descriptor Table (SSDT), which was very common and used by many rootkits of that era, as well as by AV products.

Unlike during those golden years, now we rarely ever see new emerging rootkits for Windows. This is due to the aforementioned mitigations and the complexity involved in developing a working rootkit and bypassing all the mitigations.

When a new rootkit is discovered in the wild, it is usually tied with a nation-state actor such as with Turla and Derusbi.

Looking at the MITRE ATT&CK matrix, we can find “Rootkit” (T1014) tactic category under “Defense Evasion” group, but, unfortunately, it completely lacks crucial level of detail with exactly zero sub-techniques.

The reason rootkits require more defenders’ focus is that they are so incredibly valuable to attackers. This is because once a rootkit is successfully deployed, attackers can hide their presence while maintaining access to the compromised system (achieving persistence).

Rootkits are usually divided into two basic types, based on their privilege level:

• Kernel-Mode (KM) Rootkits – This is the typical rootkit. KM rootkits run as a highly privileged user (NT AUTHORITY\SYSTEM) in the kernel itself and can modify kernel structures in memory to manipulate the OS and hide itself from Avs, etc. In Windows, this would typically mean running as a kernel driver.
• User-Mode (UM) Rootkits – UM rootkits are rootkits that do not have a kernel-mode component. They would hide their presence on the system by using user-mode techniques and APIs that manipulate the OS, such as Hooking, Process Injection, UM rootkits don’t fall into the classic rootkit definition, as they are not necessarily running as “root” (although they might require administrator access to work properly) or a different superuser, for that matter. These days, many modern malware families contain some form of a user-mode rootkit component, as they usually try to evade detection and removal by AVs and the users themselves.
  
  In this article, we will focus on kernel-mode rootkits and the techniques they use to evade AVs and hide in the OS by manipulating the Windows kernel.
  
  Understanding these techniques is essential to blue-team members to fully defend an organization from such sophisticated attacks and to recover from such an attack in case of a breach.
  ...

...
In the past, loading a driver and changing kernel structures has been easy to execute by an attacker without too many worries, but since the introduction of mitigations such as KPP (Kernel Patch Protection aka Patch Guard) in Windows XP/Vista x64, these have become relatively scarce.

Patch Guard is a mechanism that protects kernel structures (like SSDT and IDT mentioned later) from being changed in memory or “patched” by an attacker. It periodically checks each kernel structure for changes; if a change occurred, it would cause the system to BSOD with Bug Check CRITICAL_STRUCTURE_CORRUPTION (0x109) or KERNEL_SECURITY_CHECK_FAILURE (0x139).

Nowadays, before making any changes to system structures, attackers would have to find a way to disable or bypass Patch Guard or risk crashing the system.

It is also important to note that since Patch Guard works in a periodic manner, if an attacker manages to revert their changes before the next check it would not trigger a BSOD. This is useful for changing a kernel structure such as the SMEP flag, CR4’s 20th bit, when an attacker could turn off the flag, execute their malicious code and immediately turn the flag back on to avoid the bug check.

In the past, we’ve seen the following technique used by Turla/Urobrous to bypass Patch Guard. The attackers used a hook in KeBugCheckEx to resume the execution after the bug check happened, effectively suppressing the BSOD.

Then, after Microsoft patched this hole, the attackers hooked a different function, RtlCaptureContext, which is called by KeBugCheckEx to similarly resume the execution without BSOD-ing the system.

Another method to bypass Patch Guard is described in this latest article by Kento Oki from 2021. In addition, CyberArk Labs found a bypass to Patch Guard a few years ago.

Another feature that was introduced to Windows — one that has contributed to the decline of rootkits — is DSE (Driver Signature Verification a.k.a Code Integrity verification) for drivers that basically checks that a driver is signed by a trusted certificate authority before loading it.

DSE makes it even harder for attackers to load a driver, as they would have to bypass this mitigation too — either by getting their hands on such a certificate, which they could use to sign their driver, or by exploiting the mechanism in such a way that would bypass it.

An example of a Patch Guard+DSE bypass can be found here.

There are also some older Digital Signing Enforcement/Code Integrity bypasses by hfiref0x, such as DSEFix and TDL (Turla Driver Loader).

It is important to note that any bug in a rootkit (such as an ACCESS_VIOLATION) would immediately trigger a BSOD. Zero bugs are allowed, so this is one of the reasons for the certain scarcity of rootkits, as developing and deploying one requires high level of expertise and mature development process that lone actors most often don’t possess.
...

...

Conclusion​

In this blogpost, we have deep dived into the topic of rootkits. We’ve seen a few example implementations of different rootkit functionality and covered the reasons behind each one, ultimately taking control over a system without leaving any clues for the victim to know that their machine has been compromised.

We uncovered why writing such rootkits takes skills and resources that are mostly only available to the large cyber operations that nation-state actors have. We believe that MITRE ATT&CK matrix is missing details about rootkits sub-techniques in their “Defense Evasion” section, and this set of tactics should be detailed further to provide the defenders with the necessary level of information for their defensive strategy development.

Increased awareness of such attacks and the risk they pose on organizations should drive organizations to take the necessary steps to defend themselves against such threats.

We recommend that organizations take the following steps to avoid such attacks:

1. Never disable Patch Guard (KPP).
2. Never disable Driver Signing Enforcement.
3. If possible, turn on VBS and HVCI through Group Policy (Enable virtualization-based protection of code integrity).
4. Appy Microsoft’s driver blocklist (Microsoft recommended driver block rules).
5. Never install unnecessary drivers or drivers from unknown sources.
6. Avoid having users with local admin privileges.
7. Install an EDR on the organization’s machines to mitigate and detect anomalous behavior.

 

[Andy Ful]

I would like to quote the important fragment from the article:

Unlike during those golden years, now we rarely ever see new emerging rootkits for Windows. This is due to the aforementioned mitigations and the complexity involved in developing a working rootkit and bypassing all the mitigations.

When a new rootkit is discovered in the wild, it is usually tied with a nation-state actor such as with Turla and Derusbi.

 

[ForgottenSeer 69673]

OMG Andy. I remember those old rootkits well. was the POC child of EP_Xoff and MP_ART and HolyFather from Rootkit .
Brings back some old memories. the creater of Gmer and Unhackme used to argue all the time with those guys.LOL

Thanks