UEFIブートキット永続化分析

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

使用すべき状況

• 侵害されたシステムが、OSの再インストールやディスク交換後にもC2通信を再確立する場合
• セキュアブートが改ざん、無効化されている、または予期しないマシンオーナーキー（MOK）が登録されている場合
• ファームウェアの整合性検証がベンダー提供のベースラインに対して失敗する場合
• メモリフォレンジックで、起動初期フェーズにルートキットコンポーネントがロードされていることが明らかになった場合
• UEFIインプラントを展開することが知られている高度な持続的脅威（APT）キャンペーンを調査する場合
• エンタープライズエンドポイントの堅牢化のためにファームウェアのセキュリティ態勢を監査する場合

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

前提条件

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

ワークフロー

ステップ1: SPIフラッシュファームウェアのダンプ

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

# chipsecを使用してSPIフラッシュの内容をダンプ
python chipsec_util.py spi dump firmware_dump.rom

# 代替としてflashromを使用
flashrom -p internal -r firmware_dump.rom

# ダンプの整合性を確認
sha256sum firmware_dump.rom

# SPIフラッシュディスクリプタ情報を読み取り
python chipsec_util.py spi info

# SPIフラッシュ領域のアクセス許可を確認
python chipsec_main.py -m common.spi_access

# BIOS書き込み保護が有効であることを確認
python chipsec_main.py -m common.bios_wp

# SPIフラッシュコントローラのロックを確認
python chipsec_main.py -m common.spi_lock

ステップ2: UEFI変数の検査

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

# ライブシステム上のすべてのUEFI変数を一覧表示
python chipsec_util.py uefi var-list

# SPIフラッシュダンプからUEFI変数を一覧表示
python chipsec_util.py uefi var-list-spi firmware_dump.rom

# 特定のセキュアブート変数を読み取り
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

# 分析用にUEFIキーデータベースをダンプ
python chipsec_util.py uefi keys

# セキュアブート設定モジュールを確認
python chipsec_main.py -m common.secureboot.variables

ステップ3: EFIシステムパーティション（ESP）の分析

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

# ESPをマウント（通常は最初のFAT32パーティション、約100-500MB）
mkdir /mnt/esp
mount /dev/sda1 /mnt/esp

# タイムスタンプ付きでESP上のすべてのファイルを一覧表示
find /mnt/esp -type f -exec ls -la {} \;

# BlackLotusの指標となるカスタムディレクトリ ESP:/system32/ を確認
ls -la /mnt/esp/system32/ 2>/dev/null

# Windows Boot Managerの署名を検証
sigcheck -a /mnt/esp/EFI/Microsoft/Boot/bootmgfw.efi

# 既知の正常値と比較するため、すべてのEFIバイナリをハッシュ化
find /mnt/esp -name "*.efi" -exec sha256sum {} \;

# 標準ディレクトリ以外に存在する不正な.efiファイルを確認
find /mnt/esp -name "*.efi" | grep -v "Microsoft\|Boot\|ubuntu\|grub"

# BlackLotusによって仕掛けられたgrubx64.efiを検索
find /mnt/esp -name "grubx64.efi" -exec sha256sum {} \;

# 異常がないかMeasuredBootログを調査（Windows）
# ログの場所: C:\Windows\Logs\MeasuredBoot\

ステップ4: 既知のブートキットシグネチャのファームウェアスキャン

ファームウェアダンプを既知のUEFIマルウェアパターンについて分析します:

# UEFIExtractですべてのファームウェアモジュールを抽出
UEFIExtract firmware_dump.rom all

# ベンダーベースラインからファームウェアモジュールのホワイトリストを生成
python chipsec_main.py -m tools.uefi.whitelist -a generate,baseline.json,firmware_vendor.rom

# 現在のファームウェアをホワイトリストと比較
python chipsec_main.py -m tools.uefi.whitelist -a check,baseline.json,firmware_dump.rom

# UEFI固有のYARAルールでファームウェアをスキャン
yara -r uefi_bootkits.yar firmware_dump.rom

# 抽出されたモジュールを個別にスキャン
find firmware_dump.rom.dump -name "*.efi" -exec yara -r uefi_bootkits.yar {} \;

