Forensics Checklist

Digital Forensics Evidence Collection -- NIST SP 800-86 / RFC 3227

> Frameworks: NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response), RFC 3227 (Guidelines for Evidence Collection and Archiving) > Role: SOC Analyst, Security Engineer > Time: 30-60 min > Output: Evidence collection plan with volatility-ordered acquisition steps, chain-of-custody forms, integrity hashes, and cloud forensics considerations

---

1. When to Use

If a target is provided via arguments, focus the review on: $ARGUMENTS

Invoke this skill when any of the following conditions are met:

• Incident requires forensic evidence -- A confirmed or suspected security incident has progressed to a point where evidence must be preserved for root cause analysis, legal proceedings, or regulatory compliance.
• Volatile data capture is needed -- Systems that may contain volatile forensic evidence (memory, running processes, network connections) are at risk of being rebooted, reimaged, or shut down.
• Disk imaging is required -- A system must be forensically imaged before eradication or recovery actions alter the disk state.
• Chain of custody must be established -- Evidence may be used in legal proceedings, regulatory investigations, insurance claims, or internal disciplinary actions requiring documented provenance.
• Cloud environment evidence collection -- Forensic data must be captured from cloud infrastructure (AWS, Azure, GCP) where traditional disk imaging does not apply.
• Log preservation needed -- Logs at risk of rotation, overwrite, or deletion must be preserved before they are lost.

Do not use when: The task is incident classification and response coordination (use ir-playbook), containment strategy selection (use containment), or post-incident retrospective (use post-incident-review).

---

2. Context the Agent Needs

Before beginning evidence collection, gather or confirm:

• [ ] Incident ID and severity -- Reference to the associated incident response case.
• [ ] Affected systems -- Hostnames, IP addresses, OS type/version, physical/virtual/cloud, hypervisor type if virtual.
• [ ] Current system state -- Powered on (running), powered off, suspended (VM), or unknown.
• [ ] Legal hold status -- Has legal counsel issued a preservation directive? Are there litigation or regulatory holds in effect?
• [ ] Authorization -- Written authorization from system owner or legal authority to perform forensic acquisition.
• [ ] Evidence storage -- Write-protected storage media available (forensic drives, NAS, S3 bucket with object lock).
• [ ] Forensic tools available -- Memory capture (WinPmem, LiME, DumpIt), disk imaging (dc3dd, FTK Imager, ewfacquire), network capture (tcpdump, Wireshark).
• [ ] Cloud provider access -- IAM permissions for snapshot creation, log export, and API access (if cloud environment).
• [ ] Time synchronization -- NTP configuration of affected systems; UTC timestamps preferred.
• [ ] Encryption status -- BitLocker, LUKS, FileVault, or cloud-managed encryption on affected volumes.

---

3. Process

Step 1: Establish Chain of Custody

Before touching any evidence, initialize the chain-of-custody record. Every transfer, access, or modification of evidence must be documented.

Chain of Custody Form:

CHAIN OF CUSTODY RECORD
========================
Case/Incident ID:    [IR-YYYY-NNNN]
Evidence ID:         [EVD-NNNN]
Description:         [Brief description of evidence item]
Source System:        [Hostname / IP / Cloud Resource ID]
Date/Time Collected: [YYYY-MM-DD HH:MM UTC]
Collected By:        [Name, Title, Organization]
Collection Method:   [Tool name and version]
Storage Location:    [Physical location or secure storage path]
Hash (SHA-256):      [Hash value computed at time of collection]

CUSTODY LOG:
| Date/Time (UTC) | Released By | Received By | Purpose | Location |
|---|---|---|---|---|
| [timestamp] | [name] | [name] | [reason] | [location] |

Chain of custody principles (NIST SP 800-86 Section 3.2):

• Document who collected the evidence, when, where, and how
• Record every transfer of evidence between individuals or storage locations
• Use tamper-evident bags or containers for physical media
• Compute and record cryptographic hashes (SHA-256 minimum) at collection time and verify at each transfer
• Maintain a continuous, unbroken record from collection through final disposition

