Defenders should look for dotnet-trace.exe running outside approved diagnostics or development workflows. Malicious use may show up as unexpected tracing of sensitive applications, unusual parent processes, or execution on systems where profiling tools should not be present. Correlate process creation with file output and user context, and check whether the tracing activity aligns with authorised troubleshooting.
What makes dotnet-trace.exe suspicious in the first place?
dotnet-trace.exe is a legitimate .NET diagnostics utility, so the question is usually not whether the binary exists, but whether its use matches an approved engineering or troubleshooting purpose. Defenders should treat it as suspicious when it appears on hosts that do not normally host development tooling, when it launches without an obvious change ticket or support context, or when it is pointed at an application that should not be profiled.
A useful baseline is whether the tool is being used the way your organisation actually supports it. In practice, that means comparing host role, user role, command line, timing, and target process against normal diagnostics activity rather than flagging every invocation as malicious.
Which process and command-line patterns matter most?
Start with parent process and command-line context. Unexpected launch chains, such as office productivity software, script hosts, browsers, or other non-admin user processes spawning dotnet-trace.exe, are more interesting than a known developer shell or approved admin session. Command-line review should focus on the target process, output destination, and any options that indicate long-running capture, broad process targeting, or nonstandard collection behavior.
Correlate the trace session with file creation and network-relevant timing. If the utility writes trace output to unusual directories, stage paths, network shares, or locations associated with later exfiltration, that adds weight. The same applies when the process appears alongside archive creation, compression, or scripted post-processing that is not part of routine debugging.
How should defenders validate that the activity is authorised?
Authorised diagnostics usually leave a clear trail in change records, support tickets, or developer workflows. Check whether the host is one where profiling tools are expected, whether the operator has a legitimate maintenance role, and whether the observed timing lines up with a known incident, deployment, or performance investigation. The more the activity deviates from those expectations, the less likely it is to be benign.
For broader hunting, compare the event to other dual-use tooling patterns described in Living off the Land Guide. That helps separate normal administrative use from cases where a legitimate utility is being repurposed for discovery, collection, or staging.
Risk and Threat Considerations
Malicious use of a diagnostic tool is risky because it blends into routine operations and may produce low-friction collection of sensitive application behavior. If an attacker can run dotnet-trace.exe on a production host, they may be able to observe workload internals, confirm what code is running, or capture output that supports later intrusion steps.
Failure mechanism: Abuse usually succeeds when defenders rely on process allow-lists without checking host context, user context, and target process behavior. The utility looks benign at first glance, so the attacker gains collection capability without needing obviously malicious tooling.
Impact: The result can be silent reconnaissance, exposure of application detail, and trace artefacts that support follow-on abuse or data theft. If the trace activity is paired with unusual parent processes or suspicious output handling, treat it as a possible indicator of active compromise.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1003 — OS Credential Dumping | Abuse of diagnostics often supports post-compromise collection and follow-on access. |
| T1218 — System Binary Proxy Execution | dotnet-trace.exe is a legitimate utility that can be repurposed as a living-off-the-land tool. | |
| Recommendation — Hunt for collection and post-exploitation activity when tracing appears outside approved workflows. Correlate legitimate utility use with parent process, target process, and output context. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on correlating process creation, file output, and user context. |
| Recommendation — Centralise and review process and file-activity logs for unexpected diagnostics use. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Trace misuse is found by reviewing correlated activity across host and user events. |
| Recommendation — Correlate process, file, and user events to identify unauthorised tracing. | ||
Practitioner Guidance
What to verify: Confirm that the host, operator, and target process all fit an approved diagnostics pattern. If any one of those three does not fit, do not downgrade the event just because the binary is legitimate.
Decision rule: If dotnet-trace.exe is present on a production system outside a documented troubleshooting window, prioritise triage of the launch path, output path, and the target application before assuming benign administration.
What practitioners underestimate: The tool itself is not the signal, the mismatch between the tool, the environment, and the workflow is. That is why the strongest detections combine process creation, command line, file output, and user context rather than relying on name-based blocking alone.
Practitioner takeaway: Use dotnet-trace.exe detections as a context problem, not a binary problem, because the best indicator of misuse is unauthorised diagnostics behaviour on the wrong host at the wrong time.