Chapter 6 — Operating systems and virtualization
Lesson map
Lesson 06 published. Map, example, EX016.
flowchart TD
N0["Learning outcomes and connection"]
N1["6.1 What the operating system records"]
N2["6.2 Order of volatility"]
N3["6.3 Virtualization for response"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX016"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["6.1 What the operating system records"]
N2["6.2 Order of volatility"]
N3["6.3 Virtualization for response"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX016"]
[Learning outcomes and connection]
|
v
[6.1 What the operating system records]
|
v
[6.2 Order of volatility]
|
v
[6.3 Virtualization for response]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX016]
Learning outcomes and connection
You will be able to (1) locate the operating-system records a responder needs on Linux and Windows hosts; (2) choose a collection order that respects volatility; and (3) use virtualization features (snapshots, isolation) for response without destroying evidence. Chapter 5 connected techniques to evidence; this chapter goes inside the host.
6.1 What the operating system records
Linux: authentication logs (location varies by distribution), the systemd journal, shell histories (unreliable — users and attackers can disable them), cron and systemd unit files (persistence), package logs. Windows: Security, System and Application event logs, PowerShell operational logs when enabled, scheduled tasks and services (persistence), registry run keys. Both: running processes, network connections, loaded modules and logged-in sessions — all volatile. On permit-app-2, the cron entry was the persistence that mattered, and the process list and network connections had to be captured before isolation changed them.
6.2 Order of volatility
NIST SP 800-86 advises collecting the most volatile data first when it matters: memory and running state, then network connections, then disk. A technologist decides before incidents which hosts justify memory capture (for example, servers handling personal data) and pre-installs or pre-approves the collection tools, so that collection is a runbook step rather than an improvisation. For permit-app-2, this meant capturing memory to the evidence share and hashing it before moving the VM to the quarantine network. The tool was pre-approved, so the analyst followed the runbook rather than asking for permission at night.
6.3 Virtualization for response
Hypervisors and clouds offer powerful response features. A snapshot preserves disk (and sometimes memory) state quickly; it lives inside the same platform, so it must be exported and hashed to become independent evidence. Network isolation of a virtual machine (moving it to a quarantine segment) stops lateral movement while keeping it running for collection. Beware: reverting a snapshot destroys evidence of what happened after it; deleting and rebuilding a VM before collection loses the case. On permit-app-2, both features were used together: a snapshot with memory, exported and hashed, and isolation that left the VM running.
6.4 Worked example (synthetic): a suspicious process on permit-app-2
Fictional. The endpoint agent flags /tmp/.x/kworkerd running as the web service user on permit-app-2, a VM. The runbook "Linux server suspected compromise" is followed:
- Open a case, record time and who approved collection (service owner on call).
- Take a memory capture with the pre-approved tool to the evidence share; hash it.
- Record process list, network connections and open files; hash outputs.
- Request a hypervisor snapshot with memory; export it to the evidence store; hash it.
- Move the VM to the quarantine network (only the evidence share reachable).
- Do not reboot or rebuild until the investigation lead releases the host.
Findings later showed an outbound connection to 203.0.113.77 on port 443 and a cron entry re-launching the binary. Because the VM was isolated rather than rebuilt, the team could confirm the cron persistence and check the other two app hosts for the same entry — one had it.
6.5 Common errors and limits
- Rebooting "to be safe", losing memory and connections.
- Treating an internal snapshot as preserved evidence without export and hash.
- Running investigation tools from the compromised host's own binaries, which may be altered.
- Collecting everything from every host, overwhelming storage and analysts; scope by hypothesis.
The permit-app-2 runbook guards against each of these. It forbids rebooting or rebuilding until the investigation lead releases the host, requires the hypervisor snapshot to be exported to the evidence store and hashed, and uses a pre-approved collection tool rather than the host's own binaries. Its scope came from the hypothesis that the web service user was compromised.
Exercises — chapter 6
Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.
EX016 — Persistence checklist. Steps: list five persistence locations to check on Linux and five on Windows. Rubric: 3 = ten correct locations; 2 = seven; 1 = four; 0 = none.
EX017 — Order of collection. Steps: put these in collection order and justify: disk image, process list, memory, firewall rules, network connections. Rubric: 3 = memory, processes/connections, firewall config, disk with volatility reasoning; 2 = one swap; 1 = random; 0 = none.
EX018 — Snapshot risk. Steps: explain two ways snapshots can harm an investigation and how to prevent each. Rubric: 3 = revert destroys later evidence; snapshot inside compromised platform not independent — export, hash, restrict reverts; 2 = one; 1 = vague; 0 = none.
Chapter synthesis
Know where each operating system records activity and persistence; collect by volatility using pre-approved tools; use isolation and exported, hashed snapshots instead of reboots and rebuilds; and scope collection by hypothesis.
Continue studying — chapter 06 of 30
← Chapter 05 · Course chapter index · Chapter 07 →
Continue to the next authored lesson.