Datadogのサイバーセキュリティ研究者は、シングルサインオン認証にMicrosoft 365とOktaを使用している組織を標的とする、高度な中間者（AiTM）フィッシングキャンペーンを発見しました。
このキャンペーンは、正規のSSO認証フローを乗っ取り、フィッシング耐性を欠く多要素認証方式をバイパスするための高度な手法を活用しており、エンタープライズのセキュリティ基盤に重大な脅威をもたらしています。
この攻撃は、人気の人事・給与サービスプロバイダーであるADPからの年末報酬レビューを装ったフィッシングメールを悪用していました。
これらのメールには、lnk.ieなどのURL短縮サービスの背後に隠されたリンクが含まれており、被害者をCloudflareインフラ上にホストされた第1段階のフィッシングドメインへ誘導します。
これらのドメインは、employee-hr-portal.com、corporate-hr-portal.com、mybenefits-portal.comといった福利厚生をテーマにした誘導を用いており、いずれもNameSiloを通じて登録されています。
一部の亜種では、攻撃者はパスワード保護されたPDF添付ファイル内に悪意あるリンクを埋め込み、自動検知システムを回避するために、そのパスワードをメール本文内で提供しています。
このキャンペーンは、OktaフェデレーションされたMicrosoft 365環境を侵害することを目的とした、2段階の攻撃メカニズムを採用しています。
第1段階のフィッシングページは、正規のMicrosoft 365ログイン画面を装い、FederationRedirectUrlフィールドを監視する悪意あるJavaScriptを注入します。
正規のMicrosoftエンドポイントが、被害者がIDプロバイダーとしてOktaを使用していることを示すJSONデータを返すと、悪意あるスクリプトはこのレスポンスを傍受し、フェデレーションURLを書き換えて、被害者を第2段階のOktaフィッシングドメインへ動的にリダイレクトします。
これら第2段階のドメインは、sso.oktasecure.io、sso.okta-cloud.com、sso.okta-secure.ioなどの類似インフラを使用しています。
フィッシングページは、/?company=<target>.okta.com というURLパラメータ形式を用いて、すべてのトラフィックを正規のOktaテナントへプロキシし、組織固有のカスタマイズやブランディング要素を保持することで、信頼性を高めています。
この攻撃は、window.fetchメソッドをフックすることでクライアントサイドのURL書き換えを行い、正規のOktaドメインを体系的に悪意あるプロキシへ置き換えつつ、期待される認証フローの見た目を維持します。
AiTM攻撃キャンペーン
フィッシングインフラはinject.jsを展開しており、これはクライアントサイドの認証情報窃取ツールとして、idx、JSESSIONID、proximity_、DT、sidなどの重要なOktaセッションクッキーを監視します。
このキャンペーンは少なくとも2025年8月から活動しており、2025年12月にはコードの改良が確認されていることから、MicrosoftおよびOktaの認証フローに高度な知見を持つ洗練された脅威アクターによる継続的な開発が行われていることが示唆されます。
スクリプトは、入力フィールドのchangeおよびsubmitイベントを追跡するDOMイベントリスナーを通じてユーザー名を取得し、okta_captured_usernameクッキーに認証情報を保存します。
マルウェアは毎秒、新しいクッキーがないかを確認し、重要なセッショントークンがあれば、取得した認証情報、セッションクッキー、URL、タイムスタンプを含むJSONペイロードをPOSTリクエストで/log_cookieエンドポイントへ送信し、流出させます。
攻撃者は、解析回避を目的としたCloudflare Turnstileの利用や、campaign_id、セッション識別子、IPアドレス、有効期限タイムスタンプ、使用回数制限などのキャンペーントラッキング用メタデータを含むbase64エンコードされたJSONオブジェクトをURLパスに埋め込むなど、複数の回避技術を用いています。
これは、数百人の標的ユーザーと数十の組織に対するフィッシングの有効性を監視し、アクセスを制御できる集中管理型のキャンペーンインフラが存在することを示しています。
緩和策
Okta FastPassを利用している組織は、debugContext.debugDataのriskフィールドにおいて、理由が「FastPass declined phishing attempt」となっている、結果がFAILUREのuser.authentication.auth_via_mfaイベントを通じてフィッシング試行を特定できます。
このフィールドには、正規のOktaテナントではなく、sso.okta-secure.ioのようなドメインが示されるなど、リクエスト元情報の不一致が含まれます。
FastPassを利用していない組織は、特にdebugContext.debugData.logOnlySecurityDataがMEDIUMまたはHIGHの異常行動評価を示している場合に、Cloudflareインフラから発生するCHALLENGEまたはDENY結果のpolicy.evaluate_sign_onイベントを監視する必要があります。
セキュリティチームは、network.client.geoip.as.domainがcloudflare.comを示している状況で、debugContext.debugData.behaviorsが新しいデバイスやロケーションをPOSITIVEとしてフラグしているuser.authentication.verifyイベントも監視すべきです。
組織は、フィッシング耐性のあるMFA方式を導入するとともに、認証ログを継続的に監視して異常なパターンを検知し、進化し続けるこの種の中間者攻撃から防御しなければなりません。
翻訳元: https://gbhackers.com/aitm-attack-campaign/
