セッショントークン窃取とは？Cookie・リフレッシュトークン盗難の危険性と対策方法を徹底解説

セッショントークン窃取とは何か

認証後に発行されたトークンを奪い、本人になりすます問題です

セッショントークン窃取は、利用者がログイン後に受け取るセッションCookie、アクセストークン、リフレッシュトークン などを盗み、本人がすでに認証済みである状態を横取りして再利用する問題です。Microsoft の事案対応部門によるMicrosoft Incident Response lessons on preventing cloud identity compromise↗でも、トークン窃取はクラウドID侵害の典型論点として整理されています。

ここで重要なのは、攻撃者が毎回パスワードを入力しているわけではないことです。いったん認証済みセッションを持たれると、本人確認の入口を通らずにメール、SaaS、管理画面へ入れる状態が続くことがあります。そのため、パスワード変更や多要素認証の追加だけでは後追いになりやすいのが厄介です。

AiTM や OAuth 同意フィッシングとは、盗まれるものが違います

中間者フィッシング（AiTM）は、偽の認証導線を挟み、認証後のセッションを奪う入口側の話です。OAuth同意フィッシングは、利用者が悪意あるアプリへ権限を与えることでアクセス権限を渡してしまう構造が主役です。これに対してセッショントークン窃取は、どの入口であれ、最終的にトークンを持たれた後の再利用リスクを主役にします。

また、デバイスコードフィッシングはデバイスコード悪用が入口です。セッショントークン窃取の記事では、入口を広げすぎず、Cookie やリフレッシュトークンを持たれた時にどの防御と失効が必要かを中心に整理します。

多要素認証導入済みでも、認証後のセッションを守らないと抜けます

「多要素認証を入れているから安全」と考えがちですが、トークン窃取の問題はそこにあります。認証自体は正しく行われていても、発行済みトークンが別端末や別経路で再利用されると、多要素認証を通過済みという事実ごと横取りされる形になります。

そのため、多要素認証未適用アカウントやパスワードスプレー攻撃のような認証前の話と、トークン失効や端末信頼のような認証後の話を、同じチェーンとして見ないと対策が途中で切れます。

なぜ成立するのか、どこが盲点になるのか

トークンは認証基盤だけでなく、ブラウザや端末の現実の保管場所から抜かれます

トークン窃取を見誤りやすいのは、「認証の設定」だけを見てしまうからです。実際には、ブラウザ、端末、拡張機能、委託先端末のような利用者側の現実の保管場所が狙われます。arXiv のTowards Browser Controls to Protect Cookies from Malicious Extensions↗は、悪意ある拡張機能や侵害された拡張機能がセッションCookieへ到達できる点を問題として示しました。

つまり、トークン窃取は「シングルサインオンを入れれば終わり」ではありません。ブラウザ拡張、保存済み資格情報、私物端末、委託先端末、モバイル運用など、トークンを持つ側の実装と運用を見ないと現実の再利用リスクが残ります。

失効を短く回せないと、多要素認証実施済みのセッションがそのまま残ります

Microsoft Learn のuser: revokeSignInSessions↗やトークン保護の公式資料は、「認証した事実」そのものを再利用されにくくするために、発行後のトークン管理と失効が重要だと示しています。パスワードを変えてもセッションやリフレッシュトークンの扱いが遅いと、侵害後も利用が続く時間が残ります。

ここで企業がつまずきやすいのは、ヘルプデスクはパスワードを変えるが、運用担当はセッション失効を行わず、SaaS 管理者は別系統で権限剥奪する、と手順が分かれていることです。事案対応を分業しすぎると、封じ込めより遅い引き継ぎが起きます。

異常トークンを追うには、識別子と相関の設計が必要です

トークン窃取の検知が難しい理由の一つは、「同じトークンの再利用」をログで素早く追いにくいことです。Microsoft Entra のStrengthen identity threat detection and response with linkable token identifier↗は、識別子を使ってトークンを相関しやすくする方向を示しています。

逆に言えば、識別子、端末属性、地域変化、短時間の再利用、管理者操作の相関が弱いと、「本人の継続利用」と「盗難トークンの再利用」を区別しにくくなります。ここが弱いと、被害の発見は送金詐欺や設定変更の後になります。

