Automating forensics
Lesson 2 of 3 in Automated Response and Forensics.
Manual forensics is slow in exactly the way that costs you evidence. By the time a human has found the right account, assumed the right role, worked out which volumes are attached, and remembered that memory has to come before anything that changes power state, the attacker has had twenty minutes and the responder has had three chances to do it in the wrong order.
The exam guide names a specific answer to this: the Automated Forensics Orchestrator for Amazon EC2. Know what it is before what it does — it is an AWS Solution, a reference implementation you deploy into your own accounts with CloudFormation, not a managed service you enable with a checkbox. That distinction is examinable: you own the deployment, the IAM, and the cost, and you can read and modify its state machines. Inside, Step Functions state machines drive the sequence, Systems Manager reaches into the instance, snapshots and artefacts land in a dedicated forensics account, and a tracking table records what was captured, when, by which execution.
Four phases, and it is worth knowing them as phases because exam questions describe a phase and expect you to name the tooling. Triage decides whether this instance is in scope and whether it can be acquired at all. Acquisition isolates, then captures memory, then snapshots disks. Evidence handling moves artefacts into the forensics account, hashes them, and records custody. Investigation runs the automated analysis — building a forensic volume from the snapshot, running the configured tooling against it, and producing a report.
The reason automation wins here is not that it is clever. It is that it is the same every time. A human responder’s capture is correct on a good day and wrong at 04:00; the state machine’s capture is identical in both cases, timestamps are machine-generated rather than remembered, and the ordering constraint that destroys evidence when violated is encoded rather than hoped for.
| Phase | What the orchestrator does | Why automating it matters | What you still decide |
|---|---|---|---|
Triage | Checks the instance is in scope, managed, and acquirable; records the trigger | Removes the "which account was this in again?" minutes | Scope rules — which tags, OUs, and finding types are eligible at all |
Isolation | Applies an isolation security group before touching the instance | Stops the host changing underneath the capture | Whether isolation is acceptable for this workload, or needs approval first |
Memory acquisition | Runs acquisition on the live instance through Systems Manager, uploading the image | Encodes the one ordering rule humans break: memory before any power-state change | Nothing — this should never be optional when the instance is still running |
Disk acquisition | Snapshots every attached volume and records the snapshot ids | Captures volumes a responder would have had to enumerate by hand | Retention of the snapshots, and which key encrypts them |
Evidence handling | Copies artefacts into the forensics account, hashes them, writes the custody record | Machine-generated timestamps and hashes instead of recalled ones | Where the account sits, how long you hold evidence, who may read it |
Investigation | Builds a forensic volume from the snapshot and runs the configured analysis, producing a report | The analysis starts in minutes rather than after a handover | Which tooling runs, and the human analysis the report feeds |
Doing it by hand: the disk
Snapshot every attached volume with ec2:CreateSnapshot (or CreateSnapshots for the whole instance consistently), tag the snapshot immediately with the incident id, the source instance, the capture time and the responder — an untagged snapshot in a busy account becomes an anonymous orphan within a day. Share it to the forensics account and copy it there, which requires a customer managed key, then create a volume from the copy and attach it read-only to an analysis host in a subnet with no egress. Never mount the original volume on a machine you care about.
Doing it by hand: the memory, and why it is urgent
Memory lives only while the instance runs. Acquire it with a tool run through SSM Run Command (writing the image straight to S3, not to the instance’s own disk, so you are not overwriting the evidence underneath you). Nothing else gives you injected code, decrypted secrets held only in RAM, live socket tables, or an attacker process with no on-disk artefact. The sequencing rule is absolute: capture memory before stop, reboot, or terminate. One nuance worth knowing — an instance launched with hibernation enabled writes RAM to its encrypted root volume when hibernated, which can preserve memory contents, but it must have been enabled at launch, so it is a preparation choice rather than a response option.
Doing it by hand: the context around the instance
The instance is not the whole crime scene. Capture DescribeInstances output (AMI id, launch time, instance profile, subnet, security groups, IMDS configuration), the attached IAM role and its policies, the current security group and network ACL rules, the AWS Config configuration timeline for the instance, the VPC Flow Logs for its ENI around the window, and the CloudTrail events for the instance profile’s role session. Half of a real root-cause answer lives in that list rather than on the disk.
Tagging and labelling evidence
Every artefact carries the incident id, the source resource ARN, the capture timestamp in UTC, the acquiring principal, and a hash. Tags on snapshots, object metadata and Object Lock on S3 artefacts, and one row per artefact in the tracking record. The test to apply: six months from now, could a different engineer prove which instance this image came from, when, and that nobody altered it? If not, it is data, not evidence.
What automation does not solve
It still only captures what you deployed it to capture — an instance without the SSM Agent, or outside the orchestrator’s scope rules, is a gap you find during the incident. It cannot acquire memory from a container or a Lambda function, where the equivalents are the task’s logs, the image digest, and the function version. And it makes destructive-looking actions easy, so the approval and exclusion guardrails from the previous lesson apply here too: an orchestrator that can isolate any instance in the organization is a powerful tool and a tempting target.
Key terms: Automated Forensics Orchestrator for Amazon EC2, Memory acquisition, Chain of custody, Forensic artefact
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.