アラートは「何かが起きた」という通知にすぎません。「本当に攻撃なのか」「何をされたのか」を判断するには、アラートの前後に何が起きていたかを調査する必要があります。今回はTimelineを使って、ポートスキャンから始まりデータ持ち出しで終わる一連の攻撃を5つのフェーズに分けて追います。
シリーズの前の回
この記事を読むと何ができるか
- Timelineを使ってアラートと生イベントをまとめて調査できる
source.ip→user.name→destination.ipの順でピボットしながら攻撃の流れを追える- このサンプルデータ（１回目のブログからダウンロードできます）で起きた攻撃を5つのフェーズで説明できる
※第1・2回を読んでいることを前提にしています。
Timelineを開く
Elastic Security の Timeline は、複数のイベントを時系列で並べ、相互に関連付けながら調査できる、インタラクティブなワークスペースです。
手順：
- Security → Alerts を開き、時間範囲を「Last 2 years」にします
source.ip: 192.168.1.100に対応するアラート行（user.name: admin_root、host.name: PROD-SRV-01）を探します- アクションアイコンから 「Investigate in timeline」 をクリックします
Alert detailsのフライアウトからも同じ操作が可能です。フライアウト右下の「Investigate in timeline」ボタンを使うと、アラートのコンテキストを引き継いだ状態でTimelineが開きます。
最初の絞り込み
Timelineを開いたら、まず query builder で以下のフィルターを設定します。
host.name:"PROD-SRV-01" and source.ip:"192.168.1.100"
次に _id（1件1件のログに付く一意のID）を列から削除して表示を整理します。
画面左側のフィールドリストからフィールド名をクリックして列として追加します。追うべきフィールドは以下の通りです。
| フィールド | 何を見るか |
|---|---|
@timestamp | いつ起きたか |
event.action | 何をしたか |
event.outcome | 成功か失敗か |
user.name | 誰として動いたか |
process.name | どのプロセスが実行されたか |
source.ip | どこから来たか |
destination.ip | どこへ出たか |
destination.port | どのポートへ |
network.bytes | 何バイト転送したか |
rule.name | どのルールで検知されたか |
@timestampを古いから新しい方にソートします。
rule.name が空欄のイベントは「通常のログ（生イベント）」です。攻撃チェーンは検知されたイベントだけでは完成しません。その間にある生イベントも含めて読むことで、初めて全体像が見えます。
補足：なぜ user.name:"admin_root" で絞り込まないのか
ポートスキャン段階（UTC 10:01台）の connection-attempt イベントには user.name が入っていません。user.name で絞ると攻撃の最初のフェーズが見えなくなります。
攻撃の流れを読む：5つのフェーズ
このサンプルデータには、教科書的な攻撃の5つのフェーズがすべて含まれています。各フェーズの詳細を順番に見ていきます。
フェーズ1：偵察（UTC 10:01:05〜10:01:35）
event.action: connection-attempt
event.outcome: failure
rule.name: Port Scan Detected192.168.1.100 から 172.16.0.1 に向けて、ポート445・139・80・3389・22への接続試行失敗が30秒間に5件並びます。接続が拒否されてもそれ自体が情報になります。どのサービスが動いているかがわかれば、次のステップを選べます。
| UTC | destination.port | event.outcome |
|---|---|---|
| 10:01:05 | 445（SMB） | failure |
| 10:01:06 | 139（NetBIOS） | failure |
| 10:01:07 | 80（HTTP） | failure |
| 10:01:20 | 3389（RDP） | failure |
| 10:01:35 | 22（SSH） | failure |
フェーズ2：初期アクセス（UTC 10:03:00〜10:03:06）
event.action: user-login
rule.name: Brute Force Attempt → Brute Force Success
わずか6秒の間に、ログイン失敗4件とログイン成功1件が連続します。
| UTC | user.name | event.outcome |
|---|---|---|
| 10:03:00 | admin_root | failure |
| 10:03:02 | admin_root | failure |
| 10:03:04 | admin_root | failure |
| 10:03:05 | administrator | failure |
| 10:03:06 | admin_root | success |
「失敗の連続 → 突然の成功」というパターンは、ブルートフォース攻撃の典型的な痕跡です。
見落としやすいポイント：10:03:06の成功イベントにはルール名が入っていますが、もしこのルールが存在しなかった場合、Alertsテーブルには失敗のアラートしか表示されません。ログイン成功は「異常ではない」として見落とされやすく、これが侵入を気づかれにくくする要因の1つです。
フェーズ3：権限確認（UTC 10:03:30〜10:04:30）
event.action: process-created
rule.name: Suspicious CMD Execution, Domain Enumeration, Privilege Enumeration
ログイン成功の直後、admin_root として3つのプロセスが連続して実行されます。
| UTC | process.name | process.command_line | 意味 |
|---|---|---|---|
| 10:03:30 | cmd.exe | cmd.exe /c whoami && ipconfig /all | 自分が誰か・どの環境かを確認 |
| 10:04:00 | net.exe | net user /domain | ドメインユーザー一覧を取得 |
| 10:04:30 | net.exe | net localgroup administrators | 管理者グループのメンバーを確認 |
「どの権限で入れたか」「他にどんなユーザーがいるか」を把握することで、次の行動を計画します。
フェーズ4：永続化（UTC 10:05:00〜10:07:30）
event.action: process-created
rule.name: Scheduled Task Created, Suspicious PowerShell Encoded Command, Registry Persistence
| UTC | process.name | 意味 |
|---|---|---|
| 10:05:00 | schtasks.exe | スケジュールタスクを作成（再起動後も実行され続ける仕掛け） |
| 10:06:00 | powershell.exe | Base64エンコードされたコマンドを実行（内容を難読化して検知を回避） |
| 10:07:30 | reg.exe | レジストリのRunキーに追記（ログイン時に自動実行される仕掛け） |
この段階は「侵入後に居続けるための準備」です。Base64でコマンドを難読化しているのは、シグネチャベースの検知ツールの目をくらませる典型的な手口です。
「永続化」とは：攻撃者が「1回侵入できた」だけで終わらせず、再起動後やパスワード変更後にも再び接続できる状態を作ることです。スケジュールタスク・レジストリRunキー・サービスの登録などがよく使われます。
フェーズ5：データ持ち出し（UTC 10:06:30〜10:10:00）
event.action: connected, data-transfer
rule.name: C2 Connection Attempt, Large Data Exfiltration
| UTC | event.action | destination.ip | network.bytes | 意味 |
|---|---|---|---|---|
| 10:06:30 | connected | 103.10.10.100:443 | 512 | 外部サーバーへの接続確立（C2通信） |
| 10:09:45 | process-created | — | — | Compress-Archiveでデータを圧縮・準備 |
| 10:10:00 | data-transfer | 103.10.10.100 | 85,000,000 | 85MBのデータを外部へ送信 |
「接続確立 → データ圧縮・準備 → 大量送信」という順番がTimelineで一目でわかります。
443番ポートへの通信が見逃されやすい理由：443番ポートはHTTPSの標準ポートです。多くのファイアウォールは443番を業務上の正常通信として許可しているため、C2通信はこのポートを意図的に使うことがあります。ポート番号だけで判断せず、接続先IPアドレスが既知サーバーかどうかも確認することが重要です。
ピボットで視点を切り替える
Timelineの強みは「見つけた値をその場で次の絞り込みに使える」ことです。攻撃者の行動（user.name）から外部への通信（destination.ip）という流れに沿って、以下の順でピボットすることで調査が深まります。
ピボット1：user.name で絞り込む（侵害アカウントの視点）
host.name:"PROD-SRV-01" and user.name:"admin_root"
攻撃者が admin_root でログインした後、どのプロセスを実行し、どこへ通信したかが一本線で見えます。「侵入後に何をされたか」を把握したいときに有効です。
ピボット2：destination.ip で絞り込む（外部通信の視点）
destination.ip:"103.10.10.100"
source.ip の条件を取り除き、外部サーバーへの通信だけを見ます。「いつ・どのユーザーが・何バイト送ったか」が圧縮されて表示されます。
この章のまとめ
- Timelineはアラートと生イベントをまとめて追う調査画面である
rule.nameが空のイベント（生ログ）も含めて読むことで、攻撃の全体像が見えるsource.ip→user.name→destination.ipの順でピボットすると、攻撃を立体的に理解できる- このデータの攻撃は「ポートスキャン → ブルートフォース → 権限確認 → 永続化 → データ持ち出し」の5フェーズで構成されている
- アラートだけでは攻撃の全体像は見えない。アラートは「調査の入口」である
第3回チェックリスト
- [ ] Timelineを
source.ip: 192.168.1.100で絞り込み、5つのフェーズが時系列で見えている - [ ]
user.name: admin_rootでピボットし、侵入後の活動が追えている - [ ]
destination.ip: 103.10.10.100でピボットし、C2通信と持ち出しの流れが見えている - [ ] 攻撃の流れを自分の言葉で5フェーズに整理して説明できる
次回は： EQLのsequenceで攻撃パターンを自動検出し、ES|QLで「どのIPが最も危険か」を数値で把握する方法を紹介します。目でログを追う調査の次のステップです。
