36 — Forensics, IR and Cloud Tools
Level: Advanced · Time: ~22 min · Prerequisites: Lesson 35 — SIEM, Logging and Monitoring Stacks
Why this matters
Lesson 24 gave you the incident response process; Lesson 25 covered digital forensics. This lesson is the software behind both, plus the half of the estate that barely existed a decade ago: cloud accounts and containers. What you can prove after an incident depends entirely on what you collected before it, in the right order, with a hash attached. The tools here are how a small team does that credibly — and how it avoids the two mistakes that end an investigation early, which are switching the machine off and copying the wrong thing.
The mental model: what each source can still tell you
| Source | What only it holds | What destroys it |
|---|---|---|
| Memory | running processes (including ones that never touched disk), network connections at the instant of capture, injected code in a legitimate process, credentials and keys in use | shutting the machine down, a crash, or a reboot by a helpful colleague |
| Disk | the file system and its history: deleted files, logs, artefacts, the order things happened | continued use — every write overwrites something you may need |
| Targeted collection | the artefacts you chose, from many machines, fast | delay: logs rotate and in-memory state disappears |
| Cloud control-plane logs | what an attacker did to your account: identity changes, resource changes, data access | never having enabled them in the first place |
Order of volatility is the rule that governs everything: capture the most perishable thing first (memory), then live network state, then the disk. Everything below assumes you are working on your own systems, or on systems you have explicit written authority to investigate.
Memory forensics
A memory image is the only place some evidence ever exists. Fileless malware runs from memory, an attacker's network connections exist only in the kernel's tables, injected code lives inside a legitimate process's address space, and the credentials or keys an attacker was using are sitting in memory because they were in use seconds ago.
The reference framework is Volatility, and the conceptual shape matters more than any single plugin: a core framework plus symbol tables that teach it how to read a particular kernel, with plugins as an ecosystem on top. Older versions made you remember the exact profile for the operating system build; the modern version asks for symbol tables instead, fetching them automatically for common kernels or installing them for offline analysis.
vol -f /mnt/evidence/memory.raw windows.pslist # processes, with parent relationships
vol -f /mnt/evidence/memory.raw windows.netscan # network connections as of capture
vol -f /mnt/evidence/memory.raw windows.malfind # memory regions that look injected
vol -f /mnt/evidence/memory.raw windows.cmdline # the command line each process ran with
| Plugin area | The question it answers |
|---|---|
| Process listing | what was running, in what parent-child order, and what is present in memory but absent from the active list |
| Network connections | who this host was talking to at the moment of capture — often the single most useful artefact |
| Injected and hidden code | which processes contain executable memory that is not backed by a file on disk |
| Command lines and handles | what the process was told to do, and which files and keys it held open |
| Registry and configuration hives | persistence, accounts and system settings as they were at capture time |
Two operational rules decide whether any of this is possible. First, memory must be captured before shutdown or it is gone — a polite reboot is the most effective anti-forensic tool available to an attacker who never has to lift a finger. Second, capture is itself an action on a live system: use an open-source acquisition tool appropriate to the platform, write the image to external storage, and hash it immediately.
Disk forensics and the timeline
A forensic suite does six jobs: acquire the image bit for bit, parse the file system, recover deleted files, extract artefacts, search by keyword, and build a timeline. The classic open-source combination is The Sleuth Kit for the file system work, with Autopsy on top as the graphical case interface.
mmls image.dd # partition layout: what is on this disk
fls -r -m / image.dd > bodyfile.txt # recursive listing, in body-file format
mactime -b bodyfile.txt -d 2026-01-01..2026-01-15 > timeline.csv
fls lists files — including deleted ones — and -m / records them with the metadata fields a timeline needs; mactime then turns that into dates, which is where the picture forms. When you need every timeline source at once, a purpose-built timeline tool builds a super-timeline from file system metadata, logs, registries and more:
log2timeline.py --storage-file case.plaso /mnt/evidence/image.E01
psort.py -o l2tcsv -w timeline.csv case.plaso "date > '2026-01-14'"
The timeline view is the whole point. Every incident question is ultimately "what happened in what order", and a timeline is the only artefact that answers it: this file was created four minutes after that process started, which was two minutes after the connection was made. Build it early, sort it ascending, and read it as a story.
Purpose-built forensic distributions and bootable environments — SIFT Workstation, CAINE, Tsurugi, DEFT — ship these tools with sane defaults. The reason to use one is not convenience but method: you examine a disk from a separate live environment, never by booting the suspect system. Booting writes to the disk, changes timestamps, and can destroy the evidence you came for. Take an image with a write blocker in the path, then work on the copy.
Collection at scale, carving, imaging and custody
The biggest practical change in modern incident response is that you no longer visit machines. The collection tool from Lesson 32 — Velociraptor, with its query language and packaged artefact collections — runs a hunt across every enrolled endpoint and returns targeted artefacts from the whole estate in minutes rather than days. It complements the endpoint query engine rather than replacing it: the query engine answers your standing questions continuously, while the collection tool gathers deep artefacts on demand for one specific investigation.
Not everything needs a file system analysis. When you need to recover files or find strings inside a large image, carving and streaming extraction get there faster:
bulk_extractor -o /mnt/out image.dd # streams through, extracting emails, URLs, features
foremost -i image.dd -o /mnt/carved # recovers files by header and footer signatures
strings -a -n 8 image.dd | grep -i 'password' # crude, fast, and often productive
For acquisition, use a tool built for it rather than a copy command: dc3dd or dcfldd for hash-verified raw images, ewfacquire for a compressed E01 with case metadata, and a graphical acquirer when someone else needs to reproduce your steps. The distinction to internalise: a file copy is not an image. A copy gets the live files, not the deleted ones, not the slack space at the end of each cluster, and not the partition table — and it produces nothing you can verify against a hash taken at capture time. Every acquisition computes a hash when the image is taken, records it, and re-verifies the copy afterwards.
Chain of custody is a process, not a product, and it is worth stating plainly because it is the part that gets an investigation thrown out: who collected the evidence, from which machine, at what time, using which tool and version, the hash before and after, where the media is stored, and who has had access since. Case-management software gives you a place to record it; discipline is what fills it in.
The cloud and container half
Cloud accounts fail differently from servers: the attacker usually has legitimate credentials, the "network" is an API, and your provider keeps the only complete record. Four tool families cover most of it.
| Family | Examples | What it answers |
|---|---|---|
| Account posture auditing | Prowler, ScoutSuite |
what is misconfigured across identity, storage, networking and logging |
| Query-based auditing | a SQL-over-cloud-API tool | specific questions across resources, in a language you already know |
| Infrastructure and image scanning | Checkov, tfsec, Trivy |
what is wrong in the code and the image, before it is deployed |
| Runtime and benchmark checks | Falco, kube-bench |
what is happening now, and how the cluster scores against a published baseline |
Posture tools enumerate an account and report hundreds of findings against a framework, with a --compliance style option to score against a named benchmark. Two honest observations: they are noisy on first run, because many findings are policy decisions rather than defects (a bucket that is intentionally public, an unencrypted volume in a sandbox), and they are meant to be run repeatedly — the value is the delta between this month and last, not a single heroic scan. An alternative posture tool with a different philosophy produces a service-by-service report you can hand to an owner, which is sometimes more useful for persuading people than a list of rule IDs.
The query-based approach is the one a small team gets the most out of, because it lets you ask the questions your environment actually raises — which resources are exposed to the internet, which identities can assume a privileged role, which storage buckets have logging switched off — in SQL-like statements, and it can extend to your infrastructure-as-code definitions so a misconfiguration is visible in a review rather than after deployment. Scanning belongs in the pipeline for the same reason: an image scanned in continuous integration is a build failure; the same image scanned after deployment is an incident.
Runtime container detection watches system calls and alerts on behaviour that should never happen: a shell spawned inside a container, a package manager running, a write below /etc, a container mounting a path from the host, an unexpected outbound connection. On the cluster side, the Kubernetes benchmark checker scores the cluster against the published CIS Benchmark and tells you which of the expensive defaults you left switched on.
Cloud logs come first, before any of those tools. The provider's control-plane log is the only record of what an attacker did to your account, and it cannot be reconstructed later.
| Provider | Enable first | Why |
|---|---|---|
| AWS | a CloudTrail trail to object storage, with log-file validation and retention you control, plus the data events that matter; VPC flow logs; storage access logging | the console's default event history is short; a trail is what gives you months, and validation proves it was not edited |
| Azure | Activity Log export, and Entra ID sign-in and audit log export | identity is where cloud intrusions show up first |
| GCP | Cloud Audit Logs — admin activity is recorded by default, but data access logging is off for many services until you turn it on | without data access logs you cannot tell whether anything was read |
Two hard truths to leave with. The person whose key was stolen is often the same person who can delete the logs, so the log destination needs its own account and immutable storage. And the identity provider's logs — sign-ins, MFA changes, role assumptions — are the first place to look in a cloud incident, long before you look at a server.
Mapping tools to the response phases
| IR phase (Lesson 24) | What you need at that moment | The tool |
|---|---|---|
| Preparation | an estate you can query, agents deployed, collection artefacts staged, acquisition tools ready | the query engine and collection tool from Lesson 32, plus a documented evidence-handling procedure |
| Detection and analysis | logs, network records, endpoint detections | the platform from Lesson 35, with the sensors from Lesson 31 |
| Triage and collection | the relevant artefacts from many machines at once, and memory before shutdown | the at-scale collection tool; an open-source memory acquisition tool |
| Analysis | what happened, in what order, to whom | the memory framework, the disk suite, the timeline builder, carving for unallocated space |
| Containment | isolate without destroying what you may need | network controls from Lesson 34, cloud credential revocation, account disablement — memory first |
| Eradication | remove the foothold and everything it left behind | rebuild from a known-good image, patch, and rotate every credential the host could read (Lesson 33) |
| Recovery | return to service without returning to the same state | verified restores using checksum-verified backups, with heightened monitoring for the same behaviour |
| Post-incident | what to change, with evidence attached | the case record and the timeline from the analysis, feeding new rules into the detection platform |
[!WARNING] Every tool on this page is for authorised incident response and sanctioned testing only. One line to keep in mind for the whole discipline: evidence must be acquired without altering it, hashed at the moment of capture, and accounted for from acquisition to presentation — or it is not evidence.
Attack it / Defend it
| The attack | How it works | The control that stops it |
|---|---|---|
| Fileless malware | run entirely from memory, never touching disk | memory acquisition and analysis, plus behavioural endpoint detection |
| Helpful reboot | destroy volatile evidence by restarting the machine | a documented order of volatility, and training that says call first, reboot never |
| Timestomping | falsify file timestamps to break the story | timeline cross-checks against other sources: logs, registry, network records |
| Log and artefact deletion | remove the record on the host | centralised collection off the host, integrity monitoring of log configuration |
| Anti-forensic wiping | overwrite unallocated space to destroy deleted files | early imaging with a write blocker, and carving before the space is reused |
| Container escape | exploit a privileged or over-mounted container | no privileged containers, read-only file systems, runtime detection on the host |
| Over-permissive cloud role | use a legitimate identity with far too much scope | posture auditing, least privilege, short-lived credentials, access reviews |
| Destroyed cloud logs | delete the trail that recorded the intrusion | immutable storage in a separate account, log-file validation, retention you control |
Key takeaways
- Order of volatility rules everything: memory first, then live state, then disk. A reboot costs you more evidence than any tool can recover.
- A copy is not an image. Bit-for-bit acquisition with a hash taken at capture time is what makes a finding provable.
- The timeline is the deliverable. Every incident question reduces to what happened in what order, and a super-timeline is how you answer it.
- Collection at scale changed response more than any single tool. Asking two hundred machines at once replaces a two-day walk-around.
- Cloud logs must be enabled before the incident, in storage the attacker cannot reach — the provider's record is the only one that exists.
Check yourself
- A workstation is suspected of running fileless malware. What do you capture first, what destroys it, and which two plugin areas would you query in the image?
- Why is a
cpto an external disk not a forensic image, and name three things it misses. - You have file system metadata, event logs and registry artefacts from three different sources. Which tool produces a single ordered view, and what question does that view answer?
- An account administrator leaves and you suspect cloud resource abuse. Which log do you look at first, and what would you have had to enable beforehand?
- A container is found running a shell as root. Name two controls that would have prevented it and one that would have alerted you.