Process hollowing and similar tricks work by starting a trusted program and then swapping or rewriting its code before it runs, so the attack is visible in the sequence of memory and thread API calls rather than in any file. MITRE D3FEND names the countermeasure Process Self-Modification Detection (D3-PSMD) and defines it as detection of "processes that modify, change, or replace their own code at runtime." It sits under the Detect tactic as a child of Process Analysis (D3-PA). This card explains the API patterns D3FEND describes, the ATT&CK techniques it relates to D3-PSMD, where the capability is implemented, how to test it and where it falls short. It is aimed at detection engineers and EDR owners; injection background is in the T1055 Process Injection Defensive Guide.
Key takeaways
- It watches the act, not the result. D3-PSMD intercepts API calls between a process and the operating system and matches them against patterns that rewrite executable memory or redirect a suspended child's entry point.
- Four patterns cover most hollowing. D3FEND lists code removal, new code injected or loaded, code modified, and next instruction pointer changed, each by one or more API calls.
- Legitimate self-modification exists. D3FEND warns that unpacking and decryption of code segments cause false positives, so packers, protectors and JIT engines need modelling.
- The relationship to ATT&CK is inferred. D3FEND links D3-PSMD to techniques through the Process artefact, which yields a broad list (credential dumping, web shells, Netsh helpers) rather than injection alone.
- It pairs with code verification. D3-PSMD sees the modification calls; its sibling Process Code Segment Verification (D3-PCSV) compares the resulting code with a reference. Running both narrows the gaps of each.
D3-PSMD at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-PSMD (d3f:ProcessSelf-ModificationDetection) |
| Tactic | Detect |
| Parent technique | Process Analysis (D3-PA) |
| Digital artefact | Process (D3FEND relation: analyzes) |
| Mechanism | A host security agent intercepts process to operating system API calls and compares them with attack patterns |
| D3FEND reference | Carbon Black patent "System and Method for Process Hollowing Detection" (US20170272462A1) |
| Typical data sources | EDR API and kernel telemetry, Sysmon Event IDs 8, 10 and 25 |
| Main limitation | False positives from packers and JIT code; blind spots where the agent does not see the calls |
How it works
D3FEND describes an agent on the host that intercepts API calls and compares them with signatures for calls that modify executable memory or modify the entry point address of a suspended child process. The patent D3FEND cites describes the agent recording the child's entry point when it is created suspended and again when its thread resumes, then comparing the two. The four patterns are below; the API names come from that patent and are Windows examples.
| Pattern (D3FEND) | Typical Windows API sequence in the cited patent | What the defender sees |
|---|---|---|
| Executable code of a suspended child removed from memory | Child created suspended, then NtUnmapViewOfSection on its image | A legitimate image unmapped before it ever ran |
| New executable code injected or loaded into a suspended child | VirtualAllocEx and WriteProcessMemory into the child, or NtMapViewOfSection of new code | Foreign code placed where the entry point will run |
| Executable code modified | VirtualProtectEx to make the image writable, then WriteProcessMemory | Code bytes in the image changed after load |
| Next instruction pointer changed | Allocation and write, then SetThreadContext before ResumeThread | Execution redirected away from the original entry point |
The same approach generalises beyond hollowing: any process that changes protection on its own code pages and writes to them is self-modifying, which is either a protector, a JIT engine or something to investigate. Sysmon offers a related, lower-cost signal: Event ID 25, ProcessTampering, which Microsoft describes as generated "when process hiding techniques such as "hollow" or "herpaderp" are being detected." Event ID 8, CreateRemoteThread, records the source and target process and the start address of a thread created in another process, a common precursor.
ATT&CK techniques D3FEND relates to D3-PSMD
Relationship type: inferred only. D3FEND derives every row through the shared Process artefact: D3-PSMD analyzes Process, and these techniques act on a Process (D3FEND 1.6.0, checked November 2026). Because the artefact is generic, the list reflects anything that touches a process, not only self-modification. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | Practical relevance to self-modification detection |
|---|---|---|---|
| T1003.001 | LSASS Memory | accesses Process | Low directly; credential dumping reads lsass.exe memory rather than rewriting code |
| T1003.002 | Security Account Manager | may-access Process | Low; mostly a registry and file activity |
| T1003.004 | LSA Secrets | may-access Process | Low; mostly a registry and file activity |
| T1505.003 | Web Shell | produces Process | Medium where in-memory web shells inject into server worker processes |
| T1546.007 | Netsh Helper DLL | produces Process | Low; a DLL load rather than a code rewrite |
| T1553.006 | Code Signing Policy Modification | may-create Process | Low; a configuration change |
| T1564.011 | Ignore Process Interrupts | creates Process | Low; a process wrapper behaviour |
The relevance column is an NHI Mgmt Group view, not D3FEND's. The D3FEND web page also lists techniques reached through related artefacts, such as Scheduled Task (T1053.005), Transport Agent (T1505.002), Modify Authentication Process (T1556) and Exploitation for Credential Access (T1212), and it lists Disable or Modify Tools under an ID that ATT&CK v20 has revoked; the v20 successor is T1685 Disable or Modify Tools. The technique D3-PSMD most directly addresses in practice, Process Hollowing (T1055.012), is related by D3FEND to the sibling D3-PCSV through the Process Code Segment artefact rather than to D3-PSMD. Related ATT&CK sub-techniques that use the same API sequences include Process Doppelgänging (T1055.013) and Reflective Code Loading (T1620).
Where it is implemented
| Implementation class | What it provides | Fits when |
|---|---|---|
| EDR behavioural engines | Kernel callbacks and API telemetry correlating suspended creation, cross-process writes, protection changes and thread context changes | Continuous protection across a managed fleet |
| Sysmon with SIEM rules | Event ID 25 ProcessTampering; Event ID 8 CreateRemoteThread; Event ID 10 ProcessAccess for handles opened to other processes | No-licence visibility, correlated centrally |
| Exploit protection policies | Windows Arbitrary code guard prevents memory being marked executable, which blocks many runtime code changes in the protected process; Audit only mode reports attempts | Hardening specific applications that do not generate code at runtime |
| On-demand scanners and forensics | Tools such as HollowsHunter and PE-sieve detect hollowed and patched processes after the fact; Volatility 3 malfind lists memory that may hold injected code | Triage and incident investigation |
Microsoft notes that Arbitrary code guard is incompatible with Just-in-Time compilers, such as the JavaScript engines in most browsers, unless they move JIT compilation out of the protected process. That limitation is the prevention-side version of D3FEND's false positive warning. Sysmon setup is in the Sysmon Guide.
Implementation steps
- Confirm your sensor sees the calls. Check the EDR's documentation for cross-process write, thread context and suspended process creation telemetry, and confirm the detections are enabled, not only collected.
- Add Sysmon signals where Sysmon runs. Include Event IDs 8, 10 and 25. Filter Event ID 10 to target processes that matter (lsass.exe, security agents, server workers), as Microsoft advises filtering expected accesses to control volume.
- Inventory legitimate self-modifiers. Packed commercial software, licence protectors, game anti-cheat, browsers and other JIT runtimes. Record them by signer and path.
- Pilot in alert-only mode. Two to four weeks on a representative ring; tune by signer and path, never by process name alone, since hollowing reuses legitimate names.
- Enable blocking for high-confidence patterns. Entry point redirection of a freshly created suspended process with an unmapped original image is rarely legitimate. Roll back by returning the rule to alert-only.
- Harden selected applications. Where an application does not generate code, apply Arbitrary code guard in Audit only first, review events, then enforce.
How to verify it works
- Authorised emulation: in a lab or approved window, run process hollowing and thread context hijack tests from the adversary emulation framework your red team already uses, and confirm the alert names the parent, the hollowed child and the target image.
- Sysmon check: confirm Event ID 25 appears for the hollowing test and that the event reaches the SIEM with the process GUID.
- Exclusion review: list paths and signers excluded from behavioural detection and confirm none covers common hollowing targets such as svchost.exe or rundll32.exe. See the EDR Tuning and Exclusions Management Guide.
- Cross-check with forensics: after an emulation run, scan the host with an on-demand memory scanner and compare with what the live detection reported.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Hollowing and context hijack emulations detected | 100% per quarter | Proves detection works end to end |
| Managed endpoints with behavioural memory detection enabled | Above 95% | Unprotected hosts are where hollowing succeeds |
| Self-modification alerts traced to an inventoried legitimate program | Falling month on month | Shows the allowlist is accurate and narrow |
| Time from alert to triage for suspended-child patterns | Under 30 minutes | These patterns rarely have benign causes |
Limits, bypasses and failure patterns
- Packers and protectors: D3FEND notes legitimate self-modification for decrypting or uncompressing code segments. Allowlisting by process name instead of signer turns that into a blind spot.
- Calls the agent does not see: user-mode hooks can be avoided by calling lower-level interfaces directly. Prefer sensors that also use kernel telemetry; tampering with the sensor is covered in the EDR Evasion and Defence Guide.
- Variants that avoid the classic sequence: techniques such as Process Doppelgänging and herpaderping change the image through file and section operations rather than unmapping and writing. Sysmon Event ID 25 covers some of these; confirm what your EDR covers.
- Code that never touches the image: reflective loading into new memory leaves the original code untouched. Unbacked executable memory needs separate analysis.
- Volume-driven tuning: disabling ProcessAccess logging entirely because diagnostics tools are noisy removes the precursor signal; filter instead.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring for attacks and unauthorised activity on hosts |
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | Detecting malicious code at runtime |
| NIST SP 800-53 Rev 5 | SI-16 Memory Protection | Protecting memory from unauthorised code execution, the prevention counterpart |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitoring runtime environments; analysing adverse events |
| MITRE D3FEND | D3-PA, D3-PSMD | Parent and technique |
The NIST mapping above is an NHI Mgmt Group view; D3FEND does not map D3-PSMD to NIST controls.
Related countermeasures
- Process Code Segment Verification (D3-PCSV): compares loaded code with a reference. See D3-PCSV Process Code Segment Verification.
- Process Lineage Analysis (D3-PLA): flags hollowed system processes through irregular parents. See D3-PLA Process Lineage Analysis.
- Memory Boundary Tracking (D3-MBT): another runtime memory analysis technique. See D3-MBT Memory Boundary Tracking.
- Process Termination (D3-PT): the eviction step once self-modification is confirmed malicious. See D3-PT Process Termination.
Practitioner checklist
- Confirm the EDR detects suspended creation, cross-process writes and thread context changes.
- Collect Sysmon Event IDs 8, 10 and 25 where Sysmon is deployed, with Event ID 10 filtered.
- Inventory packers, protectors and JIT runtimes by signer and path.
- Pilot in alert-only mode and tune by signer, never by process name.
- Block entry point redirection of suspended children once tuned.
- Apply Arbitrary code guard to applications that do not generate code, Audit only first.
- Run hollowing emulation every quarter and record the result.
- Review exclusions for common hollowing targets.
Standards and references
- MITRE D3FEND: Process Self-Modification Detection (D3-PSMD)
- MITRE ATT&CK: T1055.012 Process Hollowing
- Google Patents: US20170272462A1 System and Method for Process Hollowing Detection
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-3, SI-4, SI-16)
- Microsoft Learn: Sysmon (Event IDs 8, 10 and 25)
- Microsoft Learn: Exploit protection reference (Arbitrary code guard)
- GitHub: PE-sieve
Related NHI Mgmt Group resources: MITRE D3FEND Guide · T1055 Process Injection Defensive Guide · EDR Guide · Top 10 EDR Evasion Techniques