Donut shellcode is a method for converting an executable or .NET payload into position-independent shellcode that can run in memory. Security practitioners use it to test how defensive controls handle fileless execution, process hollowing, and payload delivery without a traditional dropped binary.
What Donut Shellcode Is Used For
Donut shellcode is a way to transform an executable or .NET payload into position-independent code that can be staged and executed in memory. That makes it useful for evaluating how controls behave when no obvious file is dropped to disk.
Because the payload is converted into shellcode, the test scenario shifts from ordinary file execution to in-memory execution paths. Practitioners use that to observe whether telemetry, prevention, and response controls still surface the activity when the payload is launched through an unusual loader or injection chain.
How Donut Shellcode Changes the Execution Model
The practical difference is not the application itself, but the delivery form. A binary or managed assembly is wrapped into shellcode that can be loaded by another process, which helps simulate fileless delivery, reflective loading, and process hollowing style tradecraft.
That matters because many defensive assumptions are tied to a file being written, scanned, and executed in a conventional way. In-memory execution can bypass those assumptions, so the same underlying payload may produce a very different detection and containment outcome.
For defenders, the interesting question is whether a control is watching the launch point, the memory activity, the parent-child process relationship, or the post-execution behaviour. For red teams and validation exercises, Donut shellcode is a compact way to test those layers without changing the payload logic itself.
Where Donut Shellcode Fits in Security Testing
It is best understood as an execution and delivery technique for assessment work, not as a standalone offensive goal. The technique is often used to model how malware or intrusion tooling behaves once it is converted into a memory-resident form.
That makes it useful in exercises focused on endpoint detection, process injection visibility, and response quality. It can also help validate whether hardening and monitoring controls are sensitive to non-standard execution paths rather than only to dropped executables.
When used in a lab or authorised assessment, it helps answer a simple operational question: if the payload never behaves like a normal file on disk, what still catches it?
Security Implications and Defensive Interpretation
Donut shellcode highlights a broader security reality, attackers often prefer execution paths that reduce disk artefacts and frustrate static inspection. A memory-only payload does not eliminate detection opportunities, but it changes which signals are most important.
That is why defenders should interpret this technique as a test of endpoint visibility, injection detection, memory scanning, and behavioural analytics. It also helps reveal where the environment relies too heavily on file-based controls or on assumptions about trusted process launches.
Seen through that lens, the value of Donut shellcode is diagnostic: it exposes whether security tooling can follow execution into memory, or whether it loses sight of the payload once the file boundary disappears.
Risk and Threat Considerations
Donut shellcode is attractive to threat actors because it can reduce obvious on-disk evidence and blend execution into a legitimate host process. That can make triage slower and increase the chance that initial execution is mistaken for normal process activity.
Failure mechanism: The payload is executed in memory through a loader or injection path, which shifts detection away from file reputation and toward runtime telemetry, memory inspection, and process behaviour.
Impact: If those runtime signals are weak or incomplete, malicious code may gain a longer dwell time, execute without a dropped binary, and move further before defenders recognise the compromise.
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 CSF 2.0, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | Donut shellcode is commonly used to model in-memory execution and injection tradecraft. |
| Recommendation — Map fileless execution tests to T1055 and hunt for suspicious process injection and hollowing activity. | ||
| NIST CSF 2.0 | DE.CM-01 — Network, physical, and device events are monitored | In-memory payload delivery depends on runtime visibility beyond file scanning. |
| Recommendation — Strengthen runtime monitoring so in-memory execution is still detected and triaged. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | This technique tests whether system monitoring sees shellcode execution and injection behaviour. |
| Recommendation — Use SI-4 monitoring to detect anomalous execution paths and memory-resident activity. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The term is used in assessment work to validate whether software architecture tolerates fileless execution paths. |
| Recommendation — Review execution and loading paths so architecture does not assume only file-based launching. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Fileless execution is often evaluated through the quality of logs and telemetry that record runtime behaviour. |
| Recommendation — Centralize and preserve logs that expose process creation, injection, and memory-related events. | ||
Practitioner Guidance
What to watch for: Treat this technique as a validation case for memory-focused monitoring, not just malware prevention. The main practitioner judgement is whether your controls are proving execution lineage, parent-child process relationships, and in-memory activity well enough to survive fileless delivery.
Practitioner takeaway: If a test only succeeds because the payload never lands as a conventional file, the gap is usually in visibility and behavioural detection, not in the payload itself.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
