A rootkit changes what the operating system reports about itself, so the tools you would normally use to find malware (process lists, file listings, network connection tables) are the very tools it lies to. MITRE ATT&CK tracks this as T1014 Rootkit, a technique in the Stealth tactic (TA0005) on Linux, macOS and Windows. This page takes the technique view for detection engineers and incident responders: what ATT&CK v20 says, the procedure examples it records, the v20 detection analytics and how to test them. The broader topic, including bootkits, Secure Boot and recovery, is covered in the Rootkits and Bootkits Guide, which this page does not repeat.
Key takeaways
- Detect the install, not the rootkit. Once running, a rootkit hides itself from the host. The reliable signal is the moment a driver, kernel module, kernel extension or preload library is added.
- ATT&CK maps no mitigations. The technique page states this type of attack cannot be easily mitigated with preventive controls because it abuses system features. Code signing enforcement and driver blocklists are NHI Mgmt Group recommendations, not ATT&CK mitigations.
- User-mode rootkits are common on Linux. Several v20 procedures (Rocke, Hildegard, Umbreon) hook libc through
/etc/ld.so.preload, which a file watch can catch. - Network devices and hypervisors are targets. ATT&CK records rootkits on Cisco ASA (ArcaneDoor), Juniper routers and guest VMs (UNC3886), where endpoint agents rarely run.
- Cross-view checks beat on-host trust. Compare what the host reports with what you see from outside it: network flows, memory images, offline disk scans.
What the technique covers
ATT&CK v20 (technique version 2.0) describes rootkits as programs that hide the presence of programs, files, network connections, services, drivers and other system components, by intercepting, hooking and modifying operating system API calls that supply system information. Rootkits may reside at user or kernel level, or lower, including a hypervisor or T1542.001 System Firmware. Rootkits that modify boot sectors are tracked separately as T1542.003 Bootkit. T1014 has no sub-techniques.
| Level | How it hides | v20 procedure examples | Install signal |
|---|---|---|---|
| User mode (Linux) | Preloaded shared library hooks libc functions such as readdir() | Rocke, Hildegard, Umbreon, Winnti for Linux (modified Azazel) | Write to /etc/ld.so.preload or new LD_PRELOAD use |
| User mode (service) | Trojanised or hooked service process | Ebury (user land rootkit using the SSH service), Carberp | Changed binaries or libraries of a service |
| Kernel (Linux) | Loadable kernel module hooks system calls | Drovorub, Skidmap, REPTILE, Diamorphine (TeamTNT) | Module load events; kernel taint |
| Kernel (Windows) | Driver hides processes, files and connections | HIDEDRV, Uroburos, Zeroaccess, Stuxnet, Hikit | Driver load (Sysmon 6) and new kernel service (System 7045) |
| Firmware | Persists in UEFI and reinstalls an agent | LoJax (APT28), Hacking Team UEFI Rootkit | Firmware integrity mismatch |
| Network device | Hooks device functions to evade forensics and authentication | Line Dancer and ArcaneDoor (Cisco ASA), COATHANGER | Device integrity check failures, unexpected memory-resident code |
How adversaries use it: real cases
Procedure examples from the ATT&CK v20 data, with the source ATT&CK cites:
- Drovorub (S0502): used a kernel module rootkit to hide processes, files, executables and network artifacts from user space view (NSA and FBI advisory, August 2020). ATT&CK attributes Drovorub to APT28.
- UNC3886 (G1048): used the publicly available REPTILE and MEDUSA rootkits on targeted virtual machines (Google Cloud Mandiant, 2024), and in the RedPenguin campaign (C0056) on Juniper routers (Mandiant, March 2025). MEDUSA also logs credentials. See the UNC3886 Threat Actor Profile Guide.
- ArcaneDoor (C0046): hooked the
processHostScanReply()function on Cisco ASA devices; the Line Dancer implant hooked crash dump and AAA functions to evade forensic analysis and authentication (Cisco, 2024). - TeamTNT (G0139): used the open-source Diamorphine rootkit to hide cryptocurrency mining (Trend Micro, Cisco Talos).
- Skidmap (S0468): a kernel-mode rootkit that hooks system calls to hide files and fake network and CPU statistics so the host always looks idle (Trend Micro).
- APT28 (G0007): used the LoJax UEFI rootkit (ESET, September 2018).
- AI-assisted breach (C0064): ATT&CK v20 records an adversary tasking Claude Code with generating and executing rootkits during an intrusion into Mexican government infrastructure.
Two lessons stand out. Cloud and container hosts running miners are a common place to meet a Linux rootkit, and appliance rootkits are built to defeat the vendor's own forensic and logging functions.
What to detect and where
ATT&CK v20 detection strategy DET0377, Detection of Kernel/User-Level Rootkit Behavior Across Platforms, has three analytics. All three centre on the install step.
| Platform | Analytic (ATT&CK) | Data components and log sources (from ATT&CK) | Practical rule |
|---|---|---|---|
| Windows | AN1061: unauthorised or anomalous kernel driver or DLL loads, concealed services, abnormal boot component changes | Driver Load (Sysmon 6); Service Creation (System 7045); File Creation (Sysmon 11) | New kernel driver service, or a driver load whose signer or hash is new to the estate |
| Linux | AN1062: abnormal kernel module loads, tampering with /dev or /proc, LD_PRELOAD behaviour hiding processes or files | Process Creation (auditd EXECVE); File Modification (osquery file_events); Module Load (syslog kmod) | insmod or modprobe outside patching, any write to /etc/ld.so.preload, new taint flags |
| macOS | AN1063: unsigned kernel extensions, LaunchDaemon tampering, user space hooks into system libraries | Module Load (unified log, kextd subsystem); Service Creation (osquery launch_daemons); File Modification (fsevents, Extensions) | Any new kext or LaunchDaemon on a managed Mac that MDM did not deploy |
Cross-view checks
- Network versus host: flows from a host that has no matching process or socket in its own tables point to hidden connections. Skidmap faked CPU and network statistics, so compare with hypervisor or cloud metrics too.
- Memory analysis: a memory image examined off the host can reveal hidden processes and hooks; see the Memory Forensics Guide and Volatility 3 Guide.
- Offline disk scan: mount the disk from a trusted system and compare the file listing with what the running host reported.
- Kernel taint and module lists: on Linux, the kernel marks itself tainted when an unsigned module loads in permissive mode, a simple fleet-wide signal.
- Appliance integrity tools: use the vendor's integrity checking for firewalls and VPN appliances; see the Ivanti Connect Secure Hardening and Integrity Checking Guide for one example of the approach.
Prevention controls
ATT&CK lists no mitigations for T1014. The controls below are NHI Mgmt Group recommendations that make the install step fail or get noticed, drawn from each platform's documentation. Platforms are listed alphabetically.
| Platform | Control (from platform documentation) | Rollout note |
|---|---|---|
| Linux | Module signature enforcement: with CONFIG_MODULE_SIG_FORCE or module.sig_enforce=1, only modules with a valid signature from a key the kernel holds may load; in permissive mode unsigned modules load and taint the kernel | Check third-party modules (storage, security agents) are signed before enforcing |
| macOS | Apple no longer recommends kernel extensions; system extensions run in user space. On Apple silicon, enabling kexts needs Reduced Security set from recovery with an administrator password, and with System Integrity Protection on each kext's signature is verified | Keep SIP on and Full Security on; approve only MDM-deployed kexts |
| Windows | Microsoft vulnerable driver blocklist, enabled by default since the Windows 11 2022 update and enforced with memory integrity (HVCI), Smart App Control or S mode; Microsoft also recommends the ASR rule "Block abuse of exploited vulnerable signed drivers" | Test App Control policies in audit mode and check CodeIntegrity Operational events before enforcing; a reboot is needed for running drivers |
For deeper detail see the Linux Secure Boot and Shim Guide, the App Control for Business (WDAC) guide and the Bring Your Own Vulnerable Driver and EDR Killers Guide, since a vulnerable signed driver is a common route to kernel code.
Where identity fits
Installing a kernel rootkit needs administrator or root rights, so the identity question is who holds them. Admin and root are often held by automation: configuration management service accounts, CI runners with root on build hosts and cloud instance roles that allow running commands on instances. Several v20 rootkits also steal credentials (MEDUSA logs them; Ebury sits in the SSH service), so assume every credential used on a rootkitted host is exposed. Rotate machine credentials and SSH keys that touched the host, not only human passwords, and limit which automation identities can load drivers or modules at all.
Response when you find one
- Do not trust the host: collect a memory image and network evidence before rebooting, and analyse them on a separate system.
- Scope by install signal: search the fleet for the same driver hash, module name, preload library or kext.
- Rebuild, do not clean: reimage from known-good media; for firmware rootkits follow the Firmware and Bootkit Compromise Playbook.
- Rotate credentials: every human and machine credential used on the host.
- Close the entry path: the rootkit came after an intrusion; find the initial access.
How to test and roll out
- Baseline: inventory loaded drivers, kernel modules, kexts and preload files across the fleet with osquery or EDR.
- Enable telemetry: Sysmon event 6 and System 7045 on Windows, auditd and kmod logging plus a watch on
/etc/ld.so.preloadon Linux, kext and LaunchDaemon events on macOS. - Emulate safely: in a lab, an authorised tester loads a benign test driver or module and a harmless preload library to confirm each analytic fires. Do not run real rootkits outside an isolated lab.
- Enforce in rings: driver blocklist and module signing in audit mode on a pilot ring, then enforce.
- Roll back: switch App Control policies back to audit or remove the enforcing kernel parameter if a needed driver or module is blocked, then sign or allow it explicitly.
Metrics
- Share of Windows endpoints and servers with memory integrity and the driver blocklist enforced.
- Share of Linux hosts with module signature enforcement on.
- Count of driver, module or kext loads not in the baseline, and time to review each.
- Network appliances with a successful integrity check in the last quarter.
Common failure patterns
- Relying on the infected host's view: running the usual process and file listing tools on a rootkitted host returns the rootkit's answer.
- No telemetry for module loads: Linux servers without auditd rules or kmod logging miss the one moment the rootkit is visible.
- Ignoring preload files: user-mode Linux rootkits need only one file change.
- Treating appliances as black boxes: ArcaneDoor and UNC3886 targeted devices where no EDR runs.
- Cleaning instead of rebuilding: removing visible artefacts leaves hooks and firmware implants in place.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1014; TA0005 Stealth; DET0377 | Technique and detection strategy |
| MITRE ATT&CK (related) | T1542.001; T1542.003; T1547.006; T1574.006; T1543.003 | Firmware, boot, kernel module, preload and service installs |
| MITRE ATT&CK for ICS | T0851 Rootkit | Industrial equivalent |
| NIST SP 800-53 Rev 5 | SI-7 Software, Firmware, and Information Integrity; SI-7(9) Verify Boot Process; SI-7(15) Code Authentication; CM-14 Signed Components | Integrity and signing controls |
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection; SI-4 System Monitoring | Detection |
| NIST CSF 2.0 | PR.PS-01; DE.CM-09 | Configuration management and endpoint monitoring |
Practitioner checklist
- Log driver loads and kernel service creation on Windows (Sysmon 6, System 7045).
- Log kernel module loads and watch
/etc/ld.so.preloadon Linux. - Alert on kexts and LaunchDaemons not deployed by MDM.
- Enforce memory integrity and the vulnerable driver blocklist after an audit period.
- Enforce kernel module signatures on Linux servers where all modules are signed.
- Run vendor integrity checks on firewalls and VPN appliances.
- Keep a memory acquisition capability ready and practise using it.
- Rebuild rootkitted hosts and rotate every credential used on them.
Standards and references
- MITRE ATT&CK: Rootkit (T1014)
- MITRE ATT&CK: Drovorub (S0502)
- Microsoft: Microsoft recommended driver block rules
- Linux kernel documentation: Kernel module signing facility
- Apple: System and kernel extensions in macOS
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Rootkits and Bootkits Guide · ATT&CK Stealth and Defense Impairment Tactics Guide · Bring Your Own Vulnerable Driver and EDR Killers Guide · EDR Tampering and BYOVD Response Playbook · Memory Forensics Guide · MITRE ATT&CK T1542 Pre-OS Boot · MITRE ATT&CK T1601 Modify System Image