顧客アカウントの乗っ取り：異常の検知から安全なログインまで、36の判断ポイント。

顧客はパスワードを使い回し、攻撃者はそれを当てにする

リスト型攻撃（クレデンシャルスタッフィング）は、他のサービスから漏えいしたIDとパスワードの組を自社のログインで試します。成功するたびに、実在の顧客のアカウントが開きます。登録住所、注文履歴、保存されたカード、そして数分で使える・交換できるポイントです。当サイトで分析した事案にも、会員データへのアクセス後のポイント交換、飲食店アプリの会員アカウント、ポイントサービスの会員識別子など、この経路をたどるものがあります。

この再利用可能な顧客アカウント乗っ取りプレイブックには36の判断ポイントがあり、はい・いいえの処置、証拠、担当者を示します。新たな侵害の報道ではなく、SecOpsNomad独自の手順です。顧客が自社のアプリ、通販サイト、会員・ポイントサービスに持つアカウントを対象とします。自社の従業員のアカウントにはアカウント侵害プレイブックを使います。パスワードが自社や委託先のシステムから漏えいした場合は、委託先侵害プレイブックまたは自社の漏えい対応も並行して実施します。

2つの層で同時に封じ込めます。 レート制限やボット対策などの入口の対策は、試行の波を遅らせます。セッション失効、強制的なパスワード再設定、ポイント利用の保留などのアカウントの対策は、すでに侵入された顧客を一人ずつ守ります。どちらも他方の代わりにはなりません。

攻撃の型から顧客への連絡までの7段階に、最初の初動と独立した復旧判定を加えた全体図。

全体図：攻撃の型 → ログイン成功の経路 → 入口の封じ込め → アカウントの封じ込め → 不正と価値 → 個人データ → 連絡。初動を最初に行い、復旧は判定を経て進めます。図と同じ判断を直後の表で確認できます。

まずここから：最初の1時間

初めて対応する方は、この順番で進めてください。詳しい対応は、このあとの各段階で行います。最初の1時間の目的は、すべての顧客を締め出すことなく、顧客アカウントから価値が流出するのを止めることです。

0〜10分：試行と乗っ取りを分ける。 ログイン失敗の急増は攻撃です。顧客本人ではない成功ログインは乗っ取りです。両方を数えます（段階0に、手直しして使えるクエリがあります）。
10分：案件を作り、ログを保全する。 インシデント責任者を決めます。ログイン、セッション、WAF／CDN、取引のログを、ローテーションで消える前に安全な場所へ書き出します。
10〜20分：攻撃の規模を測る。 1時間あたりの試行回数、対象アカウント数、送信元アドレス数、成功率を、平常日と比べます。
20分：入口で攻撃を減速させる。 すべてのログイン経路にレート制限をかけます。Webのページ、モバイルアプリのAPI、古いエンドポイントも含みます（段階3）。
25分：到達されたアカウントを一覧にする。 攻撃元からの成功ログイン、多数の失敗後の成功、新しい端末からのログイン直後の価値の移動。
30分：それらのアカウントを守る。 セッションとアプリのトークンを失効させ、そのうえでパスワードの再設定を求めます（段階4）。
35分：高額の操作を止める。 対象アカウントのポイント交換、ギフトカード購入、払い出し先や連絡先の変更を保留します。対象を特定できないうちは全員に適用します。
40分：提携先に連絡する。 ポイント交換先、ギフトカード発行会社、決済事業者は、完了前の移転を止められることがあります。
50分：顧客対応窓口と法務・個人情報の担当に説明する。 窓口には今日のうちに対応スクリプトが必要です。法務には、報告義務を判断するための数字が必要です。
60分：最初の状況報告を送る。 次の報告時刻も決めます。

やってはいけないこと： 数回の失敗でアカウントを恒久的にロックすること（攻撃者が意図的に本物の顧客を締め出せます）。リンク付きの通知を送ること（フィッシングに模倣されます）。失う顧客を考えずに国やネットワーク全体を遮断すること。パスワードの出どころを確認する前に「当社システムからの漏えいはない」と言うこと。

事前準備と判断ルール

平常時から、すべてのログイン経路（Web、モバイルアプリ、API、提携先のシングルサインオン）が、時刻、アカウント、接続元、端末またはユーザーエージェント、結果、実施した処置を記録していることを確認します。レート制限とボット対策の変更、セッションの一括失効、ポイント交換・出金の保留、顧客への通知を誰が実施できるかを把握し、強制再設定に踏み切る兆候を事前に決めておきます。

はい： 処置を行い、他の該当する確認もすべて実施します。
いいえ： 回答を裏付ける証拠、範囲、時間帯を記録します。アラートなしだけでは不十分です。
不明： 未解決の作業として担当と再確認時刻を決め、調査中もリスクに応じて封じ込めます。
対象外： 理由と確認者を記録し、ログ不足の代わりに使いません。

案件ID、サービスとログイン経路、影響アカウント数、UTC時間帯、回答・根拠、証拠保管先、処置・結果、実担当、再確認時刻を残します。アカウント一覧と顧客データは制限された案件領域に保管し、アカウント識別子、パスワード、トークン、顧客情報をチケットや公開ツールに載せないでください。

日本語の判断台帳をダウンロード（CSV）。空欄は非公開の案件記録用です。表計算ソフトへ追記する文字列は信頼できない入力として扱ってください。

担当： プロダクト担当は顧客に影響する変更、基盤／SREはレート制限・WAF・ボット対策、CIAM／IAMはセッション・再設定・多要素認証、不正対策チームは価値の移動、決済／経理は注文・カード・返金、提携先担当はポイント交換先や決済事業者への連絡を担当します。SOC／SIEMは時系列、カスタマーサポートは問い合わせと本人確認、法務／プライバシーは報告・通知の判断、広報は告知を担当し、責任者が再開と終結を承認します。

この手順で使う言葉

