Why do trusted utilities like PowerShell and curl help attackers evade detection?

Why trusted utilities become a detection blind spot

Trusted utilities help attackers because defenders usually baseline them as legitimate administrative tools, not as primary indicators of compromise. That trust reduces alert quality when the same binaries are used for scripting, download, staging, or execution, especially in environments where admins routinely use them for troubleshooting, automation, and remote support.

The problem is not the binary itself, but the context it creates. If a command line uses a familiar utility, many security controls see normal behaviour until the surrounding activity, such as unusual arguments, unexpected child processes, or network access, is analysed.

Attackers also benefit from the fact that these tools often exist by default. MITRE D3FEND is useful here because it helps defenders think in countermeasure terms, not just signature terms, and map suspicious utility abuse to the defensive controls that can reduce blind spots.

How PowerShell and curl blend into normal administration

PowerShell and curl are effective for evasion because they are flexible, scriptable, and common in both support workflows and automation. PowerShell can launch in-memory logic, chain commands, and interact with local or remote systems without dropping obvious custom executables. curl can retrieve payloads, interact with endpoints, and move data while looking like routine connectivity testing.

This makes them valuable for so-called living-off-the-land activity. The attacker is not trying to invent a new toolchain, but to borrow a trusted one whose presence does not stand out. That can reduce file-based artefacts, lower the chance of application reputation checks firing, and make the activity resemble ordinary admin work.

Defenders should assume that allowlisting these tools is necessary but insufficient. The security question becomes whether the command content, process lineage, script source, and network destination fit the expected use of the utility.

For detection engineering, MITRE ATT&CK Enterprise is the most practical reference because it structures the techniques around command execution, PowerShell abuse, ingress tool transfer, and execution chains that defenders can hunt for directly.

What defenders need to inspect instead of the tool name

Detection should focus on behaviour around the utility, not the utility alone. A PowerShell process started by an unusual parent, reaching out to an unknown host, decoding embedded content, or spawning a second interpreter is far more suspicious than PowerShell started from an approved admin session. Curl becomes more concerning when it downloads executable content, posts data to a rare destination, or appears in a process tree that has no operational reason to fetch remote content.

Useful telemetry includes command-line arguments, encoded or obfuscated input, child process creation, script block logging, network connections, and user context. Those signals help separate benign administration from attacker tradecraft that depends on hiding inside trusted execution paths.

Teams that want to tune detections around these patterns can use SANS Security Resources for practitioner guidance on detection engineering and incident handling, especially when building reviews around command-line abuse and suspicious scripting behaviour.

Risk and Threat Considerations

Trusted utilities create a real visibility problem because many endpoint and network controls are designed to trust them by default. When an attacker can operate through an approved binary, they can reduce obvious malware artefacts, blend into normal admin traffic, and keep initial activity below the threshold of some alerts.

Failure mechanism: Security teams over-index on binary reputation and underweight command content, process ancestry, and destination risk, so malicious activity inherits the trust of a legitimate tool.

Impact: That gap can delay detection, widen dwell time, and let attackers stage payloads, enumerate systems, or move laterally while appearing to perform routine troubleshooting or automation.

Practitioner Guidance

What to verify: Treat PowerShell and curl as expected tools, but verify whether each execution fits an approved pattern for that host, user, and time window. The most useful question is not “Was PowerShell used?” but “Was this exact command line, origin, and destination normal for this role?”

Common mistake: Allowlisting the executable name without inspecting arguments, parent process, and network behaviour creates a false sense of safety. If defenders only alert on unknown binaries, they will miss the abuse of trusted ones.

What good looks like: Mature telemetry lets analysts separate sanctioned admin use from suspicious tradecraft by correlating process tree, script content, and outbound connection details. If those three do not line up with the user’s job, the event deserves review.

Practitioner takeaway: The defensive goal is not to block PowerShell or curl outright, but to make their abuse noisy by anchoring detections on behaviour, lineage, and destination rather than tool reputation alone.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• What are effective practices for operationalizing NHI threat detection?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?