セッションハイジャックが疑われるときの初動対応｜パスワード変更で止まらない理由とCookie・トークン失効の順番

この記事の結論：パスワード変更の前に、信頼できる端末からセッションを失効する

セッションハイジャックとは、ログイン後に発行されたCookieやトークンを第三者に使われ、本人のセッションとして操作される状態です。すでに認証済みの状態が悪用されるため、MFAを設定していても追加の確認が出ない場合があります。

疑いがあるときは、信頼できる端末から、IdPと対象SaaSのセッションを失効し、同時刻の監査ログと設定変更を保全することが優先です。パスワード変更だけでは、アプリが独自に発行したセッションや連携トークンまで必ず無効になるとは限りません。失効の完了は、ボタンを押した時刻ではなく、不審な操作が止まったことを確認した時刻で判断します。

Cookieやトークンの窃取方法、攻撃の再現手順は扱いません。

どんな人・状況に向くか

• 身に覚えのない操作やセッションが画面に表示され、パスワード漏えいとは別の原因を疑っている利用者。
• EDRのインフォスティーラー警告や、MFA後の不審な操作の報告を受けた情シス、CSIRT、SaaS管理者。
• GitHub、CI/CD、クラウドのセッションやトークンを扱う開発者。

原因がパスワードの漏えい、使い回し、フィッシング画面への入力なら、先にパスワード漏洩が疑われるときの初動対応で変更するアカウントの優先順位を整理します。通知を受けただけでログインの成否が分からない段階なら、身に覚えのないログイン通知の確認方法から始めてください。

判断の基準：3つの条件で対応の深さを決める

次の条件はCyberLensの運用例です。1つでも当てはまれば、後続操作の証拠を待たずに失効へ進みます。組織の承認済み手順があれば、そちらを優先してください。

条件	判断の基準	当てはまる場合
権限が高いか	管理者、IdP、メール、経理、人事、GitHub owner、クラウド管理者	緊急。失効と保全を並行し、責任者へ報告する
継続しているか	失効後も操作が続く、再認証されないSaaSがある	緊急。独自セッション、APIトークン、連携まで広げる
端末が原因か	Cookieや認証情報へのアクセス警告がある	高。端末を隔離し、同じプロファイルのサービスを横断確認する

セッションハイジャックとは：パスワード漏えいとの違い

セッションハイジャックでは、第三者がパスワードを知っているとは限りません。ブラウザのセッションCookie、Access Token、Refresh Tokenなど、ログイン後の状態を維持する情報が悪用されることがあります。MITRE ATT&CKでも、Webセッション Cookieの窃取（T1539）は、資格情報なしで認証済みとしてアクセスされる問題として整理されています。

対象	役割	漏えいが疑われるときの主な確認
パスワード	新しいログインで本人確認に使う	変更、使い回し、回復先、MFAを確認する
セッションCookie	ブラウザのログイン状態を維持する	端末・セッション一覧とアプリ側の失効を確認する
Access Token	APIやアプリへ許可された操作を伝える	scope、audience、有効期限、発行先、失効可否を確認する
Refresh Token	新しいAccess Tokenを取得する	明示的な失効、連携アプリ、継続利用の痕跡を確認する

パスワード変更で止まらないのはなぜ？製品別の失効範囲

「全部ログアウトしたつもり」が起きるのは、製品ごとに失効の対象が違うためです。次の表は2026年11月2日に公式文書を開いて確認した内容です。

Microsoftの緊急時のアクセス失効の手順では、アカウント無効化、セッションの取り消し、端末の無効化の順が示されています。また、アプリが独自に発行したセッショントークンはEntra側から直接失効できません。したがって、SSOのセッション失効だけで「すべてのSaaSから追い出せた」と判断せず、対象アプリ側のセッションと連携権限も確認します。

