Teamsに届く「パスキーを更新してください」――“不正アクセスのわな”だった：Microsoftが確認、更新を装った手口とその対策

パスワードに代わる安全な認証手段として普及が進む「パスキー」。その設定を更新するよう求める案内が、企業へのサイバー攻撃の入り口になっていた。Microsoftが報告した。

[＠IT]

　パスキーは、パスワードを入力する代わりに、スマートフォンやPCなどに保存された暗号鍵を利用して本人を認証する仕組みだ。偽のログインサイトにパスワードを入力させる従来のフィッシング攻撃に強いという特徴がある。

　Microsoftは2026年9月9日（米国時間）、パスキーの認証設定の更新を口実にして、クラウドサービスへの不正アクセスにつなげる攻撃について、調査結果を公式ブログで公表した。

社内のIT部門を装うメッセージ――その手口とは

　Microsoftによると、こうした攻撃に関連する活動は2026年5月から確認されている。攻撃者は複数の企業アカウントに不正アクセスし、認証方法の追加やクラウド上のファイルへのアクセスなどを実行していたという。

　攻撃者はどのように従業員を信用させ、企業のクラウド環境への侵入につなげたのか。

　企業のITヘルプデスク担当者を名乗る人物からの電話やメッセージで攻撃は始まる。攻撃者は従業員の個人用携帯電話に連絡し、パスキーや多要素認証（MFA）、シングルサインオン（SSO）の設定を直ちに更新する必要があると説明する。対応しなければ業務に支障が出ると伝え、手続きを急がせる。

　その上で、Microsoftの正規のサインイン画面によく似たWebサイトへ誘導する。従業員の個人用携帯電話にSMSでリンクを送るケースもあった。

　攻撃者は事前に標的企業や従業員について調べていたとみられる。偽サイトのURLには標的企業の名称を組み込み、あたかもその企業専用の認証ページであるかのように見せ掛けていた。

　Microsoftが確認した一部のケースでは、既に乗っ取った従業員のアカウントを利用し、「Microsoft Teams」を通じて同様の案内を送っていた。社内の人物から届いた連絡に見せることで、受信者に信用させようとしていたという。

狙いはパスキーの更新ではなく、認証情報やアクセス権の奪取

　攻撃者の本当の目的は、パスキーを登録・更新させることではない。

　Microsoftが確認した攻撃では、主に2つの方法でアカウントへのアクセス権が奪われていた。

　一つは、攻撃者が用意した偽サイトを経由させる「AiTM（Adversary-in-the-Middle）フィッシング」だ。利用者と正規の認証サービスの間に攻撃者が入り込み、認証情報やログイン後のセッショントークンを取得する。

　もう一つは「デバイスコードフィッシング」と呼ばれる方法だ。利用者に正規のMicrosoft認証ページでコードを入力させ、攻撃者が操作するクライアントにアクセス権を与えさせる。

　Microsoftが調査した事例では、デバイスコードを使った認証の後、攻撃者が取得したトークンを再利用してアカウントにアクセスし、組織内の情報を調べる活動が確認された。

　いずれも、パスキーの暗号技術そのものを破った攻撃ではない。パスキーの設定変更というもっともらしい理由を示し、利用者を別の認証手続きへ誘導することで、不正アクセスを実現していた。

侵入後には攻撃者自身の認証方法を追加、クラウド上のファイルも収集

　アカウントへのアクセスに成功した攻撃者は、その状態を維持するため、被害者のアカウントに自分が管理する認証方法を追加していた。

　具体的には、新しい電話番号や認証アプリ、ワンタイムパスワード用のソフトウェアトークンなどを登録する。これにより、攻撃者は後から再び認証を試みる際にも、自分が管理する認証手段を利用できるようになる。

　さらに攻撃者は、Microsoft Graphを利用して組織内のユーザーやグループ、アクセス権限、利用可能なアプリケーションなどを調査していた。

　その後、「SharePoint Online」や「OneDrive for Business」に保存されたファイルへの大量アクセスやダウンロードが確認された。一部の侵入事例では、「Exchange Online」のメールデータにもアクセスしていた。

　データの収集は短時間で一気に実行されるとは限らない。Microsoftによると、数時間から数日間にわたって続くケースもあり、通常の業務に紛れ込むようなペースで実行されていた。

パスキーを導入していても、認証設定の変更には注意が必要

　Microsoftは今回の攻撃への対策として、フィッシング耐性のあるMFAの適用に加え、認証方法の新規登録や変更に対するアクセス制御を強化するよう推奨している。

　例えば、認証方法を登録する際には、管理対象の端末からのアクセスや、フィッシング耐性のある認証を要求する。また、業務上必要のないデバイスコード認証を制限することも挙げている。

　不正アクセスの兆候を調べる際には、普段と異なるログインだけでなく、その直後に認証方法が追加されていないか、Microsoft Graphを通じた大量の情報取得やクラウド上のファイルのダウンロードが発生していないかを、関連付けて確認することが重要だという。

　従業員に対しては、IT部門を名乗る相手から突然、認証設定の更新を求められた場合、案内されたリンクや電話番号をそのまま信用せず、社内で確認された連絡経路を通じて正当性を確かめるよう周知する必要がある。

　パスキーはフィッシングに強い認証手段だが、その導入や設定変更を装った連絡まで安全になるわけではない。今回の事例は、認証技術の強化とともに、認証設定を変更する際の運用や本人確認の手順を見直す必要性を示している。