DonutLoader uses process injection and script obfuscation on Windows

At a glance

What this is: Aryaka's research dissects the DonutLoader Windows campaign, where obfuscated batch scripting, process injection, and anti-analysis steps are used to keep a .NET implant resident in memory.

Why it matters: It matters because the campaign combines execution hiding, persistence, and telemetry evasion in ways that defeat filename-based detection and demand behavioural controls across endpoint and SOC workflows.

Context

This is a Windows malware campaign built around concealment, persistence, and in-memory execution rather than simple payload delivery. The core governance gap is that static indicators such as file names, hashes, and known paths are not enough when the loader can rename tools, hide staging folders, and move code into trusted processes.

For security teams, the relevant question is how endpoint, SOC, and threat-hunting controls hold up when adversaries combine script obfuscation, process injection, and AMSI or ETW tampering. The identity angle is indirect but real: trusted processes and execution paths become the abuse surface, so control of privileged execution contexts matters as much as payload detection.

Aryaka's starting position is typical of modern loader malware, not exceptional. The pattern is increasingly familiar across Windows intrusion campaigns that aim to survive first contact with endpoint defenses.

Key questions

Q: What breaks when Windows loaders hide in renamed PowerShell and scheduled tasks?

A: Renamed interpreters and scheduled tasks break simple allowlisting and event triage because the execution path looks like routine system activity. Defenders lose the easy signals that normally separate administration from intrusion, so they must pivot to process ancestry, script behaviour, and persistence artefacts to spot abuse before the payload settles in.

Q: Why do process injection and telemetry tampering make loader malware harder to contain?

A: Process injection moves malicious code into a trusted host, while AMSI and ETW tampering reduce the logs and content inspections that would normally expose it. Together they compress both visibility and response time, which means containment has to focus on process behaviour and memory artefacts rather than waiting for an alert from the malicious payload itself.

Q: What are the signs that a Windows loader is moving toward in-memory execution?

A: Look for batch scripts that unpack payloads, create hidden staging directories, launch renamed interpreters, and then generate unusual memory activity in trusted processes. A loader that avoids dropping a normal executable and instead pushes shellcode into explorer.exe or similar hosts is signalling that disk-based inspection will miss the final stage.

Q: How should defenders respond when AMSI or ETW tampering appears in a process chain?

A: Treat it as a high-confidence intrusion signal and immediately widen the hunt to the parent process, nearby scheduled tasks, and any injected memory regions. If telemetry is being suppressed, the safest response is to assume the host has already crossed into active compromise and validate other endpoints that share the same execution pattern.

Technical breakdown

How obfuscated batch loaders hide the first execution stage

The infection begins with a batch script that uses variable substitution, randomised labels, junk instructions, and control-flow obfuscation to make reverse engineering slower and automated analysis less reliable. The script also performs environment checks for usernames, files, and memory conditions before proceeding, which lets the loader suppress execution in sandboxes or analyst environments. It then creates a hidden staging directory and reconstructs embedded payloads from disguised content. This is a common loader pattern: the initial script is not the payload itself, but the orchestration layer that prepares the execution environment and hands off to the next stage.

Practical implication: detection logic must inspect script behaviour and staging artefacts, not just file extensions or hashes.

Why renamed PowerShell and scheduled tasks extend persistence

The campaign uses a renamed copy of powershell.exe and a scheduled task that launches a VBS script at logon, which helps the malware survive reboot and blend into ordinary administrative activity. Renaming a trusted binary does not change its capability, but it can weaken simple allowlists and operator recognition. Scheduled tasks also provide a repeatable launch mechanism that runs outside an interactive session, making containment harder if defenders only watch user-driven execution. This is persistence by disguise, not by sophistication alone.

Practical implication: monitor scheduled-task creation and renamed system binaries as persistence indicators, not benign Windows housekeeping.

How shellcode injection and AMSI tampering reduce endpoint visibility

The loader injects Donut shellcode into explorer.exe so the final .NET implant runs inside a trusted Windows process and keeps much of its activity in memory. It also tampers with AMSI and ETW to reduce the chance that endpoint tools will see script content, module loads, or suspicious execution events. That pairing matters because process injection hides execution context while telemetry tampering hides the evidence trail. Defenders should treat those as linked stages of the same technique, not separate anomalies.

