Where it has to be real.

The place that can't lie

Every trick from the earlier labs converges here. A fileless implant never touches disk — but it's a running thread, so it's in RAM. A packed payload is gibberish on disk and plaintext in memory once it unpacks to run. The call-table hooks from Lab 2 are pointers in live kernel structures. The hidden process from Lab 3 still has an EPROCESS object the allocator knows about. The NOP sled from Lab 5 is a committed, executable region somewhere in a victim's address space.

Hunt injected code by its shape

The canonical technique (Volatility's malfind): walk every process's committed memory regions (its VAD tree) and flag the ones that are executable, private, and have no backing file — then look at the first bytes. An MZ header or a run of 0x90 in a region like that has no innocent explanation. Run the scan on this sample image:

rule: executable & private & unbacked → injection candidate; inspect first bytes. Mapped-image code is cleared. A known JIT engine is flagged for tuning, not convicted — see §04.

pslist vs psscan, in the image

The same move as Lab 3, one layer down. pslist walks the doubly-linked list the OS maintains — the convenient view, and the one a rootkit unlinks itself from. psscan ignores the list and scans the memory pool for anything carrying the Proc pool tag. A process present in the scan but absent from the list unlinked itself.

Here psscan turns up a svch0st.exe (pid 6620) the list never mentions — hollowed and unlinked. On its own that's a question, not a conviction: the pool can also hold a process that exited mid-capture. The answer is corroboration — does it also own injected memory (§02) or an outbound socket? Convictions are built from agreeing evidence, never one view.

A snapshot of a moving target

Memory forensics is powerful and full of ways to fool yourself. The discipline is knowing them:

• Legitimate RWX exists. JIT engines (.NET, V8/Node, Java) and some browsers genuinely allocate private executable memory and write code into it. A naive “private RWX = evil” rule lights them up. You baseline the known JIT processes and alert on the rest — the same allowlist-then-subtract logic as Lab 4.
• Acquisition is not atomic. Imaging a live machine takes time, and memory changes while you read it — page smear leaves structures half-updated and inconsistent. A clean snapshot comes from a VM (pause and copy) or a hardware/crash-dump path; a live grab is evidence with an asterisk.
• Anti-forensics is real. Malware can unlink, overwrite pool tags, encrypt its own regions until use, or run only inside a legitimately-RWX host. Each technique defeats one method — which is exactly why you run several and compare, never trust one plugin's output as the verdict.
• It's a single frame. The image is one instant. Beaconing (Lab 4), persistence (Lab 1) and timeline live in continuous telemetry; memory confirms the what at a moment, your logs carry the when and how often.

On this Mac. Full memory imaging is harder on modern macOS (SIP, Apple-silicon protections) than the Windows tooling assumes. The lab's practical analog is live endpoint telemetry — osquery process/open-handle tables and eslogger events — which captures the same facts (unbacked executable mappings, process lineage) continuously, without a raw dump. The principle is OS-agnostic; the acquisition path differs.

Where this comes from

That's the chain, end to end: from the first instruction at 0x7c00 to the injected page in RAM — seven ways to measure the ground an attacker stands on, without ever standing on it yourself.