How can security teams detect Donut?

What Donut detection looks like in practice

The most reliable way to spot Donut is to look for execution that never behaves like a normal installed program. Donut is designed to run code from memory, so defenders should focus on process ancestry, command-line patterns, script hosts, and runtime behaviour rather than waiting for a dropped executable to appear on disk.

A useful starting point is the process chain. Legitimate launchers that quickly spawn script interpreters, LOLBins, or unmanaged child processes are often the visible edge of a memory-only payload. When that chain also includes suspicious parent-child relationships, encoded arguments, or short-lived staging processes, the loader path becomes much easier to distinguish from ordinary administration activity.

Memory telemetry matters just as much as process telemetry. Suspicious allocation patterns, writable-then-executable transitions, and threads starting from private memory regions can indicate that a shellcode loader has injected or unpacked code without a standard file artifact. For analysts, that is the key difference between generic unusual activity and an execution pattern that matches a loader-driven intrusion.

Which signals are most useful for triage?

Not every unusual process is Donut, so triage should combine several weak signals into one stronger picture. Start with launchers that appear legitimate on the surface but immediately hand off to unusual child processes, network connections, or shellcode-like execution patterns. That combination is more informative than any single event on its own.

Script-driven loading is especially important. If PowerShell, WMI, mshta, regsvr32, rundll32, or another trusted binary is used to start unmanaged payload execution, the absence of a normal on-disk program trail becomes a major clue. This is where defenders should correlate endpoint telemetry, script block logging, and memory inspection to determine whether the process is acting as a loader rather than a business application.

Network activity can also strengthen the case. Beaconing, outbound connections immediately after process start, or traffic from a process that should not normally reach the network may show that code has moved from in-memory execution to command-and-control or staged retrieval. MITRE ATT&CK Enterprise Matrix is useful here because it helps analysts map those observations to common execution and persistence patterns, while SANS Security Resources provides practical detection-engineering material for correlating host and network telemetry.

How should defenders validate and respond?

Validation should move from suspicion to proof. First confirm whether the process has a real image on disk, whether the memory region contains executable content that does not match a signed or expected module, and whether the child process tree makes operational sense for the host role. If those checks fail, treat the activity as a likely memory-resident loader event rather than an odd-but-benign admin action.

Response should be aimed at preserving evidence before the process disappears. Capture volatile memory, collect parent and child process details, preserve command lines, and retain network indicators tied to the launch time. If the process is still active, contain it at the host level and block any adjacent accounts, scripts, or automation paths that were used to deliver the payload. When the loader is tied to a legitimate-looking tool, inspect that tool’s recent use across the environment to determine whether the same pattern is repeating elsewhere.

Risk and Threat Considerations

Memory-only execution is risky because it reduces the evidence defenders normally rely on, especially file hashes, disk artefacts, and conventional software inventory. That makes initial access and post-exploitation activity harder to distinguish from approved automation, and it can delay containment when the loader is disguised as routine administration.

Failure mechanism: An attacker uses a trusted launcher or script host to stage shellcode in memory, then executes payload code without leaving a normal on-disk trail. The same approach can hide the true parent process, break simple allowlist logic, and bypass detections that depend only on file reputation.

Impact: Security teams may miss early execution, misclassify the event as benign, or lose the chance to capture volatile evidence before the payload exits or mutates. That increases the likelihood of follow-on actions such as credential theft, lateral movement, or additional payload staging.

Practitioner Guidance

What to prioritise: Build detections around process lineage plus memory behaviour, not file presence alone. The best alerts are the ones that combine a legitimate-looking launcher, unusual child processes, executable memory changes, and network activity that begins immediately after launch.

What to verify: Confirm whether the observed process has a normal executable path, whether its memory regions are consistent with expected software, and whether the launcher’s behaviour matches the host role. If the process exists only as transient memory activity, treat that as a higher-priority investigation than a noisy but visible disk-based sample.

Practitioner takeaway: Donut detection is strongest when host telemetry, memory inspection, and process ancestry are analysed together, because the loader’s main defence is not obfuscation alone, it is the absence of normal artefacts.

Related resources from NHI Mgmt Group

• Guide: Malware Guide
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?