Reflective .NET Assembly Injection

How reflective .NET assembly injection works

Reflective .net assembly injection is a memory-resident loading technique. Instead of dropping a managed assembly to disk and launching it through a normal loader path, the attacker stages the assembly in memory and invokes it inside an existing process. That makes the execution path less visible to file-centric controls and can blend malicious logic into an otherwise trusted runtime.

The technique matters because the .NET runtime is designed to load and execute managed code efficiently, and defenders often assume a binary on disk is the primary thing to inspect. When that assumption is wrong, the real question becomes whether the host process, its memory state, and its runtime activity look consistent with legitimate application behaviour.

Why attackers use it

Attackers favour reflective loading when they want to reduce artefacts, avoid simple hash-based detection, or execute code in a process that already has the right network reach, permissions, or trust relationships. It is often paired with other post-exploitation techniques such as process injection, script engine abuse, or living-off-the-land execution to keep the activity inside existing telemetry blind spots.

The defensive challenge is that the malicious payload may never appear as a conventional file, so scanning only the filesystem misses part of the picture. Techniques that rely on trusted process context can also weaken separation assumptions, especially when monitoring is focused on signed binaries rather than what they are doing in memory.

For broader EDR blind-spot patterns around reflective loading, process injection, unhooking, and tamper behaviour, see the EDR Evasion and Defence Guide.

How defenders detect exposure

Detection starts with process and memory visibility, not just file reputation. Teams should know which applications normally load managed assemblies, which parent-child process relationships are expected, and where unusual memory allocations, CLR activity, or command-line patterns suggest that code is being staged and executed outside standard installation paths.

Asset inventory also matters. If an endpoint should never host a .NET-based agent, admin utility, or automation component, then unexpected managed execution is a stronger signal than it would be on a developer workstation. Vendor advisories and threat research can help distinguish benign in-memory loading from suspicious patterns, especially when the same runtime behaviours can be used by both legitimate tooling and malware.

File-based controls still help, but they are only one layer. Memory telemetry, AMSI and script inspection where relevant, application allowlisting, and alerting on untrusted code loading all improve confidence that execution is legitimate.

Remediation and response after suspected use

When reflective injection is suspected, response should focus on containment, triage, and evidence preservation. The priority is to determine which process loaded the code, what that code accessed, and whether the host was used to stage lateral movement, credential theft, or follow-on payloads.

Because the technique often runs inside a trusted process, compromise review should include any credentials, tokens, API keys, session material, or service account secrets available to that process. If the injected code had access to privileged application state or remote management channels, those access paths may need to be treated as compromised even if the original file system looks clean.

After remediation, re-evaluate detections for memory-only execution, review exclusions that may have weakened visibility, and confirm that telemetry still captures suspicious assembly load behaviour across similar hosts.

Practical security implications

Reflective .NET assembly injection is not just a malware delivery trick, it is an execution-control problem. It shows where organisations rely too heavily on disk artefacts, allowtrusted runtime contexts to execute arbitrary managed code, or lack enough memory-level telemetry to distinguish normal application behaviour from abuse.

For defenders, the most useful mental model is to treat the runtime as part of the attack surface. If a process can load code from memory, then allowlisting, telemetry, and trust boundaries need to be evaluated at the point of execution, not only at the point of file creation.

Related resources from NHI Mgmt Group

• How should security teams prevent SQL injection in .NET applications?
• What are the signs that a .NET framework is resolving assembly names from user-controlled request data?
• How should .NET teams prevent command injection when user input reaches operating system commands?
• What are the signs that a .NET application is vulnerable to command injection?