Microsoft 365のパスキー登録を悪用する標的型攻撃、6業界で被害拡大――電話と偽の登録画面で攻撃者のパスキーを登録させる手口

Microsoft 365を利用する企業を標的に、ITサポートを装った電話（ヴィッシング）と巧妙なフィッシングサイトを組み合わせ、攻撃者自身のパスキーを被害者のアカウントに登録させるサイバー攻撃が急増している。この攻撃は、Microsoftがセキュリティ強化のために導入したパスキー登録の促し（ナッジ）に便乗したもので、すでに航空、医療、テクノロジーなど6つの業界で被害が確認されている。パスキー自体の暗号技術は破られていないが、導入・移行期における「登録プロセス」の隙を突く手口として、セキュリティ担当者は早急な対策を迫られている。

■ITサポートを装う電話と「Pink」によるデータ脅迫

企業の従業員に直接電話をかけ、社内のITサポート担当者を装って偽のMicrosoft Entraパスキー登録手順を案内する一方で、被害者のMicrosoft 365アカウントに攻撃者自身の資格情報を密かに登録する金銭目的の恐喝グループの活動が明らかになった。Okta Threat Intelligenceは2026年7月6日、このキャンペーンに関する詳細な技術分析を公開し、この脅威クラスターを「O-UNC-066」と特定した。また、Palo Alto NetworksのUnit 42は、このグループを「Pink」として追跡している。Pinkは、過去にScattered SpiderやShinyHunters、LAPSUS$などを輩出した緩やかな犯罪ネットワーク「The Com」に関連する新しい恐喝ブランドである。

この攻撃キャンペーンが始まった時期は偶然ではない。攻撃が開始された2026年4月は、MicrosoftがMicrosoft Entra ID内で管理者制御のパスキー登録を促す「ナッジ（nudge）」プロンプトの展開を開始した時期と一致する。このプロンプトは、一部の設定ではサインイン時にデフォルトで表示される。攻撃者は、Microsoft自身のセキュリティ向上への取り組みを、攻撃の口実（プリテキスト）へと悪用した。このキャンペーンは、特定のグループにとどまらない構造的な脆弱性を示している。パスワードレス移行の途上にあるすべての企業は、攻撃者がその移行プロセス自体を騙る隙が生じるというリスクに直面している。パスキーの技術自体が破られたわけではない。それを登録する「セレモニー（登録プロセス）」こそが、新たな攻撃対象領域（アタックサーフェス）となっている。

■標的となった業界と、電話による騙しの手口

Oktaの脅威分析によると、O-UNC-066（Pink）は2026年4月以降、飲食、テクノロジー、医療、自動車、建設、航空の6つの業界にわたる企業組織を標的にしている。主な目的はデータの窃取とそれによる恐喝である。同グループは2026年5月31日にデータリークサイトを公開し、被害企業から盗み出したデータのサンプルを掲載して公開圧力をかけ、侵害したアカウント自体を通じて72時間の支払期限を通告する手法をとっている。

電話を用いたソーシャルエンジニアリング（ヴィッシング）の手口は、シンプルでありながら効果的である。ITサポートを名乗る電話の主は、標的企業の名前を知っており、現在まさにその業界のIT部門が実際に導入を進めているMicrosoftのセキュリティ施策（パスキー登録）に言及する。これにより、被害者を信用させるのに十分な社会的正当性を得てしまう。この攻撃には、検知されるような不審なメール添付ファイルも、フィルターに引っかかる偽装送信元アドレスも、実行される悪意あるプログラムも存在しない。攻撃は電話から始まり、Microsoft自身のパスキーインフラを利用して持続的なアクセス権（パーシスタンス）を確立する。

■1秒間隔のポーリングを行うPHPパネル：一般的なフィッシングとの違い

このキャンペーンの中心にあるフィッシングキットは、EvilginxやTycoon 2FAといった多要素認証（MFA）バイパスキットで最も一般的な「Adversary-in-the-Middle（AitM：中間者）」プロキシではない。人間のオペレーターがリアルタイムで被害者を認証ステージへと誘導する、オペレーター制御型のPHPパネルである。防御側にとってこの違いを理解することは重要である。なぜなら、AitMインフラを対象とした従来の検知シグネチャが、この手口には通用しないからである。

