CLR-Stomp - .NET CLR-Stomping

项目说明

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 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 expands on those pieces by letting the CLR map a real GAC assembly, o that with the payload before metadata parsing, and keeps the resulting managed assembly tied to the '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 assembly's real disk path first. Afterwards, when the file-backed image mapping exists but has not yet been parsed, the custom memory manager o 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:

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

En

Two en are set before the CLR is created:

COMPLUS_ZapDisable=1 keeps the CLR from using NGen nati. 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- after the image has been replaced. The 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:

For CLR v2 by default it will use:

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. Acquired(base, size) is triggered
2. BOF o the mapped image with the payload. Sections are copied to their and Memory protections are updated section-by-section
3. CLR reads metadata from the o 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 ne with the payload bytes.

ETW CLR loader events record the '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 in the assembly entry point with In.

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 . |
| --appdomain <name> | No | AppDomain friendly name (default: CLRStomp) |
| -- "<identity>" | No | Full GAC identity for the assembly. Defaults to System.Ser (CLR v4) or System.Drawing (CLR v2) based on the payload's CLR . |

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

Examples

Basic execution:

With arguments:

Custom and AppDomain:

Detection and IOCs

A number of useful IOCs exist and are documented below:

| IOC | Where | Notes |
|-----|-------|-------|
| COMPLUS_ZapDisable=1 | Process en | Set before CLR initialization to force the MSIL load path. |
| COMPLUS_AllowStrongNameBypass=1 | Process en | Set before CLR initialization to avoid strong-name re- after stomping. |
| Local\CLRBofState_v6_<pid> | Named file mapping | Persists CLR host state across BOF in 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, =2.0.0.0, ... / System.Ser, =4.0.0.0, ... | identity | Default full identity chosen from the payload CLR . |
| [*] Initialising CLR / [+] Load_2 succeeded (stomped) / [*] Resolving entry point / [*] In entry point | Beacon output | Distincti strings emitted by the BOF. |
| PE-mapped payload into / Stomp did not fire | BOF output / memory strings | Useful strings for memory or console telemetry when a. |

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

AI Usage

This research and de 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, , debugging, testing, security analysis, and final technical decisions were performed by a human (Imdefinelyhuman).

All generated content, code, and analysis were re, , modified, and integrated manually as part of an iterati workflow.

The abo 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
* etormadi
* ldematte/HostedPumpkin
* TheWo
* TrustedSec/COFFLoader
* Dealing with Failure - SpecterOps

Lefteris (Lefty) Panos @ LRQA Red Team 2026

项目信息

开发语言：C

Star 数：146

技术要点

该项目属于红蓝攻防方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕.NET CLR-Stomping展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。