How do attackers use COR_PROFILER?

How COR_PROFILER Becomes an Execution Path

Attackers abuse COR_PROFILER by turning a .NET profiling feature into a code-loading primitive. If they can set the right environment variables, the runtime will load a profiler DLL into target .NET processes, and that DLL can run attacker-controlled code inside those processes. The technique is attractive because it can blend into normal application startup behavior.

That makes the abuse less about “patching a bug” and more about controlling a trusted loading path. The attacker is not necessarily breaking .NET itself, they are steering the runtime to load their code at process start or restart, which can make the activity look like legitimate instrumentation or application behavior.

What Attackers Gain From Profiler Loading

Once a malicious profiler is loaded, it can do more than just execute a payload. It may instrument managed code, alter in-memory behavior, hide activity from userland visibility, or reinsert itself whenever the application restarts. That is why this technique is often useful for persistence, stealthy injection, and post-compromise control over managed applications.

In practice, the value comes from placement. A profiler runs inside a target process with the same trust boundary as that process, so the attacker can piggyback on the application’s own execution context rather than launching an obviously separate suspicious binary.

What Defenders Need to Check First

Start with whether profiling is allowed on the systems and accounts that matter. A legitimate development or diagnostics setup can look very similar to abuse, so the key question is whether the environment variables, service definitions, or startup configuration that enable profiling are expected for that host and workload.

Then look for the observable signs of misuse: unexpected profiler DLLs, recent environment variable changes, and .NET process modifications that do not match approved troubleshooting or monitoring tools. The Persistence Techniques Guide is useful here because COR_PROFILER abuse sits in the same family of execution-flow hijacking and startup persistence patterns.

Risk and Threat Considerations

Profiler abuse is risky because it turns a diagnostic capability into an execution and persistence mechanism. If an attacker can write the profiling configuration for a service, application pool, or scheduled workload, they may gain durable code execution without modifying the application binary itself.

Failure mechanism: The runtime loads the attacker’s profiler library through trusted profiling settings, so the malicious DLL executes inside the managed process and can survive routine restarts or normal application activity.

Impact: Defenders may miss the compromise if they only watch for new executables, while the attacker can maintain access, manipulate managed code paths, and conceal follow-on activity inside otherwise legitimate .NET processes.

Practitioner Guidance

What to verify: Confirm which hosts, services, and accounts are allowed to use profiling, and compare that list to actual environment variable settings and loaded profiler paths. If profiling is enabled on a production system, treat any deviation from the approved profiler path as suspicious until explained.

Decision rule: If a profiler DLL is unexpected, prioritize containment and credential review for the hosting service before assuming the issue is only a host-level persistence problem. The attacker may have used the profiler path to gain code execution inside a long-lived process, which can widen the blast radius beyond that single binary.

Practitioner takeaway: COR_PROFILER abuse is a trusted-loading problem, so the real control objective is to tightly govern who can enable profiling and to make any profiler loading event easy to explain, detect, and investigate.

Related resources from NHI Mgmt Group

• How do attackers use list planting?
• How do attackers use invisible Unicode?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?