analyzing-uefi-bootkit-persistence

UEFIブートキットの永続化を分析する

使用する状況

• OSを再インストールした後やディスクを交換した後も、侵害されたシステムがC2通信を再確立する
• Secure Bootが改ざんまたは無効化されている、あるいは予期しないMachine Owner Key（MOK）の登録が確認される
• ファームウェアの整合性検証で、ベンダーが提供するベースラインとの不一致が検出される
• メモリフォレンジックで、起動初期段階に読み込まれるルートキットコンポーネントが見つかる
• UEFIインプラントの展開が知られている高度な持続的脅威（APT）キャンペーンを調査する
• エンタープライズエンドポイントの強化に向けて、ファームウェアのセキュリティ状況を監査する

使用しないでください。UEFIを搭載しないレガシーBIOSシステムの標準的なMBRベースのブートキットには使用せず、代わりにMBR/VBRブートキット分析を使用してください。

前提条件

• SPIフラッシュのダンプ、UEFI変数の検査、ファームウェアセキュリティモジュールに使用するchipsecフレームワーク
• ファームウェアボリュームの解析とDXEドライバーの抽出に使用するUEFITool / UEFIExtract
• struct、hashlib、subprocess、osモジュールを備えたPython 3.8+
• オフライン分析用の起動可能なLinuxライブUSB（侵害されたOSの実行は避けてください）
• 起動フェーズのアーティファクトのメモリフォレンジックに使用するVolatility 3
• パターンベースの検出に使用するUEFIマルウェアルールセットを備えたYARA
• 整合性比較用のベンダーファームウェアベースラインへのアクセス

ワークフロー

ステップ 1：SPIフラッシュファームウェアをダンプする

オフライン分析用にSPIフラッシュチップからUEFIファームウェアを取得します。

# Using chipsec to dump SPI flash contents
python chipsec_util.py spi dump firmware_dump.rom

# Using flashrom as an alternative
flashrom -p internal -r firmware_dump.rom

# Verify dump integrity
sha256sum firmware_dump.rom

# Read SPI flash descriptor information
python chipsec_util.py spi info

# Check SPI flash region access permissions
python chipsec_main.py -m common.spi_access

# Verify BIOS write protection is enabled
python chipsec_main.py -m common.bios_wp

# Check SPI flash controller lock
python chipsec_main.py -m common.spi_lock

ステップ 2：UEFI変数を検査する

不正な変更がないか、UEFI変数を列挙して分析します。

# List all UEFI variables on a live system
python chipsec_util.py uefi var-list

# List UEFI variables from a SPI flash dump
python chipsec_util.py uefi var-list-spi firmware_dump.rom

# Read specific Secure Boot variables
python chipsec_util.py uefi var-read SecureBoot 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read SetupMode 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read PK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read KEK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read db D719B2CB-3D3A-4596-A3BC-DAD00E67656F

# Dump UEFI key databases for analysis
python chipsec_util.py uefi keys

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

ステップ 3：EFIシステムパーティション（ESP）を分析する

不正または改変されたブートコンポーネントがないか、ESPを検査します。

# Mount ESP (typically the first FAT32 partition, ~100-500MB)
mkdir /mnt/esp
mount /dev/sda1 /mnt/esp

# List all files on ESP with timestamps
find /mnt/esp -type f -exec ls -la {} \;

# Check for BlackLotus indicators - custom directory under ESP:/system32/
ls -la /mnt/esp/system32/ 2>/dev/null

# Verify Windows Boot Manager signature
sigcheck -a /mnt/esp/EFI/Microsoft/Boot/bootmgfw.efi

# Hash all EFI binaries for comparison against known-good values
find /mnt/esp -name "*.efi" -exec sha256sum {} \;

# Check for unauthorized .efi files outside standard directories
find /mnt/esp -name "*.efi" | grep -v "Microsoft\|Boot\|ubuntu\|grub"

