analyzing-memory-images

メモリイメージの分析

一部のアーティファクトが存在する場所は、メモリだけです。たとえば、注入されたコード、復号されたペイロード、認証情報、すでに終了したプロセスのネットワーク接続などです。ディスクフォレンジックでは、これらを見つけられません。イメージが失われる前に取得し、適切な順序で適切な問いを投げかけることが重要です。

使用する場合

• 分析対象のメモリダンプ（raw、LiME、EWF、クラッシュダンプ、または VM スナップショット）がある場合
• 侵害されたホストを調査しており、RAM にのみ存在するアーティファクトが必要な場合
• 注入されたコード、プロセスのホローイング、またはリフレクティブ DLL ロードを探す場合
• ハッシュ、Kerberos チケット、キャッシュされた認証情報などの認証情報を抽出する場合
• 特定時点のキャプチャからネットワーク接続やリスニングポートを特定する場合
• SSDT フック、DKOM、隠しドライバーなどのカーネルレベルのルートキットを検出する場合

使用しない場合

• より広範なインシデント対応の方法論 — responding-to-incidents を使用してください
• 取得したのが RAM キャプチャではなくディスクイメージである場合 — analyzing-disk-images を使用してください
• 稼働中またはトリアージ中の Windows ホストのディスク上のアーティファクト — investigating-windows-endpoints を使用してください
• ディスク上の既知のマルウェアサンプルを分析する場合 — analyzing-malware を使用してください
• メモリの分析結果から検出ルールを作成する場合 — engineering-detections を使用してください

取得

稼働中のシステムでは、何よりも先にメモリを取得してください。ホスト上で実行するコマンドはすべて、メモリの内容を変化させます。まずイメージを取得し、その後にトリアージします。

# Linux — LiME (kernel module, minimal footprint)
sudo insmod lime-$(uname -r).ko "path=/evidence/mem.lime format=lime"
# Alternative: AVML (no kernel module needed, userspace)
sudo ./avml /evidence/mem.lime

# Windows — WinPMem (signed driver)
winpmem_mini_x64.exe mem.raw
# Alternative: DumpIt (single executable, click-to-run for non-technical staff)
DumpIt.exe /OUTPUT mem.raw /QUIET

# macOS — osxpmem is dead (Rekall archived, last release 2017, Intel-only, and
# blocked by SIP/kext restrictions on Big Sur+ and all Apple Silicon). Full-RAM
# capture on a modern Mac needs commercial tooling with Apple entitlements
# (e.g. Volexity Surge Collect); otherwise take process-scoped dumps and
# record that physical memory was not obtainable. See responding-to-incidents.

# VM snapshots — no agent needed
# VMware:   .vmem file alongside the .vmx (suspend the VM first for consistency)
# Hyper-V:  checkpoint creates .bin and .vsv in the snapshot directory
# KVM/QEMU: virsh dump <domain> mem.raw --memory-only
# VirtualBox: VBoxManage debugvm <name> dumpvmcore --filename mem.elf

# Crash dumps — partial but sometimes all you have
# Windows:  %SystemRoot%\MEMORY.DMP (complete dump), or minidumps
# Linux:    /var/crash/, kdump output, /proc/kcore (live, pseudo-file)

取得後、すぐにハッシュを計算してください。 SHA-256、ソースホスト、タイムスタンプ（UTC）、収集ツールとバージョン、アナリスト名を記録してください。イメージを法的または規制上の手続きで使用する場合は、この時点から証拠保全の連鎖を維持してください。

Volatility 3 のワークフロー

まず全体像を把握し、その後、証拠をたどります。プラグインを何でも手当たり次第に実行しないでください。問いごとに、それに答えるプラグインがあります。

全体像の把握

# Identify the OS profile and confirm the image is valid
vol -f mem.raw windows.info
vol -f mem.lime linux.bash
vol -f mem.raw banners.Banners    # fallback for unknown images

windows.info では、OS のバージョン、ビルド番号、カーネルのベースアドレスを確認できます。これが失敗する場合、イメージが破損しているか、形式が適切でないか、カスタムシンボルテーブルが必要な可能性があります。Linux の場合は、一致する ISF（Intermediate Symbol Format）ファイルが必要です。正確なカーネルバージョンのカーネルデバッグシンボルから生成してください。

プロセス分析

