パスワードスプレー・クレデンシャルスタッフィングとセッション窃取

MFA成功後に別の場所から操作されたら、パスワード変更だけで止められるでしょうか。アカウントとセッションの記録を分けて追います。

社内SaaSのIdPで、朝から多数の利用者に低頻度の認証失敗があり、一人のMFA成功直後に海外IPから同じセッションの操作が見つかった。

総当たり、流出資格情報の再利用、偽ログイン画面の中継、Cookieの再利用では、観測点と止めるべき資格が異なる。アカウントとセッションを分けて調べる。

誰が、どの場所で判断するのか

A社でIdP-1がmail.example.testとdocs.example.testを認証する。攻撃者は多数の社員IDへ一つの候補パスワードを試し、別途盗んだID・パスワードの組も使う。

U-41は偽ドメインlogin-example.testの画面でIdP-1へのログインを中継され、09:12にTOTPを入力した。

09:14にdocs.example.testの閲覧が通常端末から、09:17に別IPからダウンロードが発生した。ただし同一Cookieを使ったかは追加のセッションID照合が必要。

図は攻撃が成立した場合の通信を示す。実際にセッションが窃取されたかは、Cookie/トークン識別子、IdP側の発行・失効、業務アプリ側の利用記録で確かめる。

FIDO/WebAuthnはオリジンを検証するため、偽ドメイン上で正規ドメイン用の認証を成立させにくい。

この事案を読むために、どの用語を押さえるか

少数の候補パスワードを多数のアカウントへ試す攻撃。一人ごとの失敗回数を抑え、アカウントロックを避ける傾向がある。送信元IPが複数でも同一キャンペーンの場合がある。
別サービスの漏えい等で得たID・パスワードの組を対象サービスへ試す攻撃。ユーザーごとに違うパスワードが使われ得る点でスプレーと違う。
攻撃者が偽ドメイン上で正規IdPとの通信を中継し、利用者の入力と認証後のセッション情報を得る手口。見た目が正規画面に似ていても通信先のオリジンが違う。
認証後にアプリが継続利用を識別する資格。盗まれると有効期間中に本人の操作として使われ得る。パスワードやTOTPの変更だけで全セッションが必ず失効するとは限らない。
複数の要素で認証する仕組み。単純なTOTPやPushは中継・承認誘導の影響を受け得る。FIDO/WebAuthnは正規ドメインへの結び付けで偽オリジンへの中継に強い。
端末状態、場所、リスク、利用アプリ等に応じて認証・利用を制御する。IP制限だけで正当利用者やVPNとの区別はつかない。
IdPとアプリ側の有効なセッション、Refresh Token、Remembered Deviceなどを無効化する。対象と伝播時間を確認する。
認証ログはサインインの試行・結果、操作ログはログイン後の閲覧・変更・ダウンロードを示す。認証成功だけでは情報漏えいの範囲を示せない。

正常なときは、どの順序で処理されるか

認証入口を棚卸しし、IdP、VPN、旧メールプロトコル、業務アプリのログと失敗・成功イベントを同じ時刻で収集する。
一つのIP当たりだけでなく、同じ候補を多数アカウントへ試す分布、複数IPから同じID群を狙う分布、利用者単位の結果を監視する。
漏えい済み資格情報と同じパスワードの再利用を減らし、FIDO/WebAuthn等のフィッシング耐性MFAと端末制約を重要IDから適用する。
認証後のセッションID・端末・IP変化と、メール転送設定、ファイル閲覧・ダウンロード、管理設定変更を結ぶ。
事故時にはパスワードとMFA登録を確認するだけでなく、IdP・アプリ双方のセッション、Refresh Token、回復手段を失効・再検証する。

失敗回数の単純なしきい値は低速・分散型のスプレーを見落とす。逆に社内プロキシで多数の正規利用者が一つのIPに集まる場合は誤検知になる。ユーザー、端末、送信元ASN、User-Agent、時刻、対象アプリの組合せを読む。

設定値とログから、何が分かるか

成功・失敗と理由。無効ID、誤パスワード、MFA拒否、条件付きアクセス拒否を別々に集計する。
ネットワーク・端末の手掛かり。VPNやNAT、モバイル回線で変化するためIPだけで本人・攻撃者を断定しない。
パスワード、TOTP、Push、FIDO、既存セッション再利用の区別。MFA成功は後続セッションの無害性を保証しない。
発行・利用・失効を相関する識別子。生のCookie値やトークンを監査ログに保存すると漏えい源になるのでハッシュ化・短縮IDを使う。
ブラウザとアクセス先。攻撃者はUser-Agentを模倣できるため補助証拠として扱う。
メール閲覧、転送ルール追加、ファイルダウンロードなど。ログイン成功と被害の範囲を区別する。
アカウント停止、セッション失効、Refresh Token無効化の時刻。失効後の操作が残れば伝播・別資格を調べる。

