---
name: rootkit-analysis
description: >
  Detect and analyze kernel-mode and user-mode rootkits. Use when investigating
  suspected rootkit infections, analyzing hidden processes/files/registry keys,
  examining SSDT/IDT hooks, DKOM techniques, suspicious drivers, MBR/VBR
  modifications, or UEFI implants.
---

# Rootkit Analysis

Systematic approach to detecting and analyzing rootkit malware at kernel and user-mode levels.

## When to Use

- Hidden processes, files, or registry keys are suspected
- System behaves abnormally but standard tools show nothing
- Memory forensics reveals kernel-level manipulation
- Suspicious drivers or kernel modules are present
- Boot process integrity is in question

## Prerequisites

- **Volatility 3**: Memory forensics framework for hook detection, process analysis, and driver scanning
- **GMER**: Live rootkit detection on Windows systems
- **rkhunter/chkrootkit**: Linux rootkit scanning utilities
- **UEFITool**: UEFI firmware analysis for bootkit investigation
- **Ghidra or IDA**: Driver and kernel module reverse engineering
- **Memory dump** of the suspected infected system
- **Known-good MBR/firmware images** for comparison analysis
- **YARA**: Pattern-based detection rule creation
- **dd** or equivalent disk imaging tool for MBR extraction

## Step-by-Step Instructions

### Step 1: Triage — Detect Rootkit Presence

Compare results from multiple enumeration methods to find discrepancies:

```
# Compare process lists from different sources
# If pslist and psscan show different results, rootkit likely hiding processes
volatility3 -f memory.dmp windows.pslist
volatility3 -f memory.dmp windows.psscan

# Compare file listings
# Live: dir /s vs raw NTFS parsing
# Memory: filescan vs vadinfo
```

Check for common rootkit indicators:
- Process list discrepancies between tools
- Hidden files visible only via raw disk access
- Network connections from invisible processes
- Modified system call tables
- Unexpected kernel modules/drivers

### Step 2: Classify Rootkit Type

**User-Mode Rootkits:**
- IAT/EAT hooking in user processes
- DLL injection for API interception
- LD_PRELOAD (Linux) / AppInit_DLLs (Windows)

**Kernel-Mode Rootkits:**
- SSDT (System Service Descriptor Table) hooks
- IDT (Interrupt Descriptor Table) modifications
- DKOM (Direct Kernel Object Manipulation)
- IRP (I/O Request Packet) hooking
- Filter drivers / minifilter callbacks

**Bootkits:**
- MBR/VBR modification
- UEFI firmware implants
- Bootloader replacement/patching

**Hypervisor-Level:**
- Blue Pill-style VM-based rootkits
- Hypervisor hooking

### Step 3: Kernel-Level Analysis

#### SSDT Hook Detection
```
# Volatility 3 - check for SSDT modifications
volatility3 -f memory.dmp windows.ssdt

# Look for entries pointing outside ntoskrnl.exe/win32k.sys
# Normal SSDT entries point to: nt!*, win32k!*
# Hooked entries point to: unknown driver addresses
```

#### DKOM Detection
```
# DKOM hides processes by unlinking from ActiveProcessLinks
# Detect by comparing EPROCESS list traversal methods:
volatility3 -f memory.dmp windows.pslist    # Follows ActiveProcessLinks (can be manipulated)
volatility3 -f memory.dmp windows.psscan    # Pool tag scanning (harder to evade)

# Processes in psscan but NOT in pslist = likely DKOM hidden
```

#### Driver/Module Analysis
```
# List loaded drivers
volatility3 -f memory.dmp windows.driverscan
volatility3 -f memory.dmp windows.modules

# Check for unsigned or suspicious drivers
# Look for: unknown publishers, high entropy, no version info
# Run: scripts/driver_analyzer.py <driver.sys>
```

### Step 4: Hook Detection

```
# Detect inline hooks (JMP patches at function start)
# Check critical functions:
# - NtCreateFile, NtQueryDirectoryFile (file hiding)
# - NtQuerySystemInformation (process hiding)
# - NtEnumerateValueKey (registry hiding)
# - TCP/IP driver dispatch routines (connection hiding)

# Use Volatility apihooks plugin concept:
volatility3 -f memory.dmp windows.apihooks
```

Look for:
- JMP/CALL instructions at function prologues
- Detour patches (5-byte JMP near, 6-byte JMP far)
- Trampoline functions in non-standard memory regions
- Modified function pointers in dispatch tables

### Step 5: Hidden Object Discovery

```
# Hidden files: compare directory listing methods
# Hidden registry: compare registry enumeration methods
# Hidden network: compare netstat vs raw socket enumeration

# Cross-reference with disk forensics
# Raw NTFS/ext4 parsing reveals files hidden by rootkit
```

### Step 6: Bootkit Analysis

If boot-level infection suspected:

```
# Dump and analyze MBR
dd if=/dev/sda bs=512 count=1 of=mbr.bin

# Compare against known-good MBR
# Check for: modified boot code, unexpected partition entries

# UEFI analysis
# Use UEFITool to examine firmware volumes
# Check for: unknown DXE drivers, modified boot manager
# See: references/bootkit-analysis.md
```

### Step 7: Extract and Reverse Engineer

1. Dump rootkit driver from memory
2. Analyze with Ghidra/IDA (use `reverse-engineering` skill)
3. Identify hooking code and hidden functionality
4. Map communication channels (kernel-to-user callbacks, IOCTL interface)
5. Document all hooks and modifications

### Step 8: Generate Detection Artifacts

- YARA rules for rootkit binary (use `yara-rule-development` skill)
- IOCs: driver hashes, file names, registry keys, mutexes
- Behavioral indicators for EDR/SIEM
- Memory forensics signatures
- Map to MITRE ATT&CK (T1014 Rootkit, T1068 Exploitation for Privilege Escalation)

## Tools

| Tool | Purpose |
|------|---------|
| Volatility 3 | Memory forensics, hook detection |
| GMER | Live rootkit detection (Windows) |
| rkhunter/chkrootkit | Linux rootkit scanning |
| UEFITool | UEFI firmware analysis |
| Ghidra/IDA | Driver reverse engineering |

## Related Skills

- `memory-forensics` — RAM dump acquisition and analysis
- `reverse-engineering` — Driver disassembly and decompilation
- `bootkit-analysis` reference in references/
- `behavioral-analysis` — Classify rootkit behaviors