YouTube の投稿者を狙った実際の攻撃では、偽の仕事の依頼を 送ってマルウェアを実行させ、ブラウザの Cookie を盗みました。 奪ったセッションを使って、改めて認証コードを得ることなく チャンネルの乗っ取りに利用しています。Google の脅威分析チームが記録した事例です。強い認証を設けても、ログイン後に発行する セッションを守る必要があることを示しています。
セッション Cookie などのトークンは、認証済みであることを サービスに伝えます。使える状態のトークンを攻撃者が得ると、 元の多要素認証を繰り返さずに、利用者として操作できる 場合があります。成功するかどうかは、有効期限、失効処理、 端末との結び付け、サービス側の追加確認によって変わります。 セッションの盗難はアカウント乗っ取りの一経路であり、 パスワードや復旧手段の侵害も別にあります。
セッションの仕組み
ログインに成功すると、サービスはセッション識別子を Cookie で発行することがよくあります。ブラウザが後の リクエストでもそれを送るため、ページを開くたびに 認証し直す必要がありません。ほかの種類のトークンを 使うサービスや、重要な操作で再認証を求めるサービスも あります。OWASP のセッション管理ガイドは、識別子とサーバー側の状態がどう働くかを説明しています。
セッションの有効期間は、サービス、アカウントの設定、 利用状況によって異なります。ログアウトや安全上の判断で トークンが失効したり、新しいものに替わったりします。 端末やネットワークの特徴を比較し、再確認を求める サービスもあります。盗まれたトークンが危険なのは 受け入れられる間であり、どの端末でも永久に使える わけではありません。
ブラウザは HttpOnly や Secure などの属性で、通常の ページ内スクリプトから Cookie を守ります。保存された値を OS が保護する場合もあります。しかし端末自体が侵害されると、 十分な権限を持つマルウェアはブラウザの保存領域や メモリーから Cookie を取得できます。Google は端末に結び付けるセッションの解説で、その状況ではソフトウェアだけで盗難を確実に防げない 理由を説明しています。
Cookie が盗まれる経路
一つの経路は情報窃取型マルウェアです。利用者の端末で 動き、認証情報やブラウザのセッションデータを探します。 偽のダウンロード、悪意ある添付ファイルなどから入り込む 場合があります。取り出せる情報は、マルウェアの権限、 ブラウザ、端末の保護に左右されます。どの種類もすべての Cookie やパスワードを盗めるわけではありません。
別の経路は、利用者と正規サービスの間に入る偽の ログインページです。実際のログイン処理を中継しながら、 認証情報を記録し、場合によっては認証後に発行された セッショントークンも取得します。偽ページに入力した 偽ページに入力したワンタイムコードによる認証も突破され得ます。Microsoft がこの手口を解説しています。正規サイトに結び付いたパスキーは、このような ログイン時の詐欺に強い一方、認証後のセッションが 侵害される可能性は残ります。
盗まれたトークンは、そのまま使われたり、ほかの アカウント情報と一緒に売買されたりします。攻撃者が 見慣れた端末やネットワークを装っても、ブラウザの 識別情報や IP アドレスを似せるだけでアクセスが 成功するとは限りません。サービスはトークンを拒否したり、 再認証を求めたり、その後の不審な操作を検知したり できます。OWASPは、こうした状況確認の効用と限界を説明しています。
多要素認証とパスキーの守備範囲
多要素認証はログインの安全性を大きく高めます。しかし、 既存のセッショントークンを添えた後続のリクエストが すべて元の利用者から来たとは、それだけで証明できません。 盗まれたトークンをサービスがそのまま受け入れるなら、 攻撃者は多要素認証を繰り返さずに操作できます。一方、 重要な操作で追加認証を求めたり、不審なセッションを 失効させたりするサービスもあります。
IP アドレス、ブラウザ、アクセス時刻の変化は、 不正利用の検知に役立ちます。ただし、旅行や端末の 変更でも同じ変化が起こり、簡単な規則なら攻撃を 見逃すこともあります。トークンの定期的な更新や 短い有効期限は悪用できる時間を減らします。 盗難が疑われたときは、サーバー側での失効と 再認証によってアクセスを止められます。
パスキーや FIDO2 対応のセキュリティキーは偽サイトへの ログインを防ぎやすく、だまし取られ得るコードより 有利です。ただし、発行済みのセッションが トークンだけで使える場合、その盗難まで防げる わけではありません。FIDO Alliance もこの点を説明しています。Device Bound Session Credentials は、ブラウザと サイトの両方が対応する場合に端末に結び付いた証明を 加えます。Google は 2026 年に Windows 版 Chrome で 一般提供を始めましたが、対応環境と導入状況は サービスごとに異なります。
兆候と初動対応
既存のセッションを使われた場合、新規ログインの通知が 届かないことがあります。ただし、サービスが別の異常を 検知する場合もあります。覚えのない送信済みメッセージ、 メールの転送規則、アカウント設定の変更や警告を 確認しましょう。どれも別の原因はあり得るため、 通知がないから安全だと決め付けず、早めに調べてください。
サービスに端末やセッションの管理画面があれば利用しましょう。 たとえばGoogle では確認とログアウトができます。表示される場所は概算で、一台の端末に複数の セッションがある場合もあります。自分の利用状況と 照らし合わせ、覚えのないセッションはサービスの 機能で失効させて、案内に従いアカウントを保護してください。
端末のマルウェアが疑われるなら、重要なログインに 使うのを止め、組織の手順に従って調査、駆除または 再構築してください。信頼できる別の端末から セッションを失効させ、影響を受けたパスワードを 変更します。サービスの案内に沿って、復旧手段、 多要素認証の設定、アカウントの変更履歴も 確認しましょう。パスワードの変更だけでは、 すべての既存セッションが失効するとは限りません。
セッション盗難のリスクを減らす
端末とブラウザを更新し、出所の怪しいダウンロードを 避け、サービスが提供する中で最も強い認証方法を 使いましょう。セッションの確認、警告、短い有効期限、 端末との結び付けが用意されていれば、用途に合う 保護を有効にします。それぞれ違う危険を減らしますが、 侵害された端末を無害にできるわけではありません。
Browser.lol のセッションでは、訪問先サイトの Cookie を 手元のブラウザではなく遠隔のブラウザに置けます。 しかし、端末上のマルウェアが入力した認証情報を 観測したり、ブラウザを操作したり、Browser.lol の アカウントや接続を狙ったりすることは防げません。 タブを閉じても遠隔のセッションが続く場合があり、 保存したプロフィールにはブラウザの状態が残り得ます。 隔離と併せて端末を守り、訪問先サービスのセッション 管理機能も使いましょう。関連する危険については閲覧履歴が悪用される仕組みも参考にしてください。
