Interactive Memory Forensics Triage

This is the disk-trained instinct MF0.1 warned against. "Clean disk" does not mean "nothing happened" when the alert is anomalous PowerShell reaching an unknown address, that fact pattern is the canonical signature of a memory-resident attack, where the disk is empty by design and the payload lives only in RAM. Reimaging destroys the one evidence source that can answer what the PowerShell did, and the answer cannot be recovered afterward.

Correct, and this is the canonical mandatory-acquisition trigger from MF0.1: an EDR alert without corresponding disk evidence. The only evidence that can answer "what did the PowerShell actually do, what did it touch, did it spread" is the RAM of the running machine, and it is gone the moment the system reboots. The business deadline is a communication problem to manage, not a reason to destroy evidence; acquisition takes twenty to thirty minutes and the reimage can follow.

Rebooting destroys exactly the volatile evidence you need, the running process, its injected code, its live connections, the most volatile category from MF0.2. A capture taken after reboot shows a clean system that no longer contains the attack. Severing the connection can wait until after acquisition; preserving the volatile evidence cannot.

As MF0.1 stressed, if this decision requires real-time escalation at 03:14, you have already lost the evidence to the clock. The acquire-on-this-trigger call should be pre-encoded in your SOC procedure precisely so it is not negotiated live against a deadline. The correct standing answer is to acquire first; the manager can be informed, not consulted, while the capture runs.

Tempting, and you will run it soon, but jumping to the suspected answer skips the step that makes everything after it trustworthy. If the image was captured with a mismatched profile, malfind's output is meaningless, and you would not know. Identify comes before Enumerate for a reason.

Close, and this is the right neighborhood, but it is still phase 3 before phase 2. A process list read against unconfirmed symbols can report fields from the wrong offsets and look entirely plausible. Confirm the image first, then enumerate.

Correct. This is phase 2, Identify, from MF0.3, and it precedes all analysis. It confirms the OS build, that Volatility selected matching symbols, and via the kernel/user split from MF0.4 that the translation is sane, the kernel base sitting in the expected high range. Profile mismatch is the most common cause of analysis that looks right and is wrong, and one command rules it out before you trust anything downstream.

MemProcFS is excellent for triage, from MF0.5, and you may well browse next, but the very first action on any image is to confirm what it is. Whichever tool you reach for, an unverified image can mislead both; identification is the gate before exploration.

Correct. By the taxonomy from MF0.2 this is a transient artifact: attack-introduced, found by pattern not by list, with no legitimate analogue, an executable-writable private region holding an MZ header that matches no file on disk. And by the raw-first rule from MF0.3, a decisive finding is verified against raw memory, you read the bytes yourself rather than trust the plugin's parse, before it carries weight in the report.

This is the classify-by-tool error from MF0.2. The VAD tree is a volatile structure, but an entry within it describing a private, executable, file-less region with a PE header is a transient artifact. Classification follows what the evidence is, not which structure surfaced it, and the misclassification weakens the claim you can make about it.

Legitimate JIT does create RWX regions, which is exactly why you do not stop at the protection flags, from MF0.10's clean baseline. But a JIT region is not a PE image; the MZ header plus no file backing distinguishes this from benign JIT. Dismissing it as a false positive ignores the signals that separate it from one.

It is inside application memory, but ephemeral data is the application's own legitimate working state, credentials, history, decrypted buffers, from MF0.2. An injected PE the application never loaded is not the application's working state; it is attacker-introduced, which makes it transient, and the distinction governs how you report it.

The C2 connection earns a flat assertion, but stating the memory-only decoded command with the same unqualified certainty overclaims its independence. From MF0.7, the report should distinguish a finding corroborated by two sources from one resting on memory alone, even when both are true.

Correct, and this is the confidence discipline from MF0.7. The C2 connection is High: a kernel-maintained structure, tied to a process, corroborated by the independent firewall log. The decoded command is decisive and verified in memory but exists nowhere else, so the report states it as memory-derived and notes the disk holds only the encoded form, which is honest calibration rather than weakness, and it is what survives an opposing expert.

Memory-only does not mean unusable, it is the decisive evidence of what the payload actually did, and dropping it discards the most important finding. From MF0.7, the right move is to report it at its honest tier with its limitation stated, not to omit it.

Understating is its own failure. From MF0.7, a finding corroborated by two independent sources is High, and labelling it Low to "be safe" misrepresents the evidence as much as overclaiming does. Confidence is a property of the evidence; you assign the tier the evidence earns, in either direction.