Detect Rootkit in IBM QRadar

Triage

1. Identify the specific detection signal that fired: KernelDriverInstall, SuspiciousDriverLoad, LinuxKernelModuleLoad, or LdPreloadModification — each has a different initial triage path and urgency level
2. For Windows driver events (7045/4697 or Sysmon EventCode 6): check the driver binary path, file hash, and digital signature. Run: Get-AuthenticodeSignature '<driver_path>' — an unsigned driver from a temp directory is high-confidence malicious
3. For Linux kernel module loads: examine the .ko file using modinfo <module_path> to check author, description, and license fields. Legitimate modules show expected kernel version and module author. Run lsmod and compare to /proc/modules — discrepancies indicate active rootkit concealment
4. For /etc/ld.so.preload modification: immediately cat /etc/ld.so.preload to identify the injected library path. Verify the library exists, then run nm -D <library_path> to identify which libc functions it hooks (read, getdents, write, connect are common rootkit targets)
5. Check for process visibility discrepancies: compare 'ps aux' output against /proc entries using: ls /proc | grep -E '^[0-9]+$' | while read pid; do [ ! -d /proc/$pid/exe ] 2>/dev/null && echo "Hidden: $pid"; done — hidden PIDs indicate an active rootkit
6. Review the initiating process and user context: was the module load/driver install initiated by a privileged user, a compromised service account, or an unexpected binary such as a web server or database process?
7. Check dmesg output and /var/log/kern.log for kernel module load events and any ERROR or WARNING messages from the loaded module that may indicate rootkit activity or kernel tainting

Containment

1. If active Linux kernel rootkit confirmed: do NOT attempt to clean the live system — the rootkit may have hooked syscalls making all output unreliable. Isolate the host from the network immediately using firewall rules or hypervisor-level network disconnection
2. For Windows kernel rootkit confirmed: isolate the endpoint using EDR network isolation. Boot from external media (WinPE or forensic live USB) to examine the filesystem and driver store without loading potentially compromised kernel components
3. If /etc/ld.so.preload is compromised: the rootkit library is injected into every new process. Do not spawn additional shells or processes on the compromised host until the preload is removed from a trusted context (single-user mode or external boot)
4. Identify and block the C2 infrastructure: extract network IOCs from the rootkit binary if accessible from a clean context and block at perimeter. Drovorub and Skidmap used specific ports and protocols documented in their threat intelligence reports
5. Preserve volatile memory before any remediation: if forensic capability exists, take a memory dump (LiME for Linux, DumpIt for Windows) from a trusted kernel or external tool — this is the most reliable artifact for rootkit analysis
6. Revoke credentials used on the compromised host: all credentials (SSH keys, service account passwords, API keys, certificates) that were accessible on the system should be treated as compromised and rotated immediately

Evidence Collection

1. Memory dump: For Linux use LiME (Linux Memory Extractor) — insmod lime-$(uname -r).ko 'path=/mnt/external/memory.lime format=lime' — this captures a full memory image from a known-clean module before the rootkit can intercept
2. Kernel module artifacts: copy all .ko files from /lib/modules/$(uname -r)/ to external storage; hash each file and compare against known-good package checksums using rpm -V kernel or dpkg --verify linux-image-$(uname -r)
3. File system artifacts: run an offline scan using a live boot to enumerate all files without the rootkit's getdents hook — compare against the live system's 'ls' output to identify hidden files
4. Windows driver store: collect C:\Windows\System32\drivers\*.sys hashes; query the service registry at HKLM\SYSTEM\CurrentControlSet\Services for entries with ServiceType=1 (kernel driver) where ImagePath points outside the driver store
5. Network artifacts: capture pcap from a network tap or external sensor (not the compromised host's tcpdump, which may be hooked) to identify C2 communication patterns — Drovorub used port 443 with custom TLS fingerprints
6. Audit log review: Linux — /var/log/auth.log, /var/log/kern.log, journalctl -k for kernel messages, ausearch -k rootkit for auditd events; Windows — System Event Log for Event ID 7045, Security Log for 4697
7. Rootkit-specific IOC comparison: hash the suspicious module/driver and compare against known rootkit signatures from VirusTotal, YARA rules for Diamorphine, Drovorub, Skidmap, Ebury, and vendor threat intelligence reports
8. Timeline reconstruction: use filesystem timestamps (mtime, atime, ctime) on the .ko or .sys file — discrepancies between install time in logs and filesystem timestamps may indicate timestamp manipulation by the attacker

Escalation Criteria

• !Any confirmed kernel-mode rootkit — escalate immediately to incident response; kernel rootkits can intercept and manipulate all OS-level security telemetry, making the entire system untrusted
• !Evidence of syscall hooking or process hiding (discrepancy between /proc entries and ps output, or between netstat and /proc/net/ entries) — this indicates the rootkit is actively concealing attacker presence
• !Rootkit found on a domain controller, authentication server, PKI system, or privileged access workstation — blast radius includes credential theft at scale
• !/etc/ld.so.preload found containing an unknown library — all processes spawned on this host since the modification may have executed attacker-controlled code
• !Rootkit binary or driver matches a known threat actor tool (Drovorub = APT28/GRU, Skidmap = cryptomining campaigns, Diamorphine = TeamTNT) — threat intelligence escalation required
• !Evidence of lateral movement from the rootkit-infected host to other systems — SSH private keys, Kerberos tickets, or credential material may have been stolen via the hooked authentication functions