Step 2: Collect Evidence in Order of Volatility (RFC 3227)

RFC 3227 Section 2.1 defines the order of volatility -- evidence sources ranked from most volatile (shortest lifespan) to least volatile. Collect in this order to minimize evidence loss.

RFC 3227 Order of Volatility:

| Priority | Evidence Source | Volatility | Collection Window | Tool Examples | |----------|---------------|------------|-------------------|---------------| | 1 | Registers, cache | Nanoseconds | Lost on context switch or power loss | Hardware debuggers, crash dumps (rarely collected outside specialized investigations) | | 2 | Routing table, ARP cache, process table, kernel statistics, memory | Seconds to minutes | Lost on reboot or process termination | netstat, arp -a, ps aux, /proc, WinPmem, LiME, DumpIt, Volatility | | 3 | Temporary file systems | Minutes to hours | Lost on reboot or cleanup | /tmp, %TEMP%, pagefile, swap partition | | 4 | Disk | Persistent until overwritten | Stable unless wiped or reimaged | dc3dd, FTK Imager, ewfacquire, dd | | 5 | Remote logging and monitoring data | Persistent until rotation | Subject to log rotation policies | SIEM export, CloudTrail, syslog server, ELK/Splunk | | 6 | Physical configuration, network topology | Stable | Changes with infrastructure modifications | Network diagrams, switch/router configs, CMDB | | 7 | Archival media | Long-term | Stable unless damaged or degaussed | Tape backups, offline backups, cold storage |

Step 3: Volatile Data Capture

Capture volatile data BEFORE any containment action that would alter system state (network isolation may be acceptable; reboot, shutdown, or reimaging destroys volatile evidence).

3a: Memory Acquisition

Memory is the single most valuable volatile evidence source. It contains running processes, network connections, encryption keys, malware that exists only in memory, and fragments of user activity.

Linux memory acquisition:

# Using LiME (Linux Memory Extractor)
sudo insmod lime-$(uname -r).ko "path=/evidence/[hostname]_memory_[YYYYMMDD_HHMM].lime format=lime"

# Compute integrity hash immediately
sha256sum /evidence/[hostname]_memory_[YYYYMMDD_HHMM].lime > /evidence/[hostname]_memory_[YYYYMMDD_HHMM].lime.sha256

Windows memory acquisition:

# Using WinPmem
winpmem_mini_x64.exe E:\evidence\[hostname]_memory_[YYYYMMDD_HHMM].raw

# Using DumpIt (single executable, ideal for incident response)
DumpIt.exe /OUTPUT E:\evidence\[hostname]_memory_[YYYYMMDD_HHMM].dmp

# Compute integrity hash
certutil -hashfile E:\evidence\[hostname]_memory_[YYYYMMDD_HHMM].raw SHA256

Virtual machine memory:

# VMware: Suspend VM and collect .vmem and .vmsn files
# Hyper-V: Create checkpoint, export .bin memory file
# AWS EC2: No direct memory access -- use SSM or agent-based collection
# Azure VM: No direct memory access -- use agent-based collection

3b: Volatile System State

Capture the following before any containment action alters system state:

Network state:

# Active connections
netstat -anop (Windows) / ss -tunaop (Linux)

# Routing table
route print (Windows) / ip route show (Linux)

# ARP cache
arp -a (Windows/Linux)

# DNS cache
ipconfig /displaydns (Windows) / check nscd or systemd-resolved cache (Linux)

# Listening ports and associated processes
netstat -tlnp (Linux) / netstat -bno (Windows)

Process state:

# Running processes with full command lines
tasklist /v /fo csv (Windows) / ps auxwww (Linux)

# Process tree
wmic process get ProcessId,ParentProcessId,CommandLine (Windows) / pstree -p (Linux)

# Open files by process
handle.exe -a (Windows, Sysinternals) / lsof (Linux)

# Loaded DLLs/shared libraries
listdlls.exe (Windows, Sysinternals) / cat /proc/[pid]/maps (Linux)

