BlackXが中央アジアの外交機関を標的に Windows更新後も必要なSecure Boot対策
2026年10月24日 13:57
カスペルスキーのグローバル調査分析チーム（GReAT）は2026年10月22日、中央アジアの外交機関を狙ったUEFIブートキット「BlackX」の調査報告を公開した。標的はタジキスタン、ウズベキスタン、トルクメニスタンの外交組織で、同社は攻撃をAPT41の活動と中程度の確度で判断している。
同社によると、調査した標的端末には関連するWindows更新プログラムが導入されていたが、脆弱な起動コンポーネントを拒否するための追加措置が有効になっていなかった。OSの更新状況に加え、起動時の信頼設定まで確認する重要性が浮かび上がった。
■BlackLotusに似た導入手順
BlackXの発見は2026年初頭にさかのぼる。カスペルスキーは、中央アジアで確認した攻撃に、既知のUEFIブートキット「BlackLotus」と似たマルウェアが使われていることを突き止めた。
BlackLotusは2022年10月、ハッキングフォーラムで5000ドル（約78万5000円）の販売広告が確認された。当初は、Secure Bootを突破する能力に対して価格が低く、実際の検体も確認されていなかったことから、セキュリティ業界には慎重な見方があったとカスペルスキーは振り返る。
ESETは2023年3月、BlackLotusの解析結果を公表した。調査時点で最新の更新を適用したWindows 11でも、Secure Bootの脆弱性「Baton Drop」（CVE-2022-21894）を悪用できることを確認したという。この脆弱性は2022年1月に修正されていたが、攻撃者は古い署名済みの脆弱な起動ファイルを持ち込み、悪用していた。
カスペルスキーによると、追加の対策更新が提供された後、BlackLotusを使った攻撃は公には知られなくなった。BlackXは同じ脆弱性を使い、導入手順にも強い類似性がある一方、実装には相違点がある。
同社は、攻撃者がBlackLotusをリバースエンジニアリングしたか、犯罪者からソースコードを購入した可能性を挙げている。SecurityWeekは2023年7月、Baton Dropの悪用コードを除いたBlackLotusのコードがGitHubで公開されたと報じた。カスペルスキーは、APTの攻撃者が犯罪者向けツールの発想やコードを取り入れる例は珍しいと指摘している。
■Windowsより先に動くブートキット
UEFI（Unified Extensible Firmware Interface）は、OSが起動する前にハードウェアを初期化し、起動プログラムへ制御を渡すファームウェアの仕組みだ。UEFI Forumが仕様を策定しており、Secure Bootは署名と信頼データベースを使って、起動時に実行するコードを検証する。
UEFIブートキットは、この起動経路に入り込み、Windowsの通常の防御機能が動き始める前にコードを実行する。BlackXでは、システム側とEFIシステムパーティションにファイルを配置し、攻撃者の起動コードを読み込ませる手順が確認された。
EFIシステムパーティションは、通常、ハードディスクやSSD上に置かれる起動用の領域だ。この領域を残してWindowsのOS領域だけを再インストールすると、不正な起動ファイルが残る可能性がある。復旧では、OSに加えて起動領域や登録された鍵も確認対象になる。
APT41と関連付けられた別の事例には、カスペルスキーが2022年1月に公表した「MoonBounce」がある。こちらはマザーボード上のSPIフラッシュにコードを埋め込む方式で、同社によると、この種類のUEFIファームウェア内のインプラントとして公表された3例目だった。格納先がストレージの外にあるため、ディスクの交換や初期化を経ても残存する。
■管理者権限を得た後にBlackXを導入
カスペルスキーが観測した攻撃では、攻撃者は標的ネットワークへ侵入し、管理者権限を取得した後にBlackXを導入していた。BlackXは、侵入後のアクセスを維持する段階で使われていた。
端末に配置されたのは、インストーラー「inst.exe」と、RC4で暗号化された拡張子のないファイル「PVMDIJGKAX2」だ。導入に必要なファイルや文字列は暗号化ファイル側にまとめられ、復号鍵は実行時のコマンドライン引数として渡される。インストーラー単体の調査では構成要素を把握しにくい作りになっている。
導入処理はCVE-2022-21894を悪用し、攻撃者独自のマシン所有者キー（Machine Owner Key、MOK）を登録する。その鍵を使って攻撃者のEFIファイルを読み込めるようにし、起動経路へ入り込む。
起動時に実行されるペイロードは、不正なドライバをWindowsカーネルへ読み込ませる。カスペルスキーによると、このドライバには「温江区明宇网络技术服务工作室」という中国の事業体名義の証明書による署名があり、2026年10月の報告時点で、証明書は発行元によって失効処理されていた。
■セキュリティ製品への干渉とファイルのすり替え
カーネルドライバは、セキュリティ製品による監視を妨げる機能を持つ。プロセス、スレッド、レジストリに関する通知処理であるコールバックを無効化し、Windowsのイベント追跡機能「ETW」の情報取得にも干渉する。
カスペルスキーの解析では、一部の処理は同社製品またはAvast製品が導入されている場合に動く設計だった。同社が行った動的解析では、これらの処理によるカスペルスキー製品への妨害は失敗したという。
ドライバには、BlackXのファイルへのアクセスをすり替える機能もある。対象ファイルを開く要求を横取りし、代わりにWindowsの電卓「calc.exe」のファイルハンドルを返す。不正ファイルそのものを調べようとする処理を別のファイルへ誘導する仕組みだ。
■クラウドストレージを使う通信と追加ペイロード
カスペルスキーは、BlackXから展開される2種類のユーザーモードのペイロードを確認した。1つは、追加の.NETプログラムを読み込めるリモートアクセス型トロイの木馬（RAT）で、Google Drive、OneDrive、Yandex.Diskをそれぞれ通信に使う版が見つかった。
このRATはクラウド上のファイルを調べ、ファイル名の末尾に付いた識別子に応じて処理を切り替える。命令の受信、処理結果の送信、ファイルのアップロードやダウンロードなどを、クラウドストレージ経由で行う。
業務でも利用されるクラウドサービスを経由すると、接続先の名称だけでは攻撃通信を見分けにくくなる。通信先に加え、利用プロセスやファイルのやり取りを調べることが、活動を把握する手掛かりになる。
もう1つは、カスペルスキーが「OxiDLLRunner」と名付けた悪意あるDLLだ。コンパイラを使う難読化基盤「OLLVM」で解析を難しくしており、正規実行ファイルに不正なDLLを読み込ませるDLLサイドローディングを使う。正規の「jcef_helper.exe」を「googleupdate.exe」に改名したファイルが、その読み込み役を担う。
OxiDLLRunnerは同じフォルダーにある暗号化ファイルを復号し、Rustで実装されたペイロードを実行する。解析では、このペイロードが外部のC2（指令・制御）サーバーと通信し、追加のDLLを受け取って実行する設計が確認された。
■APT41との関連を示す3つの手掛かり
カスペルスキーは、識別子の一致、DLLの読み込み手法、難読化の特徴という3点から、攻撃をAPT41に関連付けた。判断の確度は中程度としている。
第1の手掛かりは、ESETが2026年6月16日に公表した「FishMonger」の調査との重なりだ。ESETはFishMongerをWinnti Groupの傘下に位置付け、中国の請負企業I-SOONによる運用が疑われるとしている。この調査では、デバッグ情報のパスに「xdd」を含むドライバ読み込み用プログラムと、UEFIブートキットが関与した可能性を示す限定的な兆候が報告された。
カスペルスキーはBlackXのペイロードでも「xdd」を複数回確認し、ESETが言及したUEFIコンポーネントに当たると推定した。さらに、正規実行ファイルと暗号化ファイルを組み合わせるDLLサイドローディングと、OLLVMの使用について、中国語圏の攻撃者の活動で見られる特徴と評価している。
MITRE ATT&CKによると、APT41は少なくとも2012年から活動しており、中国の国家支援を受けた諜報活動と金銭目的の活動を行うグループと評価されている。Winnti Groupなどの名称で報告される活動とは、一部に重なりがある。
米司法省は2020年9月、APT41関連の中国人ハッカー5人と、ゲーム業界への侵入を利用した事業に関与したマレーシア人実業家2人について、起訴内容を公表した。中国人被告らは米国内外の100を超える被害組織への侵入に関連して訴追され、当時、中国に逃亡中とされた。司法省は、情報窃取に加え、ランサムウェアや被害端末を使った暗号資産の不正採掘も挙げている。
■更新プログラムと証明書失効措置の両方を確認
カスペルスキーによると、BlackXの標的端末は関連更新を適用済みだった。攻撃で使われた古い署名済み起動ファイルを拒否するためには、更新の導入に加えて、Secure Bootの禁止署名データベース「DBX」への失効情報の登録が必要だった。
MicrosoftはBlackLotusに関連するSecure Boot回避への追加対策を、CVE-2023-24932とサポート文書「KB5025885」で案内している。2026年10月時点の手順には、2023年版証明書の導入、新しい署名を持つブートマネージャーの確認、古い「Windows Production PCA 2011」証明書のDBXへの登録などが含まれる。
証明書の失効措置には、レジストリ値を設定し、スケジュールタスク「Secure-Boot-Update」を実行する手順がある。MicrosoftはイベントID「1037」などによる適用確認方法も示している。古い証明書で署名された回復用メディアなどは起動できなくなるため、導入前の検証とメディアの更新も展開手順に含まれる。
Microsoftは2023年5月9日に初期展開、同年7月11日に手順を簡素化した第2段階を開始した。その後、2024年4月9日から評価段階、同年7月9日から展開段階へ進めた。2026年10月時点の公式資料では、自動的に証明書を失効させる強制適用段階の開始日は後日発表とされ、開始の少なくとも6カ月前に告知する方針が示されている。
「Microsoft Windows Production PCA 2011」証明書の有効期限は2026年10月19日だった。Microsoftの説明では、UEFI Secure Bootによる起動コードの検証は、信頼データベースと失効状態に基づく。古い起動ファイルを拒否する措置は、DBXへの明示的な登録によって行う。
カスペルスキーは、手動有効化の必要性が管理者に伝わりにくいと評価し、攻撃者がこの状況を見込んだ可能性を指摘した。同社は2025年のSharePoint攻撃「ToolShell」でも、初期の修正後に構成更新の手動実行が必要だった事例を挙げている。政府・外交・重要インフラなどの組織では、Microsoftの手順に沿った起動保護の適用確認とともに、起動領域やファームウェアも調査対象に含め、エンドポイントの警告を継続的に監視することが重要になる。
元記事: Chinese Hackers Breached Diplomatic Networks; Microsoft Baton Drop Enforcement Never Deployed