collecting-volatile-evidence-from-a-suspect-host

Name: collecting-volatile-evidence-from-a-suspect-host
Author: meltedinhex

18stars5forks

How to install collecting-volatile-evidence-from-a-suspect-host?

meltedinhex/analyst-ai-pack/collecting-volatile-evidence-from-a-suspect-host

$npx -y skills add meltedinhex/analyst-ai-pack --skill collecting-volatile-evidence-from-a-suspect-host

Installs into the current project.

Summary

Collects volatile evidence from a potentially compromised host in correct order of

Files · 1

View on GitHub

SKILL.md

1	# Collecting Volatile Evidence from a Suspect Host
2
3	## When to Use
4
5	- A host is suspected of compromise and you must capture state that disappears on reboot.
6	- You are performing live response before isolating or imaging the machine.
7	- You need an ordered, integrity-preserving collection for later analysis.
8
9	Do not use this as a substitute for full disk imaging when persistence matters — volatile
10	collection complements, not replaces, a forensic image. And do not reboot before collecting.
11
12	## Prerequisites
13
14	- Trusted, statically linked collection tools run from external media (not host binaries).
15	- Authorization to collect, and a destination on external/write-once media.
16
17	## Safety & Handling
18
19	- Assume host tools are compromised; use your own trusted binaries to avoid rootkit deception.
20	- Hash every artifact at collection time and record actions for chain of custody; minimize
21	changes to the host.
22
23	## Workflow
24
25	### Step 1: Follow the order of volatility
26
27	Collect most-volatile first (RFC 3227): CPU/registers and cache → RAM → network state and
28	connections → running processes → logged-on users/sessions → open files/handles → then disk.
29
30	### Step 2: Capture memory first
31
32	Acquire a full RAM image with a trusted acquisition tool before anything that alters memory; it
33	is the richest and most perishable source.
34
35	### Step 3: Snapshot network and process state
36
37	Record active connections, listening ports, ARP/DNS cache, running processes with command lines
38	and parent links, and loaded modules.
39
40	```bash
41	python scripts/analyst.py manifest ./collection --case IR-42 --host WS01
42	```
43
44	### Step 4: Record users and handles
45
46	Capture logged-on users, sessions, scheduled tasks, and open handles/files.
47
48	### Step 5: Hash, log, and hand off
49
50	Hash each artifact, write a collection manifest with timestamps, and transfer to the analysis
51	environment preserving integrity.
52
53	## Validation
54
55	- Artifacts are collected in order of volatility, memory first, before any reboot.
56	- Every artifact has a recorded hash and collection timestamp in the manifest.
57	- Trusted external tools were used; host changes are documented.
58
59	## Pitfalls
60
61	- Rebooting or shutting down before capturing RAM, destroying the best evidence.
62	- Using the host's own (possibly trojaned) tools and trusting their output.
63	- No hashing/manifest, undermining evidentiary integrity.
64
65	## References
66
67	- See [`references/api-reference.md`](references/api-reference.md) for the manifest helper.
68	- RFC 3227 and NIST SP 800-86 (linked in frontmatter).

People who liked this also viewed

6 picks

Type

collecting-volatile-evidence-from-a-suspect-host

18stars5forks

View on GitHub

How to install collecting-volatile-evidence-from-a-suspect-host?

meltedinhex/analyst-ai-pack/collecting-volatile-evidence-from-a-suspect-host

$npx -y skills add meltedinhex/analyst-ai-pack --skill collecting-volatile-evidence-from-a-suspect-host

Installs into the current project.

Summary

Collects volatile evidence from a potentially compromised host in correct order of

Files · 1

View on GitHub

SKILL.md

1	# Collecting Volatile Evidence from a Suspect Host
2
3	## When to Use
4
5	- A host is suspected of compromise and you must capture state that disappears on reboot.
6	- You are performing live response before isolating or imaging the machine.
7	- You need an ordered, integrity-preserving collection for later analysis.
8
9	Do not use this as a substitute for full disk imaging when persistence matters — volatile
10	collection complements, not replaces, a forensic image. And do not reboot before collecting.
11
12	## Prerequisites
13
14	- Trusted, statically linked collection tools run from external media (not host binaries).
15	- Authorization to collect, and a destination on external/write-once media.
16
17	## Safety & Handling
18
19	- Assume host tools are compromised; use your own trusted binaries to avoid rootkit deception.
20	- Hash every artifact at collection time and record actions for chain of custody; minimize
21	changes to the host.
22
23	## Workflow
24
25	### Step 1: Follow the order of volatility
26
27	Collect most-volatile first (RFC 3227): CPU/registers and cache → RAM → network state and
28	connections → running processes → logged-on users/sessions → open files/handles → then disk.
29
30	### Step 2: Capture memory first
31
32	Acquire a full RAM image with a trusted acquisition tool before anything that alters memory; it
33	is the richest and most perishable source.
34
35	### Step 3: Snapshot network and process state
36
37	Record active connections, listening ports, ARP/DNS cache, running processes with command lines
38	and parent links, and loaded modules.
39
40	```bash
41	python scripts/analyst.py manifest ./collection --case IR-42 --host WS01
42	```
43
44	### Step 4: Record users and handles
45
46	Capture logged-on users, sessions, scheduled tasks, and open handles/files.
47
48	### Step 5: Hash, log, and hand off
49
50	Hash each artifact, write a collection manifest with timestamps, and transfer to the analysis
51	environment preserving integrity.
52
53	## Validation
54
55	- Artifacts are collected in order of volatility, memory first, before any reboot.
56	- Every artifact has a recorded hash and collection timestamp in the manifest.
57	- Trusted external tools were used; host changes are documented.
58
59	## Pitfalls
60
61	- Rebooting or shutting down before capturing RAM, destroying the best evidence.
62	- Using the host's own (possibly trojaned) tools and trusting their output.
63	- No hashing/manifest, undermining evidentiary integrity.
64
65	## References
66
67	- See [`references/api-reference.md`](references/api-reference.md) for the manifest helper.
68	- RFC 3227 and NIST SP 800-86 (linked in frontmatter).

People who liked this also viewed

6 picks

Type