2026年9月9日、Microsoft Security Researchが「Passkey-themed social engineering leads to identity and cloud compromise」を公開しました。ITヘルプデスクを装い、「パスキー、MFA、SSOの設定を更新してください」と従業員に電話やSMSで持ちかけ、IDの乗っ取りからクラウド上のデータ収集までを進める攻撃の報告です。注目したいのは、最初の接点が従業員の個人スマートフォン上で起き、企業のEDRのログに痕跡が残らない場合がある点です。本記事では、Microsoftの公式ブログを一次情報として、攻撃の流れ、検知の視点、対策を整理します。
1. 報告の概要
- 発行元：Microsoft Security Research。公開日は2026年9月9日
- 観測時期：2026年5月から
- 内容：複数のアカウントにまたがる、クラウド上の侵入活動
- 流れ：不審なサインイン → 攻撃者による認証方法の追加 → Microsoft Graphの大量アクセス → SharePointとOneDriveのダウンロード → REST APIによるメールの収集
- Microsoftの評価：プロキシに関連するインフラを使った、侵害されたクラウドIDからの自動収集と整合する
2. 攻撃の8つの段階
| 段階 | 内容 |
|---|---|
| 1〜2 | 初期アクセス：ヘルプデスクを装った電話・SMSと、パスキーやSSOを口実にしたフィッシング |
| 3〜4 | IDの侵害：AiTM（中間者型フィッシング）やデバイスコード認証で、セッションやトークンを取得 |
| 5 | 永続化：攻撃者が管理するMFAの方式（電話番号、認証アプリ、ソフトウェアOTP）を登録 |
| 6 | 偵察：Microsoft Graphで、ユーザー、グループ、権限、リソース、アクセス可能なコンテンツを洗い出す |
| 7〜8 | データ収集と流出：SharePointとOneDriveの大量アクセス・ダウンロード、REST API経由のメール収集 |
3. 入口：パスキーは口実にすぎない
攻撃は、従業員の個人の電話番号への電話やメッセージから始まることが多いとされています。ITヘルプデスクを名乗る相手が、緊急性を強調し、パスキー、MFA、SSOの設定をすぐに更新しないと業務に支障が出ると説明します。従業員は、Microsoftのサインイン画面によく似たWebサイトに誘導されます。リンクは、個人のスマートフォンにSMSで直接届くこともあります。
Microsoftは、パスキーを使った誘い文句が多い一方で、パスキーの登録自体は攻撃者の本当の目的でないことが多いと指摘しています。パスキーの話は、AiTMやデバイスコード認証の流れに被害者を誘導するための、もっともらしい口実です。
- AiTMの場合：攻撃者が、認証情報とセッショントークンを奪う
- デバイスコードの場合：被害者が、知らないうちに、攻撃者の代わりにアクセスを承認してしまう
さらに、次のような特徴が報告されています。
- 事前の下調べ：SNSやビジネス向けプロフィールなどの公開情報から、従業員や組織の構造を調べているとみられる
- 標的の組織名を含むドメイン：一般的なドメインを取得し、標的の組織名をサブドメインに入れて、見慣れたURLに見せかける。同じ組織向けに複数のドメインを用意し、数時間で稼働させて入れ替える
- Teamsの悪用：一部では、すでに乗っ取ったアカウントから、同様の誘い文句をMicrosoft Teamsで送り、信頼を高める
4. IDを乗っ取る3つのパターン
Microsoftは、調査した事例から、次の3つのパターンを示しています。
- AiTM：管理されていない端末から、Microsoft OfficeHomeへ不審なサインインがあり、MFAも完了した。その後、My Sign-InsやMy Appsなどの画面にアクセスされ、SharePointとOneDriveの機密ファイルが、主にGraph APIで一覧された。セッションは約1時間続いた。フィッシングに強くないMFAが、AiTMで突破された事例と説明されている
- デバイスコード：パスキーの誘い文句のあと、被害者が、正規のMicrosoftの認証ページにコードを入力してしまう。承認により、攻撃者のクライアントにトークンが発行され、ブラウザのCookieを盗まなくても、許可されたリソースにアクセスできる。攻撃者はそのトークンを再利用し、MFAを回避して、偵察や次の段階に進んだ
- 認証情報の再利用：侵害された認証情報でサインインし、数日前に登録済みだった認証アプリ（PhoneAppOTP）でMFAを通過した。攻撃者が数日前に認証アプリを登録していたことを示唆する。この活動は、Node.jsとMicrosoft Graphで作られた自動化システムで、主に行われた
5. 永続化：攻撃者のMFAを登録
侵入後の最初の目的は、一時的な侵害を、継続的な足場に変えることです。攻撃者は、新しい電話番号、認証アプリ、ソフトウェアのワンタイムパスワード（OTP）のトークンなど、自分が管理するMFAの方式を登録します。これで、以後の認証の要求を、被害者の関与なしに満たせるようになります。
Microsoftによると、MFAの登録だけでは、認証情報とセッションの完全なリセットを乗り切れません。ただし、盗んだトークンや失効していないセッション、有効な認証情報と組み合わさると、長期的なアクセスを維持する手段になります。
6. 偵察：個々のGraph呼び出しは普通に見える
永続化のあと、攻撃者はMicrosoft Graphを使って、テナント内のユーザー、グループ、権限、リソースを洗い出します。Microsoftは、認証、偵察、流出の各段階で、別々のIPアドレスを使い分けていたと報告しています。個別のネットワーク指標だけでは全体像がつかめず、段階をまたいだ相関が必要になります。
Graphの偵察は、1回の呼び出しだけを見ると、不審に見えにくいのが特徴です。「/users」「/groups」「/sites」への要求は、企業の環境ではありふれています。しかし、同じIDやアプリ、トークンが、複数のリソースを系統的にたどり、権限や認証設定を確認し、その後にメール、ファイル、添付ファイルに触れると、偵察から流出への流れが浮かびます。
| 偵察の型 | 主な対象 | わかること |
|---|---|---|
| ディレクトリの列挙 | ユーザー、グループ、メンバー | ID、グループ、実効的な所属の地図 |
| 権限とMFAの調査 | ディレクトリのロール、認証方法 | 特権の割り当てと、登録済みの認証方法 |
| アプリと同意の調査 | アプリケーション、サービスプリンシパル、OAuthの許可 | 再利用できるアクセス経路と、価値の高いサービスID |
| SharePointとOneDriveの調査 | サイト、ドライブ、ファイル | 収集に使えるファイルの地図 |
| メールボックスの調査 | メッセージ、フォルダ、添付ファイル | 情報収集やBEC、添付ファイルの取得の準備 |
| コンテンツの収集 | ファイルやメッセージの中身の取得 | 偵察が収集に進んだ、最も強い指標 |
7. データ収集と流出
- SharePointとOneDriveで、FileAccessedとFileDownloadedのイベントが大量に発生
- 一部の侵入では、REST APIによるExchange Onlineのメールの取得にも及んだ
- 人間の操作というより、自動化された動きが目立ち、複数の事例で、python-httpxというユーザーエージェントが観測された。ただし、ユーザーエージェントだけで悪意があるとは判断できない
- 流出は、数時間から数日にわたり、1時間に1,000件未満のファイルやメールにとどまるなど、通常の利用に紛れる速度で続いた
8. EDRだけでは見えない（筆者の考察）
最初のフィッシングURLを、企業のEDRが入っていない個人のスマートフォンで開いた場合、その活動はエンドポイントのテレメトリに残らないことがあります。Microsoftは、多くの調査で、従業員の「電話やメッセージを受けた」という記憶が、侵害の始まりを説明する最初の、そして時には唯一の証拠になると述べています。
そのため、次の3種類のログを、つないで見ることが重要です。
| 見るもの | 確認する内容 |
|---|---|
| IDのログ | 不審なサインイン、デバイスコード認証のイベント、認証方法の追加や変更 |
| トークンのログ | トークンの発行と再利用、失効していないセッション |
| SaaSの操作ログ | Graphの大量アクセス、SharePointとOneDriveのダウンロード、メールの大量取得 |
加えて、従業員が「不審な電話を受けた」とすぐ報告できる窓口が、検知の手がかりとして効きます。
なお、パスキーそのものが危険だという話ではありません。Microsoft自身が、対策として、フィッシングに強いMFA（FIDO2やパスキー、Windows Hello for Business）の強制を挙げています。問題は、「パスキーの設定」という話題を口実にされることです。
9. Microsoftが示す対策
Microsoftは、次のように、調査、封じ込め、予防に分けて対策を示しています。
- 調査：不審なサインインのあるユーザーの新しい認証方法とデバイスを確認し、確認後に不正なものを削除する。Graphの大量・自動的なアクセス、SharePointとOneDriveのダウンロードの異常、ExchangeのREST APIの動きを、IDのイベントと突き合わせる
- 封じ込め：侵害が確認されたIDのセッションとリフレッシュトークンを失効させ、認証情報をリセットし、攻撃者が登録した認証方法とメールのルールを削除し、認証方法を安全に再登録させる
- 予防（認証）：条件付きアクセスで、フィッシングに強いMFAを強制する。デバイスコードと認証転送のフローは、明確な業務上の必要がない限りブロックする
- 予防（端末とセキュリティ情報の登録）：Exchange、SharePoint、特権のGraphアプリには、管理された準拠デバイスを要求する。認証方法の登録には、常に新しい対話的な認証、管理されたデバイスや指定した場所、フィッシングに強い認証強度を要求し、別のポリシーで、高いサインインリスクの登録をブロックする
- 予防（アプリと共有）：ユーザーによるアプリの同意を制限し、管理者の承認を必須にする。Mail.Read、Files.Read.All、Directory.Read.Allのような高い権限のサービスプリンシパルを定期的に確認する。管理されていない端末は、ダウンロードや同期のないWebのみのセッションに制限し、匿名の共有リンクを無効にする
- 予防（ログと手順）：Graphのアクティビティログとメールボックスの監査を有効にし、異常な列挙、認証方法の登録、ファイルやメールの大量アクセスにアラートを出す。ヘルプデスクが認証情報やMFAをリセットする前に、厳格な本人確認を行い、すべてのリセットで通知する
最後の項目は、ヘルプデスクを装う攻撃と、ヘルプデスク自身が攻撃される可能性の両方に効く対策です。
10. 攻撃者の帰属
Microsoft Threat Intelligenceは、今回の初期アクセスの手口を、複数の攻撃者が使っていると評価しています。Storm-3121は、ShinyHuntersとFalconによる恐喝につながる初期アクセスを担っています。Storm-3032は、BlackFileから分かれたグループで、Helixという名で恐喝を行っています。Microsoft Defenderは、これらの攻撃者と同じ系統の手口の検知に対応しています。
11. 読むときの注意点
- 内容はMicrosoft 365、Entra、Defenderの環境が前提です。ブログの検索クエリは、Defenderの高度なハンティングで使うもので、環境に合わせた調整が必要です
- ユーザーエージェントのpython-httpxや、IPアドレスとドメインの一致は、それだけで悪意の証拠にはなりません。Microsoftは、流れ全体の相関で判断するよう述べています
- サインインのログだけでは、ファイルや添付ファイルが実際に開かれたか、ダウンロードされたかは証明できません
- ドメインやIPアドレスはすぐに変わります。Microsoftは、個別の指標よりも、侵害、永続化、偵察、探索、流出という流れの繰り返しのほうが、調査の土台になると述べています
- 第8章は、Microsoftの記述を踏まえた筆者の整理です
まとめ
- ヘルプデスクを装い、パスキー、MFA、SSOの設定を口実にして、AiTMやデバイスコード認証に誘導する攻撃が、2026年5月から観測されている
- パスキーの登録は本当の目的でないことが多く、口実として使われる
- 侵害後は、攻撃者のMFAの登録、Graphでの偵察、SharePointとOneDriveの大量ダウンロード、メールの収集へ進む
- 個人のスマートフォンが起点の場合、EDRに痕跡が残らず、従業員の証言が唯一の証拠になることがある
- IDのログ、トークンのログ、SaaSの操作ログをつないで見て、フィッシングに強いMFA、条件付きアクセス、ヘルプデスクの本人確認で備える