Volatile vs Persistent

Volatile evidence lives in RAM and live state; persistent evidence survives reboot — name both on YOUR $DFIR_LAB order-of-volatility map.

Volatile vs Persistent• Audio Walkthrough

00:00/03:34

Visual · t26_volatile_vs_persistent

Volatile/persistent literacy. $DFIR_LAB only. Original Cyberlium.

Power off too early and RAM artifacts vanish — literacy starts with what disappears first.

Volatile evidence includes RAM contents, active network connections, running processes, and some live registry/cache state — lost or altered on shutdown. Persistent evidence includes disk sectors, firmware logs (sometimes), cloud sync files on disk, and archived logs — survives reboot if not overwritten. Cyberlium maps volatile vs persistent on YOUR $DFIR_LAB scenario cards — not live imaging of stranger machines without authority. Next: Disk/Memory/Net/Logs.

1. Volatile evidence (named)

RAM: processes, encryption keys in memory, malware injected only in RAM, clipboard (OS-dependent). Live network: established connections, routing table, ARP cache. Live system: logged-on users, open handles — capture before power-off when policy allows.

On $DFIR_LAB, list three volatile classes for a practice VM scenario — no live stranger host required.

Command guide

Try these commands — Volatile evidence (named)

═══ LINUX / macOS (Malware Static & Dynamic Triage) ═══

Inspect PE / ELF binary headers and sections

Command — copy this

readelf -h sample.bin 2>/dev/null || xxd -g 1 -l 32 sample.bin

Check binary entropy (high entropy often signals packed or encrypted payloads)

Command — copy this

python3 -c "
import math, sys
data = open('sample.bin', 'rb').read() if len(sys.argv) > 1 else b'MZX\x00\x90'
ent = -sum((data.count(bytes([b]))/len(data))*math.log2(data.count(bytes([b]))/len(data)) for b in set(data))
print(f'Calculated File Entropy: {ent:.4f} (Entropy > 7.0 suggests packed/encrypted)')
" sample.bin 2>/dev/null

Primary tools to practice this lesson: curl, python3. Reference sites: Evidence types (https://www.sans.org/cyber-security-skills/digital-forensics/); RFC 3227 (https://www.rfc-editor.org/rfc/rfc3227); CISA IR (https://www.cisa.gov/topics/cybersecurity-best-practices/incident-response). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.

2. Persistent evidence (named)

Disk: files, unallocated space, slack, registry hives on disk, browser databases, event logs stored on volume. Backups and cloud-sync folders on disk are persistent once written — still need authority to collect.

Defenders image disks and pull logs after volatile collection when incident policy permits — order matters.

3. Order-of-volatility literacy

Classic teaching order: network/live capture → memory → disk → logs/archives — adapted to org policy and safety. Forbidden: rebooting a lab victim VM before noting what volatile data you would lose.

Ship: two-column table — volatile vs persistent with one $DFIR_LAB example each. Next: Disk/Memory/Net/Logs.

4. What you ship: volatile vs persistent table for $DFIR_LAB

Two-column table with examples from YOUR practice scenario. $DFIR_LAB named. NO stranger live imaging. chmod 600.

5. What you record before the next lesson

Date. Volatile/persistent table. $DFIR_LAB named. File t26-m02-l01-volatile-vs-persistent.txt chmod 600.

6. Wrong vs right: tampering evidence vs chain of custody

Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.

Wrong: Reboot practice VM before documenting volatile loss. Image stranger laptop live without authority.
Right: Write volatile vs persistent table for YOUR $DFIR_LAB scenario. Next: Disk/Memory/Net/Logs.

Hands-on Exercise