用語	意味
アカウント乗っ取り（ATO）	顧客本人以外がログインし、本人として操作することです。
パスワードリスト型攻撃（クレデンシャルスタッフィング）	他のサイトから漏れたIDとパスワードの組を試す攻撃です。パスワードの使い回しがあるため成功します。多数のアカウントに、それぞれ少ない回数で試します。
パスワードスプレー	よくある少数のパスワードを、多数のアカウントに試す攻撃です。
レート制限	送信元、アカウント、端末ごとに、一定時間内のリクエスト数を制限することです。
チャレンジ	不審なログインに、一律の遮断ではなく追加の確認（ボット判定やワンタイムコード）を求めることです。
住宅用プロキシ	攻撃の通信を一般家庭の回線経由で送るサービスです。本物の顧客の通信のように見えます。
セッション／トークン	パスワード確認のあと、ログイン状態を保つものです。盗まれたり有効なまま残ったりすると、パスワードなしで使えます。
ステップアップ認証	ポイント交換や配送先変更など、危険な操作の前にだけ追加の確認を求めることです。
パスキー	顧客の端末にもとづくサインイン方式です。フィッシングで盗まれず、他のサイトで使い回せません。
漏えいパスワードの確認	既知の漏えいリストにあるパスワードを、登録・再設定・ログインの時点で拒否することです。
価値のある残高	ポイント、残高、ギフトカード、登録済みの支払い方法など、お金に換えられるものです。
個人情報保護法／個人情報保護委員会	日本の個人情報に関する法律と、それにもとづく漏えい等の報告を受け付ける委員会です。

セキュリティ担当がいない場合の役割分担

表に出てくる担当は「役割」であり、肩書きではありません。小さな会社では1人が複数の役割を持つのが普通です。それでも「ログインの制御を変えた人だけが、本物の顧客がまだログインできるかを確認する」状態は避けてください。

この手順での役割	小規模な会社での担当例	事前に用意しておくもの
インシデント責任者	代表者、CTO、またはサービス責任者	ポイント交換などの機能を止める権限
アプリケーション担当	Webサイトとアプリの開発責任者	ログイン、セッション、アカウント変更のデータへのアクセスと、デプロイできること
入口・インフラ担当	CDN、WAF、ホスティングを管理している人	レート制限とセキュリティルールの管理者権限
不正対策・決済担当	運用または経理の担当者	提携先、ギフトカード発行会社、決済事業者の連絡先
顧客対応窓口	サポートチームまたは委託先	対応スクリプト、本人確認の方法、エスカレーション先
法務・個人情報	顧問弁護士、または個人情報保護管理者	対象アカウント数と、そこで見られる情報の一覧
広報	代表者またはマーケティング責任者	承認済みの、リンクを含まない通知文
外部の支援	CDNやホスティングのサポート、決済事業者、インシデント対応会社。不正アクセスについては、警察のサイバー事案の相談窓口	攻撃の数値と時系列

画面の項目名は英語表示の名称で書いています。日本語表示では訳語が異なる場合があります。

0. 初動：試行と乗っ取りを区別する

急増の規模を測ります。試行数、アカウント数、成功率、ログイン経路を通常の日と比べます。
成功を特定します。乗っ取りとは、顧客がしていないログインの成功と、その後の顧客がしていない操作です。
案件を起票して担当を決め、ローテーションや間引きで消える前に、ログイン、セッション、取引のログを保全します。

C01〜C04のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
C01. 顧客がしていないログイン成功、変更、取引があるか？	インシデントを起票し、影響アカウントを直ちに保護する（段階4）。	未遂の攻撃として扱い、入口の対策を続けて成功件数を確認する。	ログイン結果、セッションの操作、顧客からの申告、取引ログ。	SOC＋プロダクト担当
C02. ポイント、残高、保存されたカード、ギフトカード、出金など、価値が危険にさらされているか？	不正対策と決済の担当を招集し、ポイント利用や出金の保留を検討する。	理由を記録する。アカウント内の個人データは引き続き危険にさらされている。	アカウントの機能、残高、最近の利用、出金設定。	不正対策チーム＋決済／経理
C03. 攻撃は継続しているか？	入口の封じ込めを直ちに行い（段階3）、攻撃者の適応を監視する。	ログを保全し、少量・長期間の継続を監視する。	時間ごとの試行数、活動中の接続元、現在の成功率。	基盤／SRE＋SOC
C04. 担当が決まり、ログイン・セッション・取引のログが保全されているか？	報告の頻度を決め、判断をUTCで記録する。	先に担当を決めてログを確保する。ログ不足はその後のすべての判断を制約する。	体制表、ログの出力、保持設定。	責任者

具体的な操作手順

1時間ごとの数値を出します。 自社のログインテーブルに合わせて手直ししてください（テーブル名と列名は例です）。

SELECT date_trunc('hour', event_time) AS hour,
       count(*) AS attempts,
       count(DISTINCT account_id) AS accounts,
       count(DISTINCT source_ip) AS sources,
       sum(CASE WHEN success THEN 1 ELSE 0 END) AS successes,
       round(100.0 * sum(CASE WHEN success THEN 1 ELSE 0 END) / count(*), 2) AS success_pct
FROM login_events
WHERE event_time >= now() - interval '7 days'
GROUP BY 1
ORDER BY 1;

平常日と比べます。 試行回数と対象アカウント数が急増し、成功率が下がっていれば推測の波です。成功数の増加があれば、まずそちらに対応します。
保全します。 期間中のログイン、セッション、WAF／CDN、取引の生ログを、閲覧を制限した案件フォルダーに書き出します。ログの保存期間が短ければ延ばします。
案件を作ります。 責任者、担当者、攻撃を最初に確認した時刻、次の報告時刻。

確認： 攻撃中に成功ログインがあったアカウントの数を言え、ログが通常の保存期間の外に保存されていること（C01〜C04）。

1. 攻撃の型：何がログインを狙っているかを把握

攻撃を分類します。リスト型攻撃（多数のアカウント、各少数回、漏えいした組）、パスワードスプレー（よくあるパスワード）、特定の顧客を狙う乗っ取りです。
攻撃者が使ったすべてのログイン経路を洗い出します。Webページの保護を回避するモバイルAPIや旧いエンドポイントも含めます。
接続元の特徴を把握します。データセンターのアドレス、住宅用プロキシ、ユーザーエージェント、時間の傾向です。接続元が入れ替わる場合、IPの遮断だけでは効きません。

