Microsoft 365を狙う「BigBear 2.0」、258組織でMFA回避を確認―FIDO2を妨害してセッション窃取

セキュリティ企業CloudSEKは2026年9月7日、Microsoft 365を標的とするフィッシング・アズ・ア・サービス（PhaaS）基盤「BigBear 2.0」の調査結果を公表した。攻撃基盤の管理パネルでは5,137件の認証関連記録が確認され、CloudSEKがBleepingComputerに示した説明では、461組織が標的データに含まれ、このうち258組織で少なくとも1件のMFA回避を伴う認証成功が確認された。

BigBear 2.0は、FIDO2やWebAuthnに対応するブラウザ機能をJavaScriptで妨害し、利用者をSMS、ワンタイムパスワード、プッシュ通知などの代替手段へ誘導していた。FIDO2の暗号技術を破るのではなく、フィッシング耐性のある方式が使われる前に、別の認証経路へ切り替えさせる手口である。

■Evilginx2を基盤とするAiTM型フィッシング

BigBear 2.0は、オープンソースの中間者型攻撃（AiTM）フレームワーク「Evilginx2」を基盤とするPhaaSである。被害者がフィッシングリンクを開くと、攻撃者のリバースプロキシが被害者とMicrosoftの正規認証基盤との間に入り、実際のログイン処理をリアルタイムで中継する。

静的な偽ログイン画面でIDとパスワードだけを集める従来型の手口とは異なり、AiTM型では正規サービスとの認証処理そのものが中継される。被害者がSMSコード、時間ベースのワンタイムパスワード（TOTP）、プッシュ通知などによるMFAを完了すると、Microsoftから発行される認証済みセッションのCookieをプロキシが取得できる。

攻撃者は取得したCookieを別のブラウザで再利用することで、パスワードやMFAを再入力せずに認証済みセッションへアクセスできる場合がある。BigBear 2.0の管理基盤には、Cookie取得後の再利用を自動化する仕組みも組み込まれていたという。

■FIDO2を妨害し、代替認証へ誘導

CloudSEKによると、BigBear 2.0には標準的なEvilginx2にはないカスタムJavaScriptが追加されていた。このコードは、WebAuthnで公開鍵認証情報を扱うブラウザAPIを妨害し、FIDO2セキュリティキーやパスキーを利用可能な認証手段として表示させないようにする。

FIDO2とWebAuthnでは、認証情報が正規サイトのドメインに結び付けられる。このため、通常のフィッシングサイトに認証応答を転用することは難しい。BigBear 2.0はこの仕組みを解読するのではなく、FIDO2による認証が始まる前にブラウザ側の選択肢を取り除いていた。

アカウントにSMS、TOTP、プッシュ通知などの代替認証方式が残されている場合、利用者は別の方法でサインインするよう促される可能性がある。AiTMプロキシは、その代替認証を正規のMicrosoftサービスへ中継し、認証後に発行されるセッションCookieを取得する。

CloudSEKはこのほか、「サインインの状態を維持する」に相当する設定を自動的に選択し、セッションの永続性を高める処理や、Microsoftのテレメトリー通信を妨害する処理も確認したとしている。

■2025年に実証されていた認証ダウングレード

FIDO2を利用できない状態にし、別の認証方式へ誘導する考え方は、BigBear 2.0で初めて示されたものではない。

Proofpointは2025年8月、Microsoft Entra IDでFIDO2に対応しないブラウザのユーザーエージェントをAiTMプロキシが偽装することで、利用者を別の認証方式へ誘導できることを実証した。Proofpointは当時、この手法が技術的に可能である一方、実際の攻撃者による使用は確認していないとしていた。

Proofpointの実証は、Microsoft Entra IDからFIDO2非対応の環境に見えるよう通信情報を変更する方式だった。これに対し、CloudSEKがBigBear 2.0で確認した処理は、WebAuthnが依存するブラウザ機能をJavaScriptで直接妨害する。実装方法は異なるが、FIDO2以外の認証方式へ利用者を誘導するという構造は共通している。

