SECURITY REVIEW
Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Community / AGENT SKILL
collecting-volatile-evidence-from-a-suspect-host
0
Collects volatile evidence from a potentially compromised host in correct order of volatility: memory, network state, running processes, logged-on users, and open handles, while preserving integrity and minimizing footprint. Activates for requests to collect volatile evidence, perform live response, or capture host state before shutdown.
Understand the trade-offs.
SKILL QUALITY
Not yet assessed
How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.
No quality assessment is available for this catalog entry yet.
The full skill.
Original instructions from the publisher’s SKILL.md
# Collecting Volatile Evidence from a Suspect Host ## When to Use - A host is suspected of compromise and you must capture state that disappears on reboot. - You are performing live response before isolating or imaging the machine. - You need an ordered, integrity-preserving collection for later analysis. **Do not use** this as a substitute for full disk imaging when persistence matters — volatile collection complements, not replaces, a forensic image. And do not reboot before collecting. ## Prerequisites - Trusted, statically linked collection tools run from external media (not host binaries). - Authorization to collect, and a destination on external/write-once media. ## Safety & Handling - Assume host tools are compromised; use your own trusted binaries to avoid rootkit deception. - Hash every artifact at collection time and record actions for chain of custody; minimize changes to the host. ## Workflow ### Step 1: Follow the order of volatility Collect most-volatile first (RFC 3227): CPU/registers and cache → RAM → network state and connections → running processes → logged-on users/sessions → open files/handles → then disk. ### Step 2: Capture memory first Acquire a full RAM image with a trusted acquisition tool before anything that alters memory; it is the richest and most perishable source. ### Step 3: Snapshot network and process state Record active connections, listening ports, ARP/DNS cache, running processes with command lines and parent links, and loaded modules. ```bash python scripts/analyst.py manifest ./collection --case IR-42 --host WS01 ``` ### Step 4: Record users and handles Capture logged-on users, sessions, scheduled tasks, and open handles/files. ### Step 5: Hash, log, and hand off Hash each artifact, write a collection manifest with timestamps, and transfer to the analysis environment preserving integrity. ## Validation - Artifacts are collected in order of volatility, memory first, before any reboot. - Every artifact has a recorded hash and collection timestamp in the manifest. - Trusted external tools were used; host changes are documented. ## Pitfalls - Rebooting or shutting down before capturing RAM, destroying the best evidence. - Using the host's own (possibly trojaned) tools and trusting their output. - No hashing/manifest, undermining evidentiary integrity. ## References - See [`references/api-reference.md`](references/api-reference.md) for the manifest helper. - RFC 3227 and NIST SP 800-86 (linked in frontmatter).