被害の広がり方と企業側のリスク

一つのトークン窃取が、メール・SaaS・管理画面の横断侵害へ広がります

セッショントークン窃取の怖さは、「一つの認証事故」に見えて、実際には複数の業務面へ広がることです。メール、共有ファイル、SaaS 管理画面、サポートポータルが同じセッションや近い認証前提でつながっていると、最初の 1 回のトークン再利用が複数の操作権限へ変わることがあります。

その結果、侵害は単なるログイン成功で終わらず、メール転送設定、共有リンク作成、管理者ロール変更、委託先設定の閲覧、送金フロー悪用へ波及します。入口が小さく見えても、下流の権限集中が大きいほど重くなります。

財務・委託先・高権限運用ほど、認証後セッションの価値が高くなります

特に危険なのは、財務、委託先、管理者、サポート担当のように、認証済みセッションそのものの価値が高い役割です。トークン窃取は認証方式の話に見えますが、実際には権限設計の問題でもあります。

たとえば委託先アカウントでトークンが盗まれると、業務委託先アカウント管理の弱さがそのまま露呈します。高権限者で起きると、被害は横移動やビジネスメール詐欺の入口にもなります。

検知が遅れると、『なぜ入られたか』より『入った後に何をされたか』の方が重くなります

トークン窃取は、侵入の瞬間より後続操作の方が重くなりやすいテーマです。だからこそ、EDR未導入と24時間監視不足のような検知遅れの記事とつなげて考える必要があります。認証後セッションの異常再利用を見落とすと、証跡保全や影響範囲の把握はいつも後手になります。

企業側では、「なぜパスワードが破られたか」より前に、「なぜセッションを持たれたまま長く使わせたか」を問う方が、再発防止の優先順位を決めやすくなります。

企業が優先してやるべき対策

セッショントークン窃取対策は、認証製品の追加だけでは終わりません。高リスクのセッションの棚卸し、入口の削減、発行後トークンの再利用抑止、失効の短時間化、端末側統制を同じ運用として組む必要があります。

高リスク領域からトークン保護と強い認証へ寄せるべきです

Microsoft Learn のトークン保護↗は、主要リフレッシュトークンの盗難再利用を起こしにくくする方向を示しています。すべてを一度に変えられなくても、高権限者、財務、委託先、管理画面から先に締めるべきです。

ここで重要なのは、「多要素認証を増やす」ではなく、認証済みトークンが別端末で通りにくい前提を増やすことです。弱い方式が高価値アカウントに残ると、最も守るべき場所だけ再利用に弱い状態になります。

事案対応ではパスワードリセットとセッション失効を分けないでください

トークン窃取の初動でありがちな失敗は、利用者へパスワード変更を案内して終わることです。実務では、サインインセッションの失効、リフレッシュトークンの無効化、端末確認、権限剥奪、委託先通知を一気に回さないと、攻撃者側の利用時間が残ります。

そのため、ヘルプデスク、認証基盤管理者、SaaS 管理者、CSIRT の役割を分けるにしても、利用者連絡より先に失効できるフローを定義しておく方が安全です。手順の分業は必要ですが、初動の分断は危険です。

ブラウザ拡張と委託先端末は、認証運用の外へ置かないでください

arXiv 論文が示したように、セッションCookieの保護はブラウザ拡張や端末の現実と切り離せません。ブラウザ拡張を放任し、委託先端末をブラックボックスにし、私物端末を黙認すると、トークン窃取は認証設定の外で成立します。

実務では、拡張機能の許可制、端末準拠確認、私物利用の制限、委託先端末の最低要件、保存済み資格情報の棚卸しまでを認証運用の一部として扱うべきです。

異常セッションの相関と見直しを、月次運用へ落とし込む必要があります

トークン窃取は単発の事案ではなく、「見えていない弱いセッション方針」が残り続ける運用課題です。関連付け可能なトークン識別子のような識別子、端末属性、地域変化、管理者操作を束ねて見て、月次でどのログイン画面とどのアカウント区分が危ないかを見直す必要があります。

ここまでできて初めて、認証の強化、端末統制、公開面削減が一つの改善サイクルになります。個別事案のたびに慌てるより、定期見直しの間隔を持つ方が継続的に効きます。