攻撃の流れは次の通りである。被害者がフィッシングページでユーザー名を入力すると、キットはPOSTリクエストを介してオペレーターのバックエンドパネル（/backend.php）にそれを転送する。攻撃者はその資格情報を、被害者の組織の本物のMicrosoft Entra IDログインページですぐに使用する。攻撃者がMicrosoftから提示されるMFAチャレンジを確認する間、被害者の画面には処理中を示す待機画面が表示される。オペレーターは、提示されたMFAに合わせて被害者の画面を切り替える。SMSコード用の「/submit-otp」、TOTPコード用の「/submit-authenticator」、または番号一致を求めるプッシュ通知用の「/approve-authenticator」といったページを被害者にプッシュする。被害者がフィッシングページにMFAの応答を入力すると、オペレーターは数秒以内にそれを本物のMicrosoftログイン画面に入力する。

1秒間隔のハートビートポーリングメカニズムにより、フィッシングページはオペレーターのセッション状態と同期され、被害者には一連の遷移がシームレスに見える。また、標的企業ごとのロゴや背景画像といったブランディング要素は、サブドメインごとにバックエンドにあらかじめ用意されている。一方で、一般的なMicrosoftのスタイルはMicrosoftの実際のコンテンツ配信ネットワーク（CDN）から読み込まれるため、自動セキュリティスキャナーが検出するための指標が減少する仕組みになっている。

最後のステージは、極めて巧妙に設計されている。攻撃者は被害者の本物のMicrosoft 365アカウントへのアクセスに成功すると、セキュリティ情報ポータルに移動し、自分自身のFIDO2パスキーを登録する。これと同時に、被害者の画面には登録セレモニーを模した偽の「/passkey/register」ページを表示する。このページでは、暗号通貨ウォレットのバックアップ手法から借用した「BIP-39」シードフレーズを使用して「リカバリキーを保存する」よう促す。Oktaの分析が確認している通り、BIP-39フレーズはMicrosoft Entraのパスキー登録において本来は何の役割も持たない。その目的は、もっともらしい作業で被害者の気をそらし、その間に攻撃者が本物の登録を完了させることにある。アカウントにパスキーが追加されると、Microsoftから正規の通知メールが送信されるが、攻撃者は登録したパスキーに無害な名前（被害者に提示したシードフレーズに由来する言葉など）を付けることで、その通知を日常的なものに見せかける。被害者はセキュリティのアップグレードを完了したと信じて電話を切るが、この時点で攻撃者は、被害者のアカウントに紐づいた、フィッシング耐性のある永続的な資格情報を手に入れている。

■パスワードレス移行期が新たな攻撃の窓を生む理由

このキャンペーンは「パスキーの脆弱性を突いたもの」と表現されることが多いが、その捉え方は攻撃の本質を見誤っている。FIDO2の暗号技術自体は健全である。正規の所有者のデバイスに正しく登録されたパスキーは、従来のフィッシングに対して極めて高い耐性を持つ。ブラウザが資格情報を解放する前に、宛先ドメインを暗号技術的に検証するからである。

脆弱性は「登録セレモニー」に存在する。すなわち、「組織がパスキーの導入を決定してから、すべてのユーザーが正規のパスキーを登録し終えるまでの期間」である。この移行期間中、従業員は予期しない登録プロンプトが表示されることを想定している。IT部門は新しい要件をアナウンスし、Microsoft Entraは登録を促すナッジを送信する。攻撃者は、このロールアウト自体を装うことを学習したのである。管理デバイスによる条件付きアクセスの強制を伴うパスキー導入を完了した組織は、導入前よりも保護されている。しかし、ナッジが有効化され、一部のユーザーのみが登録を終え、大半の従業員が実際のデバイスで正規の登録画面がどのように見えるかを知らない「ロールアウトの途中」にある組織は、導入を開始する前よりも一時的に脆弱な状態に置かれることになる。

Mandiantの「M-Trends 2026」レポートでは、極めてインタラクティブな音声フィッシングが企業への侵入経路として2番目に多く、調査された侵害事例の11%を占めていることが報告されている。また、Google Cloudの「H1 2026 Threat Horizons」レポートでは、調査されたクラウドインシデントの17%に音声によるソーシャルエンジニアリングが関与していた。Pinkのキャンペーンは、これらのトレンドが交差する場所に位置している。それは、電話から始まり、クラウドでの持続的アクセスを確立する攻撃であり、資格情報の移行期において、従業員が「確認できない発信者からの登録指示に従うよう条件付けられている瞬間」を突くものである。

