Process Doppelganging is a malware-loading technique that creates a process from a transacted file before the file is committed to disk. It is used to hide malicious code from file-based scanning and some EDR checks. Defenders monitor suspicious transacted file activity, anomalous process creation and hollow or hidden execution paths.
How Process Doppelganging Works
Process Doppelganging is a process-loading abuse technique that uses a transaction-backed file to create a process image before the file is committed to disk. That timing matters because security tools that depend on stable on-disk artifacts can miss what is executed, especially when the payload is only briefly present or never fully written in a normal way.
The technique belongs to a broader class of fileless or low-artifact execution patterns. The attacker’s goal is not just to run code, but to make the launch path look incomplete, transient, or inconsistent with ordinary file creation so that inspection, hashing, and file-centric telemetry become less reliable.
Why It Is Used By Attackers
Process Doppelganging is attractive because it can separate execution from the normal file lifecycle. By abusing transactional semantics, malware can gain an execution path while reducing the chance that a defender will see a clean, committed file to inspect, quarantine, or hash.
This kind of evasion is especially useful when the attacker wants to blend into legitimate process creation activity. A successful launch may still leave process telemetry, but the underlying file trail can be weaker than defenders expect, which complicates triage and provenance analysis.
For readers who want a broader view of the detection problem, NHIMG’s EDR Evasion and Defence Guide covers the same defensive theme across several sensor-blinding and execution-hiding techniques.
How Defenders Detect Exposure
Exposure is best checked by looking for the execution chain, not just the file. Suspicious transacted file activity, unusual process creation patterns, parent-child relationships that do not fit the host baseline, and execution paths that never correspond cleanly to a committed file are all important signals.
Defenders should also compare process telemetry with file-system telemetry and EDR records. When a process exists but the expected file artifacts are missing, incomplete, or inconsistent, that mismatch can indicate a stealthy loading method rather than a benign software issue.
In practice, this is a threat-hunting problem as much as a malware problem, which is why adversary-technique mapping often helps. MITRE ATT&CK Enterprise Matrix provides the common language for linking suspicious execution patterns to attacker tradecraft.
Remediation And Response Priorities
Once this technique is suspected, the immediate priority is to treat the launched process as potentially malicious even if the original file cannot be found in a standard location. Response should focus on containment, process tree review, memory inspection where available, and forensic reconstruction of the launch path from endpoint, host, and EDR telemetry.
After containment, teams should review whether the technique achieved persistence, credential access, lateral movement, or security-tool tampering beyond the initial execution. That post-launch review matters because hiding the file does not limit the malware to a single action; it may simply be the first step in a larger intrusion.
Control hardening should align with this execution model. NIST SP 800-53 Rev 5 Security and Privacy Controls supports the underlying needs for system integrity, auditing, configuration control, and malware resistance.
Risk and Threat Considerations
Process Doppelganging creates a defensive visibility gap. Because the payload can be launched before a file is normally committed, security tooling may lose the usual file-based anchors used for scanning, reputation checks, and incident reconstruction.
Failure mechanism: The attacker exploits a mismatch between process execution and file persistence, which can let malicious code run while reducing the reliability of hash-based, path-based, or file-write based detection.
Impact: Organisations may miss early compromise, misclassify the process as benign, or lose forensic evidence needed to understand the scope of intrusion and any follow-on abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | Covers stealthy execution and process abuse techniques used to evade detection. |
| Recommendation — Map suspicious launch chains to ATT&CK and hunt for process abuse, evasion, and follow-on actions. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Addresses controls for detecting and blocking malicious execution on endpoints. |
| AU-2 — Event Logging | Supports logging needed to reconstruct anomalous process creation and hidden execution paths. | |
| CM-7 — Least Functionality | Limits unnecessary executable pathways that malware can abuse for stealthy launch techniques. | |
| Recommendation — Apply malicious code protections that inspect execution paths beyond file reputation alone. Log process creation and related host events so analysts can reconstruct the execution chain. Reduce attack surface by disabling unnecessary execution paths and risky host features. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Focuses on endpoint malware detection and response against stealthy payload execution. |
| Recommendation — Harden endpoint malware defenses so hidden execution attempts are still detected and contained. | ||
Practitioner Guidance
What to watch for: Treat unexplained process creation with no clean file provenance as a high-suspicion event, especially when it is paired with unusual child processes, memory-only artifacts, or sensor blind spots.
Governance implication: Security teams should make sure endpoint detection, hunting, and incident response procedures explicitly account for process-launch paths that are not fully represented by ordinary on-disk artifacts.
Practitioner takeaway: The key question is not only “what file existed?”, but “what executed, how was it created, and what other activity followed immediately after?”
Related resources from NHI Mgmt Group
- Why do NHI programmes need stronger process ownership than many human identity programmes?
- How should organisations govern API partner onboarding as a non-human identity process?
- How can security teams apply GRC maturity benchmarks without creating process bloat?
- Should organisations use the same process for onboarding people and machine identities?