CLR-Stomp

A Beacon Object File (BOF) that loads a .NET assembly into a Cobalt Strike or compatible beacon via CLR module stomping. The payload PE is written into a victim GAC assembly's file-backed mapping so that ETW reports a legitimate on-disk path.

Project lineage

This BOF is based on the ideas and scaffolding from Being-A-Good-CLR-Host and InlineExecute-Assembly.

Being-A-Good-CLR-Host provided the proof of concept for using Load_2 together with a custom IHostMemoryManager to influence how assemblies are mapped.

InlineExecute-Assembly provided the BOF-oriented execution model and the stdout capture pattern used to get managed output back to the operator.

This version expands on those pieces by letting the CLR map a real GAC assembly, overwrite that with the payload before metadata parsing, and keeps the resulting managed assembly tied to the victim's disk identity.

This is not the first public mention of .NET assembly stomping as a tradecraft idea. Nighthawk C2's 0.2.1 "Haunting Blue" describe support for a similar .NET stomping feature.

This project is an independent BOF-focused implementation of that general idea.

How it works

The BOF lets the CLR resolve and map a real assembly from the GAC and then swaps the mapped image with the payload before the CLR has a chance to read the .NET metadata. The CLR records the victim assembly's real disk path first. Afterwards, when the file-backed image mapping exists but has not yet been parsed, the custom memory manager overwrites that mapping with the payload's PE headers and sections. From the CLR's point of view, the bind still belongs to the GAC assembly, but the executed code comes from the supplied payload.

Hosting the CLR

The BOF creates the CLR using CLRCreateInstance for an ICLRMetaHost and then obtains two host interfaces from the same runtime:

• ICLRRuntimeHost, used before Start() so the BOF can call SetHostControl() and register its custom managers.
• ICorRuntimeHost, used after startup to get the default AppDomain, load the assembly, and invoke its entry point through reflection.

Before the CLR starts, the BOF gives it a custom IHostControl. When the CLR asks that object for managers, it returns:

• IHostMemoryManager, which lets the BOF see virtual memory activity made by the CLR. The AcquiredVirtualAddressSpace callback is where the mapped victim image is overwritten.

Environment variables

Two environment variables are set before the CLR is created:

SetEnvironmentVariableA("COMPLUS_ZapDisable", "1");
SetEnvironmentVariableA("COMPLUS_AllowStrongNameBypass", "1");

COMPLUS_ZapDisable=1 keeps the CLR from using NGen native images. That matters because NGen loads do not go through the same host callbacks, so the stomp point may never be reached.

COMPLUS_AllowStrongNameBypass=1 avoids strong-name re-verification after the image has been replaced. The victim identity still belongs to the GAC assembly, but the mapped bytes no longer match that assembly's strong name.

Controlling the assembly bind

The BOF calls Load_2 with the name of a legitimate .NET assembly that we provide via the CNA and is already present in the GAC.

For CLR v4 by default it will use:

System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorarchitecture=msil

For CLR v2 by default it will use:

System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

The CLR performs a normal GAC lookup, opens the real DLL from disk, and maps it into memory as an executable image (SEC_IMAGE).

Once the image has been mapped into memory :

1. AcquiredVirtualAddressSpace(base, size) is triggered
2. BOF overwrites the mapped image with the payload. Sections are copied to their VirtualAddress and Memory protections are updated section-by-section
3. CLR reads metadata from the overwritten image
4. Load_2 returns the payload assembly

The CLR then continues normally believing it loaded the original GAC assembly although properties like CodeBase and Location still point to the legitimate GAC DLL path.

Because the assembly is loaded by strong-name identity rather than from a raw byte array, AMSI's managed assembly scan is never presented with the payload bytes.

ETW CLR loader events record the victim's GAC path as the module source, so telemetry sees a legitimate assembly load rather than an in-memory one.

Then its a matter of invoking the assembly entry point via reflection with Invoke_3.

For capturing output, a redirect of stdout to a named pipe is happening.

Running

Load clr-stomp.cna.

Arguments

Argument	Required	Description
--dotnetassembly <path>	Yes	Path to the .NET payload assembly (.exe)
--assemblyargs "<args>"	No	Arguments passed to the payload's Main(). Quote multi-word values.
--appdomain <name>	No	AppDomain friendly name (default: CLRStomp)
--victim-full "<identity>"	No	Full GAC identity for the victim assembly. Defaults to System.ServiceModel (CLR v4) or System.Drawing (CLR v2) based on the payload's CLR version.

The pipe name is generated randomly per invocation and does not need to be specified.

Examples

Basic execution:

clr-stomp --dotnetassembly /opt/tools/Seatbelt.exe

With arguments:

clr-stomp --dotnetassembly /opt/tools/Seatbelt.exe --assemblyargs "OSInfo AntiVirus"

Custom victim and AppDomain:

clr-stomp --dotnetassembly /opt/tools/Rubeus.exe --assemblyargs "triage" --appdomain MyDomain --victim-full "System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorarchitecture=msil"

Detection and IOCs

A number of useful IOCs exist and are documented below:

IOC	Where	Notes
COMPLUS_ZapDisable=1	Process environment	Set before CLR initialization to force the MSIL load path.
COMPLUS_AllowStrongNameBypass=1	Process environment	Set before CLR initialization to avoid strong-name re-verification after stomping.
Local\CLRBofState_v6_<pid>	Named file mapping	Persists CLR host state across BOF invocations in the same process. PID suffix isolates each process's state.
\\.\pipe\clr????????	Named pipe pattern	The CNA generates pipe names with clr plus 8 lowercase alphanumeric characters.
CLRStomp_clr????????	AppDomain name	Built as <appDomainName>_<pipeName> at runtime. Default base is CLRStomp; pipe suffix matches the pipe name IOC above.
System.Drawing, Version=2.0.0.0, ... / System.ServiceModel, Version=4.0.0.0, ...	Victim identity	Default full identity chosen from the payload CLR version.
[*] Initialising CLR / [+] Load_2 succeeded (stomped) / [*] Resolving entry point / [*] Invoking entry point	Beacon output	Distinctive status strings emitted by the BOF.
PE-mapped payload into victim / Stomp did not fire	BOF output / memory strings	Useful strings for memory or console telemetry when available.

However, the strongest detections should correlate behavior instead of relying on a single string.

• Native or normally unmanaged processes loading mscoree.dll, clr.dll, or mscorwks.dll
• A GAC assembly load where the recorded module path is legitimate, but the in-memory image no longer matches the backing file on disk.

AI Usage

This research and development effort was conducted collaboratively between a human and AI-assisted tooling, using the AI models GPT-5.5 and Claude Sonnet 4.6.

The AI models were used to assist with code generation and reverse engineering support.

However, all research direction, validation, debugging, testing, security analysis, and final technical decisions were performed by a human (Imdefinelyhuman).

All generated content, code, and analysis were reviewed, validated, modified, and integrated manually as part of an iterative human-guided workflow.

The above statement is a fancy way of also saying that the code has bugs and use it at your own risk!

References & Credits

• passthehashbrowns/Being-A-Good-CLR-Host
• anthemtotheego/InlineExecute-Assembly
• etormadiv/HostingCLR
• ldematte/HostedPumpkin
• TheWover/donut
• TrustedSec/COFFLoader
• Dealing with Failure - SpecterOps

Lefteris (Lefty) Panos @ LRQA Red Team 2026