さらに、月次の見直しでは「今月新しく見つかった入口」と「まだ閉じられていない古い入口」を分けて残すと改善しやすくなります。新規の問題だけでなく、残り続ける例外を可視化できるほど、トークン窃取の前段を細くする判断も速くなります。 例外を一覧で持つことが継続改善の前提です。ここを曖昧にしないでください。残件管理が要です。継続性が差を生みます。

ログ相関と端末運用をどう結び付けるか

見るべきなのはログイン成功数より、失効・再発行・端末変化の並びです

セッショントークン窃取の監視でありがちな失敗は、ログイン成功や失敗の回数だけを見てしまうことです。実際には、パスワード変更の直後も利用が続く、失効操作のあとに別端末から似た利用が出る、短時間に複数地域で同じアカウントの作業状態が切り替わる、といった前後関係の異常の方が重要です。

そのため、月次レビューではサインイン成功件数より、失効操作、再認証、端末識別子の変化、管理者権限の付け外し、共有リンク作成、メール転送設定変更などを並べて見た方が、認証後の再利用に気づきやすくなります。ログの数を増やすより、何と何を同じ画面で見るかを決めることが先です。

たとえば、失効の直後に同じ利用者で別端末から作業が再開していないか、管理者権限が付いた直後に地域や端末属性が変わっていないか、共有リンク作成や転送設定変更が続いていないかを束ねて見るだけでも、単独のログより異常を判断しやすくなります。認証イベントだけを孤立して見ないことが、セッショントークン窃取の検知では重要です。

私物端末、委託先端末、ブラウザ拡張を例外扱いにすると穴が残ります

認証基盤を丁寧に整えていても、私物端末や委託先端末を「業務都合で仕方ない例外」として放置すると、セッショントークン窃取の成立条件が残ります。とくに外部委託や一時的な支援要員では、拡張機能の制御、保存済み認証情報、ブラウザ更新、端末隔離が本体環境より弱くなりがちです。

ここでは禁止事項だけを増やすより、どのアカウント区分なら私物端末を許さないか、どの業務なら仮想デスクトップや管理端末へ寄せるか、委託先へ求める最低要件は何かを決めた方が現実的です。高価値の作業状態を持つアカウントほど、端末条件を厳しくするという考え方で線を引くと運用しやすくなります。

とくに、管理者、財務、外部委託先のように、一度入られると被害が大きい区分では、端末条件を緩くした例外が長く残りやすいです。ここを放置すると、強い認証を導入していても、運用上の例外が実質的な最弱点になります。端末統制は利便性の話ではなく、認証後の作業状態をどこまで信用するかを決める設計だと考えるべきです。

月次レビューでは『弱い方式』より『長く残る例外』から潰すべきです

実務では、すべての認証を一気に強くするより、例外として長く残っている作業状態を減らす方が効果的です。高権限者なのに端末確認が弱い、委託先だけ古い認証導線を使う、特定の管理画面だけ失効が遅い、外部公開の古い入口が残る、といった例外は、平時には見逃されやすい一方で、事故時には大きく効きます。

月次レビューでは、方式の名前を並べるより、どの部署にどの例外が残っているか、失効に何分かかるか、高権限の作業状態がどこまで外部端末に広がっているかを追う方が改善に結びつきます。セッショントークン窃取対策は、認証方式の比較ではなく、例外の整理を続ける運用です。

さらに、月次レビューの場で各部門へ「どの公開入口をまだ使っているか」「どの古いログイン面を閉じられるか」を返せるようになると、認証運用と公開面管理がつながります。セッショントークン窃取は、設定の強さだけでなく、不要な入口を減らす改善を並行させた方が継続的に効きます。

ここで見るべきなのは、最新の強い認証を何件導入したかより、例外として残る運用がどれだけ減ったかです。高権限者だけ別の入口を使う、委託先だけ古い端末条件を使う、特定の管理画面だけ失効が遅いといった例外を減らすほど、再利用される作業状態の総量も減らせます。例外の削減を改善指標にすると、認証と運用の会話がつながりやすくなります。

とくに高権限アカウントでは、例外の存在そのものを毎月説明できる状態が重要です。どの例外が残り、なぜ残り、いつ解消するのかを追えるようになると、セッショントークン窃取対策は単発の設定変更ではなく、継続的に弱点を減らす運用として回しやすくなります。

