パスキーを口実にMFAを乗っ取る手口が拡大 — Microsoftが語るAiTMとデバイスコード悪用のクラウド侵害

Microsoftは2026年9月9日、パスキー（Passkey）や多要素認証（MFA）の更新を口実とするソーシャルエンジニアリングが起点となるクラウド侵害について、調査結果を公表した。攻撃者は組織のITヘルプデスクを装い、認証情報とセッショントークンを奪取した後、自らが管理するMFA手段を登録して永続化し、Microsoft Graphを使った偵察を経てSharePoint Online、OneDrive、メールボックスからデータを収集する。Microsoft Security Researchは、同様の手口が2026年5月以降、複数のテナントで観測されていると説明している。

日本企業でもMicrosoft 365やEntra ID（旧Azure AD）の利用は広く、パスキー移行を進める組織も増えている。攻撃者はその関心を悪用しているため、利用者への周知とクラウド側の検知強化が求められる。

攻撃の流れ — 電話からクラウドのデータ収集まで

Microsoftが示した典型的な連鎖は、なりすまし、社会工学による認証奪取、永続化、偵察、収集という5段階で構成される。ドメインやIPは頻繁に入れ替わるが、この順序は共通しており、防御側が調査する際の手がかりになると同社は述べている。

起点は「ITヘルプデスク」を名乗る電話やメッセージ

攻撃は、利用者の個人用電話番号への電話やSMSから始まることが多い。発信者はITヘルプデスクを装い、「パスキーの登録やMFA、シングルサインオン（SSO）の設定を今すぐ更新しないと業務に支障が出る」と緊急性を演出する。利用者は、組織名をサブドメインに含むフィッシングサイト（例: contoso[.]add-passkey[.]com）へ誘導される。

Microsoftによると、攻撃者は事前に公開情報から従業員や組織構造を調査しており、汎用ドメインに標的組織名を埋め込む手法で信憑性を高めている。ドメインはNicenigなどのレジストラで取得され、クラウドホスティング上で短期間に差し替えながら運用される。件数は少ないが、既に侵害したアカウントからMicrosoft Teamsで同文面を拡散する事例も確認され、内部からの連絡に見えるため開封率が高まると指摘している。

パスキーは口実 — 実際はAiTMとデバイスコードを悪用

Microsoftは、パスキー登録自体は攻撃の真の目的ではない場合が多いと分析している。パスキーは利用者を誘導するための口実で、実際の奪取は次のいずれかで行われる。

• ** adversary-in-the-middle（AiTM）フィッシング **: 利用者が入力した認証情報とセッショントークンを中継して奪取する手法。攻撃者は正規の認証画面を中継し、MFAを通過したセッションをそのまま利用する
• ** デバイスコードフロー悪用 **: 利用者に正規のMicrosoft認証ページでデバイスコードの入力を促し、攻撃者が管理するクライアントにトークンを発行させる手法。ブラウザのCookieを直接盗む必要なく、権限が付与されたリソースへアクセスできる
• ** 事前登録されたMFAの悪用 **: 攻撃者が数日前にPhoneAppOTPなどの認証手段を登録し、盗んだ認証情報と組み合わせてMFAを通過するパターン

いずれの場合も、** 不審なサインイン後に「My Sign-Ins」や「My Apps」といったID管理ポータルへのアクセス **が続き、ユーザーエージェントなどの痕跡からAiTMの可能性が示唆された事例もあるという。

奪取後の永続化 — 攻撃者がMFAを登録

初期アクセスに成功すると、攻撃者は** 新たな電話番号や認証アプリ、ソフトウェアOTPトークンをMFAとして登録 する。これにより、将来の認証要求を攻撃者が管理する要素で通過できるようにする。Microsoftは、この操作は 資格情報とセッションを完全にリセットしない限り持続する永続化手段 **になると説明している。

調査では、** 「Update user.」操作でStrongAuthenticationPhoneAppDetailやStrongAuthenticationUserDetailsが追加された記録 **が痕跡として残り、Kustoクエリ（KQL）で新規登録されたデバイスを検出できることを示している。

Microsoft Graphでの偵察とSharePoint・メールの収集

永続化の後は、** Microsoft Graph APIを悪用した偵察 が行われる。/usersや/groupsで組織のユーザーやグループを列挙し、/directoryRolesや/roleManagement、/authentication/methodsで権限や認証設定を調べ、/applicationsや/servicePrincipalsでアプリとサービスプリンシパルを把握する。SharePointやOneDriveでは/sites、/drives、/search、/deltaなどを用いて 機密ファイルの探索 **が行われる。