C05〜C08のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
C05. 多数の接続元から多数のアカウントで失敗し、成功率が低いか？	漏えいした組によるリスト型攻撃として扱い、成功したアカウントを優先する。	パスワードスプレーや特定の顧客を狙う乗っ取りを確認し、対策を調整する。	接続元ごとのアカウント数、アカウントごとの試行数、成功率。	SOC
C06. モバイルAPI、旧いログイン、提携先のエンドポイントなど、ブラウザ以外の経路が使われているか？	その経路をWebのログインと同じ水準で保護する。	結論の前に、すべてのログイン経路が記録されていることを確認する。	ログ内のエンドポイント名、APIゲートウェイの記録、アプリのバージョン。	プロダクト担当＋基盤／SRE
C07. 接続元が住宅用プロキシや多数のネットワークにまたがって入れ替わっているか？	IPの遮断だけに頼らず、端末、振る舞い、アカウント単位の制限を使う。	短期的な接続元の遮断は有効な場合がある。入れ替わりの監視を続ける。	ASNとネットワークの構成、1時間あたりのアドレス数、再出現率。	基盤／SRE＋SOC
C08. パスワードが自社や委託先のシステムから漏えいした可能性があるか？	漏えいの調査を開始し、該当すれば委託先侵害プレイブックを実施する。	他のサービスからの使い回しである根拠を記録する。	初回試行での成功率、パスワード保存方法の確認、委託先の通知。	責任者＋法務／プライバシー

具体的な操作手順

経路ごとに分けます。 パスワードやワンタイムコードを受け付けるすべてのエンドポイント（Webのフォーム、モバイルAPI、古いAPIのバージョン、提携先のサインイン、パスワード再設定、コード確認）を一覧にします。攻撃者は最も守りの弱い経路を好みます。
```
SELECT endpoint, count(*) AS attempts, count(DISTINCT account_id) AS accounts,
       sum(CASE WHEN success THEN 1 ELSE 0 END) AS successes
FROM login_events
WHERE event_time BETWEEN '2026-10-04 00:00' AND '2026-10-05 00:00'
GROUP BY endpoint
ORDER BY attempts DESC;
```
分類します。 多数のアカウントに1〜2回ずつで成功率が低ければパスワードリスト型攻撃、少数のパスワードを多数のアカウントに試していればパスワードスプレー、少数の高額アカウントを慎重に狙っていれば標的型の乗っ取りです。
送信元の特徴をつかみます。 上位のネットワーク（ASN）、国、ユーザーエージェント、時間帯。多数のネットワークから少しずつ来ていれば住宅用プロキシで、アドレスの遮断だけでは持ちこたえません。
パスワードの出どころを考えます。 自社の顧客と不自然によく一致する組であれば、自社システムや委託先からの漏えいを確認します（委託先の侵害プレイブックを参照）。

確認： 攻撃の種類、使われた経路、送信元のパターンを1段落で説明できること（C05〜C08）。

2. 侵入経路：ログインが成功した理由を特定

正しいパスワードが初回の試行で通ったかを確認します。通っていれば、推測ではなく使い回しの認証情報を示します。
2段階目の認証と再設定の手順を確認します。SMSやメールのコード、再設定リンク、変更された電話番号、サポートを介した再設定です。
盗まれたセッションや有効期間の長いアプリのトークンを探します。これらはパスワード再設定ではなく、失効が必要です。

C09〜C12のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
C09. 侵害されたアカウントで、正しいパスワードが初回の試行で通ったか？	使い回しの認証情報として扱い、再設定を求めて漏えいパスワードの一覧と照合する。	推測を疑う。レート制限やロックの仕組みが機能していなかった。	アカウントごとの成功前の試行数、パスワード照合の結果。	CIAM／IAM＋SOC
C10. 2段階目の認証がない、回避された、または中継されたか？	穴を塞ぐ。危険なログインと価値の移動に、より強い認証を求める。	使われた認証方式と、それが機能した理由を記録する。	多要素認証の登録率、認証の結果、OTPの送信ログ。	CIAM／IAM＋プロダクト担当
C11. パスワード再設定、連絡先の変更、サポートを介した再設定が悪用されたか？	影響アカウントの再設定経路を固め、最近の変更を確認する。	確認した再設定のイベントと期間を記録する。	再設定の依頼、メールアドレス・電話番号の変更、サポートの記録。	CIAM／IAM＋カスタマーサポート
C12. セッションCookieや有効期間の長いアプリのトークンが盗まれた、または再利用されたか？	セッションとトークンを失効させ、価値の移動に関わる有効期間を短くする。	トークンの仕組みと確認した証拠を記録する。	セッション管理、トークンの発行・利用ログ、端末ID。	CIAM／IAM＋基盤／SRE

具体的な操作手順

1回目での成功： 攻撃元からログインされた各アカウントについて、成功の前の失敗回数を数えます。1回目で正しいパスワードが通っていれば、使い回しの認証情報を示しています。

SELECT s.account_id, s.event_time AS success_time,
       (SELECT count(*) FROM login_events f
         WHERE f.account_id = s.account_id AND NOT f.success
           AND f.event_time BETWEEN s.event_time - interval '1 day' AND s.event_time) AS failures_before
FROM login_events s
WHERE s.success AND s.source_ip IN (SELECT source_ip FROM attack_sources)
ORDER BY failures_before;

二要素目と回復手続： 対象アカウントがMFAを使っていたか、コードが要求・入力されたか、直前や直後にパスワード再設定、メールや電話番号の変更、窓口を介した回復があったかを確認します。
セッションとトークン： パスワード確認のないログイン（セッションCookieやアプリのリフレッシュトークンの再利用）を探します。これにはパスワードの再設定だけでなく、トークンの失効が必要です。

確認： 対象アカウントごとに、使い回しのパスワード、回避された二要素目、悪用された回復手続、盗まれたセッションのどれで侵入されたかが分かっていること（C09〜C12）。

3. 入口の封じ込め：顧客を締め出さずに波を遅らせる

アカウント、端末、接続元ごとのレート制限を組み合わせます。1つの軸だけでは、入れ替えで簡単に回避されます。
疑わしいログインには段階的に追加の確認を求めます。一律のロックは、攻撃者が正規の顧客を締め出す手段になります。
すべての経路を同時に守ります。攻撃者は数時間のうちに、最も守りの弱いエンドポイントへ移ります。