例外が一覧化されていれば、強い認証や失効運用をどこから先に当てるかも決めやすくなります。結局のところ、作業状態を守る運用は、例外を把握して減らし続けられるかどうかで差が付きます。

セッショントークン窃取対策で外部ログイン面の棚卸しを進めるなら ASM診断 PRO

ASM診断 PRO はトークン保護製品や認証基盤の代替ではありません。ただし、トークン窃取の前段になりやすい外から触られるログイン画面、古いポータル、委託先向け入口、放置された管理画面を外側から棚卸ししやすい構成です。

特に、どの公開導線が残っていて、どのアカウント区分がその面を使っているのかを整理できると、どこを減らせばトークン窃取の入口を先に細くできるかを判断しやすくなります。認証方式だけでなく、試される公開面そのものを減らす判断へつなげてください。

さらに、ログインURLの棚卸しを行うと、どの入口が委託先向けか、どの入口が旧運用のまま残っているか、どこに強い認証や端末条件を優先適用すべきかも見えます。セッショントークン窃取は作業状態を奪われる問題なので、入口の数と強さをそろえることが、失効運用の改善と同じくらい重要です。

外部から到達できる認証入口が多いほど、どの作業状態を優先して守るべきかの判断も難しくなります。まず入口を洗い出し、高リスク業務へ強い認証と厳しい端末条件を当てる順番を付けると、作業状態の保護と公開面の削減を同じ改善計画へ乗せやすくなります。 入口を減らす判断材料を早く揃えることが重要です。

よくある質問（FAQ）

セッショントークン窃取とパスワード漏えいの違いは何ですか？

パスワード漏えいは認証前の秘密情報が主役ですが、セッショントークン窃取は認証後に発行されたセッションCookieやリフレッシュトークンの再利用が主役です。後者は多要素認証実施済みの状態ごと悪用される点が厄介です。

パスワードを変更すれば封じ込めできますか？

それだけでは不十分です。発行済みのセッションやリフレッシュトークンが残ると、攻撃者の利用が続く場合があります。失効、無効化、端末確認、権限剥奪まで一連で行う必要があります。

AiTM とセッショントークン窃取は同じ意味ですか？

同じではありません。AiTM はトークンを盗む入口の一つです。セッショントークン窃取は、入口を限定せず、盗まれたトークンが再利用される問題全体を指します。

どの部署が主導して対策すべきですか？

認証基盤の管理者だけでは足りません。CSIRT、ヘルプデスク、SaaS 管理者、端末管理、委託先管理、財務・高権限運用まで関わります。トークンを持つ場所と、トークンが使われる場所の両方を管理する必要があります。

ASM診断 PRO はこのテーマでどう役立ちますか？

ASM診断 PRO はトークン自体を失効させる製品ではありませんが、外から見えるログイン画面、古いポータル、委託先導線、管理画面を棚卸しし、トークン窃取の前段となる公開面を減らす判断を支援できます。

まとめ

セッショントークン窃取は、認証前のパスワード攻撃とは違い、認証後セッションの再利用が主役です。だからこそ、「多要素認証を入れたから安心」と考えると見落とします。Cookie やリフレッシュトークンの保管場所、失効の短さ、端末統制、公開導線の削減までまとめて見直す必要があります。

実務では、高リスクアカウントからトークン保護と強い認証へ寄せること、パスワードリセットとセッション失効を分けないこと、ブラウザ拡張や委託先端末を認証運用の外へ置かないことが重要です。入口、発行後トークン、侵害後初動を同じサイクルで締め直してください。

そのうえで、失効操作、端末属性、地域変化、管理者操作を一緒に見られるログ相関を整え、毎月「どの例外が残っているか」を確認すると、認証方式の話が日々の運用へ落ちます。セッショントークン窃取を小さくする鍵は、強い認証の導入だけではなく、長く残る例外を減らし、失効を速く回すことです。

入口の棚卸し、端末条件、失効運用、ログ相関を同じ月次レビューへまとめると、どのアカウント区分が危ないかを継続して追えます。認証製品の比較より、例外の削減と失効時間の短縮を積み重ねる方が、現実の被害抑止には効きます。