Dotnet.exe is the .NET command-line host used to run and manage .NET applications on Windows. Attackers abuse it as a living-off-the-land binary to execute trusted code paths, side-load malicious assemblies, or blend into normal development activity. Defenders should watch for unusual parent processes, unexpected script or archive launches, and .NET execution from user-writable locations.
What Dotnet.exe Means in Attack and Defense
Dotnet.exe is the Windows host for running .NET applications, so it often looks ordinary even when it is being used as a living-off-the-land binary. That dual use is what makes it valuable to defenders and attractive to attackers.
Because the process is signed and familiar in developer environments, it can hide in plain sight. Security teams should judge it by context, not reputation, especially when it appears in places where .NET execution is unexpected.
How Attackers Abuse Dotnet.exe
Adversaries use dotnet.exe to execute trusted code paths, load malicious assemblies, or launch payloads that appear to come from legitimate tooling. In practice, this often means the binary becomes a delivery vehicle for execution rather than the payload itself.
The abuse pattern matters because it reduces the visibility gap between normal development activity and hostile tradecraft. A process that starts with a legitimate host can still lead to script execution, archive-based staging, or assembly loading from suspicious locations.
Detection Signals That Matter
Detection should focus on context around the process chain, the file location, and the child activity. Unusual parent processes, .NET execution from user-writable directories, and dotnet.exe spawning script interpreters or archive utilities are all stronger signals than the process name alone.
Telemetry is most useful when it ties command-line arguments, parent-child relationships, and file provenance together. That lets defenders distinguish expected developer usage from execution that is consistent with LOLBin abuse.
Living off the Land Guide is the best place to place dotnet.exe in the broader LOLBin landscape, including how trusted binaries are abused and how those patterns are detected.
Reducing Exposure to LOLBin Abuse
Hardening should aim to make trusted binaries less useful to attackers without breaking legitimate development workflows. Application control, script governance, and careful restriction of user-writable execution paths all reduce the opportunity for dotnet.exe to be repurposed as an execution bridge.
Defenders should also treat developer tooling as a monitored asset class. When .NET execution is expected only on build hosts or admin workstations, seeing it elsewhere can be an indicator of misuse or staging activity.
Cisco Active Directory credentials leak 2025 reinforces why trusted execution paths become more dangerous when paired with stolen credentials or service accounts, even if the binary itself is legitimate.
Risk and Threat Considerations
Dotnet.exe is risky because it can convert a normal Windows development component into a stealthy execution path. That makes it useful for masquerading, persistence staging, and blending malicious activity into environments where .NET is already common.
Failure mechanism: Attackers gain execution through a trusted host, then use assembly loading, parent-process spoofing, or unexpected child processes to conceal the real payload and evade naive allowlist-based controls.
Impact: The result can be covert code execution, delayed detection, and easier follow-on activity such as script execution, credential abuse, or lateral movement from a host that appears operationally normal.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1218 — System Binary Proxy Execution | Dotnet.exe abuse is a classic signed-binary proxy execution pattern. |
| Recommendation — Map suspicious dotnet.exe activity to T1218 and hunt for trusted-binary execution used to run attacker code. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on process, command-line, and parent-child telemetry. |
| Recommendation — Centralize and review process execution telemetry to spot abnormal dotnet.exe chains. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Dotnet.exe abuse is identified through monitoring unusual execution context and child activity. |
| CM-7 — Least Functionality | Restricting where and how .NET runs reduces the abuse surface for trusted execution paths. | |
| Recommendation — Monitor endpoint process activity and alert on suspicious dotnet.exe launches. Limit .NET execution to approved systems and workflows to reduce LOLBin abuse opportunities. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | When dotnet.exe is paired with service or workload credentials, excessive privilege amplifies impact. |
| Recommendation — Reduce excess privilege on non-human credentials used by .NET workloads and automation. | ||
Practitioner Guidance
What to watch for: Treat dotnet.exe as normal only when its location, parent process, and command-line behaviour fit your known development baseline. If those details do not match, investigate the surrounding process tree instead of focusing on the binary name alone.
Governance implication: Build separate expectations for developer endpoints, build servers, and general user devices. A clear baseline for where .NET should run makes LOLBin abuse much easier to spot and reduces false confidence in signed binaries.