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

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

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

セッショントークン窃取は、利用者がログイン後に受け取る session cookie、access token、refresh token などを盗み、本人がすでに認証済みである状態を横取りして再利用する問題です。Microsoft Incident Response のMicrosoft Incident Response lessons on preventing cloud identity compromise↗でも、token theft は cloud identity compromise の典型論点として整理されています。

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

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

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

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

MFA 導入済みでも、認証後 session を守らないと抜けます

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

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

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

token は IdP だけでなく、ブラウザや端末の現実の保管場所から抜かれます

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

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

失効を短く回せないと、MFA 実施済み session がそのまま残ります

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

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

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

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

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

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

一つの token theft が、メール・SaaS・管理画面の横断侵害へ広がります

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

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

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

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

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

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

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

企業側では、「なぜ password が破られたか」より前に、「なぜ session を持たれたまま長く使わせたか」を問う方が、再発防止の優先順位を決めやすくなります。

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

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

高リスク領域から token protection と強い認証へ寄せるべきです

Microsoft Learn のtoken protection↗は、primary refresh token の盗難 replay を起こしにくくする方向を示しています。すべてを一度に変えられなくても、高権限者、財務、委託先、管理画面から先に締めるべきです。

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

incident response は password reset と session revoke を分けないでください

token theft の初動でありがちな失敗は、利用者へパスワード変更を案内して終わることです。実務では、sign-in session revoke、refresh token invalidation、端末確認、権限剥奪、委託先通知を一気に回さないと、攻撃者側の利用時間が残ります。

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

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

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

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

異常 session の相関と review を、月次運用へ落とし込む必要があります

token theft は単発の incident ではなく、「見えていない弱い session policy」が残り続ける運用課題です。linkable token identifier のような識別子、端末属性、地域変化、管理者操作を束ねて見て、月次でどの login 面とどの account class が危ないかを見直す必要があります。

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

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

ASM診断 PRO は token protection 製品や IdP の代替ではありません。ただし、token theft の前段になりやすい外から触られる login 面、古い portal、委託先向け入口、放置された管理画面を外側から棚卸ししやすい構成です。

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

よくある質問（FAQ）

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

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

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

それだけでは不十分です。発行済み session や refresh token が残ると、攻撃者の利用が続く場合があります。revoke、invalidate、端末確認、権限剥奪まで一連で行う必要があります。

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

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

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

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

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

ASM診断 PRO は token 自体を失効させる製品ではありませんが、外から見える login 面、古い portal、委託先導線、管理画面を棚卸しし、token theft の前段となる公開面を減らす判断を支援できます。

まとめ

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

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