【ログ解析編】Sysmon・auditd・Event Logを横断して攻撃を見抜く|CTF思考フレームワーク #45
広告・PRを含みます。この記事にはアフィリエイトリンクが含まれます。掲載内容は編集方針に基づいて作成していますが、価格・在庫・キャンペーン内容はリンク先で最新情報を確認してください。

ログ解析って…数百万行のログから攻撃者を見つけるって、どうやるの?📋

WindowsならSysmon・Event Log、Linuxならauditd・syslog。攻撃者のTTPs(手口)と対応するイベントID(例:EID 4624=ログオン、4688=プロセス起動)を知っていれば、関連イベントを横断して攻撃のタイムラインが再構築できます。
ログ解析は、攻撃の痕跡を時系列で再構築する核心スキル。Sysmon Event ID(プロセス・ネット・レジストリ)、auditd(ファイル・コマンド)、Event Log(認証・サービス)、Webアクセスログ――これらを横断的に追いかけると、攻撃者の動きが浮かび上がります。

数百万行を全部見るの…?さすがに無理だよ。
この記事は、CTF思考フレームワーク第45回。ログ解析の基本(Sysmon・auditd・Event Log)と、SIEM(Splunk・Elastic)での横断検索、攻撃の典型パターンを見抜くクエリ例、初心者向けの学習ロードマップを整理します。
📖 この記事はシリーズの一部です
「CTF思考フレームワーク」 #45 / 全86記事 → シリーズ一覧を見る →
📜 「ログは嘘をつかない」。…と思いきや、攻撃者は最後にログを消したり書き換えたり。Sysmon / auditd / Event Logを多層に置き、SIEMで突き合わせて初めて真実が組み上がります。
ログ解析の核心は「単一ソースを信じない」「時系列を揃える」「コンテキストで読む」。プロセス起動・ファイル操作・認証・ネットワーク、4軸を並べたとき初めて攻撃ストーリーが見えます。
Sysmon・auditd・Event Logを横断して攻撃を見抜きます📋

ログ解析は「点のログを線にする」のがコツ。1イベントだけでは何も分からない📋
先に意味を押さえておくと読みやすい用語です。
- CTF: セキュリティの練習問題を解く競技。必ず許可された環境だけで試します。
- 横展開: 侵入後に別の端末やサーバーへ移動して被害範囲を広げる動きです。
- フォレンジック: ログや端末の痕跡から、何が起きたかを調べる作業です。
👀 観察フェーズ:まず何を見る?

まずどのログが取れる構成か確認!EDRログ・Windows Event・Sysmon・auditd・プロキシ・FW…🔍
インシデント時にまず確認するログの優先順位:認証→プロセス起動→ファイル操作→ネットワーク。Sysmon EID 1(プロセス起動)は常に第一参照。

Killchainのフェーズごとに必要なログ種別が違うんだね💡
- Windows: Security(4624/4625/4672/4688)+ Sysmon(1/3/7/10/11/12/13)
- Linux: auditd(execve/connect/openat)+ journald + bash_history
- PowerShell: ScriptBlockLogging(4104)・ModuleLogging(4103)
- Web: アクセスログ・WAFログ・アプリログ
- クラウド: CloudTrail(AWS)/ Activity Log(Azure)/ Audit Log(GCP)
- 集約: SIEM(Splunk / Elastic / Sentinel)

ログ解析の典型は4方向。
🤔 仮説フェーズ:攻撃者は何を考える?
🪟 仮説①:認証ログ
Event ID 4624(成功) / 4625(失敗) / 4672(特権)を時系列で。不審なType 3(ネットワーク)に注目。
📜 仮説②:プロセス起動
Sysmon Event ID 1で親子関係・コマンドライン・ハッシュ。Office→PowerShellは黒に近い。
🌐 仮説③:ネットワーク接続
Sysmon Event ID 3でプロセス→外部IPの紐付け。非標準プロセスの直接通信が要注意。
🔁 仮説④:永続化アイテム
Event ID 4698(タスク)、7045(サービス作成)、Sysmon 12-14(レジストリ)で居座りの仕掛けを検出。
🕶️ 攻撃者は「ログを消す」だけでなく「ノイズで紛らわす」「ログから外す」も使います。LOLBins経由の正規プロセスチェーン、PowerShell v2へのダウングレード、ETW無効化。逆に防御側はSysmon EID 7(Image Load)でAMSI Bypass DLLを検知、4104の難読化文字列をパターンマッチ。

ログは「相関」で価値が出る。単体では雑音、繋ぐと真実になる💡
🔬 検証フェーズ:どうやって確かめる?

ELK / Splunk / Microsoft Sentinelに集約→時系列の相関ルールで検知。MITRE ATT&CKマッピングも有効🧪
SIEM上でクエリを書きながら、Sigmaルールを適用するのが現代の流儀。攻撃シナリオごとにテンプレ化したルールがGitHub上で共有されています。

