Detect it by monitoring for those tools running on endpoints where they are not approved, then correlate them with attempts to stop, suspend, inject into, or disable security processes. Look for unusual handle access to protected services, process termination events, and sudden loss of telemetry from EDR or antivirus agents. Restrict admin access and alert on process manipulation attempts.
What makes Process Hacker and System Informer useful to defenders and attackers alike?
Process Hacker and System Informer are legitimate diagnostic tools, but they are also powerful enough to enumerate processes, services, handles, memory, and access rights in ways that make tampering with security software easier. On Windows endpoints, the core question is not whether the tools are present, but whether they are being used outside an approved admin workflow and alongside behaviour that changes the state of security controls.
That is why detection should focus on the combination of tool presence and suspicious action. A single process tree view is not enough; you need the context of what the user did next, what process they targeted, and whether protective telemetry suddenly became incomplete.
In practice, the most useful signal is correlation. If these tools appear on a workstation that should not run them, and shortly after you see attempts to stop, suspend, inject into, or disable security tooling, the case moves from “admin utility” to likely defence interference. EDR evasion and defence guidance is the right conceptual lens here because the observable behaviour often overlaps with tamper techniques such as process manipulation, exclusion abuse, and sensor blinding.
Which Windows events and telemetry patterns matter most?
The cleanest detections usually come from joining process creation, service control, and security product telemetry. Watch for the tool binaries themselves, unusual parent-child chains, and administrative sessions that spawn them outside known support activity. Then correlate those events with process termination, service stop, DLL injection, handle opens against protected services, and sudden gaps in EDR or antivirus reporting.
Windows event logging is especially valuable because tampering often leaves traces even when the endpoint security agent is disrupted. Process creation, service changes, and log clearing are all useful pivots, and a defender should treat any drop in telemetry from the affected host as part of the signal rather than as a separate problem. Windows event logging for security teams helps anchor those pivots around the event classes that usually reveal the sequence of activity.
Handle access is another important clue. When a non-standard administrative tool suddenly requests access to security processes or protected services, that can indicate an attempt to interfere with a defender, inspect its memory, or prepare a suspend or terminate action. The detection value is highest when the handle event is paired with a contemporaneous process manipulation attempt rather than viewed in isolation.
How should defenders separate legitimate admin use from tampering?
The deciding factor is usually intent and sequence, not the tool name alone. In a managed environment, a support engineer may open System Informer to investigate performance, but that is materially different from an endpoint where the same tool appears during a burst of service stops, process injection, and telemetry loss. The second case is much closer to active defence impairment than routine troubleshooting.
Restricting admin access matters because these tools are often most dangerous in the hands of a local administrator or a compromised privileged session. If the workstation fleet does not have a valid support use case for them, block execution or alert on launch. If you do allow them for remediation, scope that permission tightly and pair it with strong audit logging so a genuine maintenance action is visible and attributable.
It also helps to cross-check against the security stack itself. If EDR or antivirus telemetry disappears, treat that as a probable symptom of tampering, not a monitoring gap to ignore. A well-tuned environment should make it hard to stop or blind security services silently, and any exception for administrative tooling should be explicit, time-bounded, and recorded.
Risk and Threat Considerations
These tools become risky when they are used to interfere with security controls rather than inspect the system. The main exposure is not the utility itself, but the combination of elevated access, process-manipulation capability, and the ability to degrade visibility into EDR or antivirus activity.
Failure mechanism: An attacker or insider with administrative access uses a legitimate Windows process inspection tool to target protected services, suspend or terminate defensive processes, or inject code into security software, then reduces telemetry to make the action harder to spot.
Impact: Endpoint protection can be blinded or partially disabled, which increases dwell time, allows follow-on payloads to run with less resistance, and makes later investigation harder because the host may lose logs or telemetry at the exact moment it matters most.
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 | T1057 — Process Discovery | Covers process enumeration used to inspect and target security tools. |
| T1562 — Impair Defenses | Directly fits attempts to stop, suspend, inject into, or disable security software. | |
| Recommendation — Map process-inspection telemetry to T1057 and correlate it with security-tool targeting. Hunt for T1562 activity whenever these tools precede security-control disruption. | ||
| NIST CSF 2.0 | DE.AE-03 — Anomalies and Events Are Analyzed | Supports correlating tool execution, process manipulation, and telemetry loss as suspicious events. |
| PR.AA-05 — Identities Are Authenticated, Authorized, and Managed | Relevant because restricting admin use and privileged access reduces misuse of these tools. | |
| Recommendation — Analyze these endpoint anomalies together instead of treating each event in isolation. Restrict privileged access so only approved administrators can run such utilities. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Needed to retain process, service, and security-tool activity for correlation. |
| Recommendation — Generate audit records for process, service, and security-tool changes that matter. | ||
Practitioner Guidance
What to prioritise: Build detections around the behaviour chain, not the binary name. The highest-value rule is tool execution on an unapproved endpoint followed by security-process manipulation or telemetry loss.
What to verify: Confirm whether the host has a legitimate admin workflow for the tool, whether the user had approved maintenance access, and whether the security agent’s logs stopped because of a crash, a policy change, or deliberate interference. If the sequence includes handle access to protected services, treat it as a stronger indicator than a one-off process launch.
Practitioner takeaway: The important judgement is to treat Process Hacker or System Informer as a context-sensitive signal, where the real risk appears only when privileged use, security-process targeting, and visibility loss occur together.
Related resources from NHI Mgmt Group
- How do you detect ETW tampering used to blind Windows security monitoring?
- How should security teams detect and prioritize LOLBAS activity in Windows environments before attackers turn trusted tools into delivery and execution paths?
- How should security teams detect process hollowing and process herpaderping in Windows environments?
- How do security teams detect fileless malware when it runs through legitimate system tools?