『パスキーを今すぐ更新しろ』という電話が、パスキーではなくセッションを盗む理由

検索意図に一文で答える

パスキーは WebAuthn の定義どおり、秘密鍵をこの端末か同期キーチェーンに置き、Relying Party（対象サイト）のオリジンへ結び付けます。偽のログインホストはその鍵を持ち出せません。「フィッシング耐性」が成り立つ範囲は、ここまでです。成り立たない範囲は、急かされてサインインを終え、セッショントークンが相手へ落ちること、あるいは正規の Microsoft ページで相手から渡されたコードを入力し、トークンが相手の制御するクライアントへ発行されることです。

この記事は、すでにパスキーを登録したのに「更新しろ」と電話やSMSで急かされる人、そして「パスキーはビッシングの免罪符ではない」を同僚へ説明する開発者と運用向けです。Microsoft の事故通報の代わりにはならず、「パスキーをオフにする手順」でもありません。持ち帰るべきなのは、話術が覆う層、セッションとデバイスコードがそれぞれ盗む層、パスワード変更では足りない理由、電話を切ったあとこの端末で照合できることです。

今回の公表が分けて見せた層

2026年9月9日、Microsoft Security Research が英語の通報を公開しました。追跡しているのは進行中のクラウド ID 侵害です。異常なサインインのあと、相手が追加した認証方法、大量の Microsoft Graph アクセス、SharePoint と OneDrive のダウンロード、REST API によるメール収集が続きます。通報は、この活動が2026年5月から観測されていると書いています。

始まりは、丁寧に作られたフィッシングメールではありません。個人の携帯電話へかかってくる電話か、届くSMSです。発信者は社内ヘルプデスクを名乗り、切迫感を作ります。パスキー、多要素認証、シングルサインオンを今すぐ更新しないと、アカウントが止まる、と。リンクは、同じ個人番号へ別のSMSで届くことが多いです。Microsoft ははっきり書いています。話術はパスキーの周りを回りますが、パスキーの登録は、しばしば本当の目的ではありません。口実の役割は、人を二つの技術経路へ連れ込むことです。中間者（AiTM）フィッシングか、デバイスコード承認です。

中間者経路が取るのは、資格情報とセッショントークンです。デバイスコード経路では、被害者は Microsoft 自身の認証ページへ短いコードを入力するよう説得されます。トークンは相手が制御するクライアントへ発行され、ブラウザの Cookie を改めて盗む必要はありません。どちらの経路も、その後のアクセスで MFA をもう一度踏ませずに済ませることがあります。リンクを Defender 未導入の個人スマホで開くと、端末側の痕跡はほぼ空になり得ます。調査では、電話やSMSの記憶が、「侵害がどこから始まったか」を説明する最初で、ときに唯一の証拠になります。

インフラも「見慣れた顔」になるよう組まれています。通報が挙げるテーマドメインは passkeyhelpdesk.com、setupmypasskey.com、add-passkey.com、secure-passkey.com、そして会社名をサブドメインへ埋め込んだ形、たとえば contoso.add-passkey.com です。同じ会社名は integratedsso.com のような SSO テーマ域の下にも置けます。ドメインは登録から数時間で使えることがあり、遮断の窓は短いです。一部の事例では、すでに陥った同僚アカウントから Teams で同じ「パスキーを更新しろ」が送られ、電話の外へ社内の信頼が重なります。

Microsoft は初期アクセスを、Storm-3121 や Storm-3032 を含む複数のクラスタへ関連付けています。Storm-3121 の後段は、しばしば ShinyHunters と Falcon の恐喝へつながります。Storm-3032 は BlackFile から分裂し、いまは Helix の名で動く一群だと書かれています。これは生態の説明であり、かかってきた「IT の電話」がすべて同一グループである証明ではありません。引き継ぎ説明に書いてよいのは、話術と二つの技術経路です。グループ名ではありません。

パスキーは偽サイトを止められる。渡したセッションは止められない

「フィッシング耐性」を「もう騙されない」と読むと、資格情報の層とセッションの層が一文へ溶接されます。パスキーは登録時にサイトのオリジンへ結び付きます。偽ドメインが Microsoft のサインインページに見えても、通常は login.microsoftonline.com 用に置いた秘密鍵を取れません。パスワード使い回しに対する、この優位は本物です。取り消す必要はありません。