GoogleではサインインCookieのリセットの説明に、Gmailなどのアプリからはサインアウトされないことが明記されています。GitHubのセッション管理の手順は設定画面のセッション一覧を対象にしており、GitHub Mobileのセッションを失効すると、その端末は第二要素としても使えなくなります。

失効はいつ効く？1時間・15分・28時間の読み方

失効の反映時間は1つの数字では決まりません。Microsoftの継続的アクセス評価（CAE）の説明から、判断に使う数字を整理します。

状況	数字	読み方
CAE非対応の組み合わせ	既定1時間	発行済みのアクセストークンは期限まで使われる場合がある
CAE対応アプリの重要イベント	準リアルタイム、最大15分	対象はアカウント無効化、パスワード変更、管理者による失効など
CAE対応のセッション	最大28時間	トークンは長くなるが、重要イベントで失効される前提
ゲストユーザー	対象外	CAEの失効イベントはゲストに即時適用されない

対応範囲にも注意が必要です。CAEの初期実装はExchange、Teams、SharePoint Onlineが中心で、Office Web版のように対応しない組み合わせもあります。複数人で共同編集している文書では、文書やアプリを閉じるまでアクセスが残る場合があります。

読者別の影響：誰が何を確認するか

読者	まず確認すること	見落としやすい影響
個人利用者	公式画面の端末、セッション、最近のアクティビティ	メール転送、回復先、見覚えのない連携アプリ
情シス	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・デプロイ設定の変更。

ログには期限があります。EntraのサインインログはFreeで7日、P1・P2で30日のため、調査範囲を決めたら早めに取得します。製品別の期限は監査ログの保存期間の比較で確認できます。

確認が済んだら、SaaS権限棚卸しチェックリストを使って、セッション以外の残存アクセスを1件ずつ潰してください。

初動対応：失効から回復までの順番

• 10分以内：端末を替える

  信頼できる端末へ移り、対象アカウントと時刻範囲を控える。

• 30分以内：止めて失効

  新たなサインインを止め、IdPのセッションを失効する。

• 1時間以内：各SaaSへ

  メール、GitHub、クラウド、業務SaaSの独自セッションを失効する。

• 当日中：認証を作り直す

  パスワード、MFA、回復先、連携権限を確認して再設定する。

• 当日中：止まったか確認

  再認証の要求と、不審操作の停止を確認して完了時刻を記録する。

やること

1. 信頼できる端末へ切り替える。 端末侵害が疑われる場合、その端末から新しいパスワードやMFAを登録しない。
2. 緊急性が高ければ新規サインインを止める。 組織アカウントは、承認済み手順に従って一時無効化やアクセス制限を検討する。
3. IdPのセッションとRefresh Tokenを失効する。 管理画面の正式な「セッションを取り消す」「全端末からログアウト」機能を使う。
4. 各SaaSの独自セッションを失効する。 IdP側の失効だけに依存せず、メール、GitHub、クラウド、業務SaaSも確認する。
5. 認証情報と回復手段を回復する。 パスワード、MFA、パスキー、回復先、アプリパスワードを確認し、不明なものを無効化する。
6. 連携権限を見直す。 OAuthアプリ、APIトークン、SSH鍵、Personal Access Tokenを確認し、必要なものだけを残す。
7. 影響調査用のログを保全する。 サインイン、監査、メール、共有、開発基盤のログを、時刻範囲と取得者を付けて保存する。
8. 端末側の原因を調査する。 EDR、OS、ブラウザ、拡張機能を確認し、必要に応じてネットワークから隔離してCSIRTへ引き渡す。

端末を初期化しないまま再ログインすると、同じ端末から再び情報が取られる可能性があります。端末の調査結果が出るまで、対象のブラウザプロファイルでは高権限の作業を再開しないでください。

やってはいけないこと