# 変更されたCORE_DXEモジュールを確認（MoonBounce、CosmicStrandの標的）
# GUIDとハッシュをベンダーベースラインと比較

ステップ5: セキュアブートバイパスメカニズムの検出

既知のセキュアブートバイパス手法を確認します:

# セキュアブートが有効かどうかを確認
python chipsec_main.py -m common.secureboot.variables

# SMM（システム管理モード）の保護を検証
python chipsec_main.py -m common.smm

# SMM BIOS書き込み保護を確認
python chipsec_main.py -m common.bios_smi

# Windowsの場合 - バイパス指標のブート設定を確認
bcdedit /enum firmware
bcdedit /v

# testsigning/nointegritychecks/debugフラグを確認
bcdedit | findstr /i "testsigning nointegritychecks debug"

# HVCI（ハイパーバイザー強制コード整合性）が無効化されていないことを確認
# BlackLotusは HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled=0 を設定
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled

# PowerShellでセキュアブート状態を確認
# Confirm-SecureBootUEFI は適切に有効な場合に True を返す

ステップ6: ブートチェーン整合性検証の実行

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

# ベンダーハッシュに対するファームウェアの整合性を検証
sha256sum firmware_dump.rom
# ベンダー公開のハッシュと比較

# ブートローダーの署名を検証
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
sigcheck -a C:\Windows\System32\winload.efi
sigcheck -a C:\Windows\System32\ntoskrnl.exe

# 署名なしまたは無効なブートドライバを確認
sigcheck -u -e C:\Windows\System32\drivers\

# 予期しないEFI_Boot_Services_ApplicationエントリがないかMeasured Bootログを分析
# BlackLotusコンポーネントは EV_EFI_Boot_Services_Application として表示される

# ブートフェーズアーティファクトのメモリフォレンジック
vol3 -f memory.dmp windows.modules
vol3 -f memory.dmp windows.driverscan

ステップ7: UEFIブートキット分析結果の文書化

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

レポートには以下を含める:
- ファームウェアバージョン、ベンダー、プラットフォームの識別
- SPIフラッシュ保護ステータス（書き込み保護、ロックビット、アクセス制御）
- セキュアブート設定と検出されたバイパス指標
- UEFI変数の異常（不正なキー、変更されたdb/dbx、MOK登録）
- 既知の正常ベースラインに対するハッシュ検証付きESPコンテンツ一覧
- ベンダーホワイトリストとのファームウェアモジュール比較（追加、変更、削除）
- 信頼レベル付きの既知ブートキットファミリー属性
- 各コンポーネントのブートチェーン整合性検証結果
- 修復手順（再フラッシュ、キーローテーション、ハードウェア交換）
- MITRE ATT&CKマッピング（T1542.001 - システムファームウェア、T1542.003 - ブートキット）

主要な概念

用語	定義
UEFIブートキット	UEFIファームウェアまたはブートプロセスに永続化し、OSの読み込み前に実行され、OSの再インストール後も存続するマルウェア
SPIフラッシュ	マザーボード上でUEFIファームウェアを格納するSPIフラッシュメモリチップ。LoJaxやMoonBounceなどのファームウェアレベルブートキットはSPIフラッシュの内容を変更する
EFIシステムパーティション（ESP）	EFIブートローダーとドライバを含むFAT32パーティション。BlackLotusやESPecterなどのブートキットは永続化のためにESP上のファイルを変更する
セキュアブート	ブートコンポーネントのデジタル署名を検証するUEFIセキュリティ機能。脆弱性（CVE-2022-21894）やMOK登録によりバイパスされる可能性がある
DXEドライバ	UEFIブート中にロードされるドライバ実行環境ドライバ。ファームウェアインプラントは、OSの前に実行される悪意のあるDXEドライバを注入する
マシンオーナーキー（MOK）	ユーザーがインストール可能なセキュアブートキー。BlackLotusは攻撃者制御のMOKを登録して悪意のあるブートローダーに署名する
chipsec	SPIフラッシュ、UEFI変数、セキュアブート、ハードウェアセキュリティ設定の分析のための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から分析を実行する（ルートキットコンポーネントはライブ分析から隠蔽される）
• ESPのみをチェックし、SPIフラッシュファームウェアを調査しない（LoJax、MoonBounceなどのファームウェアレベルインプラントを見逃す）
• セキュアブートがすべてのブートキットを防ぐと想定する（CVE-2022-21894およびその他のバイパスが存在する）
• 修復前に元のファームウェアダンプを保存しない（重要なフォレンジック証拠）
• ベンダーイメージが本物で改変されていないことを確認せずにファームウェアを再フラッシュする

