Detect Rootkit in Elastic Security
Adversaries may use rootkits to hide the presence of programs, files, network connections, services, drivers, and other system components. Rootkits intercept and modify operating system API calls to conceal malware activity and can reside at user-space, kernel-space, or firmware levels. Real-world deployments include Drovorub (GRU-attributed Linux kernel rootkit using LKMs), Skidmap (cryptocurrency miner with kernel-mode hooking), TeamTNT's Diamorphine (open-source LKM), Ebury (SSH userland rootkit), Rocke (ld.so.preload hijacking), Umbreon (libc hooking), and Windows-based rootkits from Carberp and Stuxnet. Linux kernel rootkits typically leverage loadable kernel modules (LKMs) or shared library preloading via /etc/ld.so.preload. Windows kernel rootkits abuse driver loading mechanisms. Detection is most effective at installation and loading time — once active, rootkits actively conceal themselves from OS-level enumeration.
MITRE ATT&CK
- Tactic
- Defense Evasion
- Technique
- T1014 Rootkit
- Canonical reference
- https://attack.mitre.org/techniques/T1014/
Elastic Detection Query
/* T1014 Rootkit — Multi-signal Elastic EQL detection */
any where
/* Signal 1: Windows kernel driver service installation from suspicious path (Event 7045 or 4697) */
(
event.code in ("7045", "4697") and
(
winlog.event_data.ServiceType == "1" or
winlog.event_data.ServiceType == "0x1" or
winlog.event_data.ServiceType like~ "*kernel*driver*"
) and
(
winlog.event_data.ImagePath like~ "*\\\\Temp\\\\*" or
winlog.event_data.ImagePath like~ "*\\\\AppData\\\\*" or
winlog.event_data.ImagePath like~ "*\\\\Downloads\\\\*" or
winlog.event_data.ImagePath like~ "*\\\\ProgramData\\\\*" or
winlog.event_data.ImagePath like~ "*\\\\Users\\\\Public\\\\*"
)
)
or
/* Signal 2: Driver (.sys) file loaded from non-standard filesystem path (Sysmon Event 6) */
(
event.code == "6" and
dll.name like~ "*.sys" and
not (
dll.path like~ "C:\\\\Windows\\\\System32\\\\*" or
dll.path like~ "C:\\\\Windows\\\\SysWOW64\\\\*" or
dll.path like~ "C:\\\\Windows\\\\WinSxS\\\\*" or
dll.path like~ "C:\\\\Program Files\\\\*" or
dll.path like~ "C:\\\\Program Files (x86)\\\\*" or
dll.path like~ "C:\\\\Windows\\\\servicing\\\\*"
)
)
or
/* Signal 3: Linux kernel module loading outside package manager context */
(
event.category == "process" and
process.name in ("insmod", "modprobe") and
not process.parent.name in (
"systemd", "apt-get", "apt", "dpkg", "rpm",
"yum", "dnf", "snap", "pacman", "zypper",
"kmod", "update-initramfs", "dracut"
)
)
or
/* Signal 4: Modification of /etc/ld.so.preload — userland rootkit hook point (Rocke, Umbreon, Ebury TTP) */
(
event.category == "file" and
file.path == "/etc/ld.so.preload" and
event.type in ("creation", "change")
)Multi-signal Elastic EQL detection for T1014 Rootkit covering: Windows kernel driver service installation from suspicious staging paths (System Event 7045 / Security Event 4697), non-standard .sys driver loads via Sysmon Event 6, Linux kernel module loading via insmod/modprobe outside recognized package manager parent processes, and write/creation events on /etc/ld.so.preload used by userland rootkits such as Rocke, Umbreon, and Ebury.
Data Sources
Required Tables
False Positives & Tuning
- Hardware vendor update utilities (Dell Command Update, HP Support Assistant, NVIDIA driver installer) that stage .sys files to %TEMP% before installation and registration via sc.exe — the driver briefly appears in a suspicious path before being moved to System32
- Enterprise EDR or DLP products (Carbon Black, Trellix, Symantec) loading their own kernel drivers from a custom installation directory under Program Files that does not exactly match standard whitelist patterns, especially during sensor upgrades
- VMware Tools, VirtualBox Guest Additions, or open-vm-tools using modprobe to load vmhgfs/vboxsf/vsock kernel modules where the parent process is a shell script rather than a recognized package manager binary
- Ansible, Chef, or Puppet running insmod/modprobe as a child of a Python interpreter or shell to configure kernel networking (e.g., enabling ip_tables or loading br_netfilter for Kubernetes)
Other platforms for T1014
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Linux: Load a Benign Kernel Module from Non-Standard Path
Expected signal: auditd SYSCALL record with syscall=init_module, exe=/sbin/insmod, auid=<current_user>. DeviceProcessEvents (MDE for Linux): FileName=insmod, ProcessCommandLine containing '/tmp/testmodule/test_rootkit_sim.ko', InitiatingProcessFileName=bash/sh. dmesg shows 'argus_test: rootkit simulation module loaded'. lsmod shows 'test_rootkit_sim' in module list.
- Test 2Linux: Userland Rootkit Hook via ld.so.preload Injection
Expected signal: auditd PATH record: type=PATH name=/etc/ld.so.preload nametype=NORMAL with associated SYSCALL record showing write/openat syscall, exe=/usr/bin/tee. DeviceFileEvents (MDE for Linux): FolderPath=/etc, FileName=ld.so.preload, ActionType=FileModified or FileCreated. File integrity monitoring (if deployed) triggers on /etc/ld.so.preload change.
- Test 3Windows: Install a Kernel Driver Service from Suspicious Path
Expected signal: Security Event ID 4697 in Security Log: ServiceName=ArgusTestRootkit, ServiceFileName=C:\Users\Public\argus_test_driver.sys, ServiceType=0x00000001 (Kernel Driver), AccountName=<current_admin_user>. Sysmon Event ID 6 (Driver Loaded): ImageLoaded=C:\Users\Public\argus_test_driver.sys, Signed=true (null.sys is signed). System Event Log 7045: same service details. The file is legitimately signed but the path is suspicious.
- Test 4Linux: Enumerate Running Processes to Detect Rootkit-Induced Discrepancies
Expected signal: On a clean system: proc_pids.txt and ps_pids.txt should differ only by kernel threads and very short-lived processes, and the final comm output should be empty or show only expected kernel thread PIDs. Module comparison should show no discrepancies on a clean system. During active rootkit incident: hidden PIDs and module names would appear in the discrepancy output. This test generates no detection alerts on a clean system — it is a verification tool for the investigation phase.
References (12)
- https://attack.mitre.org/techniques/T1014/
- https://media.defense.gov/2020/Aug/13/2002476465/-1/-1/0/CSA_DROVORUB_RUSSIAN_GRU_MALWARE_AUG_2020.PDF
- https://documents.trendmicro.com/assets/white_papers/wp-a-deep-dive-into-skidmap.pdf
- https://www.anomali.com/blog/rocke-evolves-its-arsenal-with-a-new-malware-family-written-in-golang
- https://www.welivesecurity.com/2017/10/30/windigo-ebury-update-2/
- https://blog.trendmicro.com/trendlabs-security-intelligence/umbreon-linux-rootkit-hits-x86-arm-systems/
- https://www.crowdstrike.com/blog/http-iframe-injecting-linux-rootkit/
- https://github.com/m0nad/Diamorphine
- https://github.com/marin-m/vmlinux-to-elf
- https://volatility3.readthedocs.io/en/latest/
- https://www.elastic.co/security-labs/linux-rootkits-and-detections
- https://www.synacktiv.com/en/publications/a-brief-history-of-linux-kernel-module-rootkits
Unlock Pro Content
Get the full detection package for T1014 including response playbook, investigation guide, and atomic red team tests.