単一のAPI呼び出しは正規業務でも一般的だが、** 同一のIDやアプリが短時間に複数のカテゴリを横断してアクセス する点が特徴だとMicrosoftは指摘する。検知では、 30分以内に複数の偵察カテゴリへ触れたIDを抽出するKQL **などの相関が有効としている。

収集段階では、** SharePointとOneDriveのファイル、Exchange Onlineのメールや添付ファイル が対象となる。Exchangeでは REST APIを介したOne Outlook Web（アプリケーションID 20893など）経由のアクセス が観測された。Microsoftは、 収集が1時間あたり1,000ファイル／メール未満に抑えられ、数時間から数日にわたって持続する ため、通常業務に紛れやすいと述べる。自動化の痕跡として python-httpxのユーザーエージェント **が高頻度アクセスとともに確認されたが、単独で悪性と断定すべきではないと注意を促している。

Microsoftが示す調査と緩和のガイダンス

Microsoftは、本事案を** 単一のIPやドメインの一致だけで判断せず、ID、永続化、偵察、データアクセスを一連の流れとして調査する **ことを推奨している。同社が挙げる対応は次のとおりである。いずれも一次情報である同社ブログが推奨として明示している内容に限る。

** 調査で確認すべき事項 として、同社は 不審なサインイン直後の新規認証方法やデバイス登録の有無、Graphでの大量・自動的な列挙、SharePoint／OneDriveのダウンロード異常とExchange RESTのメール収集をIDや認証イベントと紐付けて確認すること、侵害が確認されたIDのセッションとリフレッシュトークンの失効、資格情報のリセット、攻撃者が登録した認証方法やメールボックスルールの削除 **を挙げている。

** 将来のリスク低減 **として、同社は次の対策を推奨している。

• ** フィッシング耐性のあるMFA（FIDO2／パスキー、Windows Hello for Business）を条件付きアクセスで強制する **
• ** Exchange、SharePoint、Graphの権限が高いアプリへのアクセスには、管理対象かつ準拠デバイスを要求する条件付きアクセスを適用する **
• ** セキュリティ情報の登録に対して、サインイン頻度を「毎回」に設定し、管理対象デバイスや信頼できる場所、フィッシング耐性MFAを要求する厳格なポリシーを別途設け、リスクが高いサインインはブロックする **
• ** デバイスコードフローと認証転送フローを、業務上の必要が明示された場合を除き条件付きアクセスでブロックする **
• ** ユーザーによるアプリの同意を制限し、管理者の承認を必須としたうえで、Mail.ReadやFiles.Read.Allなどの高権限Graph権限を持つサービスプリンシパルを定期的に棚卸しする **
• ** 管理対象外デバイスからのアクセスはダウンロードや同期を伴わないWeb限定セッションに制限し、SharePointとOneDriveの匿名共有リンクを無効化する **
• ** Microsoft Graphのアクティビティログとメールボックス監査を有効化し、列挙や認証方法登録、大量のファイル・メールアクセスに関するアラートを設定する **
• ** 音声やメールでMFAやパスキー登録を促すフィッシングについて利用者へ訓練し、不審な認証要求を報告できる正規の窓口を用意する **

同社はあわせて、** Microsoft Defender XDRの検知やAdvanced Huntingクエリ、MITRE ATT&CKへのマッピング（T1598.003、T1556.006、T1087.004など） **を公開しており、Graphの偵察や認証方法の永続化を検出するクエリを運用に組み込むことが有効としている。

日本企業が取るべき対応

日本でもMicrosoft 365への依存度は高く、パスキーやMFAの更新案内は日常的に届く。本件のように** 電話で直接指示されるケース は、メールフィルタをすり抜ける点で特に注意が必要だ。Microsoftが推奨するように、 不審なサインインの直後に新規MFAが登録されていないか、GraphやSharePointへの横断的なアクセスが急増していないか **をEntra IDやDefenderのログで確認することが、被害の早期発見につながる。

利用者側では、** 電話やTeamsで認証更新を求められてもリンクを即座に開かず、社内の正規の問い合わせ窓口で確認する 運用を徹底することが重要だ。管理者側では、 フィッシング耐性MFAへの移行と、デバイスコードフローのブロックを含む条件付きアクセスの見直し **を優先的に検討することが望ましい。

出典:

• https://www.microsoft.com/en-us/security/blog/2026/09/09/passkey-themed-social-engineering-leads-identity-cloud-compromise/