# Look for grubx64.efi planted by BlackLotus
find /mnt/esp -name "grubx64.efi" -exec sha256sum {} \;

# Examine MeasuredBoot logs for anomalies (Windows)
# Logs located at C:\Windows\Logs\MeasuredBoot\

ステップ 4：既知のブートキットのシグネチャをファームウェアからスキャンする

ファームウェアのダンプを分析し、既知のUEFIマルウェアのパターンを調べます。

# Extract all firmware modules with UEFIExtract
UEFIExtract firmware_dump.rom all

# Generate firmware module whitelist from vendor baseline
python chipsec_main.py -m tools.uefi.whitelist -a generate,baseline.json,firmware_vendor.rom

# Compare current firmware against whitelist
python chipsec_main.py -m tools.uefi.whitelist -a check,baseline.json,firmware_dump.rom

# Scan firmware with UEFI-specific YARA rules
yara -r uefi_bootkits.yar firmware_dump.rom

# Scan extracted modules individually
find firmware_dump.rom.dump -name "*.efi" -exec yara -r uefi_bootkits.yar {} \;

# Check for modified CORE_DXE module (targeted by MoonBounce, CosmicStrand)
# Compare GUID and hash against vendor baseline

ステップ 5：Secure Bootのバイパス手法を検出する

既知のSecure Bootバイパス手法を確認します。

# Check if Secure Boot is enabled
python chipsec_main.py -m common.secureboot.variables

# Verify SMM (System Management Mode) protections
python chipsec_main.py -m common.smm

# Check SMM BIOS write protection
python chipsec_main.py -m common.bios_smi

# On Windows - check boot configuration for bypass indicators
bcdedit /enum firmware
bcdedit /v

# Check for testsigning/nointegritychecks/debug flags
bcdedit | findstr /i "testsigning nointegritychecks debug"

# Verify HVCI (Hypervisor-enforced Code Integrity) is not disabled
# BlackLotus sets HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled=0
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled

# Check Secure Boot state via PowerShell
# Confirm-SecureBootUEFI returns True if properly enabled

ステップ 6：ブートチェーンの整合性検証を実行する

ファームウェアからカーネルまで、ブートチェーン内のすべてのコンポーネントを検証します。

# Verify firmware integrity against vendor hash
sha256sum firmware_dump.rom
# Compare with vendor-published hash

# Verify bootloader signatures
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
sigcheck -a C:\Windows\System32\winload.efi
sigcheck -a C:\Windows\System32\ntoskrnl.exe

# Check for unsigned or invalid boot drivers
sigcheck -u -e C:\Windows\System32\drivers\

# Analyze Measured Boot logs for unexpected EFI_Boot_Services_Application entries
# BlackLotus components appear as EV_EFI_Boot_Services_Application

# Memory forensics for boot-phase artifacts
vol3 -f memory.dmp windows.modules
vol3 -f memory.dmp windows.driverscan

ステップ 7：UEFIブートキット分析の調査結果を文書化する

包括的な分析レポートを作成します。

Report should include:
- Firmware version, vendor, and platform identification
- SPI flash protection status (write protect, lock bits, access control)
- Secure Boot configuration and any bypass indicators detected
- UEFI variable anomalies (unauthorized keys, modified db/dbx, MOK enrollment)
- ESP contents inventory with hash verification against known-good baselines
- Firmware module comparison against vendor whitelist (added, modified, removed)
- Known bootkit family attribution with confidence level
- Boot chain integrity verification results for each component
- Remediation steps (reflash, key rotation, hardware replacement)
- MITRE ATT&CK mapping (T1542.001 - System Firmware, T1542.003 - Bootkit)

主な概念