出力形式

UEFIブートキット永続化分析レポート
============================================
システム:         Lenovo ThinkPad X1 Carbon Gen 11
ファームウェア:   N3HET82W (1.54) - Lenovo UEFI BIOS
プラットフォーム: Intel 第13世代 (Raptor Lake)
TPM:              2.0 (Infineon SLB 9672)
セキュアブート:   有効 (CVE-2022-21894 によりバイパス)
分析方法:         LinuxライブUSB + chipsec + UEFITool

SPIフラッシュ保護ステータス
BIOS書き込み保護:     無効 [!]
SPIフラッシュロック (FLOCKDN): 設定済み [OK]
SMM BIOS書き込み保護: 無効 [!]
SPI保護範囲:          リージョン0のみ（ディスクリプタ）

UEFI変数分析
SecureBoot:        有効 (値=1)
SetupMode:         無効 (値=0)
PK:                Lenovo Ltd. (正当)
KEK:               Microsoft + Lenovo (正当)
db:                変更済み - 不正なエントリを含む [!]
  [!] 不明な証明書: CN=Secure Boot Signing, O=Unknown
  [!] ベンダーベースラインのdbに存在しない
MOK:               1つの不正なキーが登録済み [!]
  [!] MOK登録: CN=shim, 自己署名, ディストリベンダー製ではない

ESPパーティション分析
EFIバイナリ総数:     12
検証済み（署名済み）: 9
変更済み（ハッシュ不一致）: 2 [!]
不正:                 1 [!]

  [!] EFI/Microsoft/Boot/bootmgfw.efi - 変更済み
      期待されるSHA-256: a3f2c8...
      現在のSHA-256:    7b1e4d...
      署名:             有効（不正なMOKで署名）

  [!] EFI/Microsoft/Boot/grubx64.efi - 不正
      SHA-256:  e9c1a7...
      ベンダーベースラインに存在しない
      BlackLotusステージ2ローダーのシグネチャと一致

  [!] ESP上にsystem32/ ディレクトリが存在（BlackLotusアーティファクト）
      ディレクトリは空（インストール後にファイル削除）

ファームウェアモジュール分析
ファームウェアモジュール総数:   312
ベンダーベースラインモジュール: 312
追加モジュール:                 0
変更モジュール:                 0
SPIフラッシュ整合性:           クリーン（ファームウェアレベルのインプラントは検出されず）

ブートキット属性
ファミリー:       BlackLotus
信頼度:           高
永続化:           ESPベース（SPIフラッシュではない）
バイパス方法:     CVE-2022-21894 (バトンドロップ)
MITRE ATT&CK:    T1542.003 (ブートキット), T1553.006 (コード署名ポリシーの変更)

侵害指標
- ESP:/system32/ ディレクトリ（空、クリーンアップ後のアーティファクト）
- ESP:/EFI/Microsoft/Boot/grubx64.efi（不正、BlackLotusローダー）
- 変更されたbootmgfw.efi（攻撃者のMOKで再署名）
- レジストリによりHVCI無効化: DeviceGuard\...\Enabled = 0
- UEFI変数ストア内の不正なMOK登録
- MeasuredBootログにgrubx64.efiのEV_EFI_Boot_Services_Applicationが表示

修復手順
1. bootmgfw.efiをWindowsインストールメディアの正規コピーと交換する
2. 不正なgrubx64.efiとESP上のsystem32/ディレクトリを削除する
3. セキュアブートキーを工場出荷時設定にリセットする（MOKをクリア、PK/KEK/dbを復元）
4. BIOS書き込み保護を有効にし、SPIフラッシュロックビットを確認する
5. ファームウェアを最新バージョンに更新する（CVE-2022-21894を修正）
6. HVCIを有効にし、グループポリシーで確認する
7. 信頼できる証明書のみをセキュアブートdbに再インポートする
8. MeasuredBootログを監視し、異常なブートコンポーネントの読み込みを確認する