Attackers abuse Dotnet.exe to run .NET applications and assemblies through a trusted Microsoft runtime. This allows them to execute managed code without dropping a separate native loader, which can complicate detection. Defenders should monitor for unusual assemblies, command-line arguments, and dotnet.exe executions from user-writable paths or non-standard application folders.
How Dotnet.exe Gets Abused in Living-off-the-Land Tradecraft
Attackers use dotnet.exe as a trusted Microsoft runtime to execute managed code without introducing an obvious custom loader. That makes it useful for blending malicious activity into normal developer or application noise, especially when the binary is launched with unusual command-line arguments or from paths that do not match expected software locations.
One common abuse pattern is loading a malicious or repurposed .NET assembly directly through the runtime instead of dropping a separate native executable. That can reduce the chance of simple binary reputation checks catching the activity and shifts the defender’s job toward process lineage, command-line scrutiny, and assembly-level inspection.
This behaviour sits squarely in Living off the Land Guide territory because the tactic depends on legitimate system tooling doing unexpected work. The same operational logic also explains why defenders should watch for trusted utilities being launched from user-writable directories, temporary folders, or application paths that do not fit the host’s normal software profile.
Attackers may also use dotnet-hosted execution to stage later payloads, run scripts or in-memory logic, or mask secondary behaviours behind a routine-looking .NET process. When that process is spawned by Office, browser, archive, or script activity, the key question is whether the execution path matches a real application workflow or an abuse chain built to evade basic controls.
What Defenders Should Look For First
The highest-value signals are not just that dotnet.exe ran, but what it loaded, where it was launched from, and what it touched next. Suspicious signs include execution from non-standard folders, arguments that point to unusual assemblies, child processes that do not fit the expected application role, and repeated launches from the same user context without a clear business reason.
Process creation telemetry, script block logging where available, and file-origin review are the fastest ways to separate a legitimate runtime invocation from abuse. If the assembly is unsigned, newly written, downloaded, or living in a user-controlled location, that materially raises the likelihood that the runtime is being used as an execution wrapper rather than as part of a normal application deployment.
For a broader view of how attackers mix trusted binaries, proxies, and dual-use tooling into real intrusion chains, The State of NHI & AI Agent Breach Report 2026 is useful because it shows how abuse paths often begin with trusted execution and then pivot into credential access, persistence, or lateral movement.
When you compare these events to ordinary developer activity, the practical discriminator is context. A build server, test harness, or CI runner may legitimately invoke the runtime many times. A workstation that rarely runs .NET tooling, especially one launching it from a writable user profile or temp location, deserves immediate review.
Why This Tactic Matters for Detection and Response
Abuse of dotnet.exe is attractive because it lets attackers ride on a signed, well-known runtime instead of bringing a louder native loader. That can delay detection, complicate file-based prevention, and make simple “block unknown EXEs” controls less effective if defenders do not also inspect command lines, parent-child relationships, and assembly provenance.
The response priority is to determine whether the runtime launch was a one-off execution artifact or part of a broader intrusion chain. If the assembly has already run, examine adjacent activity for credential theft, remote access tooling, outbound connections, and persistence mechanisms that could have followed the initial launch.
Attack chains that rely on trusted Microsoft binaries are often described as MITRE ATT&CK Enterprise Matrix style living-off-the-land activity, which helps teams map the abuse to known techniques and hunt for the surrounding behaviours rather than the binary alone.
In practice, defenders should treat abnormal dotnet.exe use as a signal to widen the investigation, not narrow it. The runtime is only the delivery mechanism; the real security question is what code was executed, whether it was expected, and whether the host now shows signs of follow-on compromise.
Risk and Threat Considerations
Because dotnet.exe is a trusted runtime, attackers can use it to lower suspicion while executing managed code, which increases the chance of delayed detection and missed follow-on activity. The main risk is not the binary itself, but the trust it inherits from the operating system and the way that trust can be abused to stage, mask, or prolong compromise.
Failure mechanism: Security tooling may treat the process as benign if it focuses on signed Microsoft binaries instead of execution context, command-line intent, assembly origin, and abnormal parent-child relationships.
Impact: A malicious assembly can run under an ordinary-looking process, giving the attacker time to establish persistence, collect credentials, or move laterally before defenders recognise the execution as hostile.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Dotnet.exe abuse is a command execution technique |
| T1218 — System Binary Proxy Execution | Trusted Microsoft binaries can proxy malicious code execution | |
| Recommendation — Map suspicious runtime launches to T1059 and hunt for the surrounding execution chain. Investigate trusted-binary launches that execute unexpected code or assemblies. | ||
| NIST CSF 2.0 | DE.CM-01 — Anomalies and events are monitored to find potentially adverse events | Abusive dotnet.exe launches are best found through behavioural monitoring |
| Recommendation — Monitor process creation, command lines, and assembly paths for anomalous runtime use. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Detection depends on retaining process and execution telemetry |
| SI-4 — System Monitoring | Endpoint monitoring is needed to spot suspicious runtime abuse | |
| Recommendation — Generate audit records for process starts, command lines, and file-origin events. Correlate process lineage and file activity to identify abnormal dotnet.exe behaviour. | ||
Practitioner Guidance
What to verify: Confirm the parent process, launch path, command line, and assembly location before deciding whether the event is normal developer activity or abuse. A legitimate runtime invocation should line up with an expected application, deployment path, and user role.
Decision rule: If dotnet.exe is launched from a user-writable path or is loading an assembly from an unusual location, treat it as suspicious even if the binary itself is Microsoft-signed. Signature trust does not equal workflow legitimacy.
What practitioners underestimate: The strongest clue is often not the runtime launch itself, but the mismatch between the process context and the host’s normal software pattern. That mismatch is what turns a generic .NET execution into an abuse indicator.
Practitioner takeaway: Focus on execution context and loaded code, not just the presence of dotnet.exe; attackers rely on trusted runtimes precisely because they look ordinary until the surrounding telemetry is examined.