User and session state:

# Logged-in users
query user (Windows) / w (Linux)

# Recent logon events
wevtutil qe Security /q:"*[System[EventID=4624]]" /c:50 /f:text (Windows)
last -50 (Linux)

# Scheduled tasks / cron jobs
schtasks /query /fo csv /v (Windows) / crontab -l; ls /etc/cron.* (Linux)

3c: Temporary File Systems

# Windows temporary files
dir %TEMP% /s /o-d (sorted by date, newest first)
dir C:\Windows\Temp /s /o-d

# Linux temporary files
ls -latr /tmp /var/tmp /dev/shm

# Pagefile / swap (contains memory fragments)
# Windows: C:\pagefile.sys, C:\hiberfil.sys -- copy before shutdown
# Linux: Identify swap partitions with 'swapon --show' and image them

Step 4: Non-Volatile Data Capture (Disk Imaging)

Create a forensically sound disk image -- a bit-for-bit copy that preserves all data including deleted files, slack space, and unallocated areas.

Forensic imaging principles:

• Always write to a SEPARATE destination drive -- never write to the evidence drive
• Use write blockers (hardware or software) when connecting evidence drives
• Create a full bitstream image, not a logical copy
• Compute hash before, during, and after imaging to verify integrity
• Image the entire disk, not individual partitions

Linux disk imaging with dc3dd:

# Full disk image with built-in hashing
dc3dd if=/dev/sda of=/evidence/[hostname]_disk_[YYYYMMDD].dd hash=sha256 log=/evidence/[hostname]_disk_[YYYYMMDD].log

# Verify image integrity
dc3dd if=/evidence/[hostname]_disk_[YYYYMMDD].dd hash=sha256  sg_config_[YYYYMMDD].json
aws iam get-account-authorization-details --output json > iam_config_[YYYYMMDD].json

# Capture instance metadata
aws ec2 describe-instances --instance-ids i-XXXX --output json > instance_meta_[YYYYMMDD].json

Azure:

# Create managed disk snapshot
az snapshot create --resource-group [RG] --source [disk-id] --name forensic-snap-[YYYYMMDD]

# Export Azure Activity Log
az monitor activity-log list --start-time YYYY-MM-DDT00:00:00Z --end-time YYYY-MM-DDT23:59:59Z

# Export NSG Flow Logs (must be enabled in advance)

GCP:

# Create persistent disk snapshot
gcloud compute disks snapshot [disk-name] --zone [zone] --snapshot-names forensic-snap-[YYYYMMDD]

# Export Cloud Audit Logs
gcloud logging read 'timestamp>="YYYY-MM-DDT00:00:00Z" AND timestamp<="YYYY-MM-DDT23:59:59Z"'

Cloud forensic considerations:

• Snapshots are not bitstream images -- they capture allocated blocks only, not unallocated space or slack
• Enable VPC Flow Logs, CloudTrail (with log file validation), and audit logging BEFORE incidents occur
• Cloud provider logs are the primary evidence source; without pre-enabled logging, critical evidence may not exist
• Multi-region deployments require evidence collection across all regions
• Serverless environments (Lambda, Cloud Functions) produce only invocation logs -- there is no disk to image

---

4. Findings Classification

| Severity | Label | Definition | Evidence Handling | |----------|-------|------------|-------------------| | P0 | Critical | Evidence of active compromise, data exfiltration, or system destruction. Immediate preservation required. | Full volatile + disk acquisition. Legal hold. External forensics engagement if needed. | | P1 | High | Evidence of unauthorized access or malware presence. Significant investigation value. | Full volatile + disk acquisition. Prioritize within 4 hours. | | P2 | Medium | Evidence of suspicious activity requiring further analysis. Investigation value probable. | Targeted acquisition (specific logs, memory). Prioritize within 24 hours. | | P3 | Low | Supplementary evidence that may support investigation but is not primary. | Log preservation. Disk imaging if convenient. | | P4 | Informational | Contextual information (network topology, configuration baselines) supporting analysis. | Document and preserve digitally. |