Proofpointの公表から約1年後に、同様の発想が複数の利用者に提供されるPhaaSで確認されたことになる。フィッシング耐性のある認証方式を導入するだけでなく、脆弱な代替経路を残さない運用が重要であることを示す事例だ。

■40カ国超から5,137件の記録

CloudSEKの研究チームは2026年6月、BigBear 2.0の管理パネルにアクセスし、攻撃基盤、被害記録、運用者の構成を調査した。

管理パネルでは、攻撃期間を通じて42台の仮想プライベートサーバー（VPS）が管理されていた。これらは主にThe Constant Companyが運営するVultr上でホスティングされ、既定の「offy」と呼ばれるphishletはMicrosoft 365の認証を標的としていた。phishletとは、フィッシング基盤が正規サイトの通信を中継し、認証情報やCookieを取得するための設定ファイルである。

調査では、40カ国超にわたる3,331件の固有IPアドレスと、5,137件の認証関連記録が確認された。記録には、474件のMFA回避を伴う認証完了、1,032件の平文パスワード、4,148件のセッションCookieが含まれていた。これらの項目には重複があり得るため、それぞれを独立した被害者数として合計することはできない。

管理パネルの幅広い標的データには461組織が含まれ、CloudSEKがBleepingComputerに示した説明では、このうち258組織で少なくとも1件のMFA回避を伴う認証成功が確認された。残る組織については、攻撃を阻止したのか、利用者が認証を完了しなかったのかなど、未確認にとどまった理由は明らかになっていない。

国別ではインドが658件で最多となり、フランスが463件、サウジアラビアが353件で続いた。ニュージーランドとドイツも記録の多い国に含まれた。

■ITサービス企業やMSPを狙う

CloudSEKの分析では、ITサービス企業とマネージドサービスプロバイダー（MSP）が主要な標的となっていた。MSPのアカウントが侵害された場合、アカウントに付与された権限や顧客との接続方法によっては、顧客環境への侵入や情報窃取へ発展する可能性がある。

管理パネルは複数の利用者が使える構成で、CloudSEKは、専用のTelegramボットを通じて盗んだ情報を受け取っていた少なくとも5人のアフィリエイト運用者を確認した。主要な運用者は「General Boss」の別名を使用していたという。

BigBear 2.0には、69カ国に対応する住宅用プロキシプールも組み込まれていた。被害者の所在国に近い住宅用IPアドレスを経由してMicrosoftへ接続することで、攻撃者のVPSから直接アクセスする場合より、国外アクセスやデータセンター経由の通信として検知されにくくする狙いがあった。

ただし、被害者と同じ国のIPアドレスを使用すれば、条件付きアクセスを常に回避できるわけではない。位置情報だけに依存した判定を弱める要因となる一方、認証強度、端末の管理状態、ユーザーやサインインのリスクなど、ほかの条件は引き続き評価される。

ipapi.isを利用した接続元の判定も行われ、データセンター、VPN、セキュリティ研究者とみられるIPアドレスからの接続を遮断していた。これは自動スキャンやサンドボックスによる解析を難しくするための措置とみられる。

CloudSEKによると、運用者は2026年7月下旬以降、確認されていた42台のVPSのうち26台を管理パネルから削除していた。報告書の公開時点では管理パネルが稼働していた一方、フィッシング用インフラは約3週間にわたって停止していた。

■盗まれたセッションCookieによる影響

Microsoft 365の認証済みセッションが乗っ取られると、侵害されたアカウントに与えられた権限の範囲で、Outlook、Teams、SharePoint、OneDriveなどにアクセスされる可能性がある。Microsoft Entra IDを通じてほかのサービスへシングルサインオンしている場合は、それらのアプリケーションも影響範囲に入り得る。

攻撃者は侵害したアカウントを利用して、電子メールやファイルの閲覧と持ち出し、連絡先の収集、本人になりすましたメッセージの送信などを行える。管理者権限や他テナントへの委任権限を持つアカウントでは、影響がさらに広がる可能性がある。