調査の一本のタイムラインが、「優位がどこで止まるか」を書いています。T+0分、管理外の環境が OfficeHome へアクセスし、二次検証を求めるエラー 50074 を返します。T+1分、MFA が完了します（通報は中間者に加え、フィッシング耐性のない MFA だと書いています）。続いて 50140 が「サインインしたままにする」を中断します。同じ一分で認証は成功し、セッションが立ちます。その後およそ1時間、同じセッションがマイ アプリ、プロファイル、承認管理、セキュリティ情報を開き、Graph 経由で SharePoint と Outlook を列挙します。セッションがある以上、相手はパスキーにもう一度触る必要がありません。

したがって「パスキーを使っている」が支えられるのは、狭い結論だけです。偽ホストがこの秘密鍵を直接エクスポートするのは難しい、です。支えられないのは、偽ページでパスワードやSMSコードを急かされない、中間者が今回のサインインで発行されたトークンを取れない、セキュリティ情報に相手の認証器が増えない、です。後ろの数文には、別の証拠が要ります。開いたホスト名が公式のサインイン域か、サインイン後のセキュリティ情報に見知らぬ端末があるか、です。

デバイスコードが正規ドメインで成功する理由

中間者は、少なくともサインインに見えるページを立てなければなりません。デバイスコードはその層も外します。公式の流れは、もともとこうです。あるクライアントが短いコードを示し、ブラウザで Microsoft のデバイス ログインページを開き、そのコードを入力する。それは「あのクライアント」が自分の代理で資源へアクセスすることを承認する、という意味です。ページは本物です。証明書も本物です。アドレスバーは「Microsoft か」という検査を通ります。騙される点は、別の問いに移ります。このコードを誰が発行し、承認がどのアプリへ落ちるか。

通報の二本目の攻撃系列は、まさにこれです。パスキーの話術のあとデバイスコードへ進み、被害者は正規の認証ページで相手が渡したコードを入力し、トークンは相手が制御するクライアントへ発行されます。その後、相手はこのトークンを再生し、ディレクトリとファイルを列挙します。Cookie を改めて盗む必要もなく、MFA をもう一度踏む必要もありません。錠とドメインを見る訓練を受けた人ほど、その場で見破りにくいです。検査するよう教えられた層が、緑だからです。

したがって「アドレスバーは Microsoft」が支えられるのは、パスワードを add-passkey.com のような偽ホストへ打っていない、までです。支えられないのは、このコードが自分のノート PC のものだ、承認したあとトークンは自分のブラウザにだけ残る、です。電話、SMS、チャットで読み上げられたコードは、初期状態では「相手のクライアント」として扱ってください。「公式ページだから安全」としては扱えません。

パスワード変更が、登録済みの認証器を覆えない理由

侵入後、相手が最初にやることは、しばしばファイルをさらに漁ることではありません。自分の認証方法を、あなたの ID へ書き込むことです。通報が挙げるのは、新しい電話番号、認証アプリ、ソフトウェアワンタイムパスワードです。2026年9月4日の実監査例では、追加された記録のデバイス名は NO_DEVICE、デバイスタグは SoftwareTokenActivated、ハッシュ関数欄は hmacsha1 でした。これは「もう一つパスワードを設定した」ではありません。「次の第二要素は、相手が完了できる」です。

侵害が確認されたアカウントへの Microsoft の対処は、一連です。アクティブなセッションとリフレッシュトークンの失効、資格情報のリセット、相手が登録した認証方法の削除、相手が足したメール規則の除去、そしてフィッシング耐性のある方法での再登録です。パスワードだけ変え、セキュリティ情報を見ないのは、相手がすでに嵌めた鍵を残すことです。三本目の調査系列は、相手が数日後に以前登録した PhoneAppOTP で入り、Node.js の自動化で Graph を歩くことも示しています。パスワードは正しく、第二要素も「通った」。通ったのは、相手自身の要素です。

本機の 強度チェック が照合するのは、公開されている高頻度の弱いパスワード一覧です。対象パスワードはアップロードせず、全ウェブの Have I Been Pwned 照会でもありません。この文字列がよくある弱さかどうかは答えられます。セキュリティ情報に NO_DEVICE が増えたか、いまの電話が偽物かは答えられません。弱いパスワードとセッション乗っ取りは、同じ列のデータではありません。互いに代用しないでください。

