dotnet-trace.exe is a .NET diagnostics tool for collecting runtime tracing data from applications. Attackers may use it to invoke a trusted binary, reduce scrutiny, or gather execution data from target processes. Defenders should watch for suspicious tracing targets, unexpected collection activity, and use by accounts or hosts that do not normally perform .NET troubleshooting.
What dotnet-trace.exe Is and Why It Matters
dotnet-trace.exe is a trusted .NET diagnostics utility, which makes it useful for legitimate performance tracing but also attractive to abuse in environments where defenders allow signed tools broader latitude than ordinary binaries.
Because it is a real troubleshooting binary rather than an obviously malicious file, it can blend into administrative activity and make hostile execution look like routine diagnostics. That dual-use property is why attackers value Windows LOLBins, and why defenders should treat unusual use of tracing tools as a signal worth investigating.
How Attackers Abuse dotnet-trace.exe
In offensive activity, the tool can be invoked to collect runtime data from a process, observe application behaviour, or create noise that distracts analysts from the true purpose of the host activity. When a trusted diagnostics binary is launched from an unexpected parent process, by an unusual account, or against a process that does not fit the machine’s normal role, it becomes more than a troubleshooting event.
The abuse pattern is less about the tool itself and more about the trust defenders place in signed, vendor-provided binaries. That trust can be used to reduce scrutiny, evade simplistic allow/deny logic, and make command-line activity harder to classify quickly.
What Defenders Should Look For
Detection starts with context: which hosts normally run .NET diagnostics, who uses them, and whether the target process matches a support or engineering workflow. Suspicious patterns include tracing on servers that should not be profiled, trace collection outside approved maintenance windows, and repeated execution from user shells or automation contexts that are not typical for troubleshooting.
Command-line logging, parent-child process analysis, and host role awareness are especially valuable here. The tool is not inherently malicious, so defenders need to focus on behaviour, not just the presence of the binary.
For broader living-off-the-land tradecraft, the Living off the Land Guide shows how signed utilities become security-relevant when they are repurposed for stealth, execution, or post-exploitation activity.
Hardening, Detection, and Investigation
Reduce exposure by limiting who can run diagnostics tooling, constraining where it is available, and making sure application teams have an approved path for trace collection that security can distinguish from abuse. Application control, command-line auditing, and least-privilege administration make it harder for a LOLBin to be used casually on the wrong host.
When suspicious use is found, review the initiating account, the target process, the command line, and any follow-on collection or staging activity. If the tracing session was part of a compromise, the artefact trail may reveal what the attacker examined before moving to credential access, persistence, or exfiltration.
LOLBin abuse often rides on trusted binaries, so the relevant question is not whether the tool exists, but whether its use fits the environment’s normal operational pattern.
Risk and Threat Considerations
Attackers favour dotnet-trace.exe because it can sit inside legitimate administration patterns while still giving them visibility into running .NET processes. That makes it useful for stealthy reconnaissance, for blending in with support activity, and for working around naive controls that focus only on unknown executables.
Failure mechanism: A trusted diagnostics binary is launched in a context that defenders expect to be benign, so abnormal tracing activity is not immediately challenged and the attacker gains low-friction visibility into the target process.
Impact: The result can be improved attacker understanding of application behaviour, longer dwell time, and a weaker detection window for adjacent actions such as credential theft, staging, or lateral movement.
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 CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1218 — Signed Binary Proxy Execution | dotnet-trace.exe is a trusted signed utility that can be repurposed for proxy execution and blending. |
| Recommendation — Map unexpected use of trusted binaries to signed-binary abuse detections and hunt for proxy-execution patterns. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Command-line and process logging are central to spotting abnormal diagnostics-tool abuse. |
| Recommendation — Enable detailed process and command-line logging to detect unusual diagnostics tool usage. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Audit generation supports visibility into execution of diagnostics binaries and their parameters. |
| SI-4 — System Monitoring | Monitoring is needed to identify suspicious tracing activity and abnormal target processes. | |
| Recommendation — Generate process and command-line audit records for high-risk administrative utilities. Monitor endpoint activity for unusual tracing targets, parent processes, and execution context. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | The term depends on behavioural anomaly detection because the binary is legitimate but context may be hostile. |
| Recommendation — Correlate process lineage and usage patterns to flag anomalous diagnostics activity. | ||
Practitioner Guidance
What to watch for: Treat dotnet-trace.exe as a normal tool only when its use matches a documented support or engineering workflow. The most useful control point is not the filename alone, but whether the host, account, parent process, and target process align with an approved diagnostics use case.
Practitioner takeaway: Build detections around deviation from normal troubleshooting patterns, not around the existence of the binary itself.