C13〜C16のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
C13. 正規の顧客を締め出さずに、アカウント・端末・接続元ごとに試行を制限できるか？	組み合わせた制限を適用し、誤検知の割合を監視する。	一律のロックではなく段階的な確認を使い、不足する対策を計画する。	ルールの変更、遮断・確認の件数、サポートへの苦情。	基盤／SRE＋プロダクト担当
C14. ログインとそのAPIに、ボット検知や追加の確認が適用されているか？	観測した攻撃の型に合わせて調整し、確認の結果をすべて記録する。	狙われた経路から確認を導入し、不足を記録する。	WAF・ボット対策のルール、確認の突破率、経路の網羅状況。	基盤／SRE
C15. Web、アプリ、API、提携先のログインなど、すべての経路が対策されているか？	経路ごとの対策状況を記録し、それぞれ試験する。	未対策の経路を先に塞ぐ。攻撃者はそこへ移る。	経路の一覧、対策の対応表、試験結果。	プロダクト担当＋基盤／SRE
C16. 攻撃者が手口を変えた後も、対策は機能しているか？	成功率の監視とルールの見直しを続ける。	新しい型に合わせて再調整し、成功が続けばエスカレーションする。	変更後の成功率、新しい接続元とユーザーエージェント。	SOC＋基盤／SRE

OWASPのCredential Stuffing Prevention Cheat Sheetは多層防御を勧めています。多要素認証、CAPTCHA、IPの緩和と情報活用、端末と接続の指紋、推測しにくいユーザー名、複数段階のログイン、ヘッドレスブラウザの遮断、段階的な機能制限、漏えいパスワードの検出、普段と異なるセキュリティ上の出来事の利用者への通知です。単独で決意の固い攻撃者を止める対策はないとされています。OWASPチートシート。

具体的な操作手順

入口でレート制限をかけます。 Cloudflareでは「Security」→「Security rules」→「Create rule」→「Rate limiting rules」。ログインのパス（例：http.request.uri.path eq "/login"、メソッドPOST）を条件にし、IPごとに数え、本物の顧客が届かないしきい値と期間を設定し、BlockかChallengeを選びます。無料プランでは期間10秒のルールを1つ作れ、有料プランではより多く作れます。Cloudflare：レート制限ルール
段階1で見つけたすべての経路に繰り返します。 特にモバイルAPIです。Webのページだけのルールでは、攻撃は止まらず別の経路に移ります。
アプリケーション側でアカウントごとの制限を加えます。 たとえば、1つのアカウントで15分間に数回失敗したら、ロックではなくチャレンジかワンタイムコードを求めます。
ロックではなくチャレンジにします。 不審なログイン（新しい端末、攻撃元のネットワーク、多数の失敗）にだけ確認を求め、通常のログインは通します。
攻撃者の適応を見張ります。 初日は1時間ごとに数値を確認します。攻撃者は数時間で経路、ユーザーエージェント、速度を変えます。

確認： すべての経路で試行回数が合意したしきい値を下回り、本物の顧客の成功ログインは平常に近いままであること（C13〜C16）。

4. アカウントの封じ込め：侵入された顧客を一人ずつ守る

強制再設定の前に、影響アカウントのセッションとアプリのトークンを失効させ、攻撃者のセッションを終わらせます。
攻撃者が完了できない確認を伴う再設定を求め、使い回しでない新しいパスワードを求めます。
アカウントの履歴をもとに、攻撃者が変更したメールアドレス、電話番号、配送先、出金先、多要素認証を元に戻します。

C17〜C20のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
C17. 影響アカウントのセッションとトークンを失効させたか？	攻撃者のセッションが失敗することを確認し、アカウントごとに時刻を記録する。	直ちに失効させる。パスワード再設定だけではセッションが残る場合がある。	セッション失効のログ、失効後の操作。	CIAM／IAM
C18. 攻撃者が通過できない確認を伴う再設定を、影響アカウントに求めたか？	完了状況を追跡し、完了できない顧客を支援する。	確認済みと可能性が高い乗っ取りに実施し、使った基準を記録する。	再設定の要求、完了率、確認方法。	CIAM／IAM＋カスタマーサポート
C19. 攻撃者がメールアドレス、電話番号、住所、出金先、多要素認証の設定を変更したか？	履歴から戻し、既知の連絡先で顧客に確認する。	確認した項目と監査の範囲を記録する。	プロフィールの変更履歴、変更前の値、顧客の確認。	カスタマーサポート＋CIAM／IAM
C20. 価値の移動を伴う操作を、影響アカウント、または全アカウントで保留すべきか？	ポイント利用、移行、出金を保留し、確認の待ち行列を設ける。	代わりにそれらの操作へ追加の確認を加え、重点的に監視する。	保留のルール、待ち行列の件数、顧客への影響。	不正対策チーム＋プロダクト担当

具体的な操作手順

まずセッションを終わらせます。 方法はアプリケーションによって異なります。よくある2つの方式です（名前は例です）。

-- Server-side sessions: delete them for the affected accounts
DELETE FROM sessions WHERE account_id IN (SELECT account_id FROM affected_accounts);

-- Signed tokens (JWT): raise a per-account version the server checks on every request
UPDATE accounts SET token_version = token_version + 1
WHERE id IN (SELECT account_id FROM affected_accounts);

モバイルアプリのリフレッシュトークンと「ログインしたままにする」のトークンも失効させます。

再設定の前に、攻撃者による変更を戻します。 アカウントの変更履歴を使い、元のメールアドレス、電話番号、配送先、払い出し先、MFAの設定に戻します。戻さないと、再設定の案内が攻撃者に届きます。
再設定を求めます。 次回ログイン時に新しいパスワードを必須にし、戻した連絡先か攻撃者には通れない確認で本人を確かめ、漏えいリストにあるパスワードを拒否します。
価値の移動を保留します。 顧客が再設定を終えるまで、これらのアカウントの交換、移転、払い出し先の変更を保留します。

確認： 同じ状態にしたテスト用アカウントで、古いセッションが使えなくなり、再設定の案内が元の連絡先に届くこと（C17〜C20）。

5. 不正と価値：奪われたものを止め、取り戻す

最初の疑わしいログイン以降の、影響アカウントからの価値の移動をすべて一覧にします。ポイント利用、移行、注文、ギフトカード、出金です。
提携先へ早く連絡します。他のプログラムへ交換されたポイントやギフトカードへの変換は、短時間なら止められる場合があります。
行き先を特定します。複数のアカウントで使われた配送先、受取アカウント、出金先は、同じ攻撃者を示します。