電話を切ったあと、その場で照合できる層

スローガンは証拠になりません。照合するのは、自分が制御できることだけです。着信が既知の経路を使ったか、これから開くホスト名、セキュリティ情報に端末が増えていないか。着信のリンクを本番アカウントで開いて実験しないでください。

1. 電話を切ります。会社が書面で公開している IT チケット、社内ポータル、折り返し番号で連絡してください。いまかかってきた番号へ折り返さないでください。SMSのリンクも押さないでください。Microsoft は雇用主へ、向こうから来る認証要求を報告できる確認済み経路を従業員へ渡すよう勧めています。
2. すでにリンクを開いたなら、見るのはホスト名だけです。会社名がサブドメインにあり、接尾辞が add-passkey.com、setupmypasskey.com、secure-passkey.com なら、それは Microsoft のサインイン域ではありません。このページでパスワード、SMSコード、パスキー確認を入力しないでください。
3. 「公式サイトでコードを入力しろ」と言われたら、先に聞いてください。どのアプリ、どの端末がこのコードを発行したか。他人が読み上げたコードは、相手のクライアントです。公式のデバイスコードページは本物でも、承認先は相手のアプリであり得ます。
4. 信頼できる経路で会社アカウントへ入ったあと、セキュリティ情報 / マイ サインインを開き、認証方法を一行ずつ見てください。増えた電話番号、認証器、ソフトウェアトークン、とくにデバイス名が自分のスマホに見えないものは、管理者の手順でセッションを失効させ、削除してください。パスワード変更で止めないでください。
5. すでに身元を確認した同僚へ、短い一度きりの秘密を渡さなければならないとき、暗号文の経路へ切り替えてください。ワンタイムリンク を開き、捨ててよいカナリア、たとえば canary-fp-20260921-passkey-lure を書きます。開発者ツールの Network を開き、Preserve log をオンにします。生成したあと、このカナリアで検索してください。POST /secrets の本文にあるべきなのは暗号文、期限、閲覧回数です。原文も、ハッシュ以降の鍵も出てはいけません。リンクの形は s.html?id={id}#{key} です。RFC 9110 は、リクエスト対象 URI にフラグメントを含まないと定めています。

前の四項が閉じるのは、ID が乗っ取られる経路です。第五項が扱うのは、別のよくある誤操作です。「IT が求めたコード」や一時パスワードをスクショしてチャットへ入れることです。画像ホストとアルバムは画素を残し、OCR も残り得ます。前のノートが、そこを書いています。ワンタイムリンクがアップロードするのは暗号文だけです。鍵は # の後ろに残ります。二つの経路を混ぜないでください。先にチャットへ撮り、同じ画像へ完全なワンタイムリンク URL を貼り戻さないでください。

「パスキーがある」を読み過ぎる三つの場面

第一に、フィッシング耐性を、ソーシャルエンジニアリング耐性と読むことです。パスキーはオリジンへ結び付きます。対象は、偽のログインページが秘密鍵を直接持ち出そうとすることです。電話、SMS、社内チャットは、この層を回り、中間者かデバイスコードへ連れて行けます。Microsoft 自身の緩和一覧では、「フィッシング耐性のある MFA の強制」と並んで、音声とメールのフィッシング訓練、不要なデバイスコードフローの遮断があります。

第二に、「ページは公式だ」を「承認先は自分だ」と読むことです。デバイスコードのページは正規ホストであり得ます。錠アイコンは、トークンが誰へ発行されるかを教えません。判断の根拠は、コードの出所です。自分の端末が示したコードと、電話で読み上げられた数字は、同じ出来事ではありません。

第三に、パスワード変更を締めくくりと読むことです。パスワード、セッション、相手が登録した認証器、メール転送規則は、別のスイッチです。通報は、それらを一緒に扱えと言っています。本機で新しいパスワードを作れるのは、「まだパスワードを使うサービス」の層だけです。パスワード生成 を開けば足ります。開いてすぐ使え、長さは 6〜128 文字、初期値は 16 文字、8 文字未満では安全性が低いと示し、計算はこのブラウザで完了し、アップロードしません。セッションの失効の代わりにはなりません。自分で登録していない認証方法の削除の代わりにもなりません。