CloudSEKは、盗んだ認証情報やセッションが、初期アクセスを売買する犯罪者を通じて、ランサムウェア、データ恐喝、ビジネスメール詐欺などに悪用される可能性があると分析している。これは確認済みの二次被害ではなく、攻撃基盤の機能と犯罪市場の運用形態に基づく評価である。

■FIDO2そのものが破られたわけではない

BigBear 2.0が確認された後も、FIDO2とWebAuthnのドメイン結び付けの仕組みは、AiTM型フィッシングに対する重要な防御手段である。

今回の攻撃で問題となったのは、フィッシング耐性のある認証方式と、フィッシング可能な代替方式が同じアカウントで併用されていた場合である。FIDO2を利用できないように見せたときにSMS、TOTP、プッシュ通知へ切り替えられる構成では、その代替経路がAiTM攻撃の対象になる。

NIST SP 800-63B-4は、フィッシング耐性を、認証出力を正規の検証者に暗号学的に結び付ける仕組みとして定義している。SMSや音声通話によるコード、TOTPなどは、フィッシング耐性を持つ認証方式には分類されない。

Microsoft Entra IDの条件付きアクセスでは、「認証強度」を使って、リソースへのアクセス時に認める認証方法を指定できる。組み込みの「フィッシング耐性のあるMFA」には、FIDO2セキュリティキーやパスキーだけでなく、Windows Hello for Businessや多要素の証明書ベース認証も含まれる。

この認証強度を対象ユーザーやリソースに適用し、SMS、TOTP、プッシュ通知だけではアクセス要件を満たせないようにすれば、BigBear 2.0が利用した認証ダウングレードの経路を閉じることができる。FIDO2だけを唯一の方式にすることが必須なのではなく、アクセス先がフィッシング耐性のある認証を要求することが要点となる。

■影響を受けた可能性がある組織の対応

CloudSEKは法執行機関と複数の影響組織に通知し、責任ある開示の一環として、該当する認証情報も提供したとしている。

影響を受けた可能性がある組織は、Microsoft Entra IDのサインインログや監査ログを調べ、不審な認証成功、通常と異なる端末、未知の住宅用IPアドレス、想定外の認証方式の使用などを確認する必要がある。攻撃基盤が位置情報を偽装していたため、国名や地域だけで判定せず、端末、認証方式、ユーザー行動などを組み合わせて調査することが重要となる。

侵害が疑われるアカウントについては、パスワードを変更するだけでなく、アクティブなセッションと更新トークンを失効させ、再認証を要求する必要がある。Microsoftの資料によると、アクセスの失効を開始してから実際に無効化されるまで時間差が生じる場合があるため、トークンやセッションの性質を踏まえた対応が求められる。

グローバル管理者、条件付きアクセス管理者、セキュリティ管理者などの高権限アカウントは優先的に調査する。Microsoftも、権限を持つ管理者アカウントにフィッシング耐性のあるMFAを要求することを推奨している。

条件付きアクセスでは、認証強度に加えて、組織が管理する準拠済み端末を要求する方法も検討できる。認証済みセッションのCookieを取得されても、アクセス先が端末の管理状態を別途要求すれば、攻撃者の端末からの再利用を制限できる。

一方、フィッシング耐性のある認証を一括して強制すると、対応する認証手段を登録していない利用者や管理者がサインインできなくなる可能性がある。緊急アクセス用アカウントを含む復旧手段を準備し、対象を段階的に広げる必要がある。

BigBear 2.0の事例が示す最大の教訓は、FIDO2を登録済みの選択肢として用意するだけでは十分とは限らないことだ。重要なアカウントとリソースではフィッシング耐性のある認証強度を要求し、脆弱な認証方式へ切り替えてアクセスできないようにすることが、同種のAiTM攻撃への有効な対策となる。

元記事: BigBear 2.0 Hacked 258 Microsoft 365 Organizations by Disabling Hardware Security Keys