CloudSEKは、40カ国超・461組織を標的とした攻撃活動から、盗まれたセッションCookie4,148件と平文パスワード1,032件を発見しました。
Microsoft 365ユーザーを狙うフィッシング・アズ・ア・サービス(PhaaS)の攻撃活動によって、数千件に及ぶセッションCookieが窃取されていたことが、CloudSEKの調査で明らかになりました。これらのCookieを悪用すれば、被害者が多要素認証(MFA)を完了させた後の認証済みセッションを乗っ取ることが可能だといいます。
このセキュリティ企業はレポートの中で、「BigBear 2.0」として知られるこの攻撃活動を6月に発見したと述べています。発見のきっかけは、攻撃者の管理パネルへのアクセスに成功したことでした。
このパネルには、40カ国超にまたがる461の標的組織に関連する認証情報レコード5,137件が格納されていました。CloudSEKはまた、窃取されたセッションCookie4,148件と平文パスワード1,032件も報告しています。同社によると、474件のレコードではログインが完了しており、攻撃者はMFA完了後に生成された認証済みセッションを捕捉していたとのことです。
BigBear 2.0は、Evilginx2というフレームワークを基盤に構築されています。このフレームワークは、被害者とMicrosoftの正規認証サービスとの間に、攻撃者が制御するリバースプロキシを挟み込む仕組みです。被害者はプロキシ経由のページでサインインし、通常どおりMFAを完了させます。Microsoftが認証済みセッションCookieを発行すると、このフィッシング基盤がそれを傍受し、攻撃者は認証プロセスを再度行うことなくそのセッションを再利用できるようになります。
この攻撃活動では、被害者の所在国に応じて選定された住宅用プロキシも使用されています。これにより、悪意ある認証トラフィックが地理的にユーザーと一致しているように見せかけることが可能です。CloudSEKは、この手法が条件付きアクセスポリシーで使われる位置情報ベースのチェックを弱体化させる恐れがあると指摘しています。
研究者らはさらに、フィッシングページ上でFIDO2/WebAuthn認証を無効化するよう設計されたカスタムコードも発見しました。これにより、ユーザーがフィッシングに対して脆弱な、より弱い認証方式へ誘導される可能性があります。
CloudSEKは、BigBear 2.0を複数ユーザー向けのサービスと説明しており、少なくとも5人の関係者(アフィリエイト運営者)を特定しています。同社によると、この攻撃活動を通じて42の仮想プライベートサーバー(VPS)ノードが確認されており、そのうち26は7月下旬以降にパネルから削除されているとのことです。
CloudSEKが特定した組織のうち151件をITサービス企業およびマネージドサービスプロバイダー(MSP)が占めており、同社のデータの中で最も多く標的とされたセクターとなっています。こうした組織は、従業員が顧客環境や管理システムへの特権アクセス権を保有している場合があるため、特に価値の高い標的となり得ます。
セッション窃取の主流化
Confidisの創業者兼CEOであるキース・プラブー(Keith Prabhu)氏は、BigBear 2.0の重要な点は、MFA完了後の認証済みセッションを捕捉できる能力そのものだけではないと述べています。かつては高度なスキルを持つ攻撃者に限られていた手法を、大規模に利用できるサービスとしてパッケージ化した点にこそ意義があるといいます。
HFS Researchのアソシエイト・プラクティス・リーダーであるアクシャト・ティアギ(Akshat Tyagi)氏は、根底にある技術自体は目新しいものではないと指摘します。「BigBear 2.0が変えたのは、利用のしやすさと規模です」とティアギ氏は述べています。「AiTM(Adversary-in-the-Middle)フィッシング、住宅用プロキシ、そして自動化されたCookieリプレイを一つのサービスにパッケージ化することで、こうした攻撃を実行するために必要な専門知識のハードルを下げているのです」
この変化により、企業は認証イベントそのものの保護にとどまらない対策を考える必要があると同氏は述べています。というのも、セッションが窃取されれば、攻撃者はパスワードや追加のMFA認証を経ることなくMicrosoft 365にアクセスできてしまうためです。
プラブー氏はさらに、MFAの認証成功をもって、アカウントやセッションが安全であることの証明とみなすべきではないと付け加えています。
IDC Asia Pacificでサイバーセキュリティのプロダクトおよびサービスをカバーするシニアリサーチマネージャーのサクシ・グローバー(Sakshi Grover)氏は、セッションCookieやアクセストークン・リフレッシュトークンは、パスワードの背後にある単なる技術的な副産物ではなく、価値の高い認証情報そのものとして扱うべきだと述べています。
同氏によれば、リスクとなっているのは、多くの企業の対策が依然として認証情報の窃取を検知することに主眼を置いており、すでに認証済みのセッションが乗っ取られるケースへの対応が手薄になっている点だといいます。
フィッシング耐性のある認証方式が重要に
ティアギ氏によれば、ワンタイムパスワード(OTP)、SMS、プッシュ通知型のMFAは、この種の攻撃に対する単独の防御策として頼るべきではありません。攻撃者は、正規ユーザーに認証を完了させたうえで、その結果生じたセッションを窃取できてしまうためです。
ティアギ氏は、企業は単に選択肢の一つとして提供するだけでなく、FIDO2/WebAuthnパスキーのようなフィッシング耐性を備えた認証方式の利用を義務化すべきだと述べています。プラブー氏は、追加の選択肢としてWindows Hello for Businessや証明書ベースの認証を挙げ、条件付きアクセスの認証強度の設定を通じて、より強固な方式を強制すべきだと指摘しています。
グローバー氏は、Microsoft 365が対応している範囲では、継続的アクセス評価(Continuous Access Evaluation)やトークン保護機能も活用すべきだと述べています。ただし、プラットフォームやクライアント、ワークロードによって対応状況にばらつきがあるため、トークン保護を万能な解決策として扱うべきではないと注意を促しています。
この問題は運用面にも及んでいるとグローバー氏は指摘します。IDおよびアクセス管理ツールが、セキュリティ運用部門やSIEM基盤と十分に連携していないケースが多く、攻撃の検知を担うアナリストにとって有用なIDシグナルが分断されたままになっているというのです。
パスワードリセットだけでは不十分
「この種の事案は、単なるパスワード窃取インシデントとしてではなく、アクティブなセッション侵害として扱うべきです」とプラブー氏は述べています。
同氏は、対応策として、影響を受けたアカウントの無効化または封じ込め、Entraのサインインセッションおよびリフレッシュトークンの失効、そして再認証の強制を推奨しています。その後、インシデント対応者はMicrosoft 365のログを調査し、メールボックスへのアクセス、不正な受信トレイルール、不審なOAuth同意、新規登録されたMFAデバイス、権限変更、他のクラウドアプリケーションへのアクセスといった痕跡がないか確認すべきだとしています。
ティアギ氏は、こうした調査においてIPアドレスの位置情報はあまりあてにならない可能性があると注意を促しています。住宅用プロキシを使えば、攻撃者の活動を正規ユーザーと地理的に一致しているように見せかけられるためです。対応担当者はそれよりも、侵害されたセッション中に何が行われたかを再構築することに注力すべきだと同氏は述べています。
プラブー氏はさらに、窃取されたセッションが他の従業員や顧客、社外の関係者にアクセスするために使われなかったかどうかも調査すべきだと付け加えています。
グローバー氏はまた、セッション乗っ取りをテーブルトップ演習に組み込み、認証済みセッションが侵害された際にID管理、セキュリティ運用、メッセージング、クラウドの各チームがどのように連携すべきかを検証すべきだと述べています。こうした演習によって、従来型の認証情報窃取やランサムウェアを想定したシミュレーションでは見えてこないギャップが浮き彫りになる可能性があるといいます。
