25 — Digital Forensics Basics
Level: Intermediate · Time: ~20 min · Prerequisites: Lesson 24 — Incident Response
Why this matters
Detection tells you that something happened. Forensics tells you what it was: which account, which entry point, which files were touched, whether data left, and whether the attacker can come back. Those are the four questions a manager, an insurer and a regulator will all ask, and none of them are answered by "we saw an alert". It matters even when nothing is taken, because you cannot close an entry point you have not identified — a ransomware event that is "cleaned up" without forensics is usually a first wave. And it matters because the decisions you make in the first ten minutes, almost all of them about whether to touch the machine, determine whether the answers exist at all.
This lesson is not how to run a full investigation. It is how to behave so that someone competent can still run one afterwards — which is a skill every administrator and small-team defender actually needs.
The mental model: order of volatility
Evidence is lost at different speeds. The classic order of volatility, from most fragile to most durable, is CPU registers and cache, then memory, then network state, then disk, then backups and archives. Everything practical about forensics follows from that one ordering.
| Layer | What lives there | Survives a reboot? | How you capture it |
|---|---|---|---|
| Registers and cache | data in flight inside the processor | no — lost in microseconds | you cannot; it is gone before you arrive |
| Memory (RAM) | running processes, network connections, injected code, decryption keys, credentials used in cleartext | no — lost on power-off | capture memory first, with a memory acquisition tool |
| Network state | open sockets, established sessions, ARP cache, routing table, and the traffic itself | mostly no | ss, netstat, ip neigh, arp -a, then packet capture or flow records |
| Disk | file system metadata, event logs, browser history, execution artefacts, registry hives | yes — with caveats | image the disk with a write blocker |
| Backups and archives | older states of the same system, which is how you find the file that was deleted | yes | pull the relevant retention window |
| Remote logs | firewall, DNS, VPN, proxy, cloud audit records | yes — until retention expires | copy promptly; retention is often only 7–90 days |
[!WARNING] The single most destructive thing you can do in a suspected incident is power the machine off, or reboot it "to see if the problem clears". A reboot destroys the memory image, which is where the encryption keys, the running implant and the live network connections live. If the machine is on and you suspect a compromise, leave it on, disconnect it from the network, and capture memory before anything else.
Two rules follow, and they are the whole of beginner forensics:
- Capture memory before you power anything off.
- Document before you touch. Write down what you see, the time, the hostname and serial, and what you are about to do — before you do it. Untraceable actions make every later artefact suspect.
Where evidence lives
Endpoint disk — Windows
| Artefact | Location | What it answers |
|---|---|---|
| Event logs | C:\Windows\System32\winevt\Logs\ (.evtx) |
logons (4624, 4625, 4648), process creation (4688), services installed (7045), scheduled tasks created (4698), audit log cleared (1102) |
| File system metadata | $MFT, $UsnJrnl:$J on an NTFS volume |
which files existed, were created, renamed or deleted, and when |
| Execution artefacts | C:\Windows\Prefetch\*.pf, Amcache.hve, the AppCompatCache value in the SYSTEM hive |
what actually ran on this machine, even after the binary is deleted |
| Registry hives | C:\Windows\System32\config\{SAM,SYSTEM,SOFTWARE,SECURITY}, user NTUSER.DAT |
local accounts, services, autoruns, USB history, wireless networks, recent documents |
| Persistence | C:\Windows\System32\Tasks\, HKLM\Software\Microsoft\Windows\CurrentVersion\Run, service keys under HKLM\SYSTEM\CurrentControlSet\Services |
how the attacker survives a reboot |
| Browser and shell history | the History SQLite file in each browser profile; %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt |
what the user browsed and typed |
| Recent activity | %APPDATA%\Microsoft\Windows\Recent (LNK files, jump lists), C:\Windows\System32\sru\SRUDB.dat |
documents opened and applications used, with per-process network and CPU usage over time |
Endpoint disk — Linux
| Artefact | Location | What it answers |
|---|---|---|
| Authentication log | /var/log/auth.log (Debian family), /var/log/secure (Red Hat family), journalctl |
who logged in, from where, and what sudo was used |
| Audit trail | /var/log/audit/audit.log with auditd |
file access, process execution and syscall-level detail if it was configured in advance |
| Accounts and privilege | /etc/passwd, /etc/shadow, /etc/sudoers, /etc/sudoers.d/ |
accounts that exist and who can escalate |
| Persistence | /etc/crontab, /etc/cron.d/, /var/spool/cron/crontabs/, /etc/systemd/system/, ~/.config/systemd/user/, /etc/rc.local, ~/.bashrc, /etc/ld.so.preload |
how an intruder returns |
| Shell history | ~/.bash_history, ~/.zsh_history |
commands run — note that timestamps exist only if history timestamps were enabled beforehand |
| Logon records | last, lastb, /var/log/wtmp, /var/log/btmp, /var/log/lastlog |
successful and failed logons with times |
| File timestamps | stat, and the ext4 inode metadata |
modification, inode change and access times — remembering that access times are usually relaxed and that ctime is metadata-change time, not creation time |
Memory, network, cloud and mobile
| Source | Examples | What it answers |
|---|---|---|
| Memory | process list and command lines, loaded modules, network connections, handles to files, injected code, plaintext credentials and keys | what was running right now, including things that never touched the disk |
| Network | full packet captures, flow records (NetFlow or IPFIX), DNS query logs, firewall logs, proxy logs, VPN and RADIUS logs | whether data left, to where, how much, and which internal host did it |
| Cloud | the provider's control-plane audit log of API calls, object storage access records, identity sign-in logs, virtual network flow logs | who changed what in the account, and which identity did it |
| Mobile | call and message databases, application data containers, location history, backups | what a device did when it was not on your network — usually the hardest evidence to obtain lawfully |
[!TIP] For a small organisation the highest-yield sources are almost always these four: the authentication log, the DNS query log, the firewall egress log and the endpoint's own event log. Check that they exist and are retained for longer than your incident response window before you need them.
The process, and the integrity mechanics
| Step | What it means in practice |
|---|---|
| Identify | what systems are involved, what data they hold, who has authority to examine them, and what may legally be looked at |
| Preserve | stop the bleeding without destroying evidence: isolate the host at the network, not at the power switch; do not run a cleaner, a "fix" or an antivirus with automatic quarantine on the system under investigation |
| Acquire | take a copy — memory first if the host is live, then a disk image through a write blocker, writing to separate media |
| Analyse | work on the copy, never on the original; build a timeline; answer the questions you set out at the start |
| Report | what happened, what the evidence supports, what it does not, and what should change |
Integrity is the part beginners skip, and it is the part that makes the work worth anything:
- A write blocker is either hardware or software that guarantees nothing is written to the source. Software versions include
blockdev --setroand mounting read-only. On Linux, mount images withmount -o ro,noload— withoutnoloadthe kernel will replay the journal and modify the image, which quietly invalidates your hash. - Hash the image immediately and re-hash it every time it changes hands. Identical hashes prove the copy is unchanged since acquisition.
- A chain of custody records who handled what, when, where and why, from acquisition to the end of the case.
# 1. Identify the disk and note the serial number for the record
lsblk -o NAME,SIZE,MODEL,SERIAL
# 2. Protect the source from accidental writes
sudo blockdev --setro /dev/sdb # and confirm with: blockdev --getro /dev/sdb
# 3. Image it, hashing as you go (dc3dd is dd with hashing and logging built in)
sudo dc3dd if=/dev/sdb of=/mnt/evidence/host01.disk.img \
hash=sha256 log=/mnt/evidence/host01.disk.log
# 4. Hash the image file itself, then verify later that nothing changed
sha256sum /mnt/evidence/host01.disk.img | tee /mnt/evidence/host01.disk.sha256
sha256sum -c /mnt/evidence/host01.disk.sha256
# 5. A live Linux host: capture memory before anything is stopped (LiME or AVML)
sudo insmod ./lime.ko "path=/mnt/evidence/host01.mem format=lime"
sudo ./avml /mnt/evidence/host01.mem
A chain of custody record needs, at minimum: case reference; exhibit reference and a one-line description including the serial number; who acquired it, when and where; the tool and version used; the hash value; and every transfer afterwards, with names, times, reasons and storage location.
Timeline analysis: how artefacts become a story
One artefact is an anecdote. A timeline is evidence. The technique is to extract timestamps from every source you have — file system metadata, event logs, browser history, registry keys, authentication records, network flows — normalise them into one ordered list, and read the sequence.
Two cautions decide whether your timeline is trustworthy. The first is time synchronisation: if one host's clock is four minutes out, or in a different timezone from your logs, the correlation you build is fiction. The clock discipline from Lesson 22 is the prerequisite for this lesson. The second is that timestamps mean different things: file modification time, metadata-change time and access time are three different fields, and access times are usually not written at all on modern systems because the kernel relaxes them for performance.
# File system MAC times from an image, without mounting it (Sleuth Kit)
fls -r -m / host01.disk.img > bodyfile.txt
mactime -b bodyfile.txt -d > timeline.csv
# A super-timeline across artefacts in one pass (plaso), then export it
log2timeline.py --storage-file host01.plaso host01.disk.img
psort.py -o l2tcsv -w timeline.csv host01.plaso
For finding content rather than times, carving recovers files and strings from unallocated space, where deleted material often still sits:
A worked example: "the machine is behaving strangely"
A user reports that their laptop is slow, the fan runs constantly and a browser tab keeps reappearing. Here is the order to work in, and what each step tells you.
| Order | Artefact | What it tells you |
|---|---|---|
| 1 | ps auxf or the task list, and ss -tulpn / netstat -ano |
whether something is running that should not be, and what it is talking to right now |
| 2 | Logged-in users and recent logons (who, w, last, security event 4624) |
whether anyone else is on the machine, and whether the logons match the user's story |
| 3 | Memory capture | the running implant, its keys and its configuration, preserved before anything changes |
| 4 | Command history (~/.bash_history, PowerShell console history) |
what was typed, which is often the most human-readable evidence available |
| 5 | Execution artefacts (prefetch, Amcache, ShimCache; ~/.bash_history plus package and binary timestamps on Linux) |
what ran recently, including binaries that are now deleted |
| 6 | Persistence locations (scheduled tasks, services, autoruns, cron, systemd units) | how it comes back after a reboot |
| 7 | Authentication and audit logs, then DNS and egress logs | where it came from and whether anything was sent out |
| 8 | Build the timeline across all of the above | the sequence, which is what you report |
Steps 1 to 4 are the volatile ones and must be done while the machine is still running. Step 3 happens before step 4 in a real incident, because memory is gone the moment the machine stops.
Tooling, and when to stop
| Job | Open-source tooling | Notes |
|---|---|---|
| Disk imaging | dc3dd, ddrescue, Guymager, dd |
ddrescue for a failing disk; Guymager for a graphical, hash-logging workflow |
| Memory capture and analysis | LiME, AVML to capture; Volatility 3 to analyse (vol -f host01.mem windows.pslist, windows.netscan) |
capture format matters; analysis is read-only on the copy |
| File system and timeline | The Sleuth Kit (fls, istat, mactime), Autopsy for a graphical front end; plaso and Timesketch for super-timelines |
examine the image, never the live disk |
| Carving and content search | bulk_extractor, Foremost, Scalpel |
recovers deleted and unallocated content |
| Endpoint triage at scale | Velociraptor | collect the same artefacts from many hosts, in a recorded and repeatable way |
Lesson 36 goes deeper on all of this. One practical point now: a Linux live distribution is the usual way to examine a disk without altering it. You boot the suspect disk as a source only, from a separate medium, and work on the copy. It is also how you investigate a machine whose own operating system you no longer trust.
When to stop and call a professional. If legal action is likely, if a regulatory notification may be required, if an employee is a suspect, or if the breach is large or still spreading, your job is to preserve and escalate — not to investigate. Amateur handling destroys evidence: mounting a disk read-write, rebooting a host, running a cleaner, opening files, or simply failing to document what was done all make the artefact worthless in a proceeding. A preserved image and an honest note of what you did is a good outcome. A half-investigated machine with no records is a bad one.
Legal and privacy, practically. Disk images and logs are almost always personal data under the GDPR, which means a purpose, a lawful basis, and no more access than that purpose needs — do not browse a colleague's mail because you can. In France, monitoring an employee's activity requires that staff be informed and that the monitoring be proportionate, and where a works council exists it must be consulted; the data protection authority publishes practical guidance on this and is the right place to check. Access to evidence should be limited by role and logged. None of this is legal advice: when the incident touches employees, customers or a possible notification, involve your lawyer and your data protection officer before you start reading, not after.
Attack it / Defend it
| The attack | How it works | The control that stops it |
|---|---|---|
| Rebooting or wiping the host | destroys memory and live state; the intruder's tooling and keys are gone | isolate at the network, never at the power switch; document before touching |
| Anti-forensics by timestomping | modification times are altered, so the timeline lies | correlate multiple sources — event logs, USN journal, network flow — instead of trusting one timestamp |
| Log destruction | the audit log is cleared (Windows event 1102) or the logs are deleted | ship logs off-host in real time; alert on log clears and on log pipeline gaps |
| Living off the land | only built-in tools are used, so nothing new is written to disk | memory analysis, command-line and parent-process logging, behavioural detection |
| Encrypted or packed payloads | the binary on disk reveals nothing useful | memory analysis for keys, and behaviour rather than content |
| Fileless persistence | the payload lives in the registry, a scheduled task, or a WMI repository entry | monitor the persistence locations themselves, with file integrity monitoring |
| Timeline corruption by bad clocks | skewed host clocks make correlation impossible and events appear out of order | central, disciplined time synchronisation (Lesson 22) and an alert when a host's clock drifts |
| Evidence contamination by the responder | the first responder runs tools on the original disk or opens the files | write blockers, working copy only, hashes before and after, a written chain of custody |
| Exfiltration that leaves no local trace | data leaves over HTTPS or DNS and the endpoint records little | retain DNS and egress flow logs long enough to answer the question weeks later |
Key takeaways
- Volatility decides your order of operations. Memory before disk, and never power off a live suspect host before memory is captured.
- Documentation is not paperwork, it is the evidence. An undocumented action makes every artefact around it questionable.
- Hash at acquisition and re-hash at every handover. A copy without a verified hash is a copy nobody can rely on.
- Time synchronisation is the enabling condition. Without disciplined clocks there is no timeline, and without a timeline there is no story.
- When it is legal, regulatory or large, preserve and escalate. The professional value of a beginner in an incident is a cleanly preserved image, not a clever guess.
Check yourself
- A user's laptop is visibly mining cryptocurrency. Why is powering it off the wrong first move, and what do you do instead?
- You image a disk and the hash of the image matches at handover a week later. What does that prove, and what does it not prove?
- Name three artefacts that would tell you whether a binary ran on a Windows machine, and one that would tell you when a Linux account last logged in.
- Why can you never trust a single file's modification time to date an event?
- Your organisation is considering GDPR breach notification after an intrusion. What two things must you do before anyone starts examining the affected machines?