Process hollowing is a method where malicious code is placed into a legitimate process after that process is started in a suspended state. The original binary remains present, but its memory is replaced with attacker code, which helps hide the malware from basic file-centric defenses and simple reputation checks.
Expanded Definition
Process hollowing is a process injection technique in which an attacker starts a legitimate executable in a suspended state, replaces or rewrites its memory with malicious code, then resumes execution so the process appears normal from the outside. In NHI and agentic environments, the technique is especially relevant when defenders rely on binary reputation, path allowlisting, or parent-child process heuristics alone.
Definitions vary across vendors on whether the term should include only classic NIST Cybersecurity Framework 2.0 process tampering patterns or also broader hollowing-adjacent injection methods such as section mapping and thread hijacking. The practical distinction is that process hollowing preserves the original process container while changing the executing payload, which can weaken file-based detection and complicate incident triage. NHI teams should treat it as a post-launch execution concealment method, not a credential issue by itself, although it is often used after an attacker has obtained access through leaked secrets or compromised service accounts. The most common misapplication is assuming a trusted process image is trustworthy just because its file hash matches a known good binary, which occurs when defenders do not inspect in-memory execution state.
Examples and Use Cases
Implementing detection rigorously often introduces extra telemetry and tuning overhead, requiring organisations to weigh stronger memory visibility against higher analyst workload and false-positive risk.
- A threat actor launches a signed Windows utility in a suspended state, swaps its memory image, and uses it to run payloads while evading simple file scanning.
- A compromised build agent is used to start a benign process that is hollowed to stage ransomware, making the activity look like ordinary build tooling until memory inspection occurs.
- An attacker abuses a service account with excessive privilege, then uses process hollowing to hide lateral movement tooling inside a trusted process tree.
- Blue teams correlate process creation, thread state, and memory anomalies with guidance from the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs to spot when legitimate automation has been turned into a launch point.
- Detection engineering teams map suspicious in-memory execution to the NIST Cybersecurity Framework 2.0 to improve monitoring and incident response coverage.
In practice, process hollowing is often seen after a foothold is already established, especially when an intruder wants to hide inside a trusted executable while continuing to use stolen NHI credentials.
Why It Matters in NHI Security
Process hollowing matters because NHI compromise is rarely limited to the credential itself; attackers frequently combine stolen API keys, service account tokens, or CI/CD access with execution concealment to prolong access and frustrate remediation. NHI Management Group notes that 80% of identity breaches involved compromised non-human identities, which makes memory-based stealth tactics highly relevant once an initial identity has been abused.
From a governance perspective, process hollowing reveals gaps in endpoint telemetry, identity-to-process correlation, and containment procedures. If defenders only rotate secrets without examining execution artifacts, the adversary may remain resident through a benign-looking process that keeps operating after the secret is revoked. The right response usually combines NIST Cybersecurity Framework 2.0 monitoring with investigation of service ownership, privilege scope, and suspicious in-memory state. Organisational teams typically encounter the full impact only after a trusted process behaves abnormally during containment, at which point process hollowing becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | Process hiding often follows NHI compromise and obscures malicious execution. |
| NIST CSF 2.0 | DE.CM | The term maps to detection monitoring for anomalous process behavior and memory tampering. |
| NIST Zero Trust (SP 800-207) | PA | Zero Trust assumes trusted binaries and identities can be subverted after access is gained. |
Correlate NHI access with process telemetry and investigate suspicious in-memory execution.
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?
