analyzing-bootkit-and-rootkit-samples

ブートキットとルートキットのサンプルを分析する

使用するタイミング

• OS を再インストールしても解消されない侵害の兆候がシステムに見られる
• 侵害を示す明確な証拠があるにもかかわらず、ウイルス対策ソフトや EDR でマルウェアを検出できない
• UEFI Secure Boot が無効になっている、または整合性違反が検出される
• メモリフォレンジックでルートキットの挙動（隠されたプロセス、フックされたシステムコール）が明らかになる
• ブートキットを展開することで知られる国家レベルの脅威（APT28、APT41、Equation Group）を調査する

標準的なユーザーモードのマルウェアには使用しないでください。ブートキットとルートキットは根本的に異なるレベルで動作するため、専門的な分析手法が必要です。

前提条件

• MBR/VBR セクターを取得するためのディスクイメージングツール（dd、FTK Imager）
• UEFI ファームウェアボリュームの分析とモジュール抽出のための UEFITool
• ハードウェアレベルでファームウェアのセキュリティを評価するための chipsec
• MBR コード分析に必要な x86 リアルモードおよび 16 ビットに対応した Ghidra
• カーネルレベルのルートキット痕跡を検出するための Volatility 3
• オフラインでシステムを分析するための起動可能な Linux ライブ USB

ワークフロー

ステップ 1：ブートセクターとファームウェアを取得する

オフライン分析用に MBR、VBR、UEFI ファームウェアを抽出します。

# Acquire MBR (first 512 bytes of disk)
dd if=/dev/sda of=mbr.bin bs=512 count=1

# Acquire first track (usually contains bootkit code beyond MBR)
dd if=/dev/sda of=first_track.bin bs=512 count=63

# Acquire VBR (Volume Boot Record - first sector of partition)
dd if=/dev/sda1 of=vbr.bin bs=512 count=1

# Acquire UEFI System Partition
mkdir /mnt/efi
mount /dev/sda1 /mnt/efi
cp -r /mnt/efi/EFI /analysis/efi_backup/

# Dump UEFI firmware (requires chipsec or flashrom)
# Using chipsec:
python chipsec_util.py spi dump firmware.rom

# Using flashrom:
flashrom -p internal -r firmware.rom

# Verify firmware dump integrity
sha256sum firmware.rom

ステップ 2：ブートキットコードがないか MBR/VBR を分析する

ブートセクターのコードを調べ、悪意のある改変がないか確認します。

# Disassemble MBR code (16-bit real mode)
ndisasm -b16 mbr.bin > mbr_disasm.txt

# Compare MBR with known-good Windows MBR
# Standard Windows MBR begins with: EB 5A 90 (JMP 0x5C, NOP)
# Standard Windows 10 MBR: 33 C0 8E D0 BC 00 7C (XOR AX,AX; MOV SS,AX; MOV SP,7C00h)

python3 << 'PYEOF'
with open("mbr.bin", "rb") as f:
    mbr = f.read()

# Check MBR signature (bytes 510-511 should be 0x55AA)
if mbr[510:512] == b'\x55\xAA':
    print("[*] Valid MBR signature (0x55AA)")
else:
    print("[!] Invalid MBR signature")

# Check for known bootkit signatures
bootkit_sigs = {
    b'\xE8\x00\x00\x5E\x81\xEE': "TDL4/Alureon bootkit",
    b'\xFA\x33\xC0\x8E\xD0\xBC\x00\x7C\x8B\xF4\x50\x07': "Standard Windows MBR (clean)",
    b'\xEB\x5A\x90\x4E\x54\x46\x53': "Standard NTFS VBR (clean)",
}

for sig, name in bootkit_sigs.items():
    if sig in mbr:
        print(f"[{'!' if 'clean' not in name else '*'}] Signature match: {name}")

# Check partition table entries
print("\nPartition Table:")
for i in range(4):
    offset = 446 + (i * 16)
    entry = mbr[offset:offset+16]
    if entry != b'\x00' * 16:
        boot_flag = "Active" if entry[0] == 0x80 else "Inactive"
        part_type = entry[4]
        start_lba = int.from_bytes(entry[8:12], 'little')
        size_lba = int.from_bytes(entry[12:16], 'little')
        print(f"  Partition {i+1}: Type=0x{part_type:02X} {boot_flag} Start=LBA {start_lba} Size={size_lba} sectors")
PYEOF

ステップ 3：インプラントがないか UEFI ファームウェアを分析する

UEFI ファームウェアボリュームを調べ、許可されていないモジュールがないか確認します。

# Extract UEFI firmware components with UEFITool
# GUI: Open firmware.rom -> Inspect firmware volumes
# CLI:
UEFIExtract firmware.rom all

# List all DXE drivers (most common target for UEFI implants)
find firmware.rom.dump -name "*.efi" -exec file {} \;

# Compare against known-good firmware module list
# Each UEFI module has a GUID - compare against vendor baseline

