How can defenders detect malicious use of dotnet-counters.exe?

What makes dotnet-counters.exe useful for defenders to watch

Dotnet-counters.exe is a legitimate .NET diagnostics utility, so the key question is not whether it exists on the endpoint, but whether its use matches a normal troubleshooting workflow. In a defender's view, the tool becomes noteworthy when it appears on systems that should not host developer activity, or when it is launched in a way that suggests inspection of running processes rather than routine performance analysis.

That means the most important context is the surrounding execution chain. A single process name is rarely enough to judge intent, so defenders should anchor on parent process, command line, user account, host role, and time of execution. When those details line up with administrative troubleshooting, the event is less concerning; when they do not, the same binary can be a strong signal of reconnaissance.

Because dotnet-counters.exe is part of a broader class of legitimate utilities that can be reused during intrusion, it is helpful to treat it as one potential living off the land indicator rather than as a standalone alert. The practical detection value comes from correlating tool use with other discovery behaviors, especially process inspection, code discovery, and unusual execution on production servers.

Which telemetry patterns are most useful for detection

The strongest detections combine host telemetry with process lineage and command line detail. Look for dotnet-counters.exe started by shells, script hosts, office applications, or other unexpected parents, because those lineages are less consistent with ordinary .NET performance work. Also watch for execution under service accounts or user contexts that do not normally perform application diagnostics.

Command line inspection matters because legitimate use typically targets a specific process or session for diagnostics. Suspicious use often appears alongside broader enumeration, repeated probing of processes, or activity that is hard to justify as troubleshooting on a production server. When the tool appears in the same timeline as discovery commands, remote admin activity, or interactive inspection on a server, the probability of hostile use rises.

Correlating these signals with environment context is essential. A developer workstation, lab host, or build system may legitimately run the utility, but a business application server, domain controller, or other fixed-role server usually should not. That role-based difference is what turns the same binary from routine noise into a meaningful investigative lead.

For broader attack-chain mapping, defenders can compare the event pattern with recognized adversary behaviors in MITRE ATT&CK Enterprise Matrix, especially discovery and credential access-adjacent sequences that rely on legitimate tools for cover.

How should defenders investigate and respond

The first investigative step is to validate whether anyone had a business reason to run the tool on that host at that time. If there is no clear troubleshooting ticket, maintenance window, or engineering activity, treat the execution as suspicious and widen the review to nearby process trees, logons, and lateral movement indicators. That helps determine whether the utility was used as a one-off probe or as part of a broader intrusion.

Defenders should preserve the command line, parent and child process tree, user context, and any related session data before making containment decisions. If the activity is confirmed as unauthorized, the priority is to determine what the operator observed through the tool and whether follow-on actions suggest deeper access. In practice, dotnet-counters.exe is often less important as a payload than as evidence that an actor is mapping the runtime environment.

Good detection also benefits from hardening the environment that should not need the utility at all. Restrict where developer diagnostics tools can run, reduce local administrative access on servers, and baseline which hosts normally execute .NET diagnostic binaries. That makes deviation easier to spot and reduces the chance that legitimate tooling becomes an undetected recon path.

Practitioner Guidance

What to verify: Confirm whether the host role, user, and timing fit a normal .NET troubleshooting workflow before suppressing the alert. On production systems, a legitimate explanation should usually be easy to document.

What to prioritise: Focus first on lineage, command line, and co-occurring discovery activity, because those fields are what separate harmless diagnostics from likely reconnaissance.

Common mistake: Do not whitelist the binary globally just because it is a Microsoft tool. The same utility can be benign on one system and highly suspicious on another.

Practitioner takeaway: The most reliable signal is context, not the executable name, use the surrounding process behavior to decide whether dotnet-counters.exe represents routine diagnostics or active reconnaissance.

Related resources from NHI Mgmt Group

• How can defenders detect malicious use of Bginfo.exe?
• How can defenders detect malicious use of Csc.exe?
• How can defenders detect malicious use of devtunnel.exe?
• How can defenders detect malicious use of Eventvwr.exe?