以下はIdPと業務アプリの要約ログ。セッション値は監査用の短縮IDであり、実際のCookieではない。

text

09:00 IdP src=198.51.100.24 accounts=38
  failures=37 success=1 per_account_attempts=1
09:12 IdP user=U-41 method=password+TOTP result=success session=S41
09:12 Browser device=WS-41 origin=login-example.test
09:14 Docs user=U-41 session=S41 action=view src=192.0.2.41
09:17 Docs user=U-41 session=S41 action=download src=203.0.113.77
09:23 IdP user=U-41 session=S41 revoked=true

38アカウントへ各一回の試行はスプレーに整合するが、IdPログだけでは同じ候補パスワードだったか分からない。U-41の偽オリジンでの認証と同一S41での別IPダウンロードはセッション窃取の強い疑いを生む。

ただしIP変化の正当な理由やログの相関精度を確認する。09:23失効前のダウンロードは取得対象と閲覧範囲を調べる。

攻撃が成立するのは、どの条件か

状態・攻撃	成立条件、証拠、対策の位置
スプレー	多数IDへ同じ少数候補。ユーザー別ロック回避のため低速・分散し得る。アカウント集合と候補・時間窓で検知する。
スタッフィング	漏えいしたID・パスワードの組を試す。各IDで候補が異なり得るため、同一パスワード分布だけでは拾えない。
中継型フィッシング	偽ドメインで正規IdPの認証を中継し、利用者がTOTPやPushを完了するとセッションを得る可能性がある。ドメイン拘束のある認証を優先。
セッション再利用	Cookie/トークンが有効で、アプリが追加確認を求めなければ別端末から操作でき得る。発行と利用・失効を相関する。
MFA疲労	Push承認を繰り返し要求し、誤承認を狙う。回数、時間、位置、番号一致やFIDO移行を確認する。
旧認証経路	新IdPでMFA必須でも旧プロトコルや管理APIで免除が残れば侵入口になる。全認証入口を棚卸しする。

MFAが有効でも、セッション窃取や認証前の偽ドメイン誘導で被害が起こり得る。『MFA成功=利用者本人のすべての後続操作』とはしない。フィッシング耐性、端末制約、短いセッション寿命、異常時の再認証を組み合わせる。

判断を確かめるために、何を調べるか

判定段階	必要な証拠と結論の上限
試行の種類	候補パスワードが共通か、IDごとに違うか。IdPがパスワードをログに出さない場合は攻撃インフラと分布から慎重に推定。
認証したか	パスワード、MFA、条件付きアクセス結果を分ける。成功ログ一件から不正利用と断定しない。
セッションを奪われたか	同じセッション識別子と端末・IP・オリジン・操作を照合。IP差だけでは証明できない。
何をされたか	メール、ドキュメント、管理APIの操作ログを確認し、取得物、期間、転送設定を確定する。
止まったか	IdPと各アプリの失効時刻、残るRefresh Token、回復手段、後続操作を確認する。

パスワードスプレーは『一人に多数』ではなく『多数に少数』である。ロックしきい値に近づかないよう間隔を空け、複数のIPやアプリに散らす例がある。防御側はアカウント単位と組織全体の両方で失敗率を見て、IPだけを唯一のキーにしない。

クレデンシャルスタッフィングでは漏えいした組が正しいかを試すため、他サービスで同じパスワードを使った利用者が狙われる。正規利用者の新端末ログインと区別するには、流出の有無、送信元の分布、失敗から成功への移行、後続の異常操作を確認する。

パスワード再利用防止とMFAを組み合わせる。

中継型フィッシングは利用者のブラウザが偽ドメインへ接続し、攻撃者のサーバが正規IdPとやり取りする。TOTPは入力値を同時に中継でき、Pushも利用者が承認すると成立し得る。

FIDO/WebAuthnは認証器がオリジンを結び付けるため、偽ドメインから正規IdP用の認証結果を得にくい。

セッションCookieは認証後の資格であり、盗まれたときの対処はパスワードだけでは不足する。アプリがCookieを独立に管理する場合、IdPのセッション失効がアプリの既存Cookieへ即時反映されないことがある。

Refresh Token、アプリセッション、常時ログイン端末も一覧で失効する。

HttpOnlyはブラウザのJavaScriptからCookieを読ませない属性で、通信を中継するリバースプロキシからセッションを守る保証ではない。SecureはHTTPS経由に限定し、SameSiteは主にクロスサイト送信を制御する。

いずれも盗難済みCookieの再利用を単独で防ぐ手段ではない。

S41が同じと見える場合でも、ログ収集装置が独自に付けた相関IDと実セッションIDを混同しない。生のCookie値をログに記録すると二次漏えいになるため、監査用の安全な識別子で発行・利用・失効を追う。

