Install any skill in seconds. Free to start, no credit card required.
Get Started Free →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.
.claude/skills/detecting-rootkit-activity/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-19 | ✗→✓ | ▲ Improved | — | — |
| case-03 | ✗→✓ | ▲ Improved | — | — |
| case-10 | ✗→✓ | ▲ Improved | — | — |
| case-15 | ✗→✓ | ▲ Improved | — | — |
| case-08 | ✗→✓ | ▲ Improved | — | — |
Do not use as a first-line detection method; start with standard malware triage and escalate to rootkit analysis when hiding behavior is suspected.
Compare process lists from different data sources to find discrepancies:
bash# Volatility: Compare process enumeration methods # pslist - walks ActiveProcessLinks (EPROCESS linked list - what rootkits manipulate) vol3 -f memory.dmp windows.pslist > pslist_output.txt # psscan - scans physical memory for EPROCESS pool tags (rootkit-resistant) vol3 -f memory.dmp windows.psscan > psscan_output.txt # Compare outputs to find hidden processes python3 << 'PYEOF' pslist_pids = set() psscan_pids = set() with open("pslist_output.txt") as f: for line in f: parts = line.split() if len(parts) > 1 and parts[1].isdigit(): pslist_pids.add(int(parts[1])) with open("psscan_output.txt") as f: for line in f: parts = line.split() if len(parts) > 1 and parts[1].isdigit(): psscan_pids.add(int(parts[1])) hidden = psscan_pids - pslist_pids if hidden: print(f"[!] HIDDEN PROCESSES DETECTED (in psscan but not pslist):") for pid in hidden: print(f" PID: {pid}") else: print("[*] No hidden processes detected via cross-view analysis") PYEOF
Identify hooks in the System Service Descriptor Table (SSDT) and Import Address Tables:
bash# Check SSDT for hooked system calls vol3 -f memory.dmp windows.ssdt # Identify hooks pointing outside ntoskrnl.exe or win32k.sys vol3 -f memory.dmp windows.ssdt | grep -v "ntoskrnl\|win32k" # Check for Inline hooks (detour patching) vol3 -f memory.dmp windows.apihooks --pid 4 # System process # IDT (Interrupt Descriptor Table) analysis vol3 -f memory.dmp windows.idt # Check for IRP (I/O Request Packet) hooking on drivers vol3 -f memory.dmp windows.driverscan vol3 -f memory.dmp windows.driverirp
Types of Rootkit Hooks:
━━━━━━━━━━━━━━━━━━━━━
SSDT Hook: Modifies System Service Descriptor Table entries to redirect
system calls through rootkit code (filters process/file listings)
IAT Hook: Patches Import Address Table of a process to intercept API calls
before they reach the kernel
Inline Hook: Overwrites the first bytes of a function with a JMP to rootkit code
(detour/trampoline technique)
IRP Hook: Intercepts I/O Request Packets to filter disk/network operations
at the driver level
DKOM: Direct Kernel Object Manipulation - unlinking structures like
EPROCESS from the ActiveProcessLinks list without hookingIdentify unauthorized kernel drivers that may be rootkit components:
bash# List all loaded kernel modules vol3 -f memory.dmp windows.modules # Scan for drivers in memory (including hidden/unlinked) vol3 -f memory.dmp windows.driverscan # Compare module lists to find hidden drivers vol3 -f memory.dmp windows.modscan > modscan.txt vol3 -f memory.dmp windows.modules > modules.txt # Check driver signatures and verify against known-good baselines vol3 -f memory.dmp windows.verinfo # Dump suspicious driver for static analysis vol3 -f memory.dmp windows.moddump --base 0xFFFFF80012340000 --dump
Identify files and registry keys hidden by the rootkit:
bash# Linux rootkit detection with rkhunter rkhunter --check --skip-keypress --report-warnings-only # chkrootkit scanning chkrootkit -q # Windows: Compare filesystem views # Live system file listing vs Volatility filescan vol3 -f memory.dmp windows.filescan > mem_files.txt # Check for hidden registry keys vol3 -f memory.dmp windows.registry.hivelist vol3 -f memory.dmp windows.registry.printkey --key "SYSTEM\CurrentControlSet\Services" # Look for hidden services (loaded but not in service registry) vol3 -f memory.dmp windows.svcscan | grep -i "kernel"
Find hidden network connections and backdoors:
bash# Memory-based network connection enumeration vol3 -f memory.dmp windows.netscan # Compare with live netstat (if available) to find hidden connections # Hidden connections: present in memory but not shown by netstat # Look for raw sockets (often used by rootkits for covert communication) vol3 -f memory.dmp windows.netscan | grep RAW # Check for network filter drivers (NDIS hooks) vol3 -f memory.dmp windows.driverscan | grep -i "ndis\|tcpip\|afd" # Analyze callback routines registered by drivers vol3 -f memory.dmp windows.callbacks
Verify system file and kernel integrity:
bash# Check kernel code integrity (compare in-memory kernel to on-disk copy) vol3 -f memory.dmp windows.moddump --base 0xFFFFF80070000000 --dump # Compare SHA-256 of dumped ntoskrnl.exe with known-good copy # Windows: System File Checker (on live system) sfc /scannow # Linux: Package integrity verification rpm -Va # RPM-based systems debsums -c # Debian-based systems # Compare critical system binaries find /bin /sbin /usr/bin /usr/sbin -type f -exec sha256sum {} \; > current_hashes.txt # Compare against baseline: diff baseline_hashes.txt current_hashes.txt # YARA scan for known rootkit signatures vol3 -f memory.dmp yarascan.YaraScan --yara-file rootkit_rules.yar
| Term | Definition | |------|------------| | Rootkit | Malware designed to maintain persistent, privileged access while hiding its presence from system administrators and security tools | | DKOM | Direct Kernel Object Manipulation; technique of modifying kernel data structures (e.g., unlinking EPROCESS) to hide objects without hooking | | SSDT Hooking | Replacing entries in the System Service Descriptor Table to intercept and filter system call results (hide processes, files, connections) | | Inline Hooking | Patching the first instructions of a function with a jump to rootkit code; the rootkit can filter the function output before returning | | Cross-View Detection | Comparing results from multiple enumeration methods (linked list walk vs memory scan) to identify discrepancies caused by hiding | | Kernel Driver | Code running in kernel mode (Ring 0) with full system access; rootkits use malicious drivers to gain kernel-level control | | Bootkits | Rootkits that infect the boot process (MBR, VBR, or UEFI firmware) to load before the operating system and security tools |
Context: An endpoint shows network beaconing to a known C2 IP in firewall logs, but the local EDR, Task Manager, and netstat show no suspicious processes or connections. A memory dump has been acquired for analysis.
Approach:
psscan and compare with pslist to identify processes hidden via DKOMwindows.ssdt to check for system call hooks that filter process and network listingswindows.malfind to detect injected code in legitimate processeswindows.netscan to find network connections hidden from user-mode toolswindows.driverscan to identify malicious kernel drivers enabling the hidingPitfalls:
ROOTKIT DETECTION ANALYSIS REPORT
====================================
Dump File: memory.dmp
System: Windows 10 21H2 x64
Analysis Tool: Volatility 3.2
CROSS-VIEW DETECTION
Process List Comparison:
pslist processes: 127
psscan processes: 129
[!] HIDDEN PROCESSES: 2
PID 6784: sysmon64.exe (hidden rootkit component)
PID 6812: netfilter.exe (hidden network filter)
SSDT HOOK ANALYSIS
[!] Entry 0x004A (NtQuerySystemInformation) hooked -> driver.sys+0x1200
[!] Entry 0x0055 (NtQueryDirectoryFile) hooked -> driver.sys+0x1400
[!] Entry 0x0119 (NtDeviceIoControlFile) hooked -> driver.sys+0x1600
Hook Target: driver.sys at 0xFFFFF800ABCD0000 (unsigned, suspicious)
KERNEL DRIVER ANALYSIS
[!] driver.sys - No digital signature, loaded at 0xFFFFF800ABCD0000
Size: 45,056 bytes
SHA-256: abc123def456...
IRP Hooks: IRP_MJ_CREATE, IRP_MJ_DEVICE_CONTROL
Registry: HKLM\SYSTEM\CurrentControlSet\Services\MalDriver
HIDDEN NETWORK CONNECTIONS
PID 6812: 10.1.5.42:49152 -> 185.220.101.42:443 (ESTABLISHED)
- Not visible via netstat or user-mode tools
- Filtered by NtDeviceIoControlFile SSDT hook
ROOTKIT CAPABILITIES
- Process hiding (DKOM + SSDT)
- File hiding (NtQueryDirectoryFile hook)
- Network connection hiding (NtDeviceIoControlFile hook)
- Kernel-mode persistence (driver service)
REMEDIATION
- Boot from clean media for offline remediation
- Remove malicious driver from offline registry
- Verify MBR/VBR/UEFI integrity for boot persistence
- Full system rebuild recommended for kernel-level compromise| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-12 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-01 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-17 | pass→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-19 | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-03 | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-20 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-10 | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-11 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-15 | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-04 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-02 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-21 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-09 | pass→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-05 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-16 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-14 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-18 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-07 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-13 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-06 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-08 | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-22 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 21 counted toward the lift figure. The other 1 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +23 percentage points is the difference between those two pass rates over the 21 comparable cases.
The per-case answers from this run were removed by the retention sweep, so the case table below shows the verdicts without the text either arm produced. The counts above were recorded at the time and are unaffected. Answers are now kept for 180 days.
Other measured skills in the registry, with their headline benchmark lift.