# Verify Secure Boot configuration
python chipsec_main.py -m common.secureboot.variables

# Check SPI flash write protection
python chipsec_main.py -m common.bios_wp

# Check for known UEFI malware patterns
yara -r uefi_malware.yar firmware.rom

Known UEFI Bootkit Detection Points:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LoJax (APT28):
  - Modified SPI flash
  - Added DXE driver that drops agent to Windows
  - Persists through OS reinstall and disk replacement

BlackLotus:
  - Exploits CVE-2022-21894 to bypass Secure Boot
  - Modifies EFI System Partition bootloader
  - Installs kernel driver during boot

CosmicStrand:
  - Modifies CORE_DXE firmware module
  - Hooks kernel initialization during boot
  - Drops shellcode into Windows kernel memory

MoonBounce:
  - SPI flash implant in CORE_DXE module
  - Modified GetVariable() function
  - Deploys user-mode implant through boot chain

ESPecter:
  - Modifies Windows Boot Manager on ESP
  - Patches winload.efi to disable DSE
  - Loads unsigned kernel driver

ステップ 4：カーネルレベルのルートキットの挙動を検出する

実行中のシステムを分析し、ルートキットの痕跡を探します。

# Memory forensics for rootkit detection
# SSDT hook detection
vol3 -f memory.dmp windows.ssdt | grep -v "ntoskrnl\|win32k"

# Hidden processes (DKOM)
vol3 -f memory.dmp windows.psscan > psscan.txt
vol3 -f memory.dmp windows.pslist > pslist.txt
# Diff to find hidden processes

# Kernel callback registration (rootkits register callbacks for filtering)
vol3 -f memory.dmp windows.callbacks

# Driver analysis
vol3 -f memory.dmp windows.driverscan
vol3 -f memory.dmp windows.modules

# Check for unsigned drivers
vol3 -f memory.dmp windows.driverscan | while read line; do
    driver_path=$(echo "$line" | awk '{print $NF}')
    if [ -f "$driver_path" ]; then
        sigcheck -nobanner "$driver_path" 2>/dev/null | grep "Unsigned"
    fi
done

# IDT hook detection
vol3 -f memory.dmp windows.idt

ステップ 5：ブートプロセスの整合性を検証する

ブートチェーン全体の整合性を検証します。

# Verify Windows Boot Manager signature
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi

# Verify winload.efi
sigcheck -a C:\Windows\System32\winload.efi

# Verify ntoskrnl.exe
sigcheck -a C:\Windows\System32\ntoskrnl.exe

# Check Measured Boot logs (if TPM is available)
# Windows: BCDEdit /enum firmware
bcdedit /enum firmware

# Verify Secure Boot state
Confirm-SecureBootUEFI  # PowerShell cmdlet

# Check boot configuration for tampering
bcdedit /v

# Look for boot configuration changes
# testsigning: should be No
# nointegritychecks: should be No
# debug: should be No
bcdedit | findstr /i "testsigning nointegritychecks debug"

ステップ 6：ブートキット／ルートキットの分析を記録する

分析結果を包括的にまとめます。

Analysis should document:
- Boot sector (MBR/VBR) integrity status with hex comparison
- UEFI firmware module inventory and integrity verification
- Secure Boot status and any bypass mechanisms detected
- Kernel-level hooks (SSDT, IDT, IRP, inline) identified
- Hidden processes, drivers, and files discovered
- Persistence mechanism (SPI flash, ESP, MBR, kernel driver)
- Boot chain integrity verification results
- Attribution to known bootkit families if possible
- Remediation steps (reflash firmware, rebuild MBR, replace hardware)

主な概念

用語	定義
ブートキット	OS の読み込み前に実行されるよう、ブートプロセス（MBR、VBR、UEFI）に感染し、低レベルでの永続的な制御を得るマルウェアです
MBR（マスターブートレコード）	ブートストラップコードとパーティションテーブルを含む、ディスクの先頭 512 バイトです。MBR ブートキットはこのコードを悪意のあるローダーに置き換えます
UEFI（統合拡張ファームウェアインターフェイス）	BIOS に代わる最新のファームウェアインターフェイスです。UEFI ブートキットはファームウェアボリュームに悪意のあるモジュールを埋め込むか、ESP を改変します
Secure Boot	ブートコンポーネントのデジタル署名を検証する UEFI のセキュリティ機能です。BlackLotus のようなブートキットは脆弱性を悪用してこれを回避します
SPI フラッシュ	UEFI ファームウェアを格納するフラッシュメモリチップです。LoJax や MoonBounce のような高度なブートキットは、ファームウェアレベルで永続化するために SPI フラッシュを改変します
DKOM（カーネルオブジェクトの直接操作）	関数をフックせずにカーネル構造を改変し、プロセス、ファイル、ネットワーク接続を隠すルートキットの手法です
ドライバー署名の強制（DSE）	カーネルドライバーにデジタル署名を要求する Windows のセキュリティ機能です。ブートキットは起動中に DSE を無効化し、署名されていないルートキットドライバーを読み込みます

