Detect Rootkit in CrowdStrike LogScale
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/
LogScale Detection Query
// T1014 Rootkit — CrowdStrike Falcon LogScale (Humio) detection
// Covers Windows suspicious driver loads, Linux LKM loading, and ld.so.preload modification
#event_simpleName in ("DriverLoad", "ProcessRollup2", "SyntheticProcessRollup2", "FileWriteInfo", "FileCreateInfo")
| kvParse()
// Normalize field case for matching
| imageFileName_lc := lower(ImageFileName)
| parentBase_lc := lower(ParentBaseFileName)
| targetFile_lc := lower(TargetFileName)
| fileName_lc := lower(FileName)
| case {
// Signal 1: Windows kernel driver loaded from suspicious non-standard path
// DriverLoad fires when a kernel-mode driver .sys is loaded by the OS
#event_simpleName = "DriverLoad"
imageFileName_lc = /(\/|\\)(temp|appdata|downloads|programdata|users[\/\\]public)[\/\\]/
| detection_type := "SuspiciousDriverLoad"
| indicator := ImageFileName ;
// Signal 2: Linux kernel module load via insmod or modprobe
// outside a recognized package manager parent process
#event_simpleName in ("ProcessRollup2", "SyntheticProcessRollup2")
fileName_lc in ("insmod", "modprobe")
NOT parentBase_lc = /(systemd|apt-get|apt|dpkg|rpm|yum|dnf|snap|pacman|zypper|kmod|update-initramfs|dracut)/
| detection_type := "LinuxKernelModuleLoad"
| indicator := CommandLine ;
// Signal 3: Write or creation of /etc/ld.so.preload
// used by Rocke, Umbreon, Ebury for userland rootkit shared library injection
#event_simpleName in ("FileWriteInfo", "FileCreateInfo")
targetFile_lc = "/etc/ld.so.preload"
| detection_type := "LdPreloadModification"
| indicator := TargetFileName ;
// Drop non-matching events
* | drop() ;
}
// Enrich with hash for IOC correlation
| table(
[_time, ComputerName, UserPrincipalName, detection_type, indicator,
FileName, ImageFileName, TargetFileName, CommandLine,
ParentBaseFileName, SHA256HashData, ConfigBuild, aid],
limit = 1000
)
| sort(_time, order=desc)CrowdStrike Falcon LogScale CQL detection for T1014 Rootkit using three case branches: (1) DriverLoad events where the .sys image path contains suspicious staging directories (Temp, AppData, Downloads, ProgramData, Public) indicating a non-standard kernel driver load, (2) ProcessRollup2 events where insmod or modprobe is executed with a parent process that is not a recognized package manager (targeting Drovorub, Diamorphine, Skidmap-style LKM installations), and (3) FileWriteInfo/FileCreateInfo events targeting /etc/ld.so.preload for Rocke/Umbreon/Ebury-style userland rootkit LD_PRELOAD hooking. SHA256HashData is surfaced for immediate IOC lookups.
Data Sources
Required Tables
False Positives & Tuning
- CrowdStrike Falcon sensor self-updates and sensor component upgrades that trigger DriverLoad events for the cs-falconstore.sys or csagent.sys driver from paths that may temporarily appear non-standard during the update staging process — baseline by SHA256HashData and ConfigBuild fields
- Third-party EDR co-existence scenarios where SentinelOne, Tanium, or Absolute Agent kernel drivers load during their installation from custom subdirectories not covered by the regex allowlist in the DriverLoad signal
- Linux development or CI/CD build agents compiling and loading custom kernel modules using insmod as part of kernel driver unit tests, where the parent is a Make, GCC, or CI runner process rather than a package manager
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.