Detect Rootkit in Google Chronicle
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/
YARA-L Detection Query
rule t1014_rootkit_multi_signal {
meta:
author = "Argus Detection Engineering"
description = "T1014 Rootkit: detects kernel driver installation from suspicious paths, Linux LKM loading outside package manager context, and /etc/ld.so.preload modification. Covers Drovorub, Skidmap, Diamorphine, Rocke, Umbreon, and Ebury TTPs."
severity = "CRITICAL"
priority = "HIGH"
mitre_attack_tactic = "Defense Evasion"
mitre_attack_technique = "T1014"
reference = "https://attack.mitre.org/techniques/T1014/"
version = "1.0"
created = "2026-04-13"
events:
/* Signal 1: Windows kernel driver service installation from suspicious staging path
Maps to Security Event 4697 or System Event 7045 ingested into UDM as STATUS_UPDATE */
$win_driver.metadata.event_type = "STATUS_UPDATE"
$win_driver.metadata.product_event_type = /^(4697|7045)$/
re.regex(
$win_driver.target.resource.name,
`(?i)(\\temp\\|\\appdata\\|\\downloads\\|\\programdata\\|\\users\\public\\)`
)
$win_driver.principal.hostname = $host1
/* Signal 2: Linux kernel module loaded via insmod or modprobe
outside a recognized package manager parent process */
$lkm_load.metadata.event_type = "PROCESS_LAUNCH"
re.regex($lkm_load.target.process.file.full_path, `/(insmod|modprobe)$`)
not re.regex(
$lkm_load.principal.process.file.full_path,
`(systemd|apt-get|apt|dpkg|rpm|yum|dnf|snap|pacman|zypper|kmod|dracut|update.initramfs)`
)
$lkm_load.principal.hostname = $host2
/* Signal 3: Modification or creation of /etc/ld.so.preload
used by userland rootkits (Rocke, Umbreon, Ebury) to inject shared libraries */
$ld_preload.metadata.event_type = "FILE_MODIFICATION"
$ld_preload.target.file.full_path = "/etc/ld.so.preload"
$ld_preload.principal.hostname = $host3
condition:
$win_driver or $lkm_load or $ld_preload
}Chronicle YARA-L 2.0 rule detecting T1014 Rootkit TTPs across three independent event variables ORed in the condition: (1) Windows kernel driver service registration from suspicious staging paths mapped via product_event_type 4697/7045, (2) Linux kernel module loading by insmod/modprobe where the parent process is not a recognized package manager, and (3) /etc/ld.so.preload file modification used by Rocke, Umbreon, and Ebury for userland rootkit shared library injection. Any single signal fires the rule.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate enterprise software deployments (VPN clients such as Cisco AnyConnect or Palo Alto GlobalProtect, backup agents such as Veeam or Commvault) that register Windows kernel mode drivers via sc.exe from installation paths that include ProgramData subdirectories not covered by the standard allowlist
- Linux infrastructure agents (Datadog, New Relic, Dynatrace, Falco) loading eBPF helper kernel modules using insmod or modprobe where the parent is a Python or Go binary rather than a package manager — these are common in containerized and cloud-native environments
- Authorized red team or penetration testing exercises simulating rootkit installation on designated test hosts within the Chronicle-monitored environment that have not been excluded from the rule scope via hostname allowlist
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.