What are the best practices for investigating in-memory malware on an endpoint?

Use endpoint scan data as a forensic starting point, not a final conclusion. Prioritise indicators that reveal memory-based activity, such as code injection, packed or fileless malware, and unrecognised code. Correlate those findings with disk artifacts, running processes, and persistence mechanisms. That combination gives teams enough context to decide whether to isolate the host, terminate processes, and block related indicators.

What matters first when you are looking for memory-resident activity

Start by treating endpoint scan output as a lead, not proof. In-memory malware often leaves weaker disk evidence than traditional malware, so the investigation has to focus on process behaviour, code injection, suspicious command lines, and unsigned or unexpected modules loaded into a legitimate process.

The practical test is whether the endpoint shows a believable execution chain. A single alert is rarely enough. You want to understand what started, what it touched, what it spawned, and whether the process tree makes sense for the host, user, and time of day.

Forensics is strongest when you correlate memory indicators with other endpoint artefacts. Disk files, prefetch or execution traces, services, scheduled tasks, WMI persistence, and network connections can turn an ambiguous memory finding into a defensible incident hypothesis.

How to validate an in-memory malware suspicion on the endpoint

Validation usually means comparing the process image in memory with what should be on disk. If a process is running from an unexpected location, has a parent-child relationship that does not fit normal software behaviour, or contains injected code regions, the odds of malicious activity rise quickly.

Look for evidence of fileless execution paths, such as PowerShell, WMI, LOLBins, or script-host abuse, especially when those processes appear in a chain with unusual network activity or credential access. A legitimate tool can be abused, so the question is not only “what is running?” but “why is it running this way?”

Endpoint telemetry becomes much more useful when it is joined with threat intelligence and process context. That includes hashes, command line arguments, module load order, handle activity, and whether the same pattern appears on other hosts. Repetition across endpoints can point to a campaign rather than an isolated anomaly.

When the evidence is strong, isolate the host before the attacker can use the same process or memory space for lateral movement. If the evidence is weak, preserve volatile data first, then continue collecting before you terminate anything that might destroy the artefacts you need.

Risk and Threat Considerations

In-memory malware is risky because it can reduce the amount of durable evidence available to defenders while still using legitimate processes to execute malicious code. That creates a detection gap: an endpoint can look clean on disk while still being actively abused in memory.

Failure mechanism: The attacker hides payloads inside a trusted process, injects code into memory, or executes without leaving a conventional file footprint, which makes standard on-disk scanning and simple IOC matching unreliable.

Impact: Teams can miss active compromise, delay containment, and allow persistence, credential access, or lateral movement to continue until the host is fully triaged.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS Control 8 — Audit Log Management	Endpoint memory investigations depend on correlated logs and process telemetry.
	CIS Control 10 — Malware Defenses	Memory-resident malware investigation is a core malware defense use case.
	CIS Control 13 — Network Monitoring and Defense	Memory malware often reveals itself through unusual network connections and C2 activity.
Recommendation — Collect and preserve endpoint logs that help reconstruct process execution and suspicious activity. Use malware defenses that detect suspicious code execution, injection, and fileless activity. Correlate endpoint findings with network telemetry to confirm active malicious communication.
MITRE ATT&CK	T1055 — Process Injection	Process injection is a central memory-malware mechanism on endpoints.
	T1027 — Obfuscated Files or Information	Packed or obfuscated payloads are common in memory-focused malware investigations.
	T1059 — Command and Scripting Interpreter	Fileless and in-memory attacks often use scripting interpreters on endpoints.
Recommendation — Hunt for injected code regions and abnormal execution inside legitimate processes. Inspect for packing, obfuscation, and unpacking behaviour during triage. Review script interpreter use, command lines, and spawned child processes for abuse.

Practitioner Guidance

What to prioritise: Preserve volatile evidence first when memory artefacts are still present, then correlate the suspicious process with child processes, network sessions, loaded modules, and any persistence mechanism before you take destructive actions.

Decision rule: If the process is both unusual and capable of reaching sensitive systems, treat the case as a containment event, not a curiosity. If the host is business-critical and you cannot isolate immediately, capture memory, process, and network state before remediation starts.

What to verify: Confirm whether the suspicious activity has a plausible parent process, a known-good file path, and a legitimate operational reason. If any of those checks fail, escalate the investigation and widen the scope to adjacent hosts and accounts.

Practitioner takeaway: The key judgment is not whether a payload exists on disk, but whether the endpoint shows an active malicious execution chain that justifies containment before evidence disappears.