# Process listing — what was running
vol -f mem.raw windows.pslist     # walks the ActiveProcessLinks list
vol -f mem.raw windows.psscan     # scans for EPROCESS structures
                                          # (finds hidden/unlinked processes)
vol -f mem.raw windows.pstree     # parent-child relationships

# Compare pslist vs psscan: processes in psscan but not pslist were
# unlinked from the active list — this is DKOM or a terminated process
# that has not been fully cleaned up. Either is worth investigating.

プロセス一覧で確認する点：

• 親プロセスが不自然なプロセス（services.exe の配下にない svchost.exe）
• 単一インスタンスであるはずのプロセスが複数存在する場合（lsass.exe、csrss.exe）
• 名前のつづりが間違っているプロセス（scvhost.exe、lssas.exe）
• 予期せず SYSTEM として実行されているプロセス
• 侵害が疑われる時刻の前後に作成時刻が集中しているプロセス

# DLL listing — what each process loaded
vol -f mem.raw windows.dlllist --pid <PID>
# Look for DLLs loaded from unusual paths (Temp, AppData, user-writable dirs)

# Handles — files, registry keys, mutexes, events
vol -f mem.raw windows.handles --pid <PID>
# Mutexes are especially useful: malware families often use characteristic
# mutex names to prevent re-infection

注入されたコードの検出

メモリ分析の真価が発揮されるのはここです。ディスクベースのフォレンジックでは、ファイルに一度も書き込まれていないコードは確認できません。

# VAD-based detection — finds memory regions with suspicious protections
vol -f mem.raw windows.malfind
# Reports regions that are:
#   - Committed, private memory with PAGE_EXECUTE_READWRITE
#   - Containing a PE header (MZ magic) in a region not backed by a file
#   - Tagged as VadS (private) rather than VadF (file-mapped)

# Dump suspicious regions for further analysis
vol -f mem.raw windows.malfind --dump --pid <PID>

malfind の結果の解釈：

• RWX 領域がすべて悪意あるものとは限りません。JIT コンパイラー（.NET CLR、Java、Chrome V8）は正当に実行可能メモリを割り当てます。プロセス名でこれらを除外してください。
• バックファイルのない領域に PE ヘッダー（MZ + "This program"）がある場合、悪意ある可能性は非常に高いです。
• ペイロードを段階的に実行する場合、PE ヘッダーのないシェルコードがよく使われます。領域の先頭で 0xFC（cld 命令）、0x60（pushad）、または call + pop のシーケンスを探してください。

ホロープロセスの検出：

# Compare on-disk PE headers with in-memory PE headers
vol -f mem.raw windows.pslist --dump   # dump process executables
# Then compare each dumped image against the on-disk original:
#   - Different PE header = process hollowing
#   - SizeOfImage mismatch = section unmapping/remapping
#   - Entry point outside the main module = hijacked execution

# Look for processes where the PEB ImageBaseAddress does not match the
# VAD entry for the main executable — a sign of hollowing or replacement

認証情報の抽出

メモリには、ディスクフォレンジックでは復元できない形式の認証情報が含まれています。たとえば、平文のパスワード（WDigest を使用する Windows 10 1607 より前のバージョン）、NTLM ハッシュ、Kerberos チケット、キャッシュされたドメイン認証情報です。

# SAM hashes (local accounts)
vol -f mem.raw windows.hashdump

# LSA secrets (service account passwords, auto-logon credentials, VPN)
vol -f mem.raw windows.lsadump

# Cached domain credentials (mscash2 format — crackable but slow)
vol -f mem.raw windows.cachedump

# For Kerberos tickets, dump lsass.exe memory and use mimikatz/pypykatz:
vol -f mem.raw windows.memmap --pid <lsass_pid> --dump
pypykatz lsa minidump <dumped_lsass_file>
# Yields: NTLM hashes, Kerberos TGTs and service tickets, WDigest
# plaintext (if enabled), DPAPI master keys

見つかった認証情報はすべて、被害範囲を広げます。 各ハッシュやチケットは、攻撃者が利用できたラテラルムーブメントの経路を示しています。responding-to-incidents での範囲特定にこれらを活用してください。

ネットワークの痕跡

# Active and recently closed connections, listening ports
vol -f mem.raw windows.netscan
# Fields: protocol, local/remote address:port, state, PID, owner process

# DNS cache: Volatility 3 has no built-in Windows DNS-cache plugin. Recover
# resolved names from process memory instead, or use a third-party plugin.
vol -f mem.raw windows.memmap --pid <PID> --dump && strings -a pid.*.dmp | grep -iE '\.(com|net|org|ru|cn)\b'

