フィッシングが成功したら？ログで追うアカウント乗っ取り
フィッシング成功後も、流出したパスワードは使われ続けます。zcrLogのThreat Incidentsの読み方とAccount Takeoverの兆候、対応の要点を解説します。
社員がメールを開き、見慣れたシステムのロゴを目にして、リンクをクリックし、URLが1文字違うことに気づかないままパスワードを入力する——それだけでフィッシングは成功してしまいます。ただ、多くの組織が意外と聞かない質問があります。「それで、その後は？」流出したパスワードは攻撃者の受信箱で終わりません。実際のログイン画面で試されることになります。そしてセキュリティチームが本当に注目すべきなのは、検知が難しい発信元メールそのものではなく、その後に続くAccount Takeover（アカウント乗っ取り）の兆候です。これは実際にログの中で捉えることができます。
「フィッシング」はログが直接見られるIncident Typeではない
一般的なSIEMには「フィッシングを検知」というボタンはありません。だましのプロセスそのものは、被害者のメールクライアントやブラウザという、システムの外側で起きているからです。ログとして記録・検証できるイベントになるのはそのあとです。ログが実際に捉えるのは、パスワードが流出したあとの挙動です——繰り返しのパスワード推測・総当たり（brute force）、侵入後の権限昇格（privilege escalation）、他端末への横展開（lateral movement）、そしてデータの持ち出し（data exfiltration）です。
実際に、zcrLogのデモ環境で、Threat IncidentsとDetection Rulesの画面を見ながら、こうした各段階がどう現れるのかを確認してみました。以下に出てくるのは実際の顧客インシデントではありません。例を挙げる箇所はどれも仮定の話で、お伝えしたいのは、画面の読み方と、各シグナルが何を意味するのかです。（zcrLogの詳細はこちら — ライブデモにはデモ用ログイン（demo / demo）が必要です。）
Threat Incidentsテーブルの読み方
Threat Analysis > Threat Incidents ページには、インシデントが1行に1件ずつ並びます。乗っ取りの兆候を探すとき、特に役立つのは次のカラムです。
- Type — インシデントの種類です。たとえば
brute_force、privilege_escalation、lateral_movement、data_exfiltrationなどがあります。
- Status — インシデントの状況です。たとえば、開いているか、閉じているかがわかります。
- Threats — そのインシデントがまとめている下位シグナルの数です。
- Username — そのインシデントに関わるアカウントです（ログにアカウント名が含まれている場合）。同じアカウントが複数のインシデントに現れていれば、そこがたどるべき糸口です。
- Source IPとDestination IP — アクティビティがどこから来て、どこに着いたかを示します。詳しくは次のセクションで触れます。
仮定のケースで、これらのカラムをあわせて読んでみます。brute_forceのインシデントに1つのアカウントが挙がっていて、Sourceは社外のアドレス、Destinationは社内のシステムだとします。これがパスワード推測の段階です。そのあと同じUsernameがprivilege_escalationのインシデントにも現れたなら、推測が成功した可能性があり、誰かがそのアカウントに本来ない権限まで取ろうとしていることになります。さらにそのアカウントでlateral_movementのインシデントが出れば、他のマシンへ手を伸ばしているということです。どれか1つだけでは、決め手にはなりません。同じアカウントがこの順番でTypeを進んでいくなら、乗っ取りではないと確認できるまでは、乗っ取りとして扱うべきパターンです。
テーブルのインシデントには、MITRE ATT&CKのタグが付くこともあります。MITREのフレームワークでは、T1110（Brute Force）はパスワード推測にあたるTechniqueで、TA0006（Credential Access）のTacticに分類されます。T1021（Remote Services）は他のマシンへ広がっていくための手口で、TA0008（Lateral Movement）のTacticに分類されます。アカウント乗っ取りそのものを最も直接的に表すTechniqueはT1078（Valid Accounts）です。攻撃者は無理に破って入るのではなく、正規の認証情報でログインしてきます。ただし、ATT&CKのタグが示すのはTacticやTechniqueの名前であって、それが実際に起きた証拠ではありません。タグを頼りにする前に、その裏にあるイベントを確認してください。
Source IP → Destination IPの読み方
Source IPとDestination IPは、どちらか片方のアドレスではなく、ペアで読みます。見るべきパターンは、外部の公開アドレスに見えるSource IPが、組織内部のネットワーク（10.x.x.x、172.16～172.31.x.x、192.168.x.xといったRFC1918のプライベートアドレス範囲）にあるDestination IPとペアになっているものです。実際の乗っ取りの典型的な流れとも合っています。フィッシングで流出したパスワードを持つ攻撃者は、たいてい組織の外部からログインし、アクセスできた瞬間に内部リソースへ向かおうとします。
注意点が2つあります。外部のSourceアドレスは、在宅勤務や出張中の社員のアクセスも同じように見えるため、アドレスだけでは誰がログインしているのかはわかりません。ペアだけで決めつけず、UsernameやインシデントのTypeなどで裏づける必要があります。また、両方のアドレスが社内のものというペアは、外から入ってくる段階ではなく、すでに侵入した攻撃者が内部で動き回っている段階を指している場合があります。ただしVPN経由のログインも社内アドレスに見えることがあるため、それだけでどちらとも決められません。
IPのペアを、同じ行のアカウントやインシデントのTypeとあわせて見ると、ログを1行ずつ追うのとはまったく違う全体像が見えてきます。その突き合わせを自動でやるために設計されているのが、zcrLogがログを収集し、こうした挙動を1つのビュー・1つのテーブルにつなげて見せる仕組みです。SOCチームがファイルごとに手動でCorrelateする必要がなくなります。
フィッシング成功後の挙動をカバーするRule
zcrLogのDetection Rules Management > Rule Templates ページには、すぐ使えるDetection Ruleがテンプレートとして並んでいます。たとえばBrute Force (SSH)、Privilege Escalation、Anomalous Login Locationなどです。
このうちAccount Takeoverに最も直結するのはAnomalous Login Locationです。これは、同じアカウントがそのアカウントの通常の挙動と比べて不自然な場所からログインした際のシグナルを検知するRuleで、フィッシング成功後にセッションが乗っ取られた際の典型的な兆候です。Brute Force (SSH)は、SSHに対するパスワード推測の段階に、Privilege Escalationはログインが通ったあとの段階に当てはまります。どのRuleを頼りにするにせよ、そのRuleが有効（Active）になっていることを確認してください。動いていないRuleは何も検知しません。
MFAだけでは足りない理由
MFAは、単純なパスワード流出の問題をかなり減らしてくれます。ただし、最近の多くのフィッシングキットはAdversary-in-the-Middle型で、本物のログイン画面をそのままプロキシし、MFAを通過した直後のセッショントークンを盗みます。つまりMFAだけでは万全な防壁にはならず、ログイン成功後の異常な挙動を検知する層——上で触れたAnomalous Login Locationのような仕組み——を重ねる必要があります。
フィッシングで流出したパスワードは、組織内部のシステムだけでなく、公開されているログインページに対しても繰り返し試されることがよくあります。この点はフィッシング後のCredential Stuffingについての記事で詳しく解説しており、なぜ組織内部で待ち構えるだけでなく、公開Webページという入り口側でブロックできることが重要なのかを説明しています。
シグナルを検知したら自動で対応する
Ruleがトリガーされた次のステップで重要なのは、誰が何のボタンを押すかであって、「システムがアラートを出した」で終わりではありません。重要なポイントでHuman Approval（人による承認）を挟んだ自動対応フローの組み立て方は、すべて手作業にしないためのフィッシング対応Playbookで詳しく解説しています。また、上で触れたTA0006やT1110のようなTactic/Techniqueが具体的に何を指すのか知りたい方は、MITRE ATT&CKとは何かを参考にしてください。
フィッシング発生後に見るべきシグナルまとめ
| 挙動シグナル | ログ上のIncident Type | 何がわかるか |
|---|
| 繰り返しのパスワード推測・総当たり | brute_force | 誰かがアカウントに対してパスワードを試しています。フィッシングで流出したパスワードかもしれません |
| 侵入後の権限昇格 | privilege_escalation | 中に入った誰かが、そのアカウントに本来ない権限まで取ろうとしています |
| 他端末・他システムへの横展開 | lateral_movement | そのアカウントが、他のマシンやシステムへ手を伸ばすのに使われています |
| システムからのデータ持ち出し | data_exfiltration | 後半の段階です。データがシステムの外へ出ていっています |
これらのシグナルを1つのビューにつなげて見せる仕組みを持たない組織は、たいていAccount Takeoverに気づくのが手遅れになったタイミングです——まだパスワード推測（brute_force）の段階で、対処がずっと簡単だったはずなのに、実際にデータが流出（data_exfiltration）してから初めて気づくことになります。
zcrLogの全パッケージと料金を見る →
出典
- Microsoft Security Blog — From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud — MFA通過後にセッションCookieを盗むAdversary-in-the-Middleフィッシングの仕組みを確認。これによりMFAを完全に回避できることを示す
- MITRE ATT&CK — T1078 Valid Accounts、T1110 Brute Force、T1021 Remote Services — 本文全体で参照しているTechniqueの定義
自社がこうしたシグナルをどれくらい早く見つけられるか、知りたくありませんか？
お気軽にご相談ください。無料でご相談いただけます。