■Storm-2372とのツール共有と、コモディティ化するアイデンティティ脅威

ZeroBECが並行して実施した、フィッシング・アズ・ア・サービス（PaaS）プラットフォーム「DEBULL」に関する調査（2026年7月4日公開、同年6月下旬から7月上旬に観測されたデバイスコードキャンペーンを対象）では、Microsoftが2025年2月に「Storm-2372」として文書化した手口とのインフラの重複が特定された。Microsoftは当時、Storm-2372を中程度の確度でロシアの国益に合致するグループと評価しており、その標的はヨーロッパ、北米、アフリカ、中東の政府、NGO、防衛、電気通信、医療、エネルギー部門に及んでいた。

DEBULLプラットフォームは、Storm-2372スタイルのアイデンティティ攻撃手法（Microsoft Authentication Brokerフロー、デバイスコード認証、侵害後の環境としてのMicrosoft 365など）を再利用可能なツールとしてパッケージ化し、オペレーターがバックエンドインフラをゼロから構築することなく展開できるようにしているとみられる。ZeroBECの分析では、DEBULLのコードベースからトルコ語の開発者によるマーク（「Code'u otomatik kopyala（コードを自動コピー）」というコードコメントや、「SAYAÇ（カウンター）」と命名された変数）が特定された。ただし、これらはコードの系譜を示すものであり、オペレーターの国籍を断定するものではない。

ZeroBECの分析が指摘する実質的な意味合いは、Storm-2372スタイルのアイデンティティ攻撃手法が、再利用可能なブローカーインフラとしてパッケージ化されているという点である。今月はパスキー、来月は別のMicrosoftの機能といったように、バックエンドを再構築することなく、被害者を釣るための「餌」を入れ替えることができる。O-UNC-066（Pink）は、現在このプラットフォームを利用している1つのクラスターに過ぎない。同じツールを使用し、異なる口実を用いた模倣犯による攻撃が発生することは、ほぼ確実とみられる。

Oktaが観測したフィッシングインフラは、DDoS-Guard（AS57724、ロシア）およびIQWeb FZ-LLC（AS59692、米国）にホストされていた。登録されたパスキー関連のドメインには、「deploypasskey[.]com」（2026年4月21日登録）、「passkeydeploy[.]com」（2026年4月23日登録）、「passkeyadd[.]com」（2026年5月8日登録）、「setpasskey[.]com」（2026年5月23日登録）、「assignpasskey[.]com」（2026年6月14日登録）などがあり、これらは標的企業ごとのサブドメインを生成するために使用されていた。

■Microsoft 365管理者およびセキュリティチームが今すぐ取るべき対策

Microsoft 365およびMicrosoft Entra IDを運用している組織のセキュリティチームは、このキャンペーンが現在進行形のアクティブな脅威であると認識し、直ちに以下の対策を講じるべきである。Oktaの防御分析によると、このフィッシングキットはOktaのようなサードパーティのアイデンティティプロバイダー（IdP）へのフェデレーション（連携）を試みない。そのため、MicrosoftテナントがOktaを介してフェデレーションされている組織は、今回分析されたメカニズムによる直接的なリスクにはさらされていない。しかし、電話を介したソーシャルエンジニアリングの経路は、IdPの構成に関係なく攻撃者にとって有効であることに注意が必要である。

1. **2026年4月以降のパスキー登録に関するEntra IDログの監査**：キャンペーンが開始された2026年4月以降の、FIDO2パスキーの追加に関するMicrosoft Entraのサインインログおよび監査ログを確認する。アカウント所有者と直接確認が取れない登録については、攻撃者によって登録された可能性があるものとして扱う。不審な登録が見つかった場合の対処手順は以下の通りである。まず、認識されていないパスキーおよびすべての認識されていない認証システムを削除し、次にすべてのアクティブなセッションを取り消し、その後にパスワードをリセットする。この順序を逆にすると、パスワードをリセットした後も攻撃者が制御するパスキーが残ってしまう可能性がある。

