ディスクイメージをクローンし、タイムラインを構築して、静的なシグネチャをベースにインシデントを追う――そんな悠長な「死体解剖」の時代はとうに過ぎ去っています。
現代の高度標的型攻撃（APT）や、洗練されたランサムウェアオペレーターは、ディスクに痕跡をほとんど残しません。彼らが好むのは、メモリ空間という名の「生きた暗闇」です。Reflective DLL Injection、Process Hollowing、あるいは Cobalt Strike や Sliver といったC2フレームワークが展開するビーコン。これらはすべて、RAMの揮発性領域の中で密かに息づき、コマンドを実行し、クレデンシャルを強奪して、隣接するシステムへと横移動（ラテラルムーブメント）していきます。
インシデントレスポンスの現場において、私たちに与えられた時間は極めて限定的です。初動の数時間を誤れば、単一マシンの侵害は数千台規模のActive Directoryドメイン全体の完全崩壊（ドメインドミネーション）へとエスカレートします。
本稿では、メモリフォレンジック（主に Volatility 3 を想定）から得られたアーティファクトを起点とし、「今すぐこのシステムをネットワークから完全に隔離すべきか」「即座に全社規模のパスワードリセット（Krbtgtを含む）を断行すべきか」「あるいは静的な監視を維持しつつ観測を続けるべきか」を冷徹に判断するための、実践的なトリアージおよび意思決定フレームワークを提示します。
—
1. ディスクからメモリへ：なぜ「ライブメモリ解析」がトリアージの命運を握るのか
EDR（Endpoint Detection and Response）アラートが「不審なプロセス」を検知したとき、従来のSOCオペレーションはディスク上のPEファイルをウイルス対策エンジンに放り込むことから始めがちです。しかし、攻撃者が mimikatz を直接メモリにインジェクションしていた場合、あるいは正常な svchost.exe のメモリ空間を乗っ取っていた場合、ディスク上には「クリーンなシステムファイル」しか存在しません。
メモリフォレンジックが暴き出すのは、以下の3つの「動的真実」です。
1. プロセスの血統（Lineage）と実態: 親プロセスと子プロセスの関係性が偽装されていないか（例: explorer.exe の親プロセスが services.exe になっている等の不整合）。
2. メモリマップの異常: ディスク上のファイルと紐づいていない、実行可能（PAGE_EXECUTE_READWRITE）なメモリ領域の存在。
3. アクティブな通信セッション: カーネル空間のネットワーク構造体（TCP_TABLE 等）から直接抽出された、暗号化C2チャネルの実IPアドレスとポート。
これらを瞬時に評価し、脅威の「深さ（Depth）」と「幅（Breadth）」を数値化することこそが、トリアージの極意です。
—
2. メモリ構造の深淵：VAD（Virtual Address Descriptor）とインジェクションの検知ロジック
メモリトリアージの意思決定を支える、最も強力なアーティファクトの一つが VAD（Virtual Address Descriptor） です。
Windowsカーネルは、各プロセスが使用する仮想メモリのアドレス空間をバイナリツリー（VADツリー）で管理しています。プロセスがメモリを確保する際、その領域の保護属性（Read, Write, Execute）が定義されます。
通常、ディスク上のDLLやEXEがロードされる場合、メモリ領域は SEC_IMAGE としてマップされ、VADツリー内には対応するファイルオブジェクト（ディスク上のパス）へのポインタが存在します。
しかし、Reflective DLL Injection などの手法でインメモリ展開されたコードは、API（VirtualAllocEx など）によって動的に確保された領域（PAGE_EXECUTE_READWRITE / ERW）に配置されます。この領域は SEC_COMMIT であり、対応するファイルオブジェクトが存在しません。つまり、「実行可能属性を持っているにもかかわらず、ディスク上のどのファイルとも紐づいていないメモリ領域」が存在することになります。
これが、Volatilityの windows.malfind プラグインが検出を試みる根本的なアノマリーです。
VADアノマリーの判断基準
- 危険度：高 (Critical)
- VAD属性が
PAGE_EXECUTE_READWRITE(0x40) - マップされたファイルが「なし」（
File: None） - メモリの先頭に
MZヘッダ（4D 5A）または不審なシェルコード（例:FC 48 83 E4 F0– Metasploitの典型的なx64アライメントコード）が存在する。
—
3. メモリトリアージ意思決定マトリクス（MTDM）
メモリ解析から得られた証拠に基づき、レスポンスチームが取るべきアクションを3つのステージに分類します。
| 検出されたメモリ構造の異常（アーティファクト） | 侵害の深さ（Severity） | 推奨される即時アクション | 意思決定のロジック |
| :— | :— | :— | :— |
| 非特権プロセス（例: chrome.exe）内へのインジェクション、C2通信（非SSL/既知シグネチャ）のパケット痕跡。VAD異常あり。 | Tier 1: Localized / Volatile (局所的・揮発性) | 対象ホストの論理隔離（EDRによる隔離）、メモリイメージのフルダンプ取得、該当プロセスのメモリダンプ解析。 | 攻撃の足場（Foothold）は確立されているが、権限昇格や永続化の痕跡が未確認。即座に隔離すれば封じ込め可能。 |
| lsass.exe のメモリ読み取り（PAGE_READWRITE ハンドルのオープン）、SYSTEM権限プロセス（spoolsv.exe 等）へのインジェクション、特権トークンの窃取（Token Impersonation）。 | Tier 2: Privilege Escalation / Persistence (特権昇格・永続化) | ホストの物理隔離（ネットワークケーブル抜線）、ドメインユーザー（特にローカルAdminおよびドメインAdmin）のセッション強制切断およびパスワードリセット。 | 攻撃者が管理者権限を掌握。認証資格情報（NTLMハッシュやKerberosチケット）が窃取された可能性が極めて高く、同一セグメント内の他ホストへのラテラルムーブメントが不可避な状態。 |
| ドメインコントローラ（DC）のメモリ上における lsass.exe の汚染、NTDS.ditへのアクセスプロセス、またはメモリ上の krbtgt 秘密鍵暗号化セッションへのアクセス痕跡。 | Tier 3: Domain-Wide Compromise (ドメイン完全掌握) | 組織ネットワーク全体の外部境界閉塞（インターネットセグメントの遮断）、Active Directoryの二重 krbtgt パスワードリセット、全システムにおける認証情報の強制ローテーション。 | ドメイン全体の信頼関係が崩壊。ゴールデンチケット（Golden Ticket）が作成可能な状態であり、システム隔離だけでは攻撃者の永続性を排除できない。インフラの「再構築」レベルの対応が必要。 |
—
4. Volatility 3 による実戦的解析とトリアージ判断
ここでは、インシデントハンドラーが直面する実際のメモリアナリシスの流れを、Volatility 3 の出力結果をベースにシミュレーションします。
ステップ1: 不審なプロセスの親子関係の特定
まずはプロセスツリーを確認します。不審な親プロセスから起動されたシステムプロセスがないかをスキャンします。
python3 vol.py -f suspicious_memdump.raw windows.pstree解析のポイント:
もし以下のような出力が得られた場合、トリアージレベルは即座に Tier 2 へ移行します。
0xfa8001a2b040 cmd.exe 3040 1024 ... (正常なシェル)
. 0xfa8001c3c080 powershell.exe 4012 3040 ...
.. 0xfa8001e4d0c0 svchost.exe 5088 4012 ... <-- [異常] svchost.exeがPowerShellから起動しているWindowsの設計上、svchost.exe は services.exe（Service Control Manager）によってのみ起動されるべきです。ユーザーセッション内の powershell.exe から起動された svchost.exe は、100%の確率でプロセスのなりすまし（Process Hollowing等）が行われています。
ステップ2: VAD異常の自動検出（Malfind）
次に、該当の svchost.exe (PID: 5088) に隠蔽されたコードが注入されていないかを確認します。
python3 vol.py -f suspicious_memdump.raw windows.malfind --pid 5088出力例:
Process: svchost.exe Pid: 5088 Address: 0x7f00012a0000 Size: 0x1000
VAD Tag: VadS Protection: PAGE_EXECUTE_READWRITE
0x7f00012a0000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ..............
0x7f00012a0010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@.......Protection: PAGE_EXECUTE_READWRITE（実行可能かつ書き込み可能という、通常のPEロードではあり得ない属性）。- ダンプの先頭が
4d 5a（MZヘッダ：Windowsの実行可能ファイルの署名）。 - しかし、このメモリ領域に関連付けられたディスク上のファイル（
.dllや.exe）は存在しない。
これは、インメモリで注入されたPEファイル（C2ビーコンなど）の決定的な証拠です。
ステップ3: ネットワーク接続の紐付け
このインジェクションされたプロセスが、現在進行形でどこにデータを送っているかを特定します。
python3 vol.py -f suspicious_memdump.raw windows.netscan出力例:
Offset Proto LocalAddr LocalPort ForeignAddr ForeignPort State PID Owner
0xfa8001f5e010 TCPv4 192.168.12.45 49201 203.0.113.80 443 ESTABLISHED 5088 svchost.exeこれでパズルのピースが揃いました。
- PID 5088 (
svchost.exe) は、PowerShellから起動された偽装プロセスである。 - そのメモリ内には、ファイルレスで展開されたPEファイルが存在する。
- このプロセスは、外部の悪意あるIP（
203.0.113.80:443）とアクティブなセッションを持っている。
この時点で、トリアージ判断は 「Tier 1（即時論理隔離）」 から、クレデンシャル窃取の有無を確認するための 「Tier 2（特権昇格・LSASS検証）」 へと進みます。
—
5. 自動トリアージ判定スクリプトの実装
SOCの現場では、アナリストが手動でこれらのコマンドを叩いて結果を目視で比較している時間はありません。
以下に示すPythonスクリプトは、Volatility 3のJSON形式の出力結果（またはAPI経由のパース結果）を擬似的にシミュレートし、メモリ内のアノマリースコアを算出して、自動的に対応優先順位（トリアージスコア）と、推奨されるDFIRアクションを決定するロジックの実装例です。
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
import json
import sys
class MemoryTriageEngine:
"""
メモリ解析結果からインシデントの深刻度を自動判定し、
推奨されるレスポンスアクションを提示するトリアージエンジン。
"""
def __init__(self, process_data, network_data, vad_data):
self.processes = process_data
self.network = network_data
self.vad = vad_data
self.score = 0
self.indicators = []
def evaluate_process_tree(self):
"""プロセスの親子関係の不整合を評価する"""
system_processes = ["smss.exe", "csrss.exe", "wininit.exe", "services.exe", "lsass.exe", "svchost.exe"]
for proc in self.processes:
pid = proc["pid"]
ppid = proc["ppid"]
name = proc["name"].lower()
parent_name = self._get_process_name(ppid)
# svchost.exeがservices.exe以外から起動されている場合の評価
if name == "svchost.exe" and parent_name and parent_name != "services.exe":
self.score += 40
self.indicators.append(f"[HIGH] svchost.exe (PID: {pid}) spawned by abnormal parent: {parent_name}")
# lsass.exeがwininit.exe以外から起動されている場合の評価
if name == "lsass.exe" and parent_name and parent_name != "wininit.exe":
self.score += 80
self.indicators.append(f"[CRITICAL] lsass.exe (PID: {pid}) spawned by abnormal parent: {parent_name}")
def evaluate_vad_anomalies(self):
"""VAD（メモリ保護属性）の異常を評価する"""
for entry in self.vad:
pid = entry["pid"]
protection = entry["protection"]
has_mz = entry["has_mz_header"]
mapped_file = entry["mapped_file"]
# PAGE_EXECUTE_READWRITE (ERW) 且つファイルマッピングなし
if protection == "PAGE_EXECUTE_READWRITE" and not mapped_file:
self.score += 30
self.indicators.append(f"[MEDIUM] Suspicious ERW memory allocation with no file backing in PID: {pid}")
if has_mz:
self.score += 50
self.indicators.append(f"[CRITICAL] Dynamic PE/DLL (MZ header detected) injected in memory of PID: {pid}")
def evaluate_network_connections(self):
"""ネットワークコネクションと疑わしいプロセスの紐付け"""
# 悪意あるプロセスリスト（インジェクションが確認されたPIDなど）
suspicious_pids = [entry["pid"] for entry in self.vad if entry["protection"] == "PAGE_EXECUTE_READWRITE"]
for conn in self.network:
pid = conn["pid"]
state = conn["state"]
foreign_addr = conn["foreign_address"]
if pid in suspicious_pids and state == "ESTABLISHED":
self.score += 50
self.indicators.append(f"[CRITICAL] Active C2 connection established by injected process PID: {pid} to {foreign_addr}")
def _get_process_name(self, pid):
for proc in self.processes:
if proc["pid"] == pid:
return proc["name"].lower()
return None
def determine_triage_level(self):
"""最終的なトリアージスコアから、インシデントハンドリングの意思決定を下す"""
self.evaluate_process_tree()
self.evaluate_vad_anomalies()
self.evaluate_network_connections()
print("=" * 80)
print(f" MEMORY FORENSICS AUTOMATED TRIAGE REPORT (Score: {self.score})")
print("=" * 80)
for ind in self.indicators:
print(ind)
print("-" * 80)
if self.score >= 120:
print("[DECISION] TIER 3 - DOMAIN-WIDE COMPROMISE / IMMEDIATE FULL ISOLATION")
print(" -> ACTION: Disconnect target host from network physically.")
print(" -> ACTION: Initiate active credential rotation (including Domain Admin & krbtgt twice).")
print(" -> ACTION: Perform memory-dump of domain controllers immediately.")
elif 60 <= self.score < 120:
print("[DECISION] TIER 2 - LOCAL SYSTEM COMPROMISE / PRIVILEGE ESCALATION")
print(" -> ACTION: Isolate the host logically via EDR API.")
print(" -> ACTION: Revoke all active sessions for users logged into this machine.")
print(" -> ACTION: Extract full memory dump for offline deep analysis.")
else:
print("[DECISION] TIER 1 - SUSPICIOUS BEHAVIOR / OBSERVE AND CONTAIN")
print(" -> ACTION: Restrict network access via local firewall rules.")
print(" -> ACTION: Monitor process execution logs and DNS queries closely.")
print("=" * 80)
# シミュレーション用ダミーデータ
if __name__ == "__main__":
mock_processes = [
{"pid": 4, "ppid": 0, "name": "System"},
{"pid": 672, "ppid": 4, "name": "smss.exe"},
{"pid": 1024, "ppid": 672, "name": "wininit.exe"},
{"pid": 4012, "ppid": 1024, "name": "powershell.exe"},
{"pid": 5088, "ppid": 4012, "name": "svchost.exe"}, # 親がPowerShellという異常
]
mock_vad = [
{
"pid": 5088,
"protection": "PAGE_EXECUTE_READWRITE",
"has_mz_header": True,
"mapped_file": None # ディスク上にファイルがない（Reflective DLL）
}
]
mock_network = [
{
"pid": 5088,
"foreign_address": "203.0.113.80",
"state": "ESTABLISHED"
}
]
engine = MemoryTriageEngine(mock_processes, mock_network, mock_vad)
engine.determine_triage_level()—
6. アーキテクトに求められる「防御層（ガードレイル）」の設計
メモリフォレンジックによるトリアージ能力を高めることは極めて重要ですが、より本質的なのは「メモリを汚染させないアーキテクチャ」を事前に組み込んでおくことです。防御側（Blue Team）のテックリードやセキュリティアーキテクトは、以下の防御策を標準設計に組み込む必要があります。
1. 仮想化ベースのセキュリティ（VBS）とHVCIの強制
Windows 10/11およびWindows Server 2016以降で利用可能な HVCI（Hypervisor-Protected Code Integrity / メモリ整合性） を有効にします。これにより、カーネルモードのドライバが未署名の場合や、メモリ上で直接実行コード（W^X: Write XOR Executeルール）を変更しようとする行為（例えば PAGE_EXECUTE_READWRITE への変更）をハイパーバイザーレベルでブロックします。
2. Credential GuardによるLSASSの保護
攻撃者がローカル管理者権限を取得したとしても、LSASSプロセスのメモリ（lsass.exe）からNTLMハッシュやKerberos TGTを直接ダンプできないよう、Windows Defender Credential Guard を実装します。これは、LSASSプロセスの一部（LSA分離プロセス）をVBSで隔離された仮想コンテナ内に配置するため、たとえSYSTEM権限を持つマルウェアであっても、そのメモリ空間に直接アクセスすることは不可能になります。
3. APIフックの検知とEDRの強化
最新のEDRは、メモリ上での不審なAPIコール（VirtualAllocEx -> WriteProcessMemory -> CreateRemoteThread というインジェクションの典型パターン）を検知するために、ユーザーモードフック（User-mode hooking）を使用しています。
しかし、攻撃者は Direct Syscalls（ntdll.dll のフックを回避して直接カーネルへシステムコールを投げる手法）を用いてこれを回避しようとします。
アーキテクトとしては、ETW（Event Tracing for Windows）の Microsoft-Windows-Threat-Intelligence プロバイダ（ETW-Ti）を利用するEDRを採用し、カーネルレベルで不審なメモリ操作APIの実行を監視・ブロックできる製品を選定すべきです。
—
7. エピローグ：揮発する戦場で、冷徹な一手を打つために
メモリフォレンジックは、インシデントハンドラーにとっての「X線写真」です。ディスク上のログがどれほど巧妙に消去されようとも、実行中のCPUとRAMは嘘をつけません。
重要なのは、メモリから得られた不都合な真実――例えば「ドメインコントローラのメモリ上で、SYSTEM権限のインジェクションとC2通信が同時に見つかった」という事実――に対して、組織の政治的なバイアスを排除し、「即座にドメイン全体の信頼関係を破棄（krbtgtの二重リセットを実行）し、全通信を物理的に遮断する」という超高難度の意思決定をシステマチックに下せるかどうかです。
本稿で示した意思決定フレームワークと自動トリアージのロジックが、貴組織のインシデントレスポンス能力を「受動的なログ監視」から「能動的なインメモリ制圧」へと昇華させる一助となることを願ってやみません。
コメント