Evidence that survives scrutiny

Why this matters

Most incidents never reach a courtroom, and the handling rules still matter, because they are what make your findings believable — to an insurer, a regulator, a customer's auditor, an internal disciplinary process, or the analyst who inherits the case at the next shift change.

The exam tests this as a set of precise, orderable rules: what to collect first, how to prove it did not change, and when you are out of your depth. They are worth knowing exactly. Evidence handled carelessly is not merely weaker — it is frequently worthless, and the error is discovered long after it can be corrected.

The lesson

Order of volatility

Evidence disappears at different rates, so collect in order of how fast it is going.

From most to least volatile:

1. CPU registers and cache. Effectively uncollectable in practice; listed for completeness and because the exam lists it.
2. RAM — running processes, network connections, loaded modules, injected code, decrypted data, and credentials in memory. Gone at power-off.
3. Network state — active connections, ARP cache, routing table, open ports. Changes by the second.
4. Running system state — logged-on users, scheduled tasks, running services, temporary files.
5. Disk — the filesystem, including deleted-but-unallocated content. Survives reboot; degrades as the system keeps running.
6. Remote and archived logs — centralised logging, SIEM data. Relatively stable, bounded by retention.
7. Backups, archives and physical records. The most durable.

The consequences worth internalising:

• Do not reboot or shut down a host you intend to investigate. Rebooting to "clear" malware destroys everything in memory, which is often where the only evidence of a fileless intrusion lives. This instinct is extremely common and is the single most destructive reflex in incident response.
• Capture memory before disk, and before isolating the host if isolation will trip a process that clears state.
• Even collecting changes the system. Running a tool writes to memory, touches timestamps, and creates log entries. The answer is not to avoid collecting; it is to record what you ran, when, and as whom, so your own footprint is distinguishable from the attacker's. An investigation that cannot tell its own traces from the intruder's has created a problem it cannot solve later.
• Volatility competes with containment, which is the tension lesson 30 closed on.

Acquisition: memory, disk, cloud

Memory is captured with a dedicated acquisition tool writing the image to external storage or a network share. Notes that matter: the capture tool runs on the live system and therefore perturbs it; the image is large; and a memory image is the richest single artefact you can take from a compromised host — processes with their command lines, network connections, injected code, credentials, and often the unpacked malware that never touched disk in readable form.

Disk is acquired either as a full physical image (bit-for-bit, including unallocated space) or a logical/targeted collection (specific files, logs, registry hives, browser history, artefacts of execution). Full imaging is thorough and slow; targeted collection is fast and answers most incidents. Which you choose depends on whether anyone will contest the findings.

Two rules stated explicitly for the exam:

• Use a write blocker when imaging attached physical media, so the acquisition cannot modify the source.
• Prefer imaging a powered-down disk where practical, and remember the trade: powering down destroys memory, so memory comes first.

Cloud and virtual acquisition is different in ways worth knowing, because it is increasingly the actual case:

• Snapshots are the usual mechanism, and they are fast, non-disruptive and natively supported. A snapshot of a running instance's disk plus a memory dump from the hypervisor gets you most of what a physical seizure would.
• You cannot image the underlying hardware. The provider owns it — the shared-responsibility boundary from lesson 21, in its evidentiary form.
• The control plane is itself evidence, and often the most important: API audit logs, identity logs, configuration history. In cloud incidents the interesting activity is frequently API calls, not anything on a host.
• Ephemeral resources vanish, taking their evidence. Preserve first, analyse second: snapshot before anyone terminates the instance, and make "do not delete it" the first message you send.
• Provider assistance may be required for some data, and requesting it takes time you should start early.

Whatever the medium: preserve first, analyse later. The instinct to start looking immediately has destroyed more evidence than any attacker.

Hashing, chain of custody and documentation

Three mechanisms that together let someone else trust what you hold.

Hashing. Compute a cryptographic hash of the image at acquisition, record it, and recompute it later to demonstrate the data has not changed. This is what converts "here is a copy" into "here is a copy provably identical to what was taken". Use a current algorithm — SHA-256 — and note that MD5 still appears in older tooling and is unsuitable for anything contested.

Chain of custody. An unbroken record of who held the evidence, when, and what they did with it. Each entry: item identifier, date and time, who took custody from whom, purpose, and where it was stored. A gap in the chain is an opening for the argument that the evidence was altered, and that argument does not need to be true to be effective.

Documentation, which is the part an analyst controls completely and most often does worst. Record:

• What you collected, from which system, identified unambiguously — hostname and a stable identifier, since hostnames are reused.
• When, in UTC, and the system's clock offset if known.
• How: the tool, its version, the exact command.
• Who performed it.
• The hash, at acquisition.
• Where it is stored, and who can reach it.

The standard to aim at is that someone else could repeat your work from your notes and get the same result. That is also the standard that makes a handover possible, which is the version of this you will use far more often than the legal one.

Working from a copy, never the original

The rule with no exceptions, and the reason for the previous section.

Analysis is performed on a verified copy. The original — the seized disk, the acquired image, the snapshot — is stored unmodified and untouched. Before and after analysis, the working copy's hash is compared to the original's.

Why it is absolute:

• Analysis modifies. Mounting a filesystem can update timestamps. Opening a file changes access times. Some tools write to the volume they are examining.
• Mistakes happen, and with a preserved original a mistake costs a copy rather than the evidence.
• Repeatability is the foundation of credibility. Another examiner must be able to start from the same original and reach the same result.
• A modified original is unrecoverable. There is no undo, and the discovery usually comes much later.

Practically: mount images read-only, use a write blocker on physical media, work in a dedicated analysis environment, and keep the pristine copy somewhere with access control and its hash recorded.

The same logic holds for malware samples in lesson 33 — analyse a copy, in isolation — and it is the same instinct as the whole course's: the check that the thing is unchanged has to be separate from the thing.

When to hand over to a specialist

Knowing the boundary of your competence is a professional skill, and the exam does test it, because the wrong answer is usually "keep going".

Hand over, or bring specialists in, when:

• Legal proceedings or law enforcement are likely. Evidentiary standards rise sharply and procedural errors become fatal.
• The incident is beyond the team's capacity, in scale or in hours. A multi-week response with three people does not end well.
• Specialised expertise is required: deep malware reverse engineering, industrial control systems, mainframes, unusual platforms.
• The insurer or a contract requires it — many policies mandate panel firms, and using someone else can affect cover. This is a preparation item, per lesson 29.
• Independence is needed. An insider investigation, or one where the security team's own actions are in question, needs someone who is not part of the story.
• An executive or a regulator will need to rely on the findings, and an external report carries weight an internal one does not.

What to do while waiting for them, which is the practically useful half:

• Preserve everything. Do not clean up. Do not reimage. Do not delete the snapshot.
• Stop making changes that are not necessary for containment, and record the ones that are.
• Write down what you have done already, in detail — the first responder's actions are always part of the analysis.
• Keep the evidence secured with the chain of custody started.
• Do not speculate in writing. Early theories in an email tend to resurface as the organisation's position. Record observations as observations and conclusions as conclusions, a distinction lesson 38 returns to.

The judgement to carry: bringing in help is not an admission that you failed. It is a decision made on scope, evidentiary risk and capacity — and the organisations that make it late are the ones that treated it as a verdict on the team instead.

Topics this lesson owns

• [x] Order of volatility
• [x] Acquisition: memory, disk, cloud
• [x] Hashing, chain of custody and documentation
• [x] Working from a copy, never the original
• [x] When to hand over to a specialist