T1547.006 Kernel Modules and Extensions is a technique in the MITRE ATT&CK framework under the Persistence tactic. It refers to the use of kernel modules in Linux (Loadable Kernel Modules, or LKMs) and kernel extensions in macOS (kexts) to extend the core functionality of the system’s kernel without requiring a reboot.
These modules and extensions enable the dynamic addition of capabilities directly into the kernel, such as providing hardware support, adding file system extensions, and performing other low-level operations within the kernel’s domain. By modifying or adding kernel modules, systems can be adapted or extended to support specific functionality or features.
To read about other sub-techniques of the T1547 Boot Logon or Auto Start Execution technique, you can visit the related hub blog.
Adversaries exploit kernel modules and kernel extensions to gain persistence and privilege escalation by modifying the kernel to execute malicious code during system boot. This technique targets LKMs in Linux and kexts in macOS, both of which allow attackers to extend the kernel’s functionality without the need for a reboot.
By loading malicious modules or extensions into the kernel, adversaries can maintain persistent access to a compromised system, ensuring that malicious programs execute automatically on system startup. This method can also allow attackers to escalate privileges, as kernel-level access provides the ability to bypass security controls and execute actions at the highest level of the operating system.
To understand the potential dangers of kernel-level exploitation, we consider a scenario where an adversary has already gained access to a Linux system and escalated privileges to root, a critical prerequisite for loading kernel modules. With root access, the adversary can write a malicious Loadable Kernel Module (LKM) in C, specifically designed to perform nefarious tasks such as hiding files and processes, establishing backdoors, or granting unauthorized root access. To ensure seamless integration with the system, the malicious module is compiled using Linux kernel headers to maintain compatibility with the running kernel version.
A particularly sophisticated example of this type of attack is the Snapekit rootkit [1]. Snapekit exemplifies the potential severity of kernel-level threats, leveraging advanced techniques to infiltrate Linux systems with exceptional stealth. Delivered via a specially crafted dropper, it strategically unpacks the snapekit.ko* module into the /lib/modules/ directory, ensuring its kernel-level insertion is both effective and covert.
What makes Snapekit especially dangerous is its use of advanced obfuscation methods, such as spoofing process names, masquerading as legitimate system processes like kworker, and exploiting Linux capabilities to escalate privileges further.
|
SHA256*: 571f2143cf04cca39f92c67a12ea088bf0aee1161f490e1f8a935019939d56cb |
The rootkit's core objective is comprehensive system obfuscation, effectively concealing files, processes, and network activities from monitoring tools. This level of stealth makes Snapekit extremely difficult to detect, enabling persistent unauthorized access and prolonged exploitation of compromised systems.
For this technique, adversaries first develop a malicious kernel extension (kext) for macOS, typically written in C or C++. This kext is designed to carry out malicious actions, such as establishing backdoors, hiding files, or intercepting user activities. They compile the kext using Xcode, Apple's integrated development environment, with a command like:
|
xcodebuild -target [KextNameDecided] -configuration Release |
This command compiles the kext against macOS kernel headers, ensuring compatibility with the targeted macOS version.
Next, to bypass macOS's security measures, adversaries must address the signing of the kext. Ideally, they use a developer ID certificate granted by Apple, but this is often not feasible for malicious activities. Therefore, they might target systems with System Integrity Protection (SIP) disabled, allowing unsigned kexts to be loaded. Alternatively, they may use social engineering or other methods to trick users into disabling SIP.
With SIP disabled, the adversary then loads the kext into the system using the kextload command:
|
sudo kextload /path/to/malicious.kext |
Once the kext is loaded, it operates with kernel-level privileges, providing the adversary with significant control over the system. This can include executing code with elevated privileges, modifying system processes, or remaining hidden from traditional security tools.
[1] A. Ishiaku, “Snapekit detection with,” Wazuh, Oct. 30, 2024. Available: https://wazuh.com/blog/snapekit-detection-with-wazuh/. [Accessed: Dec. 09, 2024]