Microsoft、マルウェア署名サービス「Fox Tempest」を制圧、1000超の不正コード署名証明書を失効

「正規のコード署名がついているマルウェアって、どうやって検知すればいいの？」
「Microsoftが制圧したって聞いたけど、もう安全になったの？」

チップス

ボス、Microsoft Artifact Signingを悪用したマルウェア署名サービスって、それ自体が驚きでしゅ…

ボス

うむ、Microsoftが5月19日に公表したFox Tempestだ。1000を超える不正な短期コード署名証明書を発行し、複数のランサム集団へ提供していた。

本記事ではマルウェア署名サービス「Fox Tempest」の手口と、Microsoftによる制圧の意味、企業が取るべき防御策を解説します。
「正規署名なら信頼できる」という前提が崩れる事案として、防御方針の見直しが求められます。

続きを読めば、コード署名を信頼している既存の検知ロジックの落とし穴が見え、現場で取れる多層防御の方向性が分かります。

Fox TempestのMSaaSモデルとは

Fox Tempestは、サイバー犯罪市場で「マルウェア署名サービス」を商品として提供していた組織です。
正規のクラウドサービスを巧妙に悪用していた点が、この事案の特異性を示しています。

Microsoft Artifact Signingを悪用した短命証明書

Fox TempestはMicrosoft Artifact Signing機能を悪用し、短期間だけ有効な不正コード署名証明書を量産していました。
顧客となる別の犯罪者は、Fox Tempestが管理する仮想マシンに自分のマルウェアをアップロードすると、署名済みバイナリを受け取れる仕組みです。
後にホスティング基盤を米国のVPS事業者Cloudzyへ移しており、商用クラウドを次々と踏み台にする巧妙な運用も浮かび上がっています。

事案の主要数値はこちらです。

「正規署名なら安全」が通用しない時代

多くのEDR・アンチウイルスは、有効なコード署名のあるバイナリを優先度の低い検査対象として扱う傾向があります。
Fox Tempest経由のマルウェアは、まさにこの抜け道を狙ったもので、Defender SmartScreenなどの警告も回避しやすくなっていました。
Vanilla TempestやStorm-0501といったランサム集団が、初期侵入の段階でこの署名済みバイナリを利用していた点も注目すべきです。

チップス

「署名されているから大丈夫」って思っていまし​たけど、もう通用しないんでしゅね…

ボス

うむ、署名は「誰が出したか」を保証するに過ぎん。「内容が安全か」は別問題と理解せよ。

制圧後の現実と企業が取るべき防御

今回の制圧は大きな成果ですが、根本的な解決ではありません。
類似の手口は今後も出現する前提で、検知ロジックの考え方を更新しましょう。

証明書失効と検知ルールの追従

Microsoftは1000超の証明書を失効させ、関連するAzureテナントを停止しました。
各組織のEDR・WSUS・配布管理基盤では、失効リストの反映状況を確認するとともに、過去に検出した署名済みバイナリの再点検が必要です。
SIEMで証明書のサブジェクトCNやシリアル番号を保存している場合は、過去ログを横断検索して該当する痕跡がないか調べる価値があります。

当面取るべき行動を整理します。

振る舞い検知とゼロトラストへの軸足移動

署名済みバイナリを完全に信頼するスタンスは、Fox Tempestのような事案で破綻します。
EDRの設定で「署名済みは検査スキップ」のような最適化を入れている場合は、ポリシーを見直すべきです。
ゼロトラストの考え方に沿って、署名の有無ではなく実行時の振る舞い・通信先・権限要求を主軸に評価する設計へ寄せていくのが本筋です。

チップス

署名チェックを甘くしている設定、たぶん社内にも残っていそうでしゅ…

ボス

うむ、性能を取って甘くしている例は多い。Fox Tempestを機にポリシーを見直すべきだな。

まとめ：「署名済み＝安全」を捨てる転換点

Fox Tempestの制圧は朗報ですが、攻撃手法そのものが消えるわけではありません。
企業として取るべき行動を整理します。

チップス

サインがあるからって油断しないようにしなきゃでしゅ！

ボス

うむ、信用すべきは行動だ。形式ではない。

詳しい情報はMicrosoft Security Blog公式を参照してください。