How do attackers use Donut?

How Donut turns managed code into in-memory payloads

Donut is used to convert a .NET assembly or other executable into shellcode that can be loaded and run from memory. That changes the delivery problem from “drop a file and execute it” to “inject or stage code directly,” which can reduce disk artefacts and make file-based scanning less effective.

That in-memory form is why attackers pair Donut with script hosts, exploit chains, loaders, or post-exploitation tooling. The underlying goal is usually not the converter itself, but the ability to move a payload into a process where execution looks closer to normal runtime behaviour than to a standalone executable being launched from disk.

Why attackers like Donut for delivery and evasion

Donut is attractive when an attacker wants a payload that is easier to embed, harder to inspect on disk, or more flexible to hand off between stages. A shellcode form can be embedded in scripts, memory loaders, or exploitation workflows, so the payload can be delivered without the obvious file-centric artefacts defenders often look for.

That does not make the activity invisible. It shifts what defenders should watch: memory allocation patterns, suspicious script launch behaviour, unusual child processes, and code-loading activity that does not fit the host’s normal software profile. The useful question is not only “is there a file?”, but “what is causing code to appear in memory and execute there?”

For a broader view of how attackers package and stage payloads, Malware Guide is a useful reference point for loaders, fileless behaviour, and evasion patterns. When the focus is on real intrusion paths rather than theory, The State of NHI & AI Agent Breach Report 2026 is a relevant navigation aid for compromise patterns that include stolen access material and payload delivery paths.

What defenders should investigate when Donut-like activity appears

Because Donut is a delivery and execution technique, investigation should centre on process behaviour rather than only on the originating file. Look for script engines, LOLBin-style execution chains, suspicious parent-child process relationships, memory region changes, and unsigned or unexpected code being loaded into trusted processes.

It is also worth checking whether the payload was used to establish persistence, launch a secondary stage, or bridge into credential theft or lateral movement. In practice, the loader is often the first observable step in a larger intrusion path, not the end state.

When you want threat context beyond generic malware discussion, CISA advisories can help anchor observed behaviour to active attacker tradecraft, and the MITRE ATT&CK Enterprise Matrix is useful for mapping memory injection, process abuse, and credential-access follow-on activity. The CISA cyber threat advisories feed is also useful when the question is whether a technique is part of a broader active campaign rather than an isolated event.

Practitioner Guidance

What to verify: Confirm whether the suspicious activity is just a staged in-memory loader or part of a wider compromise. The key distinction is whether the host merely executed unusual code, or whether that code also reached into sensitive credentials, remote services, or persistence mechanisms.

Decision rule: If the suspicious chain includes script execution, memory injection, and a process that should not normally host custom code, treat it as a high-priority investigation even if no file was written to disk. If the payload executed in a trusted process, prioritise containment and memory-focused triage before relying on disk artefacts.

What practitioners underestimate: Donut-style tradecraft often succeeds because teams overfit detection to files, hashes, and quarantine events. A practical response plan needs visibility into process lineage, memory activity, and the behaviour of loaders, not just the presence or absence of a dropped executable.

Practitioner takeaway: The main defensive shift is from file-centric detection to execution-centric detection, because the attacker’s advantage comes from getting code running in memory under a process that looks ordinary enough to avoid casual scrutiny.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?