---

5. Output Format

Produce the evidence collection report with these exact sections:

## Forensic Evidence Collection Report: [Incident ID]
**Date:** [YYYY-MM-DD]
**Skill:** forensics-checklist v1.0.0
**Frameworks:** NIST SP 800-86, RFC 3227
**Examiner:** [Name or "AI-assisted -- human examiner required for court-admissible evidence"]

### Collection Summary
[3-5 sentences. State what evidence was collected, from which systems,
the order of collection, and any evidence that could not be obtained.]

### Evidence Inventory
| Evidence ID | Type | Source System | Collection Time (UTC) | SHA-256 Hash | Examiner | Storage Location |
|---|---|---|---|---|---|---|
| EVD-0001 | Memory dump | [hostname] | [timestamp] | [hash] | [name] | [location] |
| EVD-0002 | Disk image (E01) | [hostname] | [timestamp] | [hash] | [name] | [location] |
| EVD-0003 | Log export | [source] | [timestamp] | [hash] | [name] | [location] |

### Volatility Order Compliance
| RFC 3227 Priority | Evidence Source | Collected | Notes |
|---|---|---|---|
| 1 | Registers/cache | [Yes/No/N/A] | [Notes] |
| 2 | Routing/ARP/process table/memory | [Yes/No] | [Notes] |
| 3 | Temporary file systems | [Yes/No] | [Notes] |
| 4 | Disk | [Yes/No] | [Notes] |
| 5 | Remote logging data | [Yes/No] | [Notes] |
| 6 | Physical configuration | [Yes/No] | [Notes] |
| 7 | Archival media | [Yes/No/N/A] | [Notes] |

### Chain of Custody
[Include chain of custody form for each evidence item]

### Integrity Verification
| Evidence ID | Acquisition Hash | Verification Hash | Match |
|---|---|---|---|
| EVD-0001 | [hash] | [hash] | [YES/NO] |

### Evidence Gaps
[List any evidence that could not be collected and the reason]

### Cloud Evidence (if applicable)
| Cloud Provider | Resource | Evidence Type | Collected | Notes |
|---|---|---|---|---|
| [AWS/Azure/GCP] | [Resource ID] | [Snapshot/Logs/Config] | [Yes/No] | [Notes] |

---

6. Framework Reference

NIST SP 800-86 -- Guide to Integrating Forensic Techniques into Incident Response

Published by NIST (August 2006), SP 800-86 provides guidance on integrating forensic techniques into the incident response lifecycle. It covers the forensic process across four phases:

1. Collection -- Identifying, labeling, recording, and acquiring data from relevant sources while preserving data integrity. Emphasizes the importance of following a methodical, documented approach.

1. Examination -- Processing collected data using forensically sound methods to extract relevant information. Includes filtering, searching, and pattern matching across data sources.

1. Analysis -- Analyzing the results of examination to derive conclusions relevant to the investigation. Correlating findings across multiple evidence sources.

1. Reporting -- Documenting the methods, tools, findings, and conclusions of the forensic examination in a format suitable for the intended audience (technical, legal, management).

NIST SP 800-86 covers forensic techniques for files, operating systems, networks, and applications. It emphasizes that forensic considerations should be integrated into the organization's incident response process from the outset, not treated as an afterthought.

RFC 3227 -- Guidelines for Evidence Collection and Archiving

RFC 3227 (February 2002, authored by Dominique Brezinski and Tom Killalea) provides best-practice guidelines for evidence collection and archiving in the context of computer security incidents. Key principles:

• Order of volatility -- Collect evidence from the most volatile sources first. The RFC defines the canonical volatility order: registers/cache, routing table/ARP cache/process table/kernel statistics/memory, temporary file systems, disk, remote loggin

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: UnitOneAI
• Source: UnitOneAI/SecuritySkills
• License: MIT
• Homepage: https://www.unitone.ai

Install and usage instructions live in the source repository linked above.