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.
Works with
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versiondetecting-rootkit-activityExecute the skills CLI command in your project's root directory to begin installation:
Fetches detecting-rootkit-activity from mukul975/Anthropic-Cybersecurity-Skills and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate detecting-rootkit-activity. Access via /detecting-rootkit-activity in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Automate repetitive workflows and reduce manual effort
Example
Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Learn new skills, understand complex topics, get expert guidance
Example
Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Enhance output quality through reviews, suggestions, and refinements
Example
Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
1
total installs
1
this week
8.6K
GitHub stars
0
upvotes
Run in your terminal
1
installs
1
this week
8.6K
stars
| 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 |
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:
# 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:
# 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 hooking
Identify unauthorized kernel drivers that may be rootkit components:
# 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:
# 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:
# 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:
# 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
Prerequisites
Time Estimate
15-45 minutes depending on use case complexity
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
mukul975/Anthropic-Cybersecurity-Skills
Solid pick for teams standardizing on skills: detecting-rootkit-activity is focused, and the summary matches what you get after install.
detecting-rootkit-activity reduced setup friction for our internal harness; good balance of opinion and flexibility.
We added detecting-rootkit-activity from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
detecting-rootkit-activity has been reliable in day-to-day use. Documentation quality is above average for community skills.
Keeps context tight: detecting-rootkit-activity is the kind of skill you can hand to a new teammate without a long onboarding doc.
detecting-rootkit-activity has been reliable in day-to-day use. Documentation quality is above average for community skills.
Keeps context tight: detecting-rootkit-activity is the kind of skill you can hand to a new teammate without a long onboarding doc.
detecting-rootkit-activity is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
detecting-rootkit-activity reduced setup friction for our internal harness; good balance of opinion and flexibility.
Useful defaults in detecting-rootkit-activity — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
showing 1-10 of 31