2. **条件付きアクセスによるパスキー登録の管理デバイスへの制限**：この攻撃の核心的なメカニズムは、有効な認証セッションが確立された後、Microsoftのセキュリティ情報ポータルで認証システムをセルフサービスで追加できる仕様に依存している。条件付きアクセスポリシーを使用して、認証システムの追加をMDM（モバイルデバイス管理）に登録された管理デバイスのみに制限することで、攻撃者が制御するブラウザセッションからパスキーを追加することを構造的に不可能にできる。管理デバイスへの登録制限をすぐに適用できない組織は、一時的にセルフサービスでのパスキー登録を無効化し、IT部門の監視下での登録を義務付けることを検討すべきである。

3. **正規のパスキー登録プロセスについて従業員に周知する**：本物のFIDO2パスキー登録では、ユーザーのデバイスがハードウェアベースの安全なストレージ（AppleデバイスのSecure Enclave、AndroidのStrongBox、Windows HelloのTPMなど）を使用してキーペアを生成し、ブラウザはWebページ上のフォームではなく、OSネイティブのシステムダイアログを表示する。シードフレーズのリストを表示したり、リストから単語を確認させたり、Webフォーム上で「リカバリキー」を保存するよう求めたりすることはない。BIP-39フレーズを使用する、リカバリキーの保存を求める、あるいはデバイス側のプロンプトが一切表示されずに完了するような登録フローは、正規のMicrosoft Entraパスキー登録ではない。この違いを、パスキー導入時のコミュニケーションの一環として従業員に直接伝える必要がある。

4. **電話での要求に応じる前のIT確認プロトコルの確立**：このソーシャルエンジニアリングの主な侵入経路は、予期しない電話である。電話で受けたITの指示には常に従うという組織のルールは、攻撃者に悪用される隙となる。Oktaは、連絡してきた人物の身元を従業員が独自に検証する方法（例えば、一度電話を切り、相手から提供された番号ではなく、公開されている社内の内線番号にかけ直すなど）を確立し、周知することを強く推奨している。

5. **不要なデバイスコード認証の無効化**：ZeroBEC、DEBULL、Storm-2372の系譜で文書化されている、より広範なデバイスコードフィッシングの手口にさらされている組織は、特定のワークフローで明示的に必要とされない限り、Entraの条件付きアクセスでMicrosoftデバイスコード認証を制限または無効化し、予期しないデバイスコード認証イベントがないかEntraのログを監視する。

6. **登録後のデータ探索アクティビティの監視**：攻撃者がMicrosoft 365アカウントへのパスキー登録に成功した場合、次に調査すべきは「そのパスキーが削除されたか」だけでなく、「何にアクセスされたか」である。Pinkはアカウントへのアクセスを取得した後、迅速にSharePointやOneDriveからのデータ窃取へと移行する。パスキーの削除とパスワードのリセットという部分的な対処だけでは、攻撃者がすでに文書を収集し終えていることを見落とす可能性がある。組織は、不審なパスキー登録が行われた期間以降のSharePointおよびOneDriveのアクセスログを確認し、大量のダウンロード、機密リポジトリへの異常なアクセスパターン、あるいは見慣れないIPアドレスやユーザーエージェント文字列からのアクセスがないかを検証すべきである。

■パスキーは依然として正しい投資である

O-UNC-066（Pink）のキャンペーンは、パスキーが企業認証のアプローチとして誤っていることを示す証拠と捉えるべきではない。パスキーは、Microsoft 365アカウント侵害の大部分を占めるAitMプロキシキット、パスワードスプレー、資格情報の詰め込み（クレデンシャルスタッフィング）といった、資格情報窃取攻撃のカテゴリ全体を排除する。適切に登録されたハードウェアベースのパスキーは、現在利用可能な最も強力な認証システムの1つである。オリジンドメインへの暗号技術的な紐づけがあるからこそ、攻撃者はそれを破ろうとするのではなく、それが存在する前の「登録の窓」を攻撃しているのである。