# Linux equivalent
vol -f mem.lime linux.sockstat

確認するポイント：

• 想定外のプロセスから外部 IP への接続がないか（特に svchost.exe、rundll32.exe、regsvr32.exe）
• 通常とは異なる番号のリスニングポートがないか。バックドアは高位ポートをバインドすることがよくあります
• pslist には表示されなくなったプロセスからの接続がないか（終了した C2 チャネルがメモリ内にのみ残っている場合があります）
• リモート IP を脅威インテリジェンスフィードとすぐに照合してください

コマンド履歴とコンソール出力

# Command-line arguments for every process
vol -f mem.raw windows.cmdline
# Reveals encoded PowerShell commands, lateral movement tool arguments,
# reconnaissance commands, and data staging operations

# Console input/output buffers (cmd.exe sessions)
vol -f mem.raw windows.consoles
# Can recover full command history and output even after the window is closed

# Linux shell history from memory (survives history -c)
vol -f mem.lime linux.bash

エンコードされた PowerShell はよく見られます。-EncodedCommand の引数をデコードしてください。

echo "<base64_string>" | base64 -d | iconv -f UTF-16LE -t UTF-8

メモリからのタイムライン構築

プロセス作成時刻、ネットワーク接続、ハンドルのタイムスタンプを組み合わせ、メモリのみからタイムラインを構築します。このタイムラインには、ディスクに一度も書き込まれなかったイベントが記録されます。

UTC Timestamp        | Artifact        | Detail                          | PID
2026-07-10 02:14:02  | Process create  | cmd.exe via explorer.exe        | 4812
2026-07-10 02:14:08  | Process create  | powershell.exe via cmd.exe      | 5104
2026-07-10 02:14:09  | Network conn    | 5104 -> 203.0.113.50:443 EST   | 5104
2026-07-10 02:14:15  | Process create  | rundll32.exe (no DLL in cmdline)| 6220
2026-07-10 02:14:15  | malfind hit     | RWX region with PE header       | 6220
2026-07-10 02:14:22  | Network conn    | 6220 -> 198.51.100.10:8443 EST | 6220

これを responding-to-incidents のディスクおよびログのタイムラインと統合し、空白を補完してください。メモリからは実行されたものがわかり、ディスクからは永続化されたものがわかり、ログからは記録されたものがわかります。いずれか一つだけでは全体を把握できません。

ルートキットの検出

カーネルモードのルートキットは、プロセス、ファイル、レジストリキー、ネットワーク接続を隠すため、OS の構造を改変します。ルートキットは生のメモリイメージから隠れることができないため、メモリ解析が主要な検出方法です。

# SSDT hooking — System Service Descriptor Table
vol -f mem.raw windows.ssdt
# Entries pointing outside ntoskrnl.exe or win32k.sys are hooked

# Driver and module enumeration
vol -f mem.raw windows.driverscan    # scan for DRIVER_OBJECT
vol -f mem.raw windows.modules       # loaded kernel modules
vol -f mem.raw windows.modscan       # scan for unlinked modules
# Modules in modscan but not modules = hidden drivers

# Callbacks — rootkits register notify routines to intercept operations
vol -f mem.raw windows.callbacks

# IDT — Interrupt Descriptor Table modifications. Volatility 3 ships this for
# Linux only (linux.check_idt); there is no windows.idt. On Windows, IDT hooking
# is largely a pre-PatchGuard (x86) technique — check SSDT and callbacks above.
vol -f mem.lime linux.check_idt
# Handlers pointing to addresses outside known kernel modules are suspicious

DKOM（直接カーネルオブジェクト操作）：

• プロセスのリンク解除：EPROCESS を ActiveProcessLinks から削除します
• pslist（リストをたどる）と psscan（メモリをスキャンして抽出する）を比較して検出します
• 同じ原理は、スレッド、ドライバー、その他のカーネルオブジェクトにも当てはまります

Linux 固有の解析

# Process listing
vol -f mem.lime linux.pslist
vol -f mem.lime linux.pstree
vol -f mem.lime linux.psaux         # with command-line arguments

# Shell history recovered from process memory
vol -f mem.lime linux.bash

# ELF binaries in memory — find injected shared objects
vol -f mem.lime linux.elfs

# Syscall table integrity — detect syscall hooking
vol -f mem.lime linux.check_syscall
# Entries not pointing to the expected kernel text range are hooked

