セッションハイジャックやCookie・アクセストークン漏えいが疑われるときに、利用者・情シス・開発者・SaaS管理者が確認するログ、セッション失効、端末隔離、証跡保全、エスカレーション条件と対応の優先順位を、実務チェックリストで解説します。
この記事の目次 9項目から選ぶ
冒頭要約
セッションハイジャックとは、ログイン後に発行されたCookieやトークンを第三者に使われ、本人のセッションとして操作される状態です。すでに認証済みの状態が悪用されるため、MFAを設定していても追加の確認が出ない場合があります。
疑いがあるときは、信頼できる端末から、IdPと対象SaaSのセッションを失効し、同時刻の監査ログと設定変更を保全することが優先です。パスワード変更だけでは、アプリが独自に発行したセッションや連携トークンまで必ず無効になるとは限りません。
この記事では、個人利用者、情シス、開発者、SaaS管理者が、状況確認、封じ込め、影響調査、記録、エスカレーションを安全に進める順番を整理します。Cookieやトークンの窃取方法、攻撃の再現手順は扱いません。
セッションCookie、Authorizationヘッダー、アクセストークンは、それ自体が認証情報です。解析サイト、チャット、チケット、スクリーンショットへ値を貼らず、サービス名、アカウント、発生時刻、セッションIDの末尾など、組織で許可された識別情報だけを記録してください。
セッションハイジャックとは：パスワード漏えいとの違い
セッションハイジャックでは、第三者がパスワードを知っているとは限りません。ブラウザのセッションCookie、Access Token、Refresh Tokenなど、ログイン後の状態を維持する情報が悪用されることがあります。
| 対象 | 役割 | 漏えいが疑われるときの主な確認 |
|---|---|---|
| パスワード | 新しいログインで本人確認に使う | 変更、使い回し、回復先、MFAを確認する |
| セッションCookie | ブラウザのログイン状態を維持する | 端末・セッション一覧とアプリ側の失効を確認する |
| Access Token | APIやアプリへ許可された操作を伝える | scope、audience、有効期限、発行先、失効可否を確認する |
| Refresh Token | 新しいAccess Tokenを取得する | 明示的な失効、連携アプリ、継続利用の痕跡を確認する |
Microsoftの公式文書でも、IdPが発行するトークンと、各アプリが独自に発行するセッショントークンは別に管理されると説明されています。したがって、SSOのセッション失効だけで「すべてのSaaSから追い出せた」と判断せず、対象アプリ側のセッションと連携権限も確認します。
読者別の影響：誰が何を確認するか
| 読者 | まず確認すること | 見落としやすい影響 |
|---|---|---|
| 個人利用者 | 公式画面の端末、セッション、最近のアクティビティ | メール転送、回復先、見覚えのない連携アプリ |
| 情シス・CSIRT | IdPとSaaSのサインイン・監査ログ | IdP失効後も残るアプリ独自セッション、他ユーザーへの波及 |
| 開発者 | GitHub、クラウド、CI/CDのセッションとトークン | リポジトリ操作、Secrets参照、デプロイ、クラウド権限の利用 |
| SaaS管理者 | 管理者ロール、OAuth同意、APIトークン、監査ログ | 外部共有、メール転送、永続化された連携権限 |
管理者、メール、IdP、GitHub、クラウド管理画面のセッションは、単一サービスだけでなく組織全体へ影響が広がる可能性があります。後続操作が見つかるまで待たず、封じ込めと証跡保全を並行します。
まず確認すること：10分チェックリスト
1. 何を根拠に疑ったかを記録する
- 身に覚えのない成功ログイン、MFA通知、端末追加、認証設定変更の時刻。
- EDRやブラウザ保護機能によるインフォスティーラー、Cookie、認証情報へのアクセス警告。
- 本人が操作していないメール送信、転送ルール、OAuth同意、ファイル共有、リポジトリ操作。
- 紛失端末、共有端末、不審なブラウザ拡張機能、偽のログイン画面を利用した可能性。
通知文だけで断定せず、身に覚えのないログイン通知の確認方法に沿って、公式画面の成功・失敗・ブロックを確認します。
2. 対象範囲を分ける
- 対象アカウントとテナント、権限、利用サービスを特定する。
- IdPのセッション、対象SaaSのセッション、OAuthアプリ、APIトークンを別項目にする。
- 同じブラウザプロファイル、端末、SSOを使う他サービスを洗い出す。
- 個人アカウントと会社アカウントが同じ端末で利用されていたか確認する。
3. 公式画面でセッションと端末を確認する
- 現在有効なWeb・モバイル・デスクトップアプリのセッション。
- 端末、ブラウザ、OS、最終利用時刻、利用アプリに心当たりがあるか。
- IdPのサインインが成功していないのに、SaaS側で操作が続いていないか。
- 不明なOAuthアプリ、アプリパスワード、Personal Access Token、SSH鍵がないか。
場所やIPアドレスは手掛かりですが、VPN、モバイル回線、企業プロキシで変わります。場所だけで本人・第三者を断定せず、時刻、端末、認証方法、操作内容を組み合わせます。
4. 後続操作を確認する
- MFA、パスキー、回復用メール、電話番号の追加・削除。
- メールの自動転送、受信トレイルール、委任、外部共有の変更。
- 管理者権限、グループ、条件付きアクセス、API権限の変更。
- データの大量閲覧・ダウンロード、共有、削除、エクスポート。
- GitHub、CI/CD、クラウドでの鍵・トークン・Secrets・デプロイ設定の変更。
調査対象を整理するときは、SaaS権限棚卸しチェックリストを使うと、セッション以外の残存アクセスを確認しやすくなります。
初動対応：やること、やらないこと、記録すること
やること
- 信頼できる端末へ切り替える。 端末侵害が疑われる場合、その端末から新しいパスワードやMFAを登録しない。
- 緊急性が高ければ新規サインインを止める。 組織アカウントは、承認済み手順に従って一時無効化やアクセス制限を検討する。
- IdPのセッションとRefresh Tokenを失効する。 管理画面の正式な「セッションを取り消す」「全端末からログアウト」機能を使う。
- 各SaaSの独自セッションを失効する。 IdP側の失効だけに依存せず、メール、GitHub、クラウド、業務SaaSも確認する。
- 認証情報と回復手段を回復する。 パスワード、MFA、パスキー、回復先、アプリパスワードを確認し、不明なものを無効化する。
- 連携権限を見直す。 OAuthアプリ、APIトークン、SSH鍵、Personal Access Tokenを確認し、必要なものだけを残す。
- 影響調査用のログを保全する。 サインイン、監査、メール、共有、開発基盤のログを、時刻範囲と取得者を付けて保存する。
- 端末側の原因を調査する。 EDR、OS、ブラウザ、拡張機能を確認し、必要に応じてネットワークから隔離してCSIRTへ引き渡す。
「失効」操作の効果はサービス、トークン種別、アプリの実装によって異なります。操作ボタンを押した時刻だけでなく、再認証が要求されたか、不審操作が止まったか、各SaaSのセッションが終了したかを確認し、完了時刻を記録します。
やってはいけないこと
- Cookieやトークンをオンラインデコーダー、検索、チャットへ貼り付けない。
- 被疑端末でパスワード変更、MFA再登録、管理画面操作を続けない。
- ブラウザのCookie削除だけで、第三者側のセッションも無効になったと考えない。
- パスワード変更やIdPの失効だけで、アプリ独自セッションも終了したと決めつけない。
- 不審なセッションを調査目的で再利用したり、別端末へコピーしたりしない。
- ログ、通知、端末を保全せずに初期化・削除し、調査可能性を失わない。
- 侵害中の可能性が高いアカウントを、証跡保全だけのため長時間有効にしない。
記録すること
対象アカウント・テナント:
アカウントの権限・担当業務:
最初に異常を確認した日時・通知:
本人の心当たり:
対象端末・ブラウザ・OS:
IdPのサインイン結果・認証方法:
対象SaaSのセッション・最終利用時刻:
不明なOAuthアプリ・トークン・鍵:
メール転送・共有・権限の変更:
確認した操作ログと対象期間:
実施したセッション・トークン失効:
失効操作時刻・効果確認時刻:
パスワード・MFA・回復先の変更:
端末の隔離・調査状況:
保全したログ・取得者・保存先:
エスカレーション先・判断時刻:
次回確認日時:ログの読み方に迷う場合は、セキュリティログを読む初心者向けの基本で「誰が、いつ、どこから、何へ、どの結果でアクセスしたか」を整理します。漏えい可能性の報告と調査範囲は、漏えい疑い初動テンプレートへ転記できます。
判断基準：危険度とエスカレーション条件
| 優先度 | 条件 | 推奨対応 |
|---|---|---|
| 緊急 | IdP、メール、管理者、経理、人事、GitHub、クラウドの不明なセッション | 新規アクセスを制限し、セッション失効、ログ保全、CSIRT・責任者への報告を並行する |
| 緊急 | MFA・回復先・管理者権限・メール転送・OAuth同意が変更された | アカウント侵害として扱い、残存アクセスと他ユーザーへの波及を確認する |
| 高 | 被疑端末で複数サービスを利用し、Cookie・トークンへのアクセス警告がある | 端末を隔離し、同じブラウザプロファイルとSSO配下のサービスを横断確認する |
| 高 | セッション失効後も操作が続く、または再認証されず利用できるSaaSがある | アプリ独自セッション、APIトークン、サービスアカウント、外部連携まで確認範囲を広げる |
| 中 | 不明なセッションはあるが、後続操作や設定変更を確認できない | セッションを失効し、対象期間のログを保全して監視を継続する |
| 低 | 本人の端末・時刻・操作と一致し、不明な設定変更もない | 判断根拠を記録し、不要な古いセッションを整理する |
優先度は、Cookieやトークンを盗まれた経路の推測ではなく、アカウントの権限、残るアクセス、設定変更、データ操作、他サービスへの波及で決めます。現時点で公開ログから判断できない場合は、「侵害なし」ではなく「未確認」と記録します。
よくある誤解
「MFAを突破された」ことと「MFAが無意味」は同じではない
Pass-the-Cookieでは、MFA完了後のセッションが再利用されることがあります。MFAを外すのではなく、フィッシング耐性の高い認証、端末保護、再認証、セッション監視、短い有効期間を組み合わせます。
「パスワードを変えれば全端末からログアウトする」とは限らない
Google Workspaceの公式手順では、管理対象アカウントのパスワード変更後にサインインCookieのリセットも案内されています。サービスごとの公式手順で、セッションとトークンの失効を別に確認します。
「自分のブラウザでCookieを消せば封じ込め完了」ではない
自分の端末からCookieを削除しても、別の端末や第三者が保持するセッションをサーバー側で無効化できるとは限りません。公式のセッション管理画面または管理者機能で失効します。
「ログイン履歴に異常がないから安全」とは限らない
すでに有効なセッションが使われると、新しいログインとして目立たない場合があります。IdPのサインインログだけでなく、SaaSの監査ログ、セッション一覧、メール・共有・権限の変更を確認します。
関連用語・関連ページ
- Session Hijackingとは: 認証後のセッションを第三者に利用される状態。
- Pass-the-Cookieとは: 取得されたセッションCookieを利用する考え方。
- Access Tokenとは: APIやアプリへの認可を表すトークン。
- Refresh Tokenとは: Access Tokenを再取得するための長期トークン。
- Token Revocationとは: 発行済みトークンを明示的に無効化する仕組み。
- 身に覚えのないログイン通知の確認方法: 不審通知と成功ログインを安全に切り分ける。
- 身に覚えのないMFA変更通知の初動対応: 認証方法や回復先が変わった場合の封じ込め。
- SaaS権限棚卸しチェックリスト: OAuth、管理者権限、休眠アカウントを確認する。
- 漏えい疑い初動テンプレート: 報告、影響確認、記録を実務フォーマットに落とす。
- SSOとMFAの違い: ログイン統合と本人確認強化の役割を整理する。
- インシデント対応トピック: 検知、封じ込め、証拠保全、報告、復旧の順で次の行動を選ぶ。
- セキュリティ用語クイズ: セッション、認証、トークンの理解を確認する。
公式情報・参考情報
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations - インシデント対応を検知、対応、復旧を含む継続的なリスク管理として扱うための公式指針。
- OWASP Session Management Cheat Sheet - サーバー側の失効、再認証、タイムアウト、セッション監視に関する実装・運用ガイド。
- Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID - IdPトークンとアプリ独自セッションの違い、緊急時のアクセス失効を説明する公式文書。
- Google Account Help: Secure a hacked or compromised Google Account - 不審なアクティビティ、端末、回復情報、アプリ、Gmail設定を確認する公式手順。
- Google Workspace Admin Help: Reset a user’s password - 管理対象アカウントのパスワードとサインインCookieをリセットする公式手順。
- GitHub Docs: Viewing and managing your sessions - Web・モバイルセッションを確認し、見覚えのないセッションを失効する公式手順。
この記事は2026年7月18日時点の公式情報を基に、製品に依存しない初動判断へ要約しています。管理画面の名称、失効範囲、反映時間は変更される場合があるため、実施時は各サービスの最新公式手順と組織の承認済み手順を確認してください。