このキャンペーンがもたらす具体的な教訓は、パスキーのセキュリティそのものではなく、登録プロセスのガバナンスに関するものである。新しい認証規格が導入されるたびに登録の瞬間が生まれ、その登録の瞬間は常にソーシャルエンジニアリングの標的になり得る。Microsoftのパスキーナッジ機能は、企業規模で導入を促進するための健全なメカニズムである。それを安全に運用できる企業とは、管理デバイスでの登録強制、正規の登録画面がどのようなものかについての明確な従業員への周知、そして電話口の攻撃者をITサポートと誤認させないためのヘルプデスク検証プロトコルを組み合わせている企業である。これらの対策は、パスキーのセキュリティ価値を損なうものではなく、パスキーを機能させるためのプロセスを保護するものなのである。

■注目ポイントQ&A

●パスキーはフィッシング耐性があるはずなのに、なぜ攻撃者に盗まれてしまうのですか？

パスキーの技術自体が盗まれているわけではありません。FIDO2の暗号技術は資格情報を特定のドメインとデバイスに紐づけるため、偽のWebサイトが正規のパスキー認証を受け取ることはできません。今回の「Pink」のキャンペーンは、パスキー認証を突破しようとするのではなく、その前段階を狙っています。攻撃者は電話と偽のログインページを使って被害者のパスワードとMFAコードを騙し取り、それを使って本物のMicrosoft 365アカウントにログインします。その後、Microsoftの正規のセキュリティ情報ポータルから、攻撃者自身のFIDO2パスキーを登録します。パスキーの暗号的な安全性が機能するのは「正しい所有者に登録された後」であり、登録プロセスそのものは条件付きアクセスポリシーやユーザー教育によって保護する必要があります。

●偽の登録画面を見分けるために、本物のMicrosoft Entraパスキー登録画面の特徴を教えてください。

正規のMicrosoft Entraパスキー登録では、Webページ内のフォームではなく、オペレーティングシステム（OS）やハードウェアセキュリティキーによる「ネイティブのデバイスダイアログ（システムレベルのプロンプト）」が表示されます。例えば、Windows Helloを使用しているWindowsデバイスでは、Windowsセキュリティのプロンプトが表示され、生体認証やPINの入力を求められます。モバイルデバイスではシステムシートが表示されます。このプロセスにおいて、Webフォーム上で単語のリストを書き留めさせたり、リストから単語を確認させたり、「リカバリキー」を保存させたりすることは絶対にありません（BIP-39シードフレーズは一切使用されません）。これらの手順が表示された場合はすぐに操作を中止し、電話を切り、社内で公開されている正規のITヘルプデスクの番号に連絡してください。

●自社で進めているパスキーの導入ロールアウトが、従業員を危険にさらしている可能性はありますか？

はい、特に「登録移行期間中」はリスクが高まります。パスキーの導入を発表し、ユーザーに登録を促すナッジを開始しているものの、管理デバイスのみに登録を制限する条件付きアクセスポリシーをまだ適用していない組織は、最も高いリスクにさらされています。従業員は登録の指示があることを予期している一方で、実際のデバイスで正規の登録画面がどのように見えるかをまだ理解しておらず、IT部門も未管理デバイスからのセルフサービス登録をブロックできていないためです。このリスクを軽減するには、「条件付きアクセスを使用して新規パスキー登録をMDM管理デバイスに制限すること」「IT部門が電話で直接登録を誘導することはないと従業員に周知すること」「2026年4月以降のパスキー登録ログを監査すること」の3つの対策が有効です。

●Microsoft 365アカウントに身に覚えのないパスキーが見つかった場合、どうすればよいですか？

まず「認識されていないパスキーとすべての認証システムを削除」し、次に「すべてのアクティブなセッションを取り消し」、最後に「パスワードをリセットする」という順番で対処してください。パスワードのリセットを最初に行うと、パスキーはパスワード変更の影響を受けない独立した認証要素であるため、攻撃者が制御するパスキーがアカウントに残ったままになる可能性があります。その後、不審なパスキーが登録された時期以降のSharePointおよびOneDriveのアクセスログを確認し、大量のファイルアクセスやダウンロード、不審な接続パターンがないかを調査してください。また、組織のセキュリティチームや、利用している場合はOkta、またはMicrosoftのセキュリティ報告窓口にインシデントを報告してください。

元記事: Vishing Campaign Hijacks Microsoft 365 Passkey Enrollment Across Six Industries