ヘルプデスクへのMFAリセット、パスワード再発行、端末登録依頼を受けたときの本人確認、ログ確認、セッション失効、エスカレーション条件を実務向けに整理する。
冒頭要約
ヘルプデスクへの「MFAをリセットしてほしい」「スマホを替えたので認証アプリを登録したい」「パスワードを再発行してほしい」という依頼は、利用者を助ける日常業務です。一方で、攻撃者が正規ユーザーになりすまして認証手段を差し替える入口にもなります。
Microsoft Security BlogやGoogle Cloud/Mandiantの公開情報では、Scattered Spider / UNC3944 / Octo Tempestに関連する攻撃で、ヘルプデスクへのなりすましやMFA要素の追加・変更が観測されています。ここで重要なのは、攻撃手順を覚えることではなく、本人確認と復旧操作を「高リスクな変更」として扱うことです。
まずやるべきことは、依頼者の主張を鵜呑みにせず、登録済み連絡先、既存の信頼済み端末、上長・システムオーナー承認、チケット履歴、IdPログを分けて確認することです。対応後も、セッション失効、MFA/パスキー登録、回復情報、OAuthアプリ、SaaS監査ログまで確認します。
この記事は、情シス、ヘルプデスク、SaaS管理者、開発組織の管理者向けに、MFAリセット・パスワード再発行・端末登録依頼を安全に扱う確認順序を整理します。具体的な攻撃再現、なりすまし文面、侵入手順は扱いません。
読者別の影響：誰が何を確認するか
アカウント復旧は、単なる問い合わせ対応ではありません。本人確認、認証器の登録、セッション、SaaS権限、ログ保全が同時に関係します。最初に担当者ごとの見る範囲を分けると、作業が混線しにくくなります。
| 読者・担当者 | まず見ること | 放置したときのリスク |
|---|---|---|
| ヘルプデスク | 依頼経路、本人確認、登録済み連絡先、既存チケット、上長承認 | 攻撃者にMFA要素や一時パスワードを渡す |
| 情シス・IdP管理者 | サインインログ、MFA登録履歴、セッション、条件付きアクセス、回復情報 | パスワード変更だけで攻撃者セッションや認証器が残る |
| SaaS管理者 | Microsoft 365、Google Workspace、Slack、GitHub、CRMなどの監査ログ | SSO後のSaaS操作、OAuth同意、外部共有を見落とす |
| 開発者・DevOps | GitHub、CI/CD、クラウド、APIトークン、管理者ロール | コード、シークレット、クラウド権限へ波及する |
| CSIRT・SOC | 類似依頼、複数ユーザー発生、ログ保全、インシデント判断 | 単発問い合わせとして処理し、組織的な攻撃を見逃す |
Microsoft Entraでは、認証管理者がユーザーの認証方法を追加・変更し、MFA再登録要求やセッション失効を実施できます。Google Workspaceでも、管理者はユーザーのパスワード、パスキー・セキュリティキー、バックアップコード、サインインCookie、連携アプリを管理できます。つまり、ヘルプデスクや管理者が扱う復旧操作は、攻撃者から見れば「正規の管理機能を使った突破口」になり得ます。
まず確認すること：依頼を受けた直後のチェックリスト
復旧依頼で最初に避けるべきなのは、「急いでいる」「役員案件」「現場が止まる」という言葉に押され、本人確認を省略することです。次の順番で確認します。
| 確認項目 | 見るポイント |
|---|---|
| 依頼経路 | 公式チケット、社内電話、登録済みメール、Slack/Teamsの正規ワークスペースか |
| 依頼内容 | パスワード再発行、MFA再登録、電話番号変更、セキュリティキー追加、端末登録のどれか |
| 対象アカウント | 一般ユーザーか、IdP/メール/クラウド/GitHub/経理・人事SaaSの高権限アカウントか |
| 本人確認 | 公開情報ではなく、社内で管理された情報や既存の信頼済み経路で確認できるか |
| 登録済み連絡先 | 依頼中に提示された電話番号・メールではなく、事前登録済みの連絡先へ折り返せるか |
| 既存端末 | 管理済み端末、会社支給端末、既存の信頼済み認証器で承認できるか |
| 上長・所有者承認 | 高権限・委託先・役員・外部ユーザーの場合、別経路の承認があるか |
| ログ | 直前の失敗ログイン、MFA通知、リセット要求、異常な場所・端末がないか |
| 変更後の制限 | 再登録後すぐ高リスク操作を許可するか、一定時間は制限するか |
| 記録 | 誰が、何を根拠に、いつ変更し、何を未確認として残したか |
Google Cloud/Mandiantは、パスワードリセットやMFA登録では公開されている個人情報に頼らず、既知の連絡先への折り返しや社内メールなどのアウトオブバンド確認を組み合わせることを推奨しています。NIST SP 800-63Bも、認証器の追加・失効・回復はライフサイクルイベントとして記録し、通知や失効を伴うべきものとして整理しています。
「この番号に折り返してください」「この個人メールへ送ってください」という依頼は、本人確認の材料にはなりません。事前登録済みの電話番号、社内ディレクトリ、管理済み端末、上長承認など、攻撃者がその場で指定できない経路で確認します。
初動対応：やること、やらないこと、記録すること
MFAリセット依頼では、早く復旧することと、安全に復旧することの両方が必要です。特に高権限アカウントでは、利便性を優先して一時パスワードや新しいMFA要素を渡す前に、影響範囲を決めます。
やること
- 依頼者の本人確認を、事前登録済み連絡先または既存の信頼済み端末で行う。
- 高権限アカウントでは、上長、システムオーナー、別管理者の二者承認を求める。
- 直前のサインインログ、MFA要求、失敗連続、地理情報、端末、User-Agentを確認する。
- 復旧後は、全セッション失効、MFA/パスキー登録、回復メール・電話番号、OAuthアプリ、アプリパスワードを確認する。
- 委託先・外部パートナーの場合は、契約、担当者、利用期限、外部ユーザー権限を確認する。
- 変更内容、承認者、本人確認の根拠、未確認事項をチケットに残す。
やらないこと
- 依頼者がその場で提示した電話番号や個人メールだけへ一時パスワードを送らない。
- 生年月日、従業員番号、部署名、公開プロフィールだけで本人確認しない。
- 「MFAを再登録したから完了」としない。既存セッションや連携アプリが残る場合があります。
- 高権限アカウントの復旧をヘルプデスク単独で完結させない。
- 検証のために不審リンクや不明なチャット招待を開かない。
記録すること
対象アカウント:
依頼日時:
依頼経路:
依頼内容:
本人確認に使った根拠:
承認者:
実施した変更:
セッション失効の有無:
MFA/パスキー登録確認:
回復情報の確認:
SaaS監査ログの確認範囲:
未確認事項:
次回レビュー日:この記録は、フィッシング報告テンプレート や 漏えい疑い初動テンプレート に接続できます。MFAリセットが正当な問い合わせだった場合でも、本人確認の根拠を残すことで、後から「なぜ許可したか」を説明できます。
判断基準：通常問い合わせか、セキュリティ初動か
すべてのアカウント復旧依頼を重大インシデントにする必要はありません。ただし、次の条件がある場合は、通常のヘルプデスク対応ではなくセキュリティ初動として扱います。
| 優先度 | 条件 | 推奨対応 |
|---|---|---|
| 高 | IdP、メール、クラウド、GitHub、経理・人事SaaSの管理者アカウント | 二者承認、ログ保全、セッション失効、再登録後の高リスク操作制限 |
| 高 | 依頼者が登録済み連絡先を避ける、個人番号・個人メールを指定する | 変更を保留し、別経路の本人確認と上長確認を実施 |
| 高 | 直前に不審なログイン失敗、MFA疲労、パスワードリセット通知がある | MFA疲労攻撃の初動対応 と同じくセッション・MFA・SaaS監査ログを確認 |
| 高 | 委託先・外部パートナー・退職予定者・休職者に関係する | 契約、所有者、外部ユーザー権限、期限を確認 |
| 中 | 複数ユーザーから同時に類似のMFAリセット依頼がある | フィッシング・ソーシャルエンジニアリング疑いとして横断確認 |
| 中 | 端末紛失・スマホ機種変更・パスキー再登録が絡む | 既存端末、MDM、回復情報、パスキー・セキュリティキーの履歴を確認 |
| 低 | 正規チケット、登録済み連絡先、上長確認、ログ整合性がそろう | 通常復旧として実施し、変更記録と次回レビューを残す |
Microsoft Learnでは、MFA再登録要求やセッション失効が管理者操作として整理されています。Google Workspace管理者向けドキュメントでも、パスキー・セキュリティキーの追加・削除、バックアップコード、サインインCookie失効、アプリ連携の削除が管理対象です。復旧操作は、ログインを戻すだけでなく、既存のアクセス状態をリセットする作業として扱います。
復旧後に確認すること：セッション、MFA、SaaS、回復情報
本人確認が正当で、復旧操作を実施したあとも、確認は終わりません。攻撃者がすでに認証済みセッション、アプリ同意、回復情報、外部共有を残している場合があるためです。
| 確認対象 | 見るポイント |
|---|---|
| セッション | refresh token、サインインCookie、モバイルアプリ、ブラウザセッションを失効したか |
| MFA/パスキー | 新規登録、削除、電話番号変更、同一電話番号の複数ユーザー登録がないか |
| 回復情報 | 回復メール、回復電話番号、バックアップコード、SSPR登録方法が正しいか |
| IdP設定 | 条件付きアクセス、信頼済み場所、MFA除外、認証方法ポリシーが変更されていないか |
| SaaS監査ログ | メール転送、共有リンク、OAuth同意、外部アプリ、管理者操作、ファイルダウンロード |
| 端末 | 管理済み端末、MDM登録、紛失端末、見覚えのないデバイス登録 |
| 開発基盤 | GitHub権限、CI/CDシークレット、クラウドロール、個人アクセストークン |
Microsoft Entraでは、セッション失効やMFA再登録要求を組み合わせて使う場面があります。Google Workspaceでは、サインインCookieのリセット、パスキーやセキュリティキーの削除、バックアップコードの再発行、アプリ連携の削除が確認対象になります。どのサービスでも、画面名は変わるため、ボタン名より「どの状態を無効化・確認したか」を記録します。
ヘルプデスク運用として整えること
このテーマは、利用者教育だけでは解決しません。攻撃者は、困っている利用者を助けたいというヘルプデスクの役割を利用します。手順を厳しくするだけでなく、担当者が迷わず断れる条件を明文化します。
1. 復旧操作をリスク別に分ける
同じ問い合わせでも、パスワード再発行、MFA要素追加、パスキー再登録、回復メール変更、管理者アカウント復旧では重さが違います。高リスク操作ほど、二者承認、既存端末確認、チケット必須、事後ログ確認を求めます。
2. 本人確認に使ってよい情報を決める
生年月日、社員番号、部署名、上長名、公開プロフィール、名刺情報は、攻撃者も知っている可能性があります。本人確認には、社内で管理された情報、既存の信頼済み端末、登録済み連絡先への折り返し、上長・システムオーナー承認を組み合わせます。
3. 断る条件を明文化する
「急ぎ」「役員案件」「現場が止まる」だけでは、確認省略の理由にしません。登録済み連絡先を使えない、上長承認が取れない、直前ログが不審、対象が高権限、といった条件では、変更を保留できるようにします。
4. 復旧後のログレビューを標準化する
対応チケットを閉じる前に、セッション失効、MFA/パスキー登録履歴、サインインログ、SaaS監査ログ、連携アプリを確認します。セキュリティログの読み方 と SaaS権限棚卸しチェックリスト を組み合わせると、確認対象を整理しやすくなります。
よくある誤解
「本人が電話してきたので本人確認は済んでいる」
電話の声、部署名、社員番号、急ぎの事情だけでは本人確認になりません。攻撃者は、公開情報や漏えい済み情報を使ってもっともらしい説明を作れます。本人確認は、依頼者がその場で指定できない既存経路で行います。
「MFAを再登録すれば安全に戻る」
MFA再登録は、正規ユーザーを戻す操作であると同時に、攻撃者の認証器を追加してしまう操作にもなります。登録後は、既存のセッション、古いMFA方法、回復情報、OAuthアプリ、アプリパスワードを確認します。
「高権限アカウントも一般ユーザーと同じ復旧でよい」
IdP管理者、メール管理者、クラウド管理者、GitHub Organization owner、経理・人事SaaS管理者は、1つの復旧操作で広い範囲に影響します。高権限アカウントでは、二者承認、再登録後の高リスク操作制限、ログ保全を標準にします。
「パスキーにすれば復旧リスクは消える」
パスキーやFIDO2はフィッシング耐性を高めますが、端末紛失や機種変更の復旧導線は残ります。パスキー導入の落とし穴 でも整理した通り、強い認証方式ほど、復旧フローを弱い裏口にしない設計が必要です。
関連用語・関連ページ
- ソーシャルエンジニアリング: 人の判断や手続きを悪用する攻撃を理解する入口。
- 多要素認証: MFAリセットで何が変わるのかを整理する基礎用語。
- MFA Fatigue: プッシュ通知の誤承認が絡む場合の理解に役立つ。
- パスキー と FIDO2: 復旧フローと合わせて考えるフィッシング耐性認証。
- IdP と SSO: 1つの復旧操作が複数SaaSへ波及する理由を理解する。
- 認証と認可の違い: 本人確認と権限判断を切り分ける比較記事。
- MFA疲労攻撃の初動対応: 通知承認やサインインログの見方。
- 心当たりのないパスワードリセットメールの確認方法: 利用者側のリセット通知対応。
- SaaS権限棚卸しチェックリスト: 復旧後のSaaS権限・OAuth・外部共有確認。
- フィッシング確認チェックリスト: メール・チャット起点の依頼を確認する。
- 認証と認可のミニCTF と ログイン失敗ログの読み取りミニCTF: 初心者が安全に判断練習できる演習。
まとめ：復旧操作は「助ける作業」ではなく「認証器の変更イベント」
ヘルプデスクのMFAリセットやパスワード再発行は、利用者を助ける重要な業務です。ただし、攻撃者も同じ窓口を狙います。依頼者の急ぎ具合ではなく、対象アカウント、本人確認の根拠、直前ログ、承認者、変更後の残存セッションで判断します。
最初に整えるべきことは、本人確認の材料、二者承認の条件、復旧後のログレビュー、記録テンプレートです。高権限アカウント、外部委託先、複数ユーザー同時発生、直前の不審ログがある場合は、通常問い合わせではなくセキュリティ初動として扱います。
次に進むなら、SaaS権限棚卸しチェックリスト で復旧後の権限を確認し、MFA疲労攻撃の初動対応 でサインインログとセッション失効の順番を整理してください。パスキーやFIDO2を導入している組織では、パスキー導入の落とし穴 と合わせて、復旧フローを先に訓練することが重要です。
公式情報・参考情報
- Microsoft Security Blog: Octo Tempest crosses boundaries to facilitate extortion, encryption, and destruction ヘルプデスクへのなりすまし、パスワードリセット、MFA要素追加が観測された事例と防御観点を確認できる。
- Google Cloud Blog: Defending Against UNC3944 パスワードリセットとMFA登録に対する本人確認強化、公開情報に依存しない確認、MFA登録ログ監視の推奨を確認できる。
- NIST SP 800-63B: Digital Identity Guidelines 認証器の登録、ライフサイクル、アカウント回復、通知、失効の考え方を確認できる。
- Microsoft Learn: Manage user authentication methods for Microsoft Entra multifactor authentication Microsoft Entraでの認証方法管理、MFA再登録要求、セッション失効、アプリパスワード削除の扱いを確認できる。
- Microsoft Learn: How it works: Microsoft Entra self-service password reset SSPRの前提、認証方法登録、通知、管理者ロールのリセット条件を確認できる。
- Google Workspace Admin Help: Manage a user’s security settings Google Workspaceでのパスワードリセット、パスキー・セキュリティキー管理、バックアップコード、サインインCookie失効、連携アプリ削除を確認できる。