C21〜C24のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
C21. ポイント、残高、ギフトカードが利用または移行されたか？	取り消しまたは残高の回復を行い、案件ごとに記録する。	確認した移動を記録し、当面は保留のルールを維持する。	台帳、利用ログ、残高の履歴。	不正対策チーム＋決済／経理
C22. 注文が行われた、または保存された支払方法が使われたか？	キャンセルまたは出荷を止め、返金し、決済事業者に連絡する。	確認した注文を記録し、遅れて行われる注文を監視する。	注文履歴、配送先の変更、決済の記録。	決済／経理＋プロダクト担当
C23. ポイントが提携先のプログラムや他のサービスに交換されたか？	提携先に交換後の価値の凍結を依頼し、案件の詳細を共有する。	確認した提携先への交換を記録する。	交換ログ、提携先の案件番号、時刻。	提携先担当＋不正対策チーム
C24. 配送先、受取人、出金先などの行き先が、複数のアカウントで共通しているか？	その行き先を遮断し、提携先と、必要に応じて警察に報告する。	確認した行き先を記録する。	行き先の一覧、アカウントの関連、届出の記録。	不正対策チーム＋法務／プライバシー

具体的な操作手順

最初の不審なログイン以降の、対象アカウントからの価値の移動をすべて一覧にします。

SELECT t.account_id, t.event_time, t.type, t.amount, t.destination
FROM transactions t
JOIN affected_accounts a ON a.account_id = t.account_id
WHERE t.event_time >= a.first_suspicious_login
ORDER BY t.event_time;

すぐに提携先へ連絡します（下のテンプレート）。ポイント交換先、ギフトカード発行会社、決済事業者に、取引IDと時刻を伝え、完了前のものを止めるよう依頼します。

繰り返し現れる移転先を探します。 複数のアカウントから価値を受け取った配送先、受取口座、払い出し先、メールアドレスは、攻撃者の回収先です。

SELECT destination, count(DISTINCT account_id) AS accounts, sum(amount) AS total
FROM transactions
WHERE account_id IN (SELECT account_id FROM affected_accounts)
GROUP BY destination
HAVING count(DISTINCT account_id) > 1
ORDER BY accounts DESC;

それらの移転先を新しい取引で使えないようにし、 補償の判断のためにアカウントごとの損失を記録します。

確認： すべての価値の移動が、状態（停止済み、回収済み、損失）と担当者付きで一覧になっていること（C21〜C24）。

6. 個人データ：攻撃者が見られた情報を特定

ログインした顧客が閲覧・ダウンロードできる情報を一覧にします。氏名、住所、電話番号、注文履歴、カード情報の一部、書類です。
APIによる大量取得を確認します。セッションがあれば、プロフィールや注文のエンドポイントから大量に取得できる場合があります。
規模、データ項目、アクセスの証拠を法務／プライバシーに渡し、報告義務を判断できるようにします。

C25〜C28のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
C25. 攻撃者がアカウント内の個人データを閲覧またはダウンロードしたか？	データ項目とアカウント数を添えて法務／プライバシーに連絡する。	証拠を記録する。「ダウンロードなし」は閲覧がなかった証明ではない。	ページとAPIのアクセスログ、出力イベント、表示されるデータ項目。	法務／プライバシー＋SOC
C26. セッション中に、APIでデータが大量に取得されたか？	その型を遮断し、証拠を保全して取得されたレコードを特定する。	確認したAPIログとセッションの期間を記録する。	セッションごとのAPI要求数、エンドポイント、応答の大きさ。	基盤／SRE＋SOC
C27. 日本の個人情報保護法などで、報告対象になり得るか？	法務／プライバシーが定める期限内に、速報から報告する。	判断根拠を記録し、件数やデータ項目が変われば見直す。	法的評価、アカウント数、データ項目、最初に知った日。	法務／プライバシー
C28. ログインを共有する提携先（シングルサインオン、連携サービス）への連絡が必要か？	影響アカウントと期間を添えて連絡する。	確認した連携サービスを記録する。	SSOの利用先、連携アカウントの一覧、送付した連絡。	提携先担当＋法務／プライバシー

日本の個人情報保護法（参考）： 個人情報保護委員会の通則編ガイドラインは、不正に利用されると財産的被害が生じるおそれがある個人データの例として、送金や決済機能のあるWebサービスのログインIDとパスワードの組み合わせを挙げています。不正アクセスなど不正の目的をもって行われたおそれがある行為による漏えい等は人数にかかわらず報告対象で、本人の数が1,000人を超える場合もそれだけで報告対象です。乗っ取りがアカウント内に表示された情報の漏えいに当たるかは事案ごとの法的判断であり、法務／プライバシーが判断します。個人情報保護委員会通則編ガイドライン 3-5。

具体的な操作手順

ログインした顧客が見られるもの、ダウンロードできるものを一覧にします。 テスト用のユーザーでアカウントのページとアプリの画面をたどり、項目を書き出します（氏名、住所、電話番号、注文履歴、カード番号の一部、書類など）。
攻撃者が実際に開いたものを確認します。 攻撃者のセッション中の、プロフィール、住所、注文のページ閲覧やAPI呼び出しです。

大量収集を探します。 人の操作ではありえない頻度でプロフィールや注文のAPIを呼んでいるセッションです。

SELECT session_id, account_id, count(*) AS profile_calls
FROM api_requests
WHERE endpoint IN ('/api/v1/profile', '/api/v1/orders')
  AND session_id IN (SELECT session_id FROM attacker_sessions)
GROUP BY session_id, account_id
ORDER BY profile_calls DESC;

法務・個人情報の担当に3つの事実を渡します。 到達されたアカウント数、そこで見られる情報の項目、実際に閲覧されたとログが示すもの。日本では、決済機能のあるサービスのログインIDとパスワードや、不正アクセスなど不正の目的によるものは、人数にかかわらず個人情報保護委員会への報告が必要になりうる事態に含まれます。

確認： 法務・個人情報の担当が数字と証拠を文書で受け取り、報告についての判断を記録していること（C25〜C27）。

7. 連絡：顧客に取るべき行動を伝える

