クラウドIDを脅かす「OAuthトークン窃取（Token Theft）」とセッション管理
背景と概要
リモートワークの定着やマルチクラウド化に伴い、企業における認証基盤は従来の「社内ネットワーク（IPアドレス）による境界防衛」から、「クラウドID（Identity）を軸としたアクセス制御」へと完全に移行しました。Microsoft Entra ID（旧Azure AD）やOktaなどのアイデンティティプロバイダー（IdP）の導入により、利便性とセキュリティの両立が図られています。
しかし、攻撃者側もこの変化に適応しています。従来型の「IDとパスワードを盗み出すフィッシング詐欺」に加え、多要素認証（MFA）を通過した後に生成される「アクセスキー」や「セッションCookie（トークン）」を直接狙う「OAuthトークン窃取（Token Theft / Session Hijacking）」の手口が急速に洗練され、大きな議論を呼んでいます。
OAuthトークン窃取のメカニズムと多層化する手口
トークン窃取攻撃の恐ろしさは、被害者がどれほど強固なMFA（SMS認証、認証アプリ、生体認証など）を設定していても、一度発行された「正規のログイン済みセッション」をそのまま横取りされる点にあります。
- インフォスティーラー（情報窃取型マルウェア）によるローカルDB奪取
従業員の端末が「RedLine Stealer」「LUMMA Stealer」などの悪質なマルウェアに感染すると、Webブラウザ（ChromeやEdge等）のローカルストレージやSQLiteデータベースに暗号化されて保存されているセッションCookieやトークン情報が直接読み出され、攻撃者のC2サーバーへ転送されます。
- AiTM（中間者攻撃）プロキシによるリアルタイム強奪
フィッシングメール等から攻撃者が用意した中間プロキシサーバー（Evilginxなど）を経由させることで、ユーザーが本物のログイン画面で入力したID・パスワードだけでなく、MFA完了直後にIdPからブラウザへ発行される「ESTSAUTH」等のセッションCookieをリアルタイムで横取りします。
- OAuthアプリ（サードパーティ連携）の権限悪用
「便利ツール」や「外部連携サービス」を装った偽のOAuthアプリへの同意（Consent）をユーザーに行わせることで、ユーザーの認証トークン（Refresh Token）を攻撃者側のサーバーに保持させ、無期限でメールの読み取りやファイル操作を行わせる手口です。
トークンを悪用された際のリスク構造
盗まれたセッションCookieやリフレッシュトークンは、攻撃者の端末にインポートされることで「既にMFAを通過した正規ユーザー」として認識されます。これにより、攻撃者はMFAの再要求を受けることなく社内のSlack、Gmail、SharePoint、Salesforceなどに自由アクセスできるようになります。
さらに、攻撃者は侵入後に新たなOAuthアプリを登録したり、バックドアとなる永続的なアクセスキーを生成したりするため、ユーザーがパスワードを変更してもセッションが切れず、潜伏が長期化しやすい傾向があります。
組織における現実的な防衛・検知アプローチ
従来の「パスワード変更」や「通常のMFA」だけに頼らない、トークン自体の保護とコンテキスト監視が求められます。
- トークンと端末の紐付け（Token Binding / Token Protection）の導入
セッションCookieやトークンを端末のTPM（セキュリティチップ）に暗号的に結びつける技術の導入が進んでいます。これにより、仮にCookieデータだけが外部に流出しても、別の端末からは利用できなくなります。
- フィッシング耐性のあるMFA（FIDO2 / パスキー）への移行
AiTM攻撃に対しては、ドメイン結合の仕組みを持つFIDO2規格（YubiKeyやパスキー等）を導入することで、偽サイト上での認証処理自体を発生させない環境を作ることが有効とされています。
- リスクベースのコンディショナルアクセス（条件付きアクセス）の適用
アクセス時の「IPアドレスの急激な変化（インポッシブル・トラベル）」「不審な端末からのアクセス」をリアルタイムで判定し、トークンの有効性を即座に失効（Revoke）させる制御を組み込みます。