Practical implication: hunt for cross-process memory writes, private executable memory, and changes to AMSI or ETW behaviour together.

NHI Mgmt Group analysis

Execution hiding has become the real control problem: this campaign shows that the hard part is no longer just stopping malware from arriving. It is preventing adversaries from borrowing trusted Windows execution paths, process memory, and scheduled-task infrastructure to make malicious code look native. That shifts the control conversation toward behavioural correlation, process ancestry, and tamper resistance.

Telemetry suppression is now part of the attack path: AMSI and ETW tampering are not afterthoughts, they are deliberate stages in the intrusion. Once attackers can reduce script and event visibility, controls that rely on a single telemetry source become brittle. Security teams need to assume that visibility itself will be contested.

Process identity is an operational security boundary: the campaign relies on explorer.exe and renamed binaries to blur the line between trusted and hostile execution. In governance terms, that means defenders must treat execution context as a first-class control surface, not just user identity or file reputation. The practical answer is tighter enforcement around trusted process abuse.

Custom injection markers create a useful hunting concept: the DE AD BE CA FE BA EF marker is a memorable indicator, but the deeper lesson is that loaders increasingly leave internal state to manage duplicate injection and stability. That kind of state can be turned into a hunting clue when teams correlate memory artefacts, process reuse, and repeated injection attempts.

Behavioural detection beats indicator chasing in loader campaigns: this is a textbook case where filenames, hashes, and IP addresses age quickly, while the execution pattern remains stable. Teams that anchor detection in staging, persistence, injection, and telemetry tampering will outlast the specific payload variant. The programme implication is clear: harden the path, not just the sample.

What this signals

Loader campaigns like this one are a reminder that endpoint security now has to govern execution paths, not just block files. When adversaries can hide inside signed or trusted processes, the operating model shifts from indicator response to behavioural enforcement across staging, persistence, and memory use.

The named concept here is execution-path abuse: malicious code is no longer trying to look harmless on disk alone, it is trying to become indistinguishable from legitimate runtime activity. For practitioners, that means policy and detection need to converge around process ancestry, script interpretation, and tamper-resistant telemetry.

For practitioners

• Hunt for hidden staging directories and renamed binaries Prioritise ProgramData paths, non-standard PowerShell names, and unusual script launch chains that do not match normal administration patterns. Correlate those artefacts with batch files, VBS launchers, and user-writable execution locations.
• Monitor for scheduled-task persistence at logon Review scheduled tasks that execute scripts or interpreters at user logon, especially when they point to hidden directories or renamed executables. Treat new or altered tasks as a persistence event until proven otherwise.
• Correlate process injection with memory-resident execution Look for cross-process memory writes, private executable memory, and explorer.exe as a host for unusual child activity. Add alerts for shellcode delivery patterns that never touch disk after initial staging.
• Detect AMSI and ETW tampering as an attack stage Alert when scripts, loaders, or post-exploitation processes alter AMSI or ETW behaviour, especially if this appears alongside obfuscation or injection. Treat telemetry degradation as a containment priority, not a low-level anomaly.

Key takeaways

• DonutLoader combines obfuscated scripting, persistence, and memory injection to make a Windows implant harder to see and harder to remove.
• The campaign's defensive challenge is not one indicator but a chain of behaviours, including scheduled-task launch, explorer.exe injection, and AMSI or ETW tampering.
• Behavioural correlation across process, script, and memory telemetry is the control shift that best fits this loader pattern.

Key terms

• Process Injection: Process Injection is an attack technique that places malicious code into a legitimate running process. It helps malware hide from user-mode detection, borrow trusted process privileges and evade simple allowlists, so defenders monitor unusual memory operations, remote thread creation and mismatches between process reputation and behaviour. It often signals hands-on intrusion.
• AMSI Tampering: AMSI tampering is any attempt to interfere with the Antimalware Scan Interface so scripts or payloads are less likely to be inspected or blocked. In practice, it weakens a major visibility layer for PowerShell and other script-driven attack chains.
• Scheduled-Task Persistence: A condition where an AI agent creates or modifies recurring automation that continues after the original interaction. It matters because a one-time injection can become durable influence, making later actions look legitimate even though the underlying instruction was attacker-shaped.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to broader security programmes without losing sight of operational reality.