detecting-rootkit-activity

name	detecting-rootkit-activity
description	Detects rootkit presence on compromised systems by identifying hidden processes, hooked system calls, modified kernel structures, hidden files, and covert network connections using memory forensics, cross-view detection, and integrity checking techniques. Activates for requests involving rootkit detection, hidden process discovery, kernel integrity checking, or system call hook analysis.
domain	cybersecurity
subdomain	malware-analysis
tags	["malware","rootkit","detection","kernel-analysis","memory-forensics"]
version	1.0.0
author	mahipal
license	Apache-2.0
nist_csf	["DE.AE-02","RS.AN-03","ID.RA-01","DE.CM-01"]

Detecting Rootkit Activity

When to Use

• System shows signs of compromise but standard tools (Task Manager, netstat) show nothing abnormal
• Antivirus/EDR detects rootkit signatures but cannot identify the specific hiding mechanism
• Memory forensics reveals discrepancies between kernel data structures and user-mode tool output
• Investigating a persistent threat that survives remediation attempts and system reboots
• Validating system integrity after a suspected kernel-level compromise

Do not use as a first-line detection method; start with standard malware triage and escalate to rootkit analysis when hiding behavior is suspected.

Detection Gaps & Validation

• No SSDT hooks does NOT mean no rootkit. Modern kernel rootkits avoid SSDT patching (caught by PatchGuard) and instead use DKOM, registered kernel callbacks, IRP major-function hooks, or minifilter altitude abuse. Run ssdt, callbacks, driverirp, and modscan/driverscan, not ssdt alone.
• Cross-view is the core technique, and it has blind spots. psscan vs pslist finds DKOM-unlinked EPROCESS, but a rootkit that also scrubs pool tags or uses ETW/object-callback hiding evades it - corroborate with psxview (multiple sources), thrdscan, and netscan vs live netstat.
• Never trust a live infected host. GMER/RootkitRevealer/rkhunter run on the compromised system can be subverted by the very rootkit they hunt. Confirm findings against an offline memory image; treat live-tool "clean" results as unproven.
• Confirm a hit by dumping the suspect driver (moddump) and checking for an absent/invalid signature, then disassemble in Ghidra to locate the hook/DKOM routine; diff the in-memory ntoskrnl/critical modules against a known-good hash to prove tampering.
• Check below the OS. Bootkits (MBR/VBR) and UEFI implants load before forensics tools - verify boot-chain and firmware integrity for persistence that survives rebuilds.
• Benign lookalikes: AV/EDR, virtualization, and DRM/anti-cheat drivers legitimately hook callbacks, filter IRPs, and hide handles. Validate the driver's signer and path before classifying a hook as malicious.

Prerequisites