Sigmaルールを使えばSIEM横断のルール定義ができるんだね💡
# Splunk例:怪しい親子関係(Office→PowerShell)
index=sysmon EventCode=1 ParentImage="*\WINWORD.EXE" Image="*\powershell.exe"
# Elastic KQL例:LOLBin certutil + URL
event.code:1 and process.name:"certutil.exe" and process.command_line:*http*
# Sigmaルール(YAML)
title: Suspicious certutil download
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith: '\certutil.exe'
CommandLine|contains: 'http'
condition: selection

ログで暴く攻撃トップ3。
⚔️ 攻撃フェーズ:実際の手口
メール→Office文書→powershell.exe→外部接続、をSysmon ID 1+3で繋ぐ。
4624 Type 3 + LogonProcess=NtLmSsp + AuthPkg=NTLM + 異なるサーバを跨ぐパターンがPtH典型。
4769(TGS要求)が短時間に大量、暗号タイプRC4で複数SPN宛。古典的サイン。
攻撃者の典型的な”見えにくい”挙動:①Office文書からのマクロ→PowerShell、②正規RDPセッション内の悪意操作、③Service Account乱用、④Scheduled Task経由の遅延実行。
# 親子関係チェック(プロセスチェーン)
# WINWORD.EXE → cmd.exe → powershell.exe → certutil.exe
# のような連鎖が出たらほぼ確定
# RDP後の異常検知
# 4624 Type=10 (RemoteInteractive) + その後の不審プロセス起動
PowerShell ScriptBlockLogging(4104)は難読化されたスクリプトもデコード後の中身が記録されるので、Invoke-Mimikatzなどはバレバレです✨

ログ解析を活かす3つ!🛡️
🛡️ 防御フェーズ:どう守る?
OS標準ログだけでは穴だらけ。Sysmon(Win)・auditd(Linux)で詳細イベントを取得。
Windows Event Forwarding / fluentd / vectorでSIEMに即時転送。攻撃者が消す前に外に出す。
SigmaやAtomic Red Teamで既知攻撃を網羅。新規TTPは脅威インテリで補強。

「取って・送って・見る」の3点セットで初めてログは意味を持つ💪
ログ運用の鉄則は「網羅・転送・長期保存・検索可能」。エンドポイントで取得→即時転送→SIEMで集中分析。ローカルログだけは絶対に頼らない。
- Sysmon設定はSwiftOnSecurity / Olaf Hartongのテンプレ採用
- Windows Event Forwarding(WEF)で集約
- Linuxはauditdに加えlaurelでJSON化+転送
- PowerShell Logging全有効(ScriptBlock + Module + Transcription)
- SIEM保管期間 最低90日(PCI-DSSは1年)
- Sigmaルール継続更新、Detection-as-Code化
🛡️ 今日からできる対策ツール
フォレンジックと同じくらい大事なのが「そもそも侵入されない」こと。🛡️ ソースネクストのセキュリティツールなら、買い切りで使えるタイプも多いので、「サブスク疲れ」している人に人気です。
※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。
⚠️ よくある落とし穴
- Security Event Logだけ見てSysmonを入れない
- PowerShell v5を有効化したまま、v2を残してダウングレードを許す
- 4624のLogonType 10(RDP)と 3(Network)を区別しない
- auditdをデフォルト設定のまま運用してexecveを取り損ねる
- SIEMコストを理由にログ保管期間を短縮しすぎる
- クラウドアクセスログ(CloudTrail等)を「監査用」と捉え検知に使わない
🧰 ツール早見表
| ツール | 用途 | 備考 |
|---|---|---|
| Sysmon | Windows詳細イベント収集 | 12種以上のEID |
| auditd + laurel | Linux監査ログ | JSON化で取り回し向上 |
| Sigma | 汎用検知ルール記法 | SIEM横断で再利用可能 |
| Splunk / Elastic / Sentinel | SIEM | 分析・アラート・ダッシュボード |
| Velociraptor | IRエージェント | VQLでログをライブ収集 |
🎓 本気で学びたい人へ
インシデントレスポンスやフォレンジックを職業として目指したい方へ。🎓 ササエルはインフラとセキュリティの両輪で学べるスクールです。
📚 もっと深く学びたい人へ
実際に手を動かして攻撃手法を体で覚えたいなら『7日間でハッキングをはじめる本 TryHackMe』がおすすめ📚
📚 次に読みたい
- ネットワークForensics編|CTF思考フレームワーク #44
- ステガノグラフィ編|CTF思考フレームワーク #46
- メモリForensics編|CTF思考フレームワーク #43
- ファイルカービング編|CTF思考フレームワーク #47
✍️ 学んだことを発信する
検証記録やレポートをオンラインでまとめるなら、ConoHa WINGのWordPressが手軽で便利です。
⚖️ 大事なお約束
この記事の手法は、必ず自分の環境か、許可されたCTF・脆弱性報奨金プログラム(HackerOne、Bugcrowd等)で試してください。他人のサービスに無断で攻撃を仕掛けるのは不正アクセス禁止法違反、立派な犯罪です。学んだ知識は守る側で活かしましょう🤝