• Cookieやトークンをオンラインデコーダー、検索、チャットへ貼り付けない。値はそれ自体が認証情報です。
• 被疑端末でパスワード変更、MFA再登録、管理画面操作を続けない。
• ブラウザのCookie削除だけで、第三者側のセッションも無効になったと考えない。
• パスワード変更やIdPの失効だけで、アプリ独自セッションも終了したと決めつけない。
• 不審なセッションを調査目的で再利用したり、別端末へコピーしたりしない。
• ログ、通知、端末を保全せずに初期化・削除し、調査可能性を失わない。
• 侵害中の可能性が高いアカウントを、証跡保全だけのため長時間有効にしない。

記録すること

対象アカウント・テナント:
アカウントの権限・担当業務:
最初に異常を確認した日時・通知:
本人の心当たり:
対象端末・ブラウザ・OS:
IdPのサインイン結果・認証方法:
対象SaaSのセッション・最終利用時刻:
不明なOAuthアプリ・トークン・鍵:
メール転送・共有・権限の変更:
確認した操作ログと対象期間:
実施したセッション・トークン失効:
失効操作時刻・効果確認時刻:
パスワード・MFA・回復先の変更:
端末の隔離・調査状況:
保全したログ・取得者・保存先:
エスカレーション先・判断時刻:
次回確認日時:

ログの読み方に迷う場合は、セキュリティログを読む初心者向けの基本で「誰が、いつ、どこから、何へ、どの結果でアクセスしたか」を整理します。漏えい可能性の報告と調査範囲は、漏えい疑い初動テンプレートへ転記できます。

判断シミュレーション：同じ「不明なセッション」でも分かれる例

次の3例はすべて架空です。結論は考え方の例で、実際の事案の判断を示すものではありません。

架空の事例	判断の分かれ目	進め方
経理のメール	海外IPのセッションと転送ルールの追加	緊急。侵害として失効し、転送先と送信履歴を確認する
開発者のPC	Cookieへのアクセス警告。操作の痕跡はまだない	高。端末を隔離し、GitHubとクラウドのセッションを失効する
出張中の社員	VPN経由の新しいIP。端末と時刻が本人と一致	低。根拠を記録し、古いセッションを整理する

2つ目の例では、痕跡が見つからなくても「侵害なし」とは書かず、「端末の調査結果待ち」と記録します。ありえない移動は有力な手掛かりですが、VPNでも起きるため単独では判断しません。

判断基準：危険度とエスカレーション条件

優先度	条件	推奨対応
緊急	IdP、メール、管理者、経理、人事、GitHub、クラウドの不明なセッション	新規アクセスを制限し、セッション失効、ログ保全、CSIRT・責任者への報告を並行する
緊急	MFA・回復先・管理者権限・メール転送・OAuth同意が変更された	アカウント侵害として扱い、残存アクセスと他ユーザーへの波及を確認する
高	被疑端末で複数サービスを利用し、Cookie・トークンへのアクセス警告がある	端末を隔離し、同じブラウザプロファイルとSSO配下のサービスを横断確認する
高	セッション失効後も操作が続く、または再認証されず利用できるSaaSがある	アプリ独自セッション、APIトークン、サービスアカウント、外部連携まで確認範囲を広げる
中	不明なセッションはあるが、後続操作や設定変更を確認できない	セッションを失効し、対象期間のログを保全して監視を継続する
低	本人の端末・時刻・操作と一致し、不明な設定変更もない	判断根拠を記録し、不要な古いセッションを整理する

優先度は、Cookieやトークンを盗まれた経路の推測ではなく、アカウントの権限、残るアクセス、設定変更、データ操作、他サービスへの波及で決めます。現時点で公開ログから判断できない場合は、「侵害なし」ではなく「未確認」と記録します。

よくある誤解

「MFAを突破された」ことと「MFAが無意味」は同じではない

Pass-the-Cookieでは、MFA完了後のセッションが再利用されることがあります。MFAを外すのではなく、フィッシング耐性の高い認証、端末保護、再認証、セッション監視、短い有効期間を組み合わせます。

「ログイン履歴に異常がないから安全」とは限らない

