【AI文芸】UEFIフォレンジック
基本
「UEFIフォレンジックね……」
玲奈は手を組んで静かに目を閉じた。
「まず、UEFI（Unified Extensible Firmware Interface）は、PCの電源を入れたときに最初に動くファームウェアよ。昔のBIOSとは違って、より高度で複雑な仕組みになっている。その分、セキュリティリスクも増しているわ」
玲奈は椅子に深く腰掛け、テーブルを軽く叩いた。
「フォレンジックの観点から見ると、UEFIは極めて厄介な領域ね。なぜなら、OSが起動する前に実行されるコードだから、ここを汚染されたら通常のセキュリティツールじゃ手も足も出ない。UEFIマルウェアは持続性が高く、ストレージを初期化しても生き残る。つまり、完全なクリーンインストールをしたつもりでも、また感染する可能性があるのよ」
玲奈はわずかに口角を上げた。
「だから、UEFIのフォレンジックは、通常のディスクやメモリの分析とは別のアプローチが必要になる。まず、UEFIのファームウェアイメージをダンプして、改ざんの有無を確認する。具体的には、chipsec や UEFItool を使ってファームウェアを抽出し、既知のクリーンなイメージと比較する方法が一般的ね」
玲奈は手元のノートPCを開くと、指を滑らせた。
「UEFIフォレンジックの手順は大きく分けて三つよ。
① ファームウェアの抽出と比較： chipsec や Flashrom を使ってUEFIファームウェアのダンプを取得し、正常なUEFIとバイナリ比較をする。
② 悪意のあるモジュールの検出： UEFIには様々なDXEドライバが含まれているけど、その中に未知のコードが潜んでいないか調べる。特にPEIやDXEフェーズに注目するわ。
③ ログとイベントの解析： Windows Event Log にはUEFIに関するログが残っていることがある。セキュアブートの無効化やファームウェアアップデートの痕跡を確認するのも大事ね」
玲奈は指を組んで、静かに言葉を続けた。
「UEFIの改ざんは気付きにくい。しかも最近はBlackLotusみたいなブートキットがセキュアブートを回避する事例もある。だから、OSレベルの対策だけじゃ不十分で、ハードウェアレベルの信頼性チェックも必要になってくるのよ」
玲奈は一拍置いて、軽く肩をすくめた。
「結論として、UEFIフォレンジックはOSフォレンジックよりも遥かに難しい。でも、だからこそ面白いのよ。OSを吹き飛ばしても生き残る脅威、それをどうやって見つけ、無力化するか――その戦いの舞台がここにあるの」
玲奈は笑った。だが、その瞳の奥には、まだ語り尽くせぬ情報の嵐が渦巻いていた。
UEFIフォレンジックの詳細手順
玲奈はノートPCを開き、画面にコードを流しながら話し始めた。
「じゃあ、実際の手順をできるだけ詳しく説明するわね」
1. UEFIファームウェアの抽出
まず、UEFIのイメージを取得しないことには始まらない。方法はいくつかあるけど、代表的なものを紹介するわ。
1-1. chipsec を使用したUEFIダンプ
chipsec はIntelのプラットフォームセキュリティツールで、UEFIファームウェアのダンプや解析が可能よ。
手順：
chipsec をインストール（Linux環境推奨） git clone https://github.com/chipsec/chipsec.git cd chipsec python setup.py install
UEFIのファームウェアダンプを取得 sudo python chipsec_main.py -m tools.uefi.uefi_dump これで、chipsec がSPIフラッシュメモリからUEFIの内容をダンプする。
1-2. Flashrom を使用したダンプ
もう一つの方法として flashrom を使うのもアリね。flashrom は主にBIOSやUEFIのリード・ライトを行うツール。
手順：
flashrom をインストール sudo apt install flashrom
どのチップにアクセスできるか確認 sudo flashrom -p internal
ダンプの取得 sudo flashrom -p internal -r uefi_dump.bin
2. UEFIファームウェアの解析
ダンプしたUEFIのイメージを解析するフェーズ。ここでは、UEFITool や Binwalk、chipsec を使うわ。
2-1. UEFITool を使用した解析
UEFITool はUEFIファームウェアの内部構造を解析できるGUIツールよ。
手順：
UEFITool をダウンロード
uefi_dump.bin をロード
DXE Driver セクションを開いて、不審なモジュールを探す
未知のDXEドライバが含まれていないかチェック
PEヘッダーを確認し、不審なコードが含まれていないか
2-2. Binwalk を使った解析
binwalk はバイナリファイルのパターンを解析するツールで、UEFIの構造をざっくり見るのに役立つ。
手順：
binwalk -e uefi_dump.bin
これでファームウェアの内部構造を抽出して、個々のモジュールを確認できる。
3. UEFIマルウェアの検出
次に、ダンプしたUEFIの中にマルウェアが仕込まれていないかを調査する。
3-1. chipsec を使った改ざんチェック
chipsec はUEFIの異常を検知する機能もある。
手順：
sudo python chipsec_main.py -m tools.uefi.uefi_whitelist
これで既知のUEFIイメージと比較して、不審な変更がないかをチェックできる。
3-2. YARA を使ったUEFIマルウェアのスキャン
YARAはマルウェアのパターンを検索するツールで、UEFIの中に既知のマルウェアがないかを調べる。
手順：
YARAをインストール sudo apt install yara
既存のUEFIマルウェアのルールを適用（例：BlackLotus のシグネチャ） yara -r uefi_malware_rules.yar uefi_dump.bin
4. セキュアブート & ログの解析
UEFIの改ざんを検知するもう一つの方法として、OSレベルのログを調査するのも有効よ。
4-1. Windows Event Log の確認
Windowsなら、UEFI関連のイベントログが残っていることがある。
手順：
イベントビューア を開く
アプリケーションとサービスログ > Microsoft > Windows > Kernel-Boot に移動
Event ID 112（セキュアブートの無効化）や Event ID 1001（UEFIブートエラー）を探す
4-2. efibootmgr を使ったLinuxでのチェック
Linuxなら efibootmgr を使ってUEFIの設定を確認できる。
手順：
sudo efibootmgr -v
ここで、不審なブートエントリーがないかチェックする。
5. UEFIの修復・対策
もしUEFIが改ざんされていた場合、修復が必要になるわ。
5-1. UEFIのリカバリー
最も確実なのはメーカー提供のクリーンなUEFIイメージに書き戻すことね。
手順：
メーカー公式サイトから最新のUEFIファームウェアをダウンロード
flashrom を使って書き込み sudo flashrom -p internal -w clean_uefi.bin
5-2. TPM & セキュアブートの有効化
UEFIマルウェアの多くはセキュアブートを無効化して悪用するから、これを再有効化するのも重要。
手順：
UEFI設定画面に入る（F2 や Del で起動時に入る）
Secure Boot を有効化
TPM 2.0（Trusted Platform Module）が有効になっているか確認
6. まとめ
玲奈は手を組んで、少し微笑んだ。
「UEFIフォレンジックは、普通のOSフォレンジックと違って、より低レイヤーの戦いになる。通常のログ解析だけじゃ不十分で、ファームウェアレベルでの検証が必要よ。だから、まずはUEFIのダンプを取得して、バイナリを徹底的に解析すること。マルウェアの兆候を見つけたら、イベントログやブートエントリーを調べて、異常な動作がないかをチェックする。最後に、クリーンなUEFIを書き戻して、TPMやセキュアブートを有効化して防御を固める。これが王道ね」
玲奈はノートPCを閉じ、軽く肩をすくめた。
「ま、UEFIに手を出すような奴は、相当手練れだからね。戦うなら、それ相応の覚悟はしておくことね」
仮想事例 - 「UEFI戦争」
玲奈はノートPCの画面を睨んでいた。
スクリーンにはUEFIToolのログが流れている。
DXE Driver detected: Unrecognized module - UUID 8EFA034F-DF40-4A4C-B79F-505C999D29B0
「……いたわね」玲奈は低く呟いた。
UEFIの改ざんを示す証拠。
DXE（Driver Execution Environment）フェーズで、不審なドライバが仕込まれていた。
玲奈は手元のchipsecを走らせる。
sudo python chipsec_main.py -m tools.uefi.uefi_whitelist
[!] WARNING: Unknown module detected in DXE phase
Potential persistence threat detected
「やっぱり、こいつ……OSのブート前に実行されるように仕込まれてる」
玲奈は冷静にキーボードを叩いた。
攻撃者の狙いは明白だった。
OSがロードされる前にUEFIレベルでマルウェアを実行し、完全にステルスなバックドアを仕込む
Windowsをクリーンインストールしようが、SSDをフォーマットしようが、このUEFIマルウェアは生き残る。
いわゆる「ブートキット（Bootkit）」だった。
「くそったれ……BlackLotusの亜種かもしれないわね」
玲奈は腕を組んだ。
これは通常のフォレンジックの範疇を超えている。
OSレイヤーでの対応は無意味。ファームウェアごと焼き直さない限り、この侵入者は消えない。
玲奈は深く息を吸い、マシンのTPMステータスを確認した。
tpm2_getcap properties-variable | grep TPM2_PT_PERSISTENT
[!] WARNING: TPM disabled
「……なるほどね。セキュアブートも、TPMも殺してから仕込まれたってわけ」
敵は用意周到だった。
対抗策：UEFIを奪還せよ
玲奈は戦術を組み立てた。
UEFIのファームウェアを完全ダンプし、改ざん箇所を特定
ブラックリストに載っていない未知のコードを解析
攻撃者の署名が残っているか調べる
ファームウェアをクリーンイメージで書き直す
TPMとセキュアブートを再設定し、二度と侵入させない
玲奈は速やかにflashromを起動した。
sudo flashrom -p internal -r infected_uefi.bin
数秒後、ダンプが完了する。
玲奈は即座にbinwalkでバイナリの中身を調査する。
binwalk -e infected_uefi.bin
Unrecognized section: PE32 executable (DXE phase)
「やっぱり」
コードの一部が改ざんされ、新しいDXEドライバが挿入されていた。
玲奈はUEFIToolで開き、不審なモジュールを見つけ出す。
通常のUEFIにない、新しいドライバが追加されている。
UUIDは知らないものだが、似たパターンのマルウェアを調べると昨年報告されたUEFIブートキットの一部と一致していた。
「……これ、リモートでC2サーバーと通信する機能があるわね」
マルウェアのコードを見つめる。
OSが起動する前に、UEFIレベルでネットワーク通信を開始し、攻撃者のC2（Command & Control）サーバーと接続する仕組み。
OSに一切の痕跡を残さず、バックドアを維持するという極悪仕様。
玲奈は肩をすくめた。
「そんなもん、許すわけないでしょ」
逆転：完全なUEFIリストア
玲奈はメーカー公式のUEFIファームウェアをダウンロードする。
clean_uefi.bin
「こいつを焼き直して、完全に仕留める」
sudo flashrom -p internal -w clean_uefi.bin
書き込みが始まる。
UEFIレベルの敵を駆逐する唯一の方法——それは、クリーンなイメージで塗りつぶすこと。
玲奈は腕を組んで、書き込みの進捗を見つめる。
数分後、完了のメッセージが表示された。
Verifying flash... VERIFIED.
「……終わった」
玲奈は再起動し、UEFI設定画面に入る。
TPMを有効化し、セキュアブートを再設定。
sudo tpm2_activatecredential -c owner -C endorse -i clean_key -o secured
すべての対策が完了した。
玲奈はゆっくりと目を閉じ、静かに呟いた。
「これで、もう二度と侵入させない」
PCは沈黙していた。
だが、それは平穏の証だった。
UEFIフォレンジック戦争——完勝。
付録：メーカー自身が意図的に組み込んだバックドア
玲奈は静かに画面を見つめていた。
UEFIのダンプログが流れ、そこに記された不審なコード。
玲奈は腕を組み、軽く息を吐いた。
「……知ってる？ UEFIの脆弱性って、サイバー犯罪者だけのものじゃないのよ」
玲奈は画面を指差した。
「これ、よくあるUEFIの改ざんコードね。でも、もっと厄介なのは、こういうのがメーカー自身によって意図的に仕込まれることがあるってこと」
玲奈はキーボードを叩き、スクリーンに別のログを表示させた。
Hidden Debug Mode Detected: Manufacturing Mode Active
「例えば、隠されたデバッグインターフェース。一部のPCには、メーカーの製造テスト用にUEFIの特権モードが隠されてる。これが悪用されると、管理者権限をバイパスして、UEFIを書き換えることができるのよ」
玲奈は眉をひそめた。
「そして、もうひとつヤバいのが、Intel ME（Management Engine）やAMD PSP（Platform Security Processor）。OSよりも先に動く、独立したマイクロコントローラ。これが侵害されたら……もう何をやっても無駄ね」
玲奈は手を止め、しばらく考え込むように視線を落とした。
「これだけじゃない。リモート管理機能の悪用、Secure Bootの鍵漏洩……。2016年にはMicrosoftのSecure Bootの鍵が流出して、どんなUEFIコードでも署名を通過できる状態になった。つまり、誰でもUEFIレベルでマルウェアを仕込めるようになった」
玲奈は目を細め、静かに呟く。
「こういうの、どこまで"脆弱性"で、どこからが"意図的なバックドア"なのか……境界線が曖昧なのよ」
玲奈は軽く椅子の背に寄りかかると、天井を見上げた。
「それじゃあ、どうやって対抗するか――」
玲奈は再び画面を見つめ、指をすべらせる。
「オープンソースのファームウェアに入れ替えるって手がある。CorebootとかLibrebootとかね。Intel MEもme_cleanerを使えば部分的に無効化できる。でも……完全に消すのは難しい」
玲奈はわずかに微笑んだ。
「結局、一般のPCってのは、メーカーが完全に掌握してるのよ。本当に"クリーン"なハードウェアを使おうと思ったら、自分でファームウェアを書き直すか、特定のセキュリティ特化PCを使うしかない」
1. メーカーが設定したバックドアの種類
(1) Hidden Debug Interfaces（隠されたデバッグインターフェース）
一部のUEFIファームウェアには、メーカーや開発者向けの隠しデバッグモードが存在する。
これが悪用されると、特定のコマンドを送るだけで管理者権限でUEFIを操作できる。
例: Intelの製品に存在した「Manufacturing Mode」
特定のUEFI設定を変更せずにリモート操作が可能だった。
(2) Intel ME（Management Engine）やAMD PSP（Platform Security Processor）の存在
Intel ME（Management Engine）とAMD PSP（Platform Security Processor）は、CPUとは独立して動作する独自のマイクロコントローラ。
これらのモジュールはOSよりも先に動き、ハードウェアの完全な制御を握る。
一部の政府機関は、Intel MEを無効化するカスタムBIOSを使用している（例: PurismのLibremノートPC）。
(3) Remote Management（リモート管理機能）
企業向けのPCでは、IntelのAMT（Active Management Technology）のようなリモート管理機能が搭載されている。
これが悪用されると、OSが起動する前に外部からPCを完全制御できる。
悪用事例:
2017年に発覚した「Intel AMTの未認証リモートアクセス脆弱性」（CVE-2017-5689）は、ネットワーク経由でPCをフルコントロール可能だった。
(4) Secure Bootの鍵漏洩
Secure Bootは、本来「未承認のUEFIコードをブロックする」ためのもの。
しかし、マスターキー（プライベートキー）が漏洩した場合、どんなUEFIコードでも認証を通過してしまう。
例: MicrosoftのSecure Bootの鍵漏洩（2016年）
「Golden Key」と呼ばれるバックドアが存在し、マルウェアが署名付きUEFIコードを実行できる状態になった。
2. これらのバックドアを防ぐ方法
「メーカーが仕込んだバックドアだから防げない」と思うかもしれないけど、対策は存在する。
(1) CorebootやLibrebootのようなオープンソースBIOSを使う
既存のUEFIを捨て、完全にオープンソースのファームウェアに入れ替える。
ただし、サポートするハードウェアが限られる。
(2) Intel ME/AMD PSPを無効化する
Intel MEは「me_cleaner」を使うことで一部機能を無効化できる。 sudo python me_cleaner.py -S -r firmware.bin -w cleaned.bin
ただし、完全に無効化するのは難しく、メーカーごとに対策が異なる。
(3) UEFIファームウェアのロックダウン
一部のBIOS設定で、Secure Bootの鍵を手動で管理できる。
可能なら、Secure Bootを完全にカスタム鍵に変更して、メーカーの鍵を排除する。
(4) 物理的なハードウェア改造
Purismの「Librem」シリーズのように、Intel MEをハードウェア的に無効化したPCを使う。
これは一般のPCでは難しいが、セキュリティを徹底したい場合には検討の余地がある。
3. 結論
UEFIレベルのバックドアは、攻撃者だけでなく、メーカー自身が仕込んでいる可能性がある。
これを完全に防ぐのは難しいけど、オープンソースBIOSやIntel MEの無効化、UEFIのカスタム鍵管理である程度リスクを抑えられる。
玲奈は画面を閉じ、静かに言った。
「……ま、どこまで疑うかは自分次第だけどね」