Microsoftは、パスキーの登録を誘い文句にして企業アカウントを侵害し、Microsoft 365サービスからデータを盗み出すソーシャルエンジニアリング攻撃が現在も続いていると警告している。
2026年5月以降に確認されているこの攻撃は、攻撃者がITヘルプデスクになりすまし、偽のMicrosoftサインインページやデバイスコード認証フローに従うよう従業員を誘導することから始まる。アクセスを得た後、攻撃者は自分たちが管理する認証方式を追加し、Microsoft Graphを使ってクラウドリソースを把握し、SharePoint、OneDrive、Exchangeからデータを収集する。このキャンペーンは、パスキーの技術自体を悪用するのではなく、ソーシャルエンジニアリングの誘い文句としてパスキーを悪用している。
パスキー・フィッシング攻撃の仕組み
このキャンペーンは、標的企業とその従業員について調査することから始まる場合が多い。次に攻撃者は企業のIT部門になりすまし、アクセスを失わないためにパスキー、多要素認証、またはシングルサインオンの設定を直ちに更新する必要があると警告する。
被害者には、Microsoftのサインイン画面に見せかけたページへのリンクがSMSで送られてくることがある。BleepingComputerは、攻撃者がこうした誘い文句を使い、実際にパスキーを登録させるのではなく、被害者をAiTMフィッシングやデバイスコード認証へ誘導していると報じた。
AiTMページは認証情報やセッショントークンを取得できる一方、デバイスコード・フィッシングでは、Microsoftの正規の認証ページを通じて、攻撃者が管理するクライアントを承認するようユーザーをだますことができる。
攻撃者は1つのアカウントをクラウドの地図に変える
アクセスを得た後、攻撃者は自分たちが管理する電話番号、認証アプリ、その他のMFA方式を登録することが多い。防御側が不正な認証方式を削除し、被害者のアクティブなセッションとトークンを失効させない限り、これによりパスワードをリセットした後もアクセスを維持される可能性がある。
Microsoftは、攻撃者が続いてMicrosoft Graphを使い、ユーザー、グループ、ディレクトリーロール、アプリケーション、認証方式、SharePointサイト、OneDriveファイル、メールボックスの内容を一覧化していると述べた。個々のGraphリクエストは企業環境では正常に見えることがあるため、単一のAPI呼び出しよりも一連の活動のほうが重要になる。
データ窃取も意図的にゆっくり行われる可能性がある。Microsoftは、侵入が数時間から数日間にわたるケースを確認した。BleepingComputerによると、Microsoftは一部のケースで、攻撃者が1時間あたり1,000件未満のファイルやメールにアクセスしていたことを確認しており、正規のクラウドトラフィックに紛れ込むことを助けていた。
このキャンペーンは恐喝エコシステムと結び付いている
The Hacker Newsは、Microsoftによると、初期アクセス活動にはStorm-3121やStorm-3032を含む複数の脅威アクターが関与していた。同社は、これらのグループが関与した侵害を、データ窃取と恐喝活動から成る、より広範なエコシステムと結び付けた。
防御側にとって、これは単一の侵害されたメールボックスを超える問題となる。1つの盗まれたIDが、SSOで接続されたクラウドファイル、メール、業務アプリケーション、その他のリソースへの侵入経路になり得る。
防御側が今すべきこと
Microsoftは、疑わしいイベントを1つ探すのではなく、侵入をIDからクラウドへ連なる一連の攻撃として捉えるよう推奨している。セキュリティチームは次の対応を取るべきだ。
- 通常とは異なるサインインと認証変更を確認する：新たに登録されたMFA方式、デバイス、アプリケーションの承認を確認する。ユーザー本人であることを確認した後、不正な方式を削除し、アクティブなセッションとトークンを失効させる。
- IDとクラウドの活動を関連付ける：Microsoft Graphによる偵察に続く、通常とは異なるSharePoint、OneDrive、Exchangeのメールボックス、またはファイルのダウンロード活動を探す。
- 認証を強化し、復旧の制御を強化する：フィッシング耐性のあるMFAとConditional Accessを適用し、管理対象外デバイスからのダウンロードを制限する。また、ヘルプデスクで認証情報やMFAをリセットする前に本人確認を行う。
このキャンペーンは、より強固な認証だけでは唯一の防御線になり得ない理由を示している。パスキーは認証情報のフィッシングを困難にできるが、セキュリティチームは登録、アカウント復旧、ヘルプデスクへの依頼、セッションの失効、そして乗っ取りの成功後に続くクラウド上の活動にも対策を講じる必要がある。
関連記事：BigBear 2.0が258組織でMicrosoft 365のMFAを回避した方法を、セッションCookieを盗んだ手口と、セキュリティチームが取るべき対応とともに解説する。