ツールとシステム

• UEFITool：ファームウェアボリューム、ドライバー、モジュールを調べるための、オープンソースの UEFI ファームウェアイメージエディター兼パーサー
• chipsec：SPI フラッシュ保護、Secure Boot、UEFI 設定を検証するための、Intel ハードウェアセキュリティ評価フレームワーク
• Volatility：カーネルルートキットの検出向けに、SSDT、IDT、コールバック、ドライバー分析用プラグインを備えたメモリフォレンジックフレームワーク
• GMER：SSDT フック、IDT フック、隠されたプロセス、改変されたカーネルモジュールをスキャンする Windows 用ルートキット検出ツール
• Bootkits Analyzer：逆アセンブルや既知の正常なベースラインとの比較など、MBR/VBR コードを分析するための専用ツール

よくあるシナリオ

シナリオ：OS の再インストール後も残存する侵害の調査

コンテキスト：組織が侵害されたワークステーションを再イメージ化しましたが、数時間以内に同じ C2 ビーコン通信が再開しました。標準的なディスクフォレンジックではマルウェアは見つかりません。UEFI ブートキットが疑われます。

アプローチ：

1. 侵害された OS のコンポーネントを実行しないよう、Linux ライブ USB から起動します
2. オフライン分析用に、chipsec または flashrom を使用して SPI フラッシュファームウェアをダンプします
3. ブートセクター分析用に、dd を使用して MBR と VBR のセクターをダンプします
4. ブートローダーの整合性を検証するため、EFI システムパーティションをコピーします
5. SPI ダンプを UEFITool で開き、モジュールの GUID をベンダー提供のファームウェアと比較します
6. 存在すべきでない追加または変更された DXE ドライバーを探します
7. 疑わしいモジュールがあれば、Ghidra で分析します（x86_64 UEFI モジュール形式）
8. Secure Boot の設定を検証し、エクスプロイトを利用したバイパスがないか確認します

注意点：

• 侵害された OS の実行中にシステムを分析する（ルートキットがライブ分析から隠れる可能性があります）
• SPI フラッシュを確認しない（ディスク上のブートコンポーネントだけを分析すると、ファームウェアレベルのインプラントを見逃します）
• Secure Boot がすべてのブートキットを防ぐと思い込む（既知のバイパスが存在します。例：CVE-2022-21894）
• 再フラッシュの前に元のファームウェアダンプを保存しない（帰属の特定に不可欠な証拠です）

出力形式

BOOTKIT / ROOTKIT ANALYSIS REPORT
====================================
System:           Dell OptiPlex 7090 (UEFI, TPM 2.0)
Firmware Version: 1.15.0 (Dell)
Secure Boot:      ENABLED (but bypassed)
Capture Method:   Linux Live USB + chipsec SPI dump

MBR/VBR ANALYSIS
MBR Signature:    Valid (0x55AA)
MBR Code:         MATCHES standard Windows 10 MBR (clean)
VBR Code:         MATCHES standard NTFS VBR (clean)

UEFI FIRMWARE ANALYSIS
Total Modules:    287
Vendor Expected:  285
Extra Modules:    2 UNAUTHORIZED
  [!] DXE Driver GUID: {ABCD1234-...} "SmmAccessDxe_mod" (MODIFIED)
      Original Size: 12,288 bytes
      Current Size:  45,056 bytes (32KB ADDED)
      Entropy: 7.82 (HIGH - encrypted payload)

  [!] DXE Driver GUID: {EFGH5678-...} "UefiPayloadDxe" (NEW - not in vendor firmware)
      Size: 28,672 bytes
      Function: Drops persistence agent during boot

BOOT CHAIN INTEGRITY
bootmgfw.efi:     MODIFIED (hash mismatch, Secure Boot bypass via CVE-2022-21894)
winload.efi:      MODIFIED (DSE disabled at load time)
ntoskrnl.exe:     CLEAN (but unsigned driver loaded after boot)

KERNEL ROOTKIT COMPONENTS
Driver:           C:\Windows\System32\drivers\null_mod.sys (unsigned, hidden)
SSDT Hooks:       3 (NtQuerySystemInformation, NtQueryDirectoryFile, NtDeviceIoControlFile)
Hidden Processes: 2 (PID 6784: beacon.exe, PID 6812: keylog.exe)
Hidden Files:     C:\Windows\System32\drivers\null_mod.sys

ATTRIBUTION
Family:           BlackLotus variant
Confidence:       HIGH (CVE-2022-21894 exploit, ESP modification pattern matches)

REMEDIATION
1. Reflash SPI firmware with clean vendor image via hardware programmer
2. Rebuild EFI System Partition from clean Windows installation media
3. Reinstall OS from verified media
4. Enable all firmware write protections
5. Update firmware to latest version (patches CVE-2022-21894)