アプリごとに識別子が異なるならIdPイベントとの対応を設計する。

利用者へは、不審な認証を報告する窓口、MFA要求を承認しない手順、端末の隔離、パスワード変更後の再登録手順を案内する。被害調査では、受信メールの転送ルール、OAuth同意、保存済み共有リンクなど、セッション失効後も残る設定を確認する。

設定変更や例外運用では、何に注意するか

運用場面	崩れやすい条件と確認
共有IP・VPN	複数の正規利用者が同一IPに見える。端末ID、アカウント、セッション、利用時間を加えて誤検知を減らす。
モバイル回線	IPや地域が変わり得るため、位置だけでセッション窃取と断定しない。端末・オリジン・操作を確認する。
セッション失効遅延	IdPとアプリのキャッシュやトークン寿命を把握し、緊急停止がいつ反映されたか実際に確認する。
FIDO未対応アプリ	重要IDから移行し、旧認証経路に期限・端末制限・監視を置く。例外を無期限で残さない。
アカウント回復	攻撃者が回復メールやMFA登録を変えた可能性を確認。単にパスワードを変えても再侵入され得る。

緊急停止では利用者の業務への影響も考え、対象アカウントとセッションを特定する。ただし攻撃が進行中なら追加のダウンロードを止めるため先に失効し、後から調査を続ける。封じ込め時刻を残す。

被害を止め、再開するには何を確認するか

試行に失敗したIDと、成功後に不審な操作があるIDでは対処範囲が違う。S41の失効後もアプリ側で利用できないか確認し、攻撃者が追加した転送・共有設定を戻す。

IdP、アプリ、端末の認証・操作記録を保全し、低頻度試行の対象IDと成功したセッションを列挙する。
侵害が疑われるIDのサインインとセッションを止め、アプリ側Cookie・Refresh Token・回復手段も確認する。
流出IDのパスワードを再設定し、MFA登録・FIDO鍵・回復メール・OAuth同意の改ざんを調べる。
メール・文書・管理APIの操作を調べ、取得ファイルと転送先、共有リンク、設定変更の影響を確定する。
正規端末と本人を確認して再開し、フィッシング耐性MFAと旧経路の閉鎖、セッション異常監視を継続する。

失敗した試行全件を『侵害』と数えず、成功したIDも操作記録で被害を確かめる。セッション窃取が疑われるときは、パスワード変更後の新ログインが正常でも旧セッションの失効と後続操作停止を別に検証する。

設問の条件を、どう答案へ結び付けるか

ログの軸を『多数ID×少数候補』『漏えい組の再利用』『偽オリジンの認証』『同一セッションの別端末利用』に分ける。攻撃名を書くときは、その特徴がログで確認できるかを示し、追加で取るべきセッション・操作ログを答える。

スプレーとスタッフィングの試行分布を区別する。
MFA成功後のセッションを独立した資格として扱う。
偽ドメインと正規IdPのオリジン差を読む。
IdP・アプリ両方の失効と不正設定の残存を確認する。

短い演習で判断を確かめる

演習1：38アカウント

条件：一つの候補で38 IDを試した。

質問：どの攻撃に整合するか。

解答：パスワードスプレー。候補と時刻、複数IPも照合する。

誤答の理由：一人に多数候補を試す攻撃と混同している。

演習2：流出組

条件：各IDで異なる既知のパスワードを試した。

質問：どの攻撃に整合するか。

解答：クレデンシャルスタッフィング。流出組の再利用を調べる。

誤答の理由：共通候補でない点を見落としている。

演習3：TOTP成功

条件：U-41が偽ドメインでTOTPを入力。

質問：MFAが成功したので安全か。

解答：安全とは言えない。中継とセッション取得を調べる。

誤答の理由：TOTPの値が中継可能な点を無視している。

演習4：IPの変更

条件：S41が二つのIPから利用。

質問：窃取確定か。

解答：単独では確定しない。端末・オリジン・操作と相関する。

誤答の理由：回線変更やVPNの可能性を排除していない。

演習5：パスワード変更

条件：U-41のパスワードを更新。

質問：既存Cookieも必ず無効か。

解答：アプリ側のセッションとRefresh Tokenを別途失効・確認する。

誤答の理由：認証秘密と発行済みセッションを混同している。

演習6：HttpOnly

条件：業務アプリはCookieにHttpOnlyを設定。

質問：中継型フィッシングは防げるか。

解答：単独では防げない。フィッシング耐性MFAとセッション制御が必要。

誤答の理由：JavaScript読出し防止を通信中継への対策と混同している。

仕様を確認したいときの一次資料

MITRE ATT&CK：Password Spraying

MITRE ATT&CK：Credential Stuffing

MITRE ATT&CK：Steal Web Session Cookie

MITRE ATT&CK：Web Session Cookie再利用

CISA：フィッシング耐性MFA