What is the difference between disk-based persistence and reflective execution in malicious code?

Disk-based persistence stores code or launch changes on the filesystem so it can run again later, often leaving visible artifacts. Reflective execution runs code directly from memory, using an anonymous file or similar technique to avoid writing a payload to disk. For defenders, the first is easier to find on disk, while the second demands stronger process and memory telemetry.

How disk-based persistence changes the defender’s job

Disk-based persistence is usually the more conventional problem because the code, launch mechanism, or modified startup path leaves artefacts that defenders can hunt on the filesystem and in configuration stores. That makes it easier to tie the behaviour to a host, a user context, and a specific change event. It is not harmless, though, because persistence can survive reboots and quietly reintroduce malicious behaviour after cleanup.

What matters operationally is not just that something was written to disk, but what that write enabled. A scheduled task, service entry, startup folder item, or dropped binary can all turn a one-time intrusion into repeated execution, which is why persistence review is often part of containment and eradication rather than a separate afterthought. For broader context on why secret exposure and stored launch material matter, see NHI Mgmt Group’s Ultimate Guide to Non-Human Identities and Guide to the Secret Sprawl Challenge.

Because disk-based persistence is visible in principle, defenders can use file integrity checks, autoruns review, service inventory, and change monitoring to reduce dwell time. The catch is that visibility only helps if teams know which startup paths, scripts, and administrative tools are legitimate in their environment. Attackers often hide in places that look operationally normal, not overtly malicious.

How reflective execution avoids the disk trail

Reflective execution runs code directly in memory instead of writing a conventional payload to disk, which changes the detection problem from static artefacts to runtime behaviour. The attacker’s goal is usually to reduce forensic leftovers, evade basic file-based controls, and make the payload harder to quarantine with ordinary filesystem scanning. That is why it is often associated with in-memory loaders, shellcode, and post-exploitation tradecraft.

For defenders, the absence of a dropped file does not mean the absence of a malicious action. The useful signals shift to process lineage, abnormal memory regions, module loading patterns, child process behaviour, and suspicious API or syscall sequences. If a process starts from a trusted parent but later exhibits execution characteristics that do not match its image or purpose, memory-oriented telemetry becomes the decisive evidence source.

Reflective execution also changes the response sequence. You often need to preserve volatile evidence before killing the process, because terminating it can erase the very artefacts that explain how the code entered memory and what it touched. That makes endpoint telemetry quality and rapid triage more important than a simple file hunt.

What the difference means for detection and response

The practical difference is that disk-based persistence is usually a configuration and artefact problem first, while reflective execution is a runtime and telemetry problem first. Both can exist in the same intrusion, but they call for different default assumptions: disk-based activity is easier to enumerate after the fact, while reflective activity may never leave a clean payload on disk at all. That is why defenders should not treat “no file found” as a clean bill of health.

Current guidance in endpoint operations is to combine file-system visibility with process and memory visibility, then correlate both with user activity and network connections. A dropped file might explain the initial foothold, but memory-only execution often explains why the host continued behaving badly after the obvious artefact was removed. For attack-path context, Salt Typhoon US telecoms breach shows how stolen access and post-compromise activity can compound into persistence, while Reviewdog GitHub Action supply chain attack illustrates how execution paths can create broad exposure even when the original code path looks routine.

For practitioners, the key judgment is to match the control to the execution style: use filesystem and startup checks to find persistence, but use endpoint detection, memory inspection, and process telemetry to find reflective code. If you only do one, you will bias your search toward the attack style you are most comfortable with, not the one the adversary chose.

Risk and Threat Considerations

Reflective execution is attractive to attackers because it reduces artefacts, shortens the window for simple file-based detection, and can keep malicious activity resident even after obvious files are removed. Disk-based persistence is easier to investigate, but it can still create long-lived access if defenders miss the startup mechanism or assume cleanup of the payload file is enough.

Failure mechanism: Disk-based persistence fails defenders when the stored launch point, not the payload itself, is the real control plane, while reflective execution fails defenders when they rely on file artefacts instead of runtime telemetry to detect execution.

Impact: Both patterns can extend attacker dwell time, complicate eradication, and increase the chance that a host is re-compromised after an incomplete cleanup.

Standards & Framework Alignment

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

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1547 — Boot or Logon Autostart Execution	Disk-based persistence commonly uses startup mechanisms to rerun code after reboot.
	T1055 — Process Injection	Reflective execution overlaps with in-memory code placement and execution without a normal file trail.
Recommendation — Map suspicious startup artefacts to T1547 and review autostart paths for unauthorized execution. Correlate anomalous memory execution with T1055 and inspect processes for injected code regions.
CIS Controls v8	8.2 — Audit Logs	Runtime and process telemetry are essential when execution occurs without a useful disk artefact.
Recommendation — Centralize and retain endpoint and process logs to support in-memory execution detection.
NIST CSF 2.0	DE.CM — Continuous Monitoring	The question hinges on using the right telemetry to distinguish disk persistence from in-memory execution.
Recommendation — Use continuous monitoring to correlate filesystem changes with process and memory activity.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Exposure	Stored launch material and embedded credentials often make persistence easier to establish and reuse.
Recommendation — Remove embedded secrets and rotate exposed credentials that can be used to relaunch malware.

Practitioner Guidance

What to verify: Confirm whether the suspicious execution path depends on a persistent launch object, a dropped binary, or purely in-memory execution. If the file is absent but the process is still alive or has already executed, shift immediately to memory and process-lineage review instead of continuing a disk hunt.

Common mistake: Teams often over-focus on the payload and under-focus on the trigger. For disk-based persistence, the important question is what launches it again; for reflective execution, the important question is what injected or loaded it into memory and what it did next.

Practitioner takeaway: Treat disk artefacts as only one class of evidence, not the definition of compromise, because the best investigation path depends on whether the adversary anchored execution on disk or moved the workload straight into memory.