影響を受けた顧客に、経緯、実施した対応、取るべき行動を伝えます。他のサービスで使い回しているパスワードの変更も含めます。
サポートに想定問答と、話術では通過できない本人確認を準備します。
メールの告知にリンクを入れないようにします。アプリを開くか既知のアドレスを入力するよう案内し、告知をまねされないようにします。

C29〜C32のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
C29. 影響を受けた顧客に、明確な行動とともに通知したか？	送付と反応を追跡し、行動していない顧客に再度連絡する。	準備して送付する。遅れる場合は理由を記録する。	通知文、送付先一覧、送付・開封の記録。	広報＋プロダクト担当
C30. カスタマーサポートは想定問答と強い本人確認を準備できているか？	問い合わせ件数を監視し、ソーシャルエンジニアリングの疑いはエスカレーションする。	通知の送付前にサポートへ説明する。	想定問答、本人確認の手順、問い合わせの指標。	カスタマーサポート＋CIAM／IAM
C31. 規模、金額、顧客への影響から、公表が必要か？	事実、対応、助言を公表し、範囲が変われば更新する。	判断と根拠を記録する。	規模、不正額、法的評価、公表文の案。	広報＋法務／プライバシー
C32. 告知は、攻撃者がまねできるリンクを避けているか？	インシデント中の続報やキャンペーンでもこの規則を守る。	リンクを削除し、アプリまたは入力したアドレスへ誘導する。	告知のひな形、リンクの確認。	広報＋メールセキュリティ

具体的な操作手順

対象の顧客に通知します。 下のテンプレートで、何が起きたか、何をしたか、何をしてほしいかを伝えます。アプリ内やアカウントページとメールで送り、リンクは決して入れません。
顧客対応窓口に説明します。 下のスクリプトと、電話口の話術では通れない本人確認（戻した連絡先に送るコードなど）を渡します。
公表を検討します。 対象の顧客が多い場合、金銭的な損失がある場合、強制的な再設定など顧客から見える変化がある場合です。個別の通知と内容をそろえます。
ログインを共有する提携先に伝えます。 連携サービスやシングルサインオンの提携先が、不正利用を見張れるようにします。

確認： 通知の送信数が数えられ、窓口がスクリプトで対応しており、リンクを含む通知が1つもないこと（C28〜C32）。

8. 復旧：次の攻撃を失敗させる

登録、再設定、ログインの時点でパスワードを漏えいパスワードの一覧と照合し、レート制限を維持します。
パスキーやアプリによる認証など、より強いサインインを提供し、価値の移動には追加の確認を求めます。
多数の失敗後の成功や、新しい端末からの価値の移動を検知し続け、残るリスクを受け入れたうえでのみ終結します。

C33〜C36のはい・いいえ・不明の判断。証拠と担当は直後の表に記載。

独自の判断図。各分岐は独立して確認し、不明は未解決として管理します。

判断	はい	いいえ	証拠・不明時の確認先	主担当
C33. 登録、再設定、ログインで漏えいパスワードの照合を行っているか？	対象範囲と一覧の出典を記録し、定期的に見直す。	再設定と価値の高いアカウントから導入する。	照合の実装、一致率、一覧の更新日。	CIAM／IAM＋プロダクト担当
C34. より強いサインインを提供し、価値の高いアカウントに勧めているか？	利用率を追跡し、価値の移動に追加の確認を求める。	パスキーやアプリによる認証の導入を、期日と担当を決めて計画する。	利用率、追加確認のルール、計画。	プロダクト担当＋CIAM／IAM
C35. 多数の失敗後の成功や、新しい端末からの価値の移動を検知できるか？	アラート、担当、対応時間の目標を記録する。	終結の前に、それらのアラートを追加する。	アラートのルール、試験結果、当番への通知経路。	SOC＋不正対策チーム
C36. 残る不確実性を明示的に受け入れたうえで、責任者が終結できるか？	終結、監視期間、改善の期限を記録する。	未解決の分岐ごとに担当を付け、案件を継続する。	最終時系列、アカウント数と不正額、通知、承認。	責任者＋法務／プライバシー

NIST SP 800-63B-4は、選ばれたパスワードを、よく使われる、推測されやすい、または漏えいした値の一覧と照合すること、連続した認証の失敗回数を制限することを求めています。NIST SP 800-63B-4。

具体的な操作手順

登録・再設定・ログインの時点で、パスワードを漏えいリストと照合します。 Have I Been PwnedのPwned Passwordsの範囲検索APIを使うと、パスワードを送らずに確認できます。外部に出るのはSHA-1ハッシュ値の先頭5文字だけです。手動での簡単な確認例：
```
HASH=$(printf '%s' 'example-password' | sha1sum | awk '{print toupper($1)}')
curl -s "https://api.pwnedpasswords.com/range/${HASH:0:5}" | grep "^${HASH:5}:"
```
出力に行があれば、そのパスワードは漏えいリストに載っています。手作業ではなく、同じ確認をアプリケーションに組み込みます。
より強いサインインを提供します。 パスキーやアプリによる認証を、残高の多いアカウントから優先して勧め、価値の移動の前にはステップアップ認証を求めます。
検知を残します。 多数の失敗後の成功、1つの端末やネットワークからの多数のアカウント、新しい端末からのログイン直後の価値の移動に、アラートを設定します。
残存リスクを明記して閉じます。 たとえば、パスワードが攻撃者に知られているものの、まだ使われていないアカウントです。

確認： 既知の漏えいパスワードでのテスト登録が拒否され、多数の失敗後の成功を模したテストでアラートが上がること（C33〜C36）。OWASP：パスワードリスト型攻撃の防止

ハンティング：ログインに限定したKQLとSplunk

実際のIOCは掲載していません。 リスト型攻撃の接続元はすぐに入れ替わり、住宅用プロキシであることも多いため、IP一覧は誤解を招きます。3例とも読み取り専用で、文書・スキーマを照合したものです。実環境では実行していません。

顧客ログインのログは製品ごとに異なるため、例では仮のテーブル名を使います。KQLは、ログイン試行1件につき1行で、TimeGenerated、SrcIp、AccountId、Outcome（successまたはfailure）、UserAgentの列を想定しています。先にproject-renameや保存済み関数で列名を合わせてください。しきい値（20アカウント、50回の失敗、失敗と成功の比10:1）は出発点であり、通常の日と比べて調整します。dcountは推定値です。各例の表示上限は500件です。

