Process doppelgänging is MITRE ATT&CK T1055.013. It is a Windows sub-technique of Process Injection and belongs to the Stealth and Privilege Escalation tactics. It is a file-less variation of injection, similar in intent to process hollowing.
How attackers use it
The technique rests on Transactional NTFS (TxF), which Windows introduced in Vista to make file operations safe. To protect data integrity, TxF allows only one transacted handle to write to a file at a time. Until that write transaction ends, other handles are isolated from the writer and see only the committed version. If the system or application fails mid-write, TxF rolls back automatically.
MITRE notes that the TxF API is deprecated but still enabled as of Windows 10.
Adversaries abuse that isolation. Like hollowing, doppelgänging replaces the memory of a legitimate process so malicious code runs under cover. The difference is that TxF lets it avoid heavily monitored functions, and MITRE names NtUnmapViewOfSection, VirtualProtectEx and SetThreadContext.
MITRE describes a four step flow, of which the first two steps are:
- Transact: create a TxF transaction using a legitimate executable, then overwrite the file with malicious code. The changes are isolated and visible only inside the transaction.
- Load: create a shared section of memory and load the malicious executable into it.
The remaining steps turn that section into a running process. Because the transaction is later rolled back, the file on disk stays clean, and nothing malicious was ever committed there.
How to detect it
MITRE's detection strategy looks for abuse of TxF and undocumented process loading mechanisms, for example NtCreateProcessEx, used to build a process from an uncommitted, tainted file image in memory, later started through NtCreateThreadEx.
What that means in practice:
- Scanning files on disk will not find it. The image was never committed.
- API-level hooks on the commonly watched hollowing calls may not fire.
- The useful signals are the unusual combination of transaction APIs, section creation and process creation from a section.
Few ordinary applications use TxF today, given that it is deprecated. That makes any TxF use by an unexpected process a reasonable thing to alert on, once you have confirmed what your own software does.
How to reduce the risk
MITRE lists Behavior Prevention on Endpoint. Some endpoint products can block process injection based on common behavior sequences. For this technique, ask your vendor directly whether it covers transacted file and process creation from sections, because the usual hollowing sequence will not match.
Steps to take:
- Confirm blocking mode is on across Windows hosts.
- Ask your endpoint vendor to document coverage for TxF related injection.
- Inventory the legitimate software that still uses TxF so alerts have a baseline.
- Make sure memory based detection exists, not only file scanning.
Check your own environment
- Does your telemetry record process creation from a section rather than from a file path?
- Can you see use of transaction APIs by processes that are not backup or installer tools?
- When a process image in memory differs from its file on disk, does anything alert?
- Is your endpoint tool tested against more than one injection method?
Quick check
Why can file scanning miss process doppelgänging?
The malicious content exists only inside a TxF transaction that is rolled back, so it is never committed to disk.
Which monitored calls does doppelgänging avoid?
NtUnmapViewOfSection, VirtualProtectEx and SetThreadContext, according to MITRE.
