Microsoft Entra IDのパスキー登録機能をソーシャルエンジニアリングの手段として悪用し、アカウント乗っ取りとその後のデータ恐喝を狙う、標的を絞ったビッシング(音声フィッシング)キャンペーンが確認されています。
攻撃者はまず「passkey」という単語を含むドメイン(例: assignpasskey[.]com、deploypasskey[.]com、passkeydeploy[.]com、passkeyadd[.]com、setpasskey[.]comなど)を登録し、標的ごとにサブドメインを作成することから攻撃を開始します。
Microsoft Entra IDのログインページを模倣します。ページはMicrosoftのCDNから一般的なMicrosoftのスタイリングを読み込む一方、被害者ごとのブランディング(ロゴや背景など)はあらかじめ用意され、フィッシングキットのバックエンドから配信されることで、本物らしさを高めています。
このキャンペーンのインフラは、DDoS-Guard(AS57724)とIQWeb FZ-LLC(AS59692)上でホストされていました。
攻撃者は音声通話を使い、食品・飲料、テクノロジー、医療、自動車、建設、航空といったエンタープライズ分野の標的に対し、新しいパスキーを登録する必要があると信じ込ませます。
被害者は、Microsoftのサインインおよびパスキー登録のシーケンスを再現したフィッシングサイトへと誘導されます。
このキットは受動的なAiTM(中間者攻撃型)プロキシではなく、攻撃者が約1秒間隔のハートビートで被害者のセッションをポーリングし、被害者のMFA設定(TOTP、SMS OTP、番号照合付きプッシュ通知)に合わせてページを出し分ける、オペレーター主導型のPHPパネルとなっています。
この手口は、2025年後半にOktaが指摘した、電話をかける実行犯とフィッシングキットが被害者の行動に合わせてスクリプトをリアルタイムで調整するという攻撃手法と一致しています。
Oktaの研究者らによると、このキャンペーンはO-UNC-066(Unit 42では「Pink」と呼称)として追跡されているクラスターに帰属するもので、実行犯によるライブの通話スクリプトとリアルタイムの制御パネルを組み合わせたオペレーター主導型フィッシングキットを使用し、Microsoft 365ユーザーを偽のパスキー登録フローへと誘導しています。
このキットを分析すると、段階的な流れになっていることが分かります。まず解析回避のチェックが行われ、ユーザー名を尋ねる識別ページ、次いで入力された認証情報をオペレーターのパネルへ転送するパスワード入力画面が続き、その後「処理中」の画面が表示され、その間に攻撃者が窃取した認証情報を使って本物のMicrosoftログインへの認証を済ませる時間が確保されます。
Microsoft Entra IDのパスキー登録
MFAが求められる場面では、このキットはSMS OTP用の「/submit-otp」、TOTP用の「/submit-authenticator」、プッシュ通知用の「/approve-authenticator」といった専用ページを表示し、取得したコードをそれぞれバックエンドへ送信します。これにより、オペレーターは正規のサインインで求められる認証チャレンジを完了させることができます。
攻撃者はアクセス権を得ると、被害者がフィッシングサイト上でいかにも本物らしい偽のパスキー登録儀式を完了している間に、被害者のMicrosoftアカウントに自分自身のパスキーを登録することができます。
注目すべき点として、このキットが提示する偽のパスキー体験には、BIP-39形式のシードフレーズを表示する「リカバリーキーを保存してください」という画面や、単語の位置を確認させる要素が含まれていますが、これらはMicrosoft Entra IDのパスキーの仕組みとは無関係です。
このいかにも巧妙な仕掛けによって被害者の注意をそらしている間に、攻撃者はMicrosoftに対して攻撃者が管理するパスキーを登録します。
新しいパスキーが追加されると、Microsoftは正規の通知メールを送信するため、攻撃者は(偽のシードフレーズで使われた単語を再利用することさえあり)無害に見える名前をパスキーに付けることで、被害者の疑念を和らげようとします。
Oktaの分析では、このキットがOktaのようなサードパーティのIDプロバイダーへのフェデレーションを行う様子は確認されておらず、同社のレポートでもMicrosoftアカウントが直接侵害されたことは確認されていません。しかし、データの窃取と恐喝を可能にするアカウント乗っ取りという攻撃者の本来の目的は達成されており、実行犯は2026年5月31日にデータリークサイトを公開しています。
防御側は、電話経由で届く「パスキー」に関する依頼をリスクの高いソーシャルエンジニアリングとして扱い、こうした依頼は必ず独立した別の手段で真偽を確認する必要があります。
管理者はリスクを軽減するため、危険なサインインパターンを制限する条件付きアクセスポリシーの有効化、管理対象デバイスポリシー下でのフィッシング耐性を持つハードウェアベースのパスキー登録の強制、可能な場合はセッション内でのパスキー登録の無効化、そして異常なパスキー登録や不審な命名パターンの監視といった対策を講じることができます。
組織はまた、認証情報の変更に関するロギングとアラートを維持するとともに、標的を絞ったユーザー教育を実施し、電話を起点とした登録詐欺への脆弱性を減らすべきです。
2019年のSOC向けに書かれたSLAをそのまま受け入れるのはもうやめませんか – 2026年版AI SLAベンダーチェックリストはこちら – 無料のAI SOC SLAガイドをダウンロード
翻訳元: https://gbhackers.com/microsoft-entra-passkey-enrollment/