すでに有効なセッションが使われると、新しいログインとして目立たない場合があります。IdPのサインインログだけでなく、SaaSの監査ログ、セッション一覧、メール・共有・権限の変更を確認します。

「パスワードを変えれば全端末からログアウトする」とは限らない

Google Workspaceの公式手順では、管理対象アカウントのパスワード変更後にサインインCookieのリセットも案内されています。サービスごとの公式手順で、セッションとトークンの失効を別に確認します。

再発防止：管理者が平時に決めること

事後の見直しでは、次の4点を決めておきます。数値はOWASPの例で、業務に合わせて調整が必要です。

対策	目安・条件	根拠と注意点
アイドルタイムアウト	高価値アプリ2〜5分、低リスク15〜30分	OWASPの一般的な範囲。自社開発アプリで設定する
絶対タイムアウト	例：4〜8時間	終日業務の例。利用時間に合わせて決める
セッションの無効化	ログアウト時と期限切れ時にサーバー側で破棄	Cookieの削除だけでは足りない
トークン保護	端末に結び付いたトークンのみを受け付ける	Entraのトークン保護はネイティブアプリが中心。ブラウザは限定的

自社開発のWebアプリでは、CookieにSecure、HttpOnly、SameSiteを設定し、権限が変わる時点でセッションIDを再生成します。詳しい設計の違いはJWTとセッションの比較で確認できます。

関連用語・関連ページ

• Session Hijackingとは: 認証後のセッションを第三者に利用される状態。
• Pass-the-Cookieとは: 取得されたセッションCookieを利用する考え方。
• Token Revocationとは: 発行済みトークンを明示的に無効化する仕組み。
• 身に覚えのないMFA変更通知の初動対応: 認証方法や回復先が変わった場合の封じ込め。
• MFA疲労攻撃の初動対応: 通知を承認してしまった場合の止め方。
• 生成AIに機密情報を入力したときの初動対応: トークンをAIへ貼ってしまった場合の報告と失効。
• インシデント時の証拠保全: 失効の前後でログを失わない方法。
• SSOとMFAの違い: ログイン統合と本人確認強化の役割を整理する。
• インシデント対応トピック: 検知、封じ込め、証拠保全、報告、復旧の順で次の行動を選ぶ。
• セキュリティ用語クイズ: セッション、認証、トークンの理解を確認する。

公式情報・参考情報

以下の資料を2026年11月2日に開いて確認しました。製品を操作した検証ではなく、公開情報の確認です。管理画面の名称、失効範囲、反映時間は変更される場合があるため、実施時は各サービスの最新公式手順と組織の承認済み手順を確認してください。

• Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID - IdPトークンとアプリ独自セッションの違い、緊急時のアクセス失効。
• Microsoft Learn: Continuous access evaluation in Microsoft Entra - 重要イベントの評価、遅延、トークンの有効期間、制限事項。
• Microsoft Learn: Token protection in Conditional Access - 端末に結び付いたトークンと対応範囲。
• Microsoft Learn: Microsoft Entra data retention - サインインログの保持期間。
• Google Workspace: Sign a user out of a managed Google Account - サインインCookieのリセットと対象外のアプリ。
• Google Workspace Admin Help: Reset a user’s password - 管理対象アカウントのパスワードとサインインCookieをリセットする公式手順。
• Google Account Help: Secure a hacked or compromised Google Account - 不審なアクティビティ、端末、回復情報、アプリ、Gmail設定を確認する公式手順。
• GitHub Docs: Viewing and managing your sessions - Web・モバイルセッションを確認し、失効する公式手順。
• OWASP Session Management Cheat Sheet - サーバー側の失効、タイムアウト、セッション監視に関する実装・運用ガイド。
• MITRE ATT&CK: Steal Web Session Cookie (T1539) - 緩和策と検知の観点。
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations - インシデント対応を継続的なリスク管理として扱うための公式指針。