1. 多数のアカウントを試した接続元： 接続元アドレスごとに試行をまとめ、多くのアカウントを試してほとんど失敗したものを抽出します。共有NAT、携帯回線、企業のプロキシも似た傾向を示すため、遮断の前に確認してください。1アドレスあたり1回しか試さない分散型の攻撃はここに現れません。ユーザーエージェント、端末の指紋、時間の傾向でもまとめてください。

2. それらの接続元からの成功： 同じ期間に多数のアカウントで失敗した接続元からの、成功したログインを一覧にします。それぞれを乗っ取りの候補として扱い、その後のセッションの操作（プロフィールの閲覧、連絡先の変更、ポイント利用、注文）を確認します。

3. Splunkで多数のアカウントを試した接続元： 対象のindexとsourcetypeで、CIMのAuthenticationの項目（action、user、src）を使います。actionがsuccessとfailureの値を取ること、userが社内のサービスアカウントではなく顧客の識別子であることを確認してください。

KQL：多数の顧客アカウントを試した接続元

customer-ato-sources.kqlをダウンロード

// Microsoft Sentinel / Log Analytics. Read-only; not live-tested.
// Sources that tried many customer accounts and mostly failed.
// Expects one row per attempt: TimeGenerated, SrcIp, AccountId, Outcome.
let Lookback = 24h;
let MinAccounts = 20;  // tune against a normal day
REPLACE_WITH_CUSTOMER_LOGIN_TABLE
| where TimeGenerated between (ago(Lookback) .. now())
| summarize Attempts = count(), Accounts = dcount(AccountId),
    Failures = countif(Outcome == "failure"), Successes = countif(Outcome == "success"),
    FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SrcIp
| where Accounts >= MinAccounts and Failures > Successes * 10
| order by Accounts desc
| take 500

KQL：それらの接続元からの成功したログイン

customer-ato-success-review.kqlをダウンロード

// Microsoft Sentinel / Log Analytics. Read-only; not live-tested.
// Successful logins from sources that also failed against many accounts.
let Lookback = 24h;
let Logins = REPLACE_WITH_CUSTOMER_LOGIN_TABLE
    | where TimeGenerated between (ago(Lookback) .. now());
let StuffingSources = Logins
    | summarize Accounts = dcount(AccountId), Failures = countif(Outcome == "failure") by SrcIp
    | where Accounts >= 20 and Failures >= 50
    | project SrcIp;
Logins
| where Outcome == "success"
| where SrcIp in (StuffingSources)
| project TimeGenerated, AccountId, SrcIp, UserAgent
| order by TimeGenerated asc
| take 500

Splunk：多数の顧客アカウントを試した接続元

customer-ato-sources.splをダウンロード

index="REPLACE_WITH_LOGIN_INDEX" sourcetype="REPLACE_WITH_LOGIN_SOURCETYPE" earliest=-24h latest=now
| stats count AS attempts dc(user) AS accounts count(eval(action="failure")) AS failures count(eval(action="success")) AS successes min(_time) AS first_seen max(_time) AS last_seen BY src
| where accounts>=20 AND failures>successes*10
| convert ctime(first_seen) ctime(last_seen)
| sort - accounts
| head 500

コピーして使えるテンプレート

［角かっこ］の部分をすべて置き換えてください。顧客向けのメッセージには、パスワードもリンクも入れないでください。顧客や一般に向けた文面は、法務または個人情報の担当者が確認します。

対象の顧客への通知

段階7で、アプリ内やアカウントページとメールで使います。

件名：【重要】お客様の［サービス名］アカウントの保護について

［お客様名］様

［日付］、お客様ご本人によるものではないと考えられるログインを、お客様のアカウントで確認しました。他のウェブサイトから漏えいしたパスワードが使われた可能性が高いと考えています。
当社の対応：すべての端末でアカウントからログアウトさせ、［メールアドレス／配送先／ポイントの変更を元に戻し］、新しいパスワードを設定いただくまで［ポイント交換を保留しています］。
お客様へのお願い：
1. ［サービス名］のアプリを開くか、ウェブサイトのアドレスを直接入力して、新しいパスワードを設定してください。他で使っているパスワードは使わないでください。
2. 同じパスワードを他のサービスでもお使いの場合は、そちらも変更してください。
3. 最近の注文とポイントの履歴をご確認ください。身に覚えのないものがあれば、下記までご連絡ください。
当社がメール、SMS、電話でパスワードをお尋ねすることはありません。また、このメッセージにはリンクを含めていません。
お問い合わせ先：［電話番号と受付時間］／［アプリからのお問い合わせ方法］
［会社名］

顧客対応窓口のスクリプト

段階7で、電話、チャット、メールの対応に使います。

最初に：「お問い合わせありがとうございます。他のウェブサイトから漏えいしたパスワードによってアカウントにアクセスされたお客様のご対応をしております。」
本人確認：［事案の前から登録されていた連絡先にコードを送る／決められた質問をする］。変更されたばかりのメールアドレスや電話番号を本人確認の根拠にしない。
対象のお客様の場合：
・アカウントがログアウトされ、保護されていることを伝える。
・パスワードの再設定を手伝い、他で使っていないパスワードを勧める。
・［日付］以降の注文とポイントを確認し、損失があれば［システム］に記録して確認に回す。
「御社のシステムがハッキングされたのか」と聞かれたら：「これまでの調査では、攻撃者は他のウェブサイトのパスワードを使っていました。新たに分かったことがあれば、お客様にお知らせします。」
してはいけないこと：パスワードを聞く、リンクを送る、［担当チーム］の確認前に返金を約束する。
次の場合は［チーム・チャンネル］にエスカレーション：本人確認ができない、価値の損失がある、当社からの通知が届いていないと言われた。

提携先への移転停止の依頼

段階5で、まず電話し、続けて書面で送ります。

件名：【至急】乗っ取られたアカウントからの不正な［ポイント交換／ギフトカード購入］の保留のお願い

［提携先 ご担当者］様