# Loaded kernel modules and hidden modules
vol -f mem.lime linux.lsmod
vol -f mem.lime linux.hidden_modules

# Open files and network connections
vol -f mem.lime linux.lsof
vol -f mem.lime linux.sockstat

# Mounted filesystems and their types
vol -f mem.lime linux.mountinfo

Linux のシンボルテーブル： Windows とは異なり、Linux には固定されたカーネル構造がありません。正確なカーネルバージョンに一致する ISF ファイルを用意する必要があります。カーネルのデバッグシンボル（DWARF 情報を含む vmlinux）から dwarf2json を使って生成してください。正しいシンボルがないと、Volatility は処理に失敗するか、意味のない出力を生成します。

文字列と YARA スキャン

何を探しているかわからない場合や、イメージ全体にわたって仮説を検証する必要がある場合に使用します。

# YARA rules against the full image
vol -f mem.raw yarascan.YaraScan --yara-file rules.yar
# Scoping to a specific process:
vol -f mem.raw yarascan.YaraScan --yara-file rules.yar --pid <PID>

# Strings extraction — raw approach, still useful
strings -a -t d mem.raw > strings_ascii.txt
strings -a -t d -e l mem.raw > strings_unicode.txt
# Search for IPs, URLs, commands, known malware strings

# bulk_extractor — automated structured-data carving
bulk_extractor -o be_output mem.raw
# Produces: emails, URLs, credit card numbers, domain names, IP addresses,
# JSON/XML fragments, and other structured data, each in a separate file
# Use the histogram files (url_histogram.txt, domain_histogram.txt) first —
# stacking by frequency surfaces C2 domains and unusual patterns

メモリ解析用の YARA ルールは、ファイルベースのルールとは異なるものにしてください。 ディスク上のパックまたは暗号化されたペイロードはメモリ内で復号されるため、展開後の形式に対するルールを作成してください。また、実行時にのみ現れる文字列も対象にしてください。たとえば、ミューテックス名、C2 URL、API 解決文字列、復号された設定ブロックなどです。

退けるべき合理化

• 「ディスクイメージだけで十分です。」 ディスクフォレンジックでは、注入されたコード、メモリ内にしか存在しないペイロード、復号された設定、ディスクに一度も書き込まれなかった認証情報は確認できません。メモリは重複する情報源ではなく、別の証拠ソースです。
• 「メモリダンプは大きすぎて効率よく解析できません。」 文字列ダンプ全体を取得するのではなく、pslist、malfind、netscan、cmdline などの対象を絞ったプラグインから始めてください。5 つのプラグインを使えば、64 GB の生データを grep するより多くの情報が得られます。
• 「再イメージ化して先に進めばよいだけです。」 再イメージ化すると、揮発性証拠の唯一のコピーが破壊されます。攻撃者の行動を把握する必要があるなら、メモリが必要です。
• 「Malfind がフラグを立てたので、悪意のあるものです。」 Malfind が報告するのは疑わしいメモリ保護であり、マルウェアが確認されたということではありません。JIT エンジン、.NET アセンブリ、一部のセキュリティツールは、正当な RWX 領域を生成します。検出結果はすべて検証してください。
• 「適切な Volatility プロファイルがありません。」 Linux では、対象カーネルのデバッグシンボルから ISF を構築してください。Windows では、Volatility 3 がほとんどのバージョンを自動検出します。未対応のプロファイルは解決可能な問題であり、メモリ解析を省略する理由にはなりません。
• 「システムが再起動されたので、メモリの証拠は消えました。」 クラッシュダンプ、休止状態ファイル（hiberfil.sys）、ページファイル（pagefile.sys）、VM スナップショットを確認してください。これらにはメモリの内容が部分的に含まれており、見落とされることがよくあります。
• 「文字列の出力はノイズが多すぎて役に立ちません。」 bulk_extractor のヒストグラム、YARA ルール、または特定のインジケーターに対する grep を使用してください。生の文字列は最後の手段であり、最初に行う手順ではありません。

参考資料

• responding-to-incidents — インシデント対応の手法と証拠の取り扱いに関する詳細
• analyzing-malware — メモリから抽出したサンプルの詳細な分析
• engineering-detections — メモリ内で発見された TTP に基づくルールの作成
• hunting-threats — メモリ分析で見つかったインジケーターを使ったプロアクティブな検索