用語	定義
UEFIブートキット	UEFIファームウェアまたはブートプロセス内に永続化し、オペレーティングシステムの読み込み前に実行され、OSの再インストール後も残存するマルウェアです
SPIフラッシュ	UEFIファームウェアを格納するマザーボード上のシリアルペリフェラルインターフェース（SPI）フラッシュメモリチップです。LoJaxやMoonBounceのようなファームウェアレベルのブートキットは、SPIフラッシュの内容を改変します
EFIシステムパーティション（ESP）	EFIブートローダーとドライバーを格納するFAT32パーティションです。BlackLotusやESPecterのようなブートキットは、永続化のためにESP上のファイルを改変します
Secure Boot	ブートコンポーネントのデジタル署名を検証するUEFIセキュリティ機能です。脆弱性（CVE-2022-21894）やMOKの登録を利用して回避される可能性があります
DXEドライバー	UEFIの起動中に読み込まれるDriver Execution Environmentドライバーです。ファームウェアインプラントは悪意のあるDXEドライバーを挿入し、OSより先に実行します
Machine Owner Key（MOK）	ユーザーがインストールできるSecure Bootキーです。BlackLotusは攻撃者が制御するMOKを登録し、悪意のあるブートローダーに署名します
chipsec	SPIフラッシュ、UEFI変数、Secure Boot、ハードウェアセキュリティ構成の分析に使用するIntelのプラットフォームセキュリティ評価フレームワークです
HVCI	ハイパーバイザーによって適用されるコード整合性機能で、Windowsのセキュリティ機能です。ブートキットはこれを無効化して、署名されていないカーネルドライバーを読み込みます

ツールとシステム

• chipsec：SPI フラッシュのダンプ、UEFI 変数の読み取り、ファームウェアの書き込み保護の検証、セキュアブート設定の監査を行う Intel のフレームワーク
• UEFITool：ファームウェアボリュームの検査、DXE ドライバーの抽出、モジュール GUID の比較に使用する、オープンソースの UEFI ファームウェアイメージパーサー
• sigcheck：EFI バイナリとブートチェーンコンポーネントのデジタル署名を検証する Sysinternals のユーティリティ
• flashrom：対応プラットフォーム上のファームウェアチップの読み取りと書き込みを行う、オープンソースの SPI フラッシュプログラマー
• YARA：ファームウェアダンプ内の既知のブートキットのシグネチャを検出するため、UEFI 固有のルールセットと併用するパターンマッチングエンジン

よくあるシナリオ

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

状況：侵害が確認されたエンタープライズエンドポイントを再イメージ化しましたが、数時間以内に同一の C2 ビーコン通信が再開しました。このエンドポイントは、セキュアブートが有効な UEFI ファームウェアと TPM 2.0 チップを搭載しています。セキュリティチームは、BlackLotus や LoJax に類似した UEFI レベルのインプラントを疑っています。

アプローチ：

1. 信頼できる Linux ライブ USB からシステムを起動し、侵害された OS のコンポーネントが実行されないようにします
2. chipsec_util.py spi dump を使って SPI フラッシュファームウェアをダンプし、オフラインで分析します
3. ESP をマウントし、すべての .efi ファイルのハッシュを、同一ハードウェアの正常な既知値と照合します
4. ESP:/system32/ ディレクトリ（BlackLotus の兆候）と、許可されていない grubx64.efi がないか確認します
5. UEFIExtract でファームウェアモジュールを抽出し、GUID の一覧をベンダーのベースラインと比較します
6. セキュアブート変数を検証し、許可されていない MOK の登録や、変更された db/dbx がないか確認します
7. chipsec モジュールを使って、SPI フラッシュの書き込み保護とロックビットを確認します
8. ファームウェアダンプと抽出したモジュールを、UEFI 固有の YARA ルールでスキャンします
9. BlackLotus が疑われる場合は、レジストリで HVCI が無効になっていないか、また MeasuredBoot ログに異常なエントリがないか確認します

落とし穴：

• 侵害された OS から分析を実行する（ルートキットのコンポーネントがライブ分析から隠れる可能性があります）
• SPI フラッシュファームウェアを調べず、ESP だけを確認する（LoJax や MoonBounce などのファームウェアレベルのインプラントを見逃します）
• セキュアブートですべてのブートキットを防げると思い込む（CVE-2022-21894 などのバイパスが存在します）
• 修復前に元のファームウェアダンプを保全しない（重要なフォレンジック証拠です）
• ベンダーイメージが本物で改変されていないことを検証せずにファームウェアを書き換える

