mcpField
D
detecting-rootkit-activity

detecting-rootkit-activity

github.com/mukul975セキュリティ35.2k68 回インストール8 週間前に更新
リポジトリ

detecting-rootkit-activity について

セキュリティ分析担当者向けのルートキット検出スキルです。メモリフォレンジックと複数の列挙方法の比較により、隠れたプロセスやドライバー、接続を調べ、カーネルの整合性を確認します。

主な機能

  1. 01複数手法によるプロセス一覧の比較
  2. 02システムコールと API フックの検出
  3. 03隠れたカーネルドライバーの分析
  4. 04ファイル、レジストリ、ネットワークの隠蔽確認
  5. 05カーネルとシステムファイルの整合性検証

活用シーン

  1. 01標準ツールで見つからない侵害の調査
  2. 02メモリダンプ内の隠れたプロセスやドライバーの分析
  3. 03カーネルレベルの侵害が疑われる場合の整合性検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mukul975/anthropic-cybersecurity-skills --skill detecting-rootkit-activity

インストール後、Claude Code で/detecting-rootkit-activityを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE
references/
api-reference.md
scripts/
agent.py

詳細

ルートキットの活動を検出する

使用する状況

  • システムに侵害の兆候があるものの、標準ツール(タスク マネージャー、netstat)では異常が見つからない
  • ウイルス対策ソフト/EDR がルートキットのシグネチャを検出したものの、具体的な隠蔽手法を特定できない
  • メモリフォレンジックで、カーネルデータ構造とユーザーモードツールの出力に不一致が見つかった
  • 修復を試みても、またシステムを再起動しても残存する脅威を調査する
  • カーネルレベルの侵害が疑われた後に、システムの完全性を検証する

第一段階の検出方法としては使用しないでください。まず標準的なマルウェアのトリアージを行い、隠蔽行為が疑われる場合にルートキット分析へ進んでください。

前提条件

  • メモリフォレンジックとカーネル構造の分析に Volatility 3 を使用する
  • 稼働中のシステムのスキャンに GMER または Rootkit Revealer(Windows)を使用する
  • ファイルシステムとプロセスの完全性チェックに rkhunter と chkrootkit(Linux)を使用する
  • Windows の分析に Sysinternals ツール(Process Explorer、Autoruns、RootkitRevealer)を使用する
  • 疑わしいシステムのメモリダンプ(WinPmem、LiME)
  • 比較用のクリーンな OS ベースライン(正常と確認されたカーネルモジュールのハッシュ)

ワークフロー

ステップ 1:隠れたプロセスのクロスビュー検出

異なるデータソースのプロセス一覧を比較し、不一致を見つけます。

# 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
ステップ 2:システムコールのフックを検出する

System Service Descriptor Table(SSDT)と Import Address Table のフックを特定します。

# 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
ステップ 3:カーネルモジュールとドライバーを分析する

ルートキットのコンポーネントである可能性のある、許可されていないカーネルドライバーを特定します。

# 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
ステップ 4:ファイルとレジストリの隠蔽を検出する

ルートキットによって隠されたファイルとレジストリキーを特定します。

# 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"
ステップ 5:ネットワーク接続を分析する

隠されたネットワーク接続とバックドアを見つけます。

# 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
ステップ 6:完全性を検証する

システムファイルとカーネルの完全性を検証します。

# 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

重要な概念

用語定義
ルートキットシステム管理者やセキュリティツールから自身の存在を隠しながら、永続的な特権アクセスを維持するよう設計されたマルウェア
DKOMDirect Kernel Object Manipulation の略。フックを使わずにオブジェクトを隠すため、カーネルデータ構造(例:EPROCESS のリンク解除)を変更する手法
SSDT フックSystem Service Descriptor Table のエントリーを置き換えてシステムコールの結果を傍受し、フィルタリングする手法(プロセス、ファイル、接続を隠す)
インラインフック関数の先頭の命令を、ルートキットのコードへジャンプする命令に書き換える手法。ルートキットは関数の出力をフィルタリングしてから返すことができます
クロスビュー検出複数の列挙方法(リンクリストの走査とメモリスキャンなど)の結果を比較し、隠蔽による不一致を特定する手法
カーネルドライバーカーネルモード(Ring 0)で実行され、システム全体にアクセスできるコード。ルートキットは悪意のあるドライバーを使ってカーネルレベルの制御を獲得します
ブートキット起動プロセス(MBR、VBR、UEFI ファームウェア)に感染し、OS やセキュリティツールより先に読み込まれるルートキット

ツールとシステム

  • Volatility:クロスビュー検出、SSDT 分析、カーネル構造の検査を提供するメモリフォレンジックフレームワーク。ルートキットの検出に使用します
  • GMER:SSDT フック、IDT フック、IRP フック、隠されたプロセス/ファイル/レジストリをスキャンする、無料の Windows 向けルートキット検出ツール
  • rkhunter:既知のルートキットシグネチャ、不審なファイル、システムバイナリの変更を確認する、Linux 向けルートキット検出ツール
  • chkrootkit:シグネチャベースおよび異常ベースのチェックを通じてルートキットの存在を検出する、Linux 向けツール
  • Sysinternals RootkitRevealer:Windows API の結果とファイルシステム/レジストリの生スキャン結果を比較し、不一致を見つける Microsoft のツール

よくあるシナリオ

シナリオ:標準ツールでは侵害が見つからないシステムの調査

コンテキスト:ファイアウォールログには、エンドポイントから既知のC2 IPへのビーコン通信が記録されていますが、ローカルのEDR、タスクマネージャー、netstatには不審なプロセスや接続が表示されません。分析用にメモリダンプを取得済みです。

アプローチ:

  1. Volatilityのpsscanを実行し、pslistと比較して、DKOMによって隠されたプロセスを特定します
  2. windows.ssdtを実行し、プロセスやネットワークの一覧表示をフィルタリングするシステムコールフックを確認します
  3. windows.malfindを実行し、正規のプロセスに注入されたコードを検出します
  4. windows.netscanを実行し、ユーザーモードのツールから隠されたネットワーク接続を見つけます
  5. windows.driverscanを実行し、隠蔽を可能にする悪意のあるカーネルドライバーを特定します
  6. ルートキットのドライバーをダンプし、Ghidraで分析してフックの仕組みを把握します
  7. ブート時の永続化(MBR/VBRの改変、UEFIファームウェアへのインプラント)を確認します

落とし穴:

  • 侵害された稼働中のシステムで検出ツールを実行すること(ルートキットがツールから隠れたり、ツールを妨害したりする可能性があります)
  • SSDTフックが見つからないからといって、カーネルの整合性を前提にすること(ルートキットは代わりにDKOMやインラインフックを使う可能性があります)
  • ユーザーモードとカーネルモードの両方のルートキットコンポーネントを確認しないこと(多くのルートキットには両方があります)
  • 稼働中のシステムでのルートキットスキャナーの結果を信頼すること。必ずオフラインのメモリフォレンジックで検証してください

出力形式

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

コメント