こんにちは！セキュリティやインフラの現場に飛び込んだばかりの頃は、専門用語の嵐に圧倒されてしまいますよね。「メモリフォレンジック」とか「インシデントレスポンス」なんて聞くと、なんだかSF映画のハッカーみたいで自分には関係ない……と思ってしまうかもしれませんが、大丈夫です！一歩ずつ、身近な例えから紐解いていきましょう。
今回は、サイバー攻撃者が忍び込んだ足跡を追いかける、ちょっとスリリングで大切な技術「Windowsイベントログとメモリ情報の相関分析」についてお話しします。
—
1. 家の防犯カメラと「記憶のノート」で例えるセキュリティ
突然ですが、みなさんの自宅マンションを想像してみてください。
エントランスには防犯カメラがあって、誰がいつマンションに出入りしたのかが「映像（ログ）」として記録されていますよね。これがWindowsの世界でいう「セキュリティイベントログ（Event ID 4688など）」です。誰が何時にどのドアを開けたかという、公式な「出入りの記録」になります。
では、もし泥棒が合い鍵を使わずに、ベランダからこっそり侵入して、部屋の中でこっそり物を物色していたとしたらどうでしょう？
エントランスの防犯カメラ（イベントログ）には「怪しい侵入」として綺麗に映らないかもしれません。なぜなら、攻撃者はログの記録を巧みに書き換えたり、そもそも足跡を残さないようにシステムを騙したりするからです。
ここで登場するのが「メモリフォレンジック」です。
メモリ（RAM）とは、パソコンが現在進行形で頭を使っている「作業机」のようなもの。パソコンの電源を切ると消えてしまう儚い記憶ですが、ここには「今まさに動いているプログラムや、隠れてコソコソ行われている悪意ある作業の残骸」がリアルタイムで残っています。
つまり、
- イベントログ ＝ 防犯カメラの記録（後から見返せる公式の履歴）
- メモリ情報 ＝ 泥棒が部屋の中に置き忘れた足跡や、まさに今手に持っている道具（その瞬間の生々しい証拠）
この2つを突き合わせることで、「防犯カメラの記録には無いけれど、メモリの作業机の上には怪しいハサミが転がっているぞ！」といった、攻撃者の隠蔽工作を見破ることができるのです。
—
2. なぜ「両方」見る必要があるの？片方だけではダメな理由
新人エンジニアの皆さんからよくいただく質問が、「イベントログだけで十分じゃないですか？」というものです。
実は、攻撃者は非常に賢いです。彼らは侵入に成功すると、自分たちの足跡を消そうとイベントログをクリアしたり、改ざんしたりします。防犯カメラのテープをこっそり消去してしまうようなものです。
しかし、動いているメモリ上のデータまで完璧に隠し通すのは、攻撃者にとっても至難の業です。プログラムが動いている以上、どこかに必ずメモリの消費やプロセスの痕跡が残ります。
だからこそ、
1. 「イベントログ」で大まかなタイムライン（何時に誰がログインしたか）を確認する
2. 「メモリ」でその裏で実際に何が実行されていたかを深掘りする
この両者をパズルのように組み合わせる（相関分析する）ことで、初めて攻撃者の全貌がクリアに見えてくるというわけです。
—
3. 実践！イベントログとメモリを突き合わせる手順
ここからは、実際に現場でどのようにこの調査（フォレンジック）を行うのか、初心者の方にも分かりやすいように実務のステップをご紹介します。
ステップ1：怪しいイベントログ（Event ID 4688）を見つける
Windowsのセキュリティログには、新しいプロセス（プログラム）が起動したときに 4688 というイベントIDが記録されます。ここに注目してみましょう。
例えば、普段は絶対に起動しないはずのコマンドプロンプト（cmd.exe）や、見慣れないスクリプト実行ツールが動いている記録を見つけたとします。
ステップ2：メモリから当時のプロセスリストを抽出する
次に、メモリの保全（ダンプ）を行い、その中から当時のプロセス情報を抜き出します。ここでは、オープンソースでよく使われる解析ツール「Volatility」をイメージしてください。
メモリ上に残るプロセスの中から、先ほどのイベントログで見つけた時間帯の怪しい動きを探します。
ステップ3：タイムラインの突き合わせ
ここで、以下のような「突合（とつごう）作業」を行います。
- イベントログの主張： 「14:02に、ユーザーAが
powershell.exeを起動しました」 - メモリの現実： 「14:02のメモリ上には、
powershell.exeから外部の怪しいIPアドレスへ通信を試みる隠しコマンド（難読化されたスクリプト）が残っています」
イベントログ単体では「ただのPowerShellの実行」に見えても、メモリを覗くことで「実は悪意あるコードをネットからダウンロードして実行していた！」という決定的な証拠（インシデントの確証）を掴むことができるのです。
—
4. 実務で役立つ設定と簡易スクリプトの活用
インシデントが起きたときに慌てないためにも、日頃から「証拠を残す設定」をしておくことが最大の防御です。
① Windowsイベントログ（Event ID 4688）の詳細化設定
デフォルトの状態では、プロセスが起動したこと（ID 4688）は記録されても、「そのときどんなコマンドライン引数（オプション）で実行されたか」が記録されない場合があります。これでは攻撃の全貌がわかりません。
グループポリシーエディター（gpedit.msc）を開き、以下の設定を有効にしておきましょう。
> 設定パス:
> コンピューターの構成 ＞ Windows の設定 ＞ セキュリティの設定 ＞ 高度な監査ポリシーの構成 ＞ システム監査ポリシー ＞ アカウント管理 / ログオン/ログオフ など（※環境により異なりますが、プロセス作成の監査を有効化）
> 「プロセス作成時にコマンドライン引数を含める」を 有効 にする。
これを行っておくことで、イベントログの詳細欄に powershell.exe -enc AgBv... のような怪しいコマンドの断片が残るようになり、後からの追跡劇が劇的に楽になります。
② 簡易的なプロセス確認スクリプトの例（PowerShell）
普段の運用や初動調査で、現在動いている怪しいプロセスをサクッと確認するためのシンプルなPowerShellスクリプトの例をご紹介します。実務の現場でも、まずはこうした手元の軽量なスクリプトで当たりを付けることが多いです。
# -------------------------------------------------------------
# スクリプト名: Get-SuspiciousProcesses.ps1
# 概要: 現在実行中のプロセスから、怪しい名前やパスのものを抽出します
# -------------------------------------------------------------
# 監視対象とするキーワード（例: よく悪用されるスクリプト実行エンジンなど）
$TargetKeywords = @("powershell", "cmd", "wscript", "cscript", "mshta")
Write-Host "=== 怪しいプロセスのスキャンを開始します ===" -ForegroundColor Green
# 実行中のプロセスを取得し、名前でフィルターにかける
$Processes = Get-CimInstance Win32_Process | Where-Object {
$procName = $_.Name.ToLower()
foreach ($keyword in $TargetKeywords) {
if ($procName -like "*$keyword*") { return $true }
}
return $false
}
# 検出結果の表示
foreach ($p in $Processes) {
Write-Host "[!] 検出されたプロセス: " -NoNewline -ForegroundColor Yellow
Write-Host "$($p.Name) (PID: $($p.ProcessId))"
Write-Host " 起動コマンド: $($p.Commandline)" -ForegroundColor Cyan
Write-Host "--------------------------------------------------"
}
Write-Host "=== スキャンが完了しました ===" -ForegroundColor Greenこのようなスクリプトを定期的に回したり、インシデント発生時の初期トリアージ（選別）に使ったりすることで、メモリやログの海から素早く「おかしな挙動」を釣り上げることができるようになります。
—
5. 最後に：一歩ずつ、確実なセキュリティエンジニアへ
メモリフォレンジックとイベントログの相関分析は、最初はパズルを解くように難しく感じるかもしれません。しかし、「防犯カメラと部屋の中の状況証拠を突き合わせる」という基本の考え方さえ持っていれば、攻撃者の足跡を見失うことは少なくなります。
「難しそう」と怖じ気づく必要はまったくありません。日々の小さなログやメモリの変化に興味を持ち、少しずつ仕組みを紐解いていくことで、あなたも頼れるセキュリティの担い手になっていけますよ。
それでは、また次回の解説でお会いしましょう！一歩ずつ、一緒に学んでいきましょうね。
コメント