出力形式

UEFI BOOTKIT PERSISTENCE ANALYSIS REPORT
============================================
System:           Lenovo ThinkPad X1 Carbon Gen 11
Firmware:         N3HET82W (1.54) - Lenovo UEFI BIOS
Platform:         Intel 13th Gen (Raptor Lake)
TPM:              2.0 (Infineon SLB 9672)
Secure Boot:      ENABLED (BYPASSED via CVE-2022-21894)
Analysis Method:  Linux live USB + chipsec + UEFITool

SPI FLASH PROTECTION STATUS
BIOS Write Protection:    DISABLED [!]
SPI Flash Lock (FLOCKDN): SET [OK]
SMM BIOS Write Protect:   DISABLED [!]
SPI Protected Ranges:     Region 0 only (descriptor)

UEFI VARIABLE ANALYSIS
SecureBoot:        Enabled (value=1)
SetupMode:         Disabled (value=0)
PK:                Lenovo Ltd. (legitimate)
KEK:               Microsoft + Lenovo (legitimate)
db:                MODIFIED - contains unauthorized entry [!]
  [!] Unknown certificate: CN=Secure Boot Signing, O=Unknown
  [!] Not present in vendor baseline db
MOK:               1 unauthorized key enrolled [!]
  [!] MOK enrolled: CN=shim, self-signed, not from distro vendor

ESP PARTITION ANALYSIS
Total EFI binaries:     12
Verified (signed):      9
Modified (hash mismatch): 2 [!]
Unauthorized:           1 [!]

  [!] EFI/Microsoft/Boot/bootmgfw.efi - MODIFIED
      Expected SHA-256: a3f2c8...
      Current SHA-256:  7b1e4d...
      Signature:        Valid (signed with unauthorized MOK)

  [!] EFI/Microsoft/Boot/grubx64.efi - UNAUTHORIZED
      SHA-256:  e9c1a7...
      Not present in vendor baseline
      Matches BlackLotus stage-2 loader signature

  [!] system32/ directory present on ESP (BlackLotus artifact)
      Directory empty (files deleted post-installation)

FIRMWARE MODULE ANALYSIS
Total firmware modules:   312
Vendor baseline modules:  312
Added modules:            0
Modified modules:         0
SPI flash integrity:      CLEAN (no firmware-level implant detected)

BOOTKIT ATTRIBUTION
Family:           BlackLotus
Confidence:       HIGH
Persistence:      ESP-based (not SPI flash)
Bypass Method:    CVE-2022-21894 (baton drop)
MITRE ATT&CK:    T1542.003 (Bootkit), T1553.006 (Code Signing Policy Modification)

INDICATORS OF COMPROMISE
- ESP:/system32/ directory (empty, post-cleanup artifact)
- ESP:/EFI/Microsoft/Boot/grubx64.efi (unauthorized, BlackLotus loader)
- Modified bootmgfw.efi (re-signed with attacker MOK)
- HVCI disabled via registry: DeviceGuard\...\Enabled = 0
- Unauthorized MOK enrollment in UEFI variable store
- MeasuredBoot log shows EV_EFI_Boot_Services_Application for grubx64.efi

REMEDIATION
1. Replace bootmgfw.efi with authentic copy from Windows installation media
2. Delete unauthorized grubx64.efi and system32/ directory from ESP
3. Reset Secure Boot keys to factory defaults (clear MOK, restore PK/KEK/db)
4. Enable BIOS write protection and verify SPI flash lock bits
5. Apply firmware update to latest version (patches CVE-2022-21894)
6. Enable HVCI and verify via Group Policy
7. Reimport only trusted certificates into Secure Boot db
8. Monitor MeasuredBoot logs for anomalous boot component loading