よくある質問

すでにパスキーを登録しています。この電話にはまだ騙されますか？

騙されます。しかも、多くの場合、パスキーがコピーされたからではありません。話術はパスキーを口実に使い、本当に欲しいのは中間者が取るセッションか、正規の Microsoft ドメイン上で相手のアプリに入力するデバイスコードです。パスキーはRelying Party（対象サイト）のオリジンに結び付きます。偽のログインページから秘密鍵を直接持ち出すことは止められます。相手のクライアントを自分から承認することは止められません。

アドレスバーが Microsoft 公式に見えるなら、デバイスコードを入れてよいですか？

デバイスコードのサインインページは、もともと公式ホストであってよいものです。危険は「偽サイトかどうか」ではありません。「このコードを誰が発行し、承認がどのアプリへ落ちるか」です。電話やSMSで読み上げられたコードが承認するのは、相手が制御するクライアントであり、自分のブラウザセッションではありません。

パスワードを変えたら、この電話の件は終わりですか？

足りません。Microsoft は、侵入後に相手が自分の電話番号、認証アプリ、ソフトウェアトークンを登録すると書いています。パスワードだけ変え、セッションを失効させず、見知らぬ認証方法を消さないと、相手は自分で登録した第二要素で再び入れます。セキュリティ情報ページに増えた端末は、公式の対処手順で外してください。

同僚がチャットでワンタイムパスワードを求めています。スクショして送れますか？

生きたワンタイムパスワードやデバイスコードを、チャットのアルバムへ入れないでください。短い文はこのタブで AES-256-GCM により暗号化し、ワンタイムリンク で送り、鍵は # の後ろに置きます。形は s.html?id={id}#{key} です。作成も閲覧も開いてすぐ使え、アカウントは不要です。相手の身元は、会社が既に公開している確認経路で確かめてください。いまかかってきた自称 IT の電話ではありません。32 KB を超える材料は ファイル暗号化 へ。単ファイルは 5 GB まで、出力は .lock / .enc です。

短い秘密を、開いてすぐ使える経路へ移す

計算の境界が書いてあるページで、「パスワードを返し、スクショしない」を練習するなら、FastPwd の ワンタイムリンク を開けば足ります。登録は不要です。上のカナリアを書き、閲覧回数は 1 のままリンクを作り、上の第五項どおり Network を照合してください。本文にあるべきなのは暗号文であり、原文やハッシュ以降の鍵ではありません。身元を確認した同僚へ短いパスワードを渡すときだけ、この経路を使ってください。先に撮らないでください。見知らぬ着信へデバイスコードを読み返さないでください。

チャット履歴やチケット本文に、電話番号や身分証番号がまだ重なっているなら、先に リンク洗浄 で規則マスクし、出すかどうかを決めてください。洗浄はこの端末で完了します。原文は業務データとしてアップロードせず、アクセス解析にも書きません。まだパスワードを使うサイトでは、パスワード生成でこの端末の一意なパスワードを作ってください。電話で急かされた同じ文字列を使い回さないでください。強度チェックが答えるのは「公開されている高頻度の弱いパスワードか」だけです。「いまの電話は偽物か」には答えません。

次に「今すぐパスキーを更新しろ」と電話が来たら、三つ覚えてください。第一に、話術の中のパスキーは、しばしば口実だけです。相手が欲しいのはセッションか、デバイスコード承認です。第二に、正規ホストは、他人のアプリへトークンを発行することを止めません。第三に、締めくくりはセキュリティ情報とセッション失効であり、パスワード変更だけではありません。引き継ぎ説明に書いてよいのは、この三文です。「パスキーを付けたので、着信は無視してよい」は書けません。

関連記事

パスワードを画像ホストへスクショしたあと、ログインハッシュは OCR の平文と画像IDを止めません。パスワードを画像ホストへスクショしたあと、OCRの平文と画像IDがハッシュより危険な理由。ワンタイムリンクが消すのはサーバー上の暗号文であり、相手が画面撮影していない証明にはなりません。ワンタイムリンクはサーバーが暗号文を消したことは証明できても、相手が画面撮影していないことは証明できない。URL のハッシュ以降が HTTP に入らない理由は、URLの#以降に鍵を置ける理由と、その保護が崩れる場面 です。