当社の［サービス名］に対するアカウント乗っ取り攻撃に対応しております。日本時間［開始時刻］から［終了時刻］の間に、攻撃者が乗っ取った顧客アカウントを使い、［貴社プログラムへのポイント交換／ギフトカードの購入］を行いました。
添付：対象の取引［件数］件（当社の取引ID、時刻、金額、移転先の識別子）
次の対応をお願いいたします。
1. 完了していない取引の保留または取消し。
2. すでに完了・使用済みとなった取引の特定。
3. 記載の移転先への、さらなる移転の監視。
本件の当社窓口は［氏名、電話、メール］で、［対応時間］に対応いたします。お手数ですが、受領のご連絡をお願いいたします。
［会社名・部署・氏名］

経営層向けの要約（5行）

1. 何が起きたか：［時刻］から［時刻］にかけて、［サービス名］にパスワードリスト型攻撃。［件数］のアカウントに対して［回数］回のログイン試行。
2. 乗っ取られたアカウント：［件数］件。セッションを終了し、パスワードを再設定済み。うち［件数］件で合計［金額］の価値が引き出された。
3. 現在の状態：［経路］にレート制限を適用。［高額の操作を保留中／○時に再開］。攻撃は［低い水準で継続中／停止］。
4. 必要な判断：［例：補償の方針、個人情報保護委員会への報告、公表、○日までのポイント交換の保留の継続］
5. 次回報告：［時刻］。責任者：［氏名］

具体例：ポイントサイトを襲った週末の攻撃

架空の事例です。会社、人物、時刻、数値はすべて創作で、判断のつながりを示すためのものです。

状況： 会員30万人の通販サイトで、ポイントをギフトコードに交換できます。土曜の夜、パスワードリスト型攻撃の波が始まります。

日曜7:30 アラート。 当番のエンジニアが、ポイント交換の多さに気づきます。クエリで、2:00以降に41万件のアカウント名に対して90万回のログイン試行があり、610件で成功していたことが分かります（C01、C05）。CTOがインシデント責任者になり、ログを書き出します（C04）。
7:50 分類。 610件の成功のうち92%が、1回目で正しいパスワードを使っていました。推測ではなく、使い回しのパスワードです（C09）。通信の大半は、レート制限のなかったモバイルAPIに向いていました（C06、C15）。
8:20 減速。 WebのログインとモバイルAPIにレート制限をかけます。40分以内に攻撃者は古いAPIのバージョンに移り、そこにも追加します（C13、C16）。
8:40 価値の保留。 責任者は、苦情が出ることを受け入れて、すべてのポイント交換を6時間止めます（C20）。
9:00 アカウントの保護。 610件のセッションとアプリのトークンを失効させます。37件ではメールアドレスが変えられていたため、元に戻してから再設定を求めます（C17〜C19）。
9:30 価値の追跡。 85件のアカウントで、合計210万円分のポイントがギフトコードに交換されていました。ギフトコードの提携先が、未使用の41件を取り消します（C21、C23）。多数のアカウントからコードを受け取っていた3つのメールアドレスを遮断します（C24）。
日曜午後データ。 アカウントでは氏名、住所、電話番号、注文履歴が見られます。大量収集は見つかりません（C25、C26）。IDとパスワードで価値のある残高を使え、ログインは不正アクセスだったため、法務は個人情報保護委員会への報告が必要と判断し、火曜に速報を出します（C27）。
月曜顧客対応。 リンクを含まない通知を、アプリ内とメールで610人に送ります。窓口はスクリプトで対応します（C29、C30、C32）。失われたポイントの補償が承認されます。
2週間後再発防止。 漏えいパスワードの確認、会員向けのパスキー、交換前のステップアップ認証が稼働し、多数の失敗後の成功をアラートで監視します（C33〜C35）。責任者は、さらに多くの顧客のパスワードが攻撃者のリストにある可能性を受け入れて案件を閉じます（C36）。

分かれ目になったこと： 試行ではなく成功を数えたこと。同じ朝のうちにモバイルAPIと古いAPIまで対象にしたこと。早めにポイント交換を止め、被害を85件にとどめたこと。

未解決事項と事後の改善

乗っ取りの攻撃には、明確な境界が残りにくいものです。攻撃者がまだ使っていない認証情報、アカウントが転売されたか、記録されない画面で何が閲覧されたかは分からない場合があります。これらを明記し、合意した期間は監視を強化します。すべての行を埋めても、網羅の保証にはなりません。

終結時は、異常に気付くまでの時間、ログや対策が欠けていたログイン経路、締め出された正規の顧客の数、価値の移動を止めるまでの時間を振り返ります。答えを担当と期限に落とし込み、検証環境のログインに対する演習で確認してください。

参考資料と更新履歴

以下は2026-10-06に確認した資料です。製品・ライセンス・ログ構成が変わるため、実行前に自環境の仕様を確認してください。

2026-10-06：初版。 EN／日本語の判断IDとクエリを一致させて公開。

30秒でわかる要点

顧客はパスワードを使い回し、攻撃者はそれを当てにする

まずここから：最初の1時間

事前準備と判断ルール

この手順で使う言葉

セキュリティ担当がいない場合の役割分担

0. 初動：試行と乗っ取りを区別する

具体的な操作手順

1. 攻撃の型：何がログインを狙っているかを把握

具体的な操作手順

2. 侵入経路：ログインが成功した理由を特定

具体的な操作手順

3. 入口の封じ込め：顧客を締め出さずに波を遅らせる

具体的な操作手順

4. アカウントの封じ込め：侵入された顧客を一人ずつ守る

具体的な操作手順

5. 不正と価値：奪われたものを止め、取り戻す

具体的な操作手順

6. 個人データ：攻撃者が見られた情報を特定

具体的な操作手順

7. 連絡：顧客に取るべき行動を伝える

具体的な操作手順

8. 復旧：次の攻撃を失敗させる

具体的な操作手順

ハンティング：ログインに限定したKQLとSplunk

KQL：多数の顧客アカウントを試した接続元

KQL：それらの接続元からの成功したログイン

Splunk：多数の顧客アカウントを試した接続元

コピーして使えるテンプレート

対象の顧客への通知

顧客対応窓口のスクリプト

提携先への移転停止の依頼

経営層向けの要約（5行）

具体例：ポイントサイトを襲った週末の攻撃

未解決事項と事後の改善

参考資料と更新履歴