These tactics let malicious code run inside the apparent identity of a legitimate Windows process, which weakens trust in process names and signatures. Herpaderping can make the on disk image look trusted while hostile code executes in memory, allowing payloads to evade casual inspection. That mismatch between visible process identity and actual behavior creates a serious detection and response gap.
How process hollowing and herpaderping undermine defender trust
Both techniques exploit a defender’s assumption that a running process reflects the file that launched it. Hollowing replaces a legitimate process’s memory image after startup, while herpaderping manipulates what is written on disk versus what is executed in memory. The result is a mismatch between visible process identity, static file inspection, and actual runtime behavior.
That mismatch matters because many triage workflows still begin with the process name, parent-child chain, signer reputation, or on-disk hash. When those signals no longer line up with execution reality, analysts can misclassify malicious activity as benign, delay escalation, or trust an artifact that no longer represents the active payload.
Why detection gets harder than simple process-name spoofing
These tactics are risky for defenders because they attack multiple layers of visibility at once. A hollowed process may inherit the surface characteristics of a trusted binary, yet execute attacker-controlled code in memory. A herpaderped file may also look harmless when reviewed later, because the on-disk image can be altered to mislead inspection after the executable content has already been staged or mapped.
That creates a practical gap between file-centric controls and runtime-centric controls. Static scanners, hash-based allowlists, and manual review of the executable on disk may all miss the malicious behavior if they are not paired with memory inspection, behavior telemetry, and process execution lineage.
Defenders should therefore treat any strong reliance on “known good process equals safe process” as fragile when malware can separate disk state from memory state. A trustworthy binary name or signature is useful, but it is no longer enough on its own to conclude that the active code path is safe.
What defenders should verify before trusting the process
process hollowing and herpaderping make runtime verification more important than file reputation alone. Teams need to confirm whether the process image in memory still matches the expected module, whether the parent process and launch chain make sense, and whether the binary’s behavior aligns with its advertised purpose. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because the relevant control families map directly to process monitoring, integrity, and auditability.
Defenders also need to validate the limits of their detection stack. If endpoint tooling only records process creation and the final file on disk, it may miss the point where the payload was swapped or the on-disk image was intentionally distorted. Memory-scoped telemetry, script-block and child-process observation, and alerting on suspicious image replacement behavior become materially more valuable than a reputation check alone.
Where Windows telemetry supports it, analysts should prefer evidence that ties a process to its original launch artifact, not just its current name. That means correlating file provenance, process creation, module loading, memory anomalies, and unexpected parent-child relationships before closing an alert as benign.
Risk and Threat Considerations
These techniques are attractive to attackers because they turn defender trust into a weakness. By separating what is visible on disk from what is running in memory, an adversary can reduce the chance that casual inspection, reputation-based triage, or delayed review will identify the payload before it acts.
Failure mechanism: The defense assumes the process image, file hash, and runtime code are aligned, but hollowing and herpaderping deliberately break that assumption. Static inspection sees one artifact while execution occurs from another.
Impact: The likely result is missed detection, slower containment, and a larger window for credential theft, lateral movement, or payload execution before analysts realise the process is not what it appears to be.
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 NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Process hollowing and herpaderping break integrity assumptions about running code. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Defenders need correlated audit data to spot file-to-memory mismatches and suspicious execution chains. | |
| Recommendation — Correlate runtime image integrity with process telemetry and alert on image replacement or mismatch. Review and correlate process, module, and file events to identify hollowed or herpaderped processes. | ||
| MITRE ATT&CK | T1055 — Process Injection | Process hollowing is a process-manipulation technique that fits ATT&CK tradecraft for injected execution. |
| Recommendation — Map alerts to T1055 and hunt for suspicious memory replacement and process tampering. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | The answer depends on monitoring runtime behavior, not just static file inspection. |
| DE.AE-02 — Detected events are analyzed to understand attack targets and methods | Analyzing hollowing and herpaderping requires interpreting process anomalies as attacker methods. | |
| Recommendation — Monitor process behavior continuously and investigate code/state mismatches as potential events. Analyze process anomalies for tactic and technique indicators, not just signature matches. | ||
Practitioner Guidance
What to prioritize: Treat memory-backed process validation and execution lineage as higher priority than trusting the visible executable name or signature. If your investigation starts and ends with the on-disk binary, you are likely looking in the wrong place.
What to verify: Confirm whether the process’s observed behavior matches its original launch context, whether its in-memory image is consistent with the expected module, and whether the parent-child chain and command line are plausible for that host. MITRE ATT&CK Enterprise Matrix helps map those observations to adversary behavior, while NIST Cybersecurity Framework 2.0 is useful for aligning detection and response processes around those signals.
Common mistake: Assuming that a trusted filename, valid signature, or previously clean hash means the current process is safe. In this tactic class, the file a defender inspects may not be the code that is actually running.
Practitioner takeaway: The defensive objective is not to trust less everywhere, but to trust the process only when file state, memory state, and behavior all agree.
