Why Volatile Evidence Matters
Memory can preserve process state, loaded modules, mapped regions, open handles, socket records, command context, and operating-system structures that never reach disk or have already changed. It can connect an endpoint event to the process state present at collection time. It is also fragile: collection changes the system, state disappears, structures vary by version, and an untrusted kernel can mislead tools that rely on it.
Begin with an investigative question. Examples include: Which process owned this synthetic TEST-NET connection? Does an executable region have a corresponding trusted image? Do independent process views disagree? Which process held the fictional document when the simulated impact event began? Collecting everything without a question increases exposure and does not make conclusions stronger.
Sanitization Is Part of Lab Design
A real memory image can contain passwords, tokens, private keys, messages, customer records, source code, and personal activity. It must never be uploaded to a public service or reused as course material. This module uses instructor-authored sanitized JSON observations that model selected views from a disposable fixture VM. No raw memory image is distributed, and the records contain no real accounts, browser profile, cloud identity, employer data, or internet history.
The transformation report lists removed fields and fixed replacements. Network records use TEST-NET addresses and reserved domains. Any string resembling a secret is a labeled dummy value that cannot authenticate anywhere. Learners verify the image and report hashes before analysis and use only offline tools already present in the VM.
Use a Cross-View Workflow
- Record source, acquisition method, operating-system build, collection time, hash, sanitizer version, and known limitations.
- Build the broad inventory: processes with start times, parentage, users, modules, mapped regions, handles, sockets, services, and integrity evidence.
- Compare independent views. Reconcile the process list with scan results, modules with mapped files, sockets with endpoint logs, and boot state with trusted platform records.
- Investigate inconsistencies while preserving alternatives such as terminated processes, race conditions, unsupported structures, tool defects, and legitimate security software.
- Report the smallest evidence-backed conclusion and identify what another source must confirm.
Tool output is an interpretation, not ground truth. Record tool and symbol versions. Validate a surprising result with another view before escalating it as stealth or tampering.
Recognize Family Evidence Safely
| Hypothesis | Sanitized evidence to compare | Boundary |
|---|---|---|
| Injected or hidden execution | Unexpected executable memory, region permissions, missing file backing, thread ownership, and disagreement between process views | The course explains structural evidence but does not create injection or hiding behavior |
| Rootkit or bootkit | Cross-view disagreement, module and driver provenance, boot measurements, integrity records, and collection gaps | A discrepancy also fits tool incompatibility or legitimate low-level software |
| Spyware or stealer | Fictional handles to labeled sensitive objects, unexpected process context, and sanitized access events | No real credential, browser, input, or token data exists in the fixture |
| RAT or bot component | Process lineage, long-lived state, socket ownership, synthetic TEST-NET connections, and endpoint timing | Commands are represented as harmless event labels, never executable content |
| Ransomware or wiper | Process state near the simulated file-impact timeline, object handles, and recovery-control event labels | The fixture performs no encryption, deletion, or recovery change |
| Cryptominer | Synthetic CPU records, worker-thread shape, unexplained module provenance, and pool-like TEST-NET flow metadata | Resource use needs process and workload context |
Scope the Conclusion and the Response
Memory is a snapshot, not a complete incident timeline. Combine it with disk, endpoint, identity, network, deployment, and platform integrity evidence. State whether a conclusion is confirmed, likely, possible, or unsupported, and define those terms for the report. If acquisition may be incomplete or the kernel may be untrusted, involve an authorized specialist and preserve the original evidence.
Do not experiment on a real affected host, search for personal content, or extract authentication material for curiosity. The response objective is to answer approved incident questions with the least exposure necessary.
Suggested Study Plan (6 hours)
The published duration includes active practice, not video playback alone. Complete each block with the course-owned evidence and retain the stated deliverable so another reviewer can reproduce your reasoning.
| Study block | Time | Required evidence |
|---|---|---|
| Guided lesson and primary-source review | 1h 21m | Annotated notes that separate observations, hypotheses, limits, and version-sensitive facts. |
| Worked evidence walkthroughs | 1h 8m | Reproduce the lesson's tables or decision flow and challenge at least two assumptions. |
| Independent practice rounds | 1h 8m | Apply the method to two alternate records in the sanitized evidence pack and compare the conclusions. |
| Required lab | 1h 30m | A cross-view evidence table, a correlated timeline, ranked hypotheses with alternatives, a collection-limit statement, and a privacy-safe escalation note. |
| Knowledge check and review | 53 minutes | Answer the evidence check, review the rubric, and record one production follow-up. |
Evidence Check
Question: One memory view lists a process that the normal process list does not. Does that prove a rootkit?
Reveal the defensive reasoning
No. It is a cross-view discrepancy. Possible explanations include a terminated process, race condition, unsupported structure, acquisition damage, parsing error, or low-level hiding. Validate time, operating-system and symbol compatibility, independent views, integrity evidence, and endpoint records before assigning a rootkit hypothesis.
Primary References
Use these primary sources for the current standard or tool behavior. The course records framework versions so mappings can be reviewed when upstream guidance changes.