Proxy execution is the abuse of a trusted system utility or application to run malicious code indirectly. It hides attacker intent inside normal software behaviour, which weakens security tools that focus on suspicious binaries rather than the process path used to launch them.
Expanded Definition
Proxy execution is an evasion technique in which a trusted binary, script host, or administrative utility is used to start code indirectly, so the malicious action inherits the legitimacy of a normal process path. In NHI security, this matters because defenders increasingly monitor what runs and where credentials live, but proxy execution exploits how execution is launched.
This technique overlaps with living-off-the-land abuse, but it is narrower: the core issue is indirect execution through an allowed intermediary rather than custom malware alone. Guidance varies across vendors on whether a given event is classified as proxy execution, LOLBin abuse, or command interpreter chaining, so practitioners should treat the label as a behavioral pattern rather than a single product alert. The NIST Cybersecurity Framework 2.0 is relevant here because execution trust, logging, and detection all depend on strong asset and event visibility.
The most common misapplication is assuming that a signed or trusted parent process is safe, which occurs when defenders ignore command-line context, child-process lineage, and the account identity used to launch it.
Examples and Use Cases
Implementing detections for proxy execution rigorously often introduces more telemetry, tuning, and operational noise, requiring organisations to weigh stronger detection against false-positive handling and analyst workload.
- A scheduled task launches a built-in scripting host to download and run a payload, hiding the malicious activity inside routine administration patterns.
- An attacker uses a legitimate automation tool to spawn a shell, then pivots to a sensitive NHI token stored in memory or a local configuration file.
- A service account invokes a trusted utility to execute a second-stage command, making the chain appear like ordinary maintenance rather than attack traffic.
- Detection teams correlate process ancestry with identity context after reviewing patterns in the Ultimate Guide to NHIs, then compare those findings with MITRE ATT&CK execution techniques to refine analytics.
- Cloud automation jobs are abused to run indirect commands, especially where secrets, API keys, or certificates are available to the job runner and not tightly bound to the intended workload.
In practice, proxy execution is often surfaced only after defenders notice an allowed utility behaving in an unusual sequence or frequency, rather than because the payload itself is obviously malicious.
Why It Matters in NHI Security
Proxy execution becomes especially dangerous in NHI-heavy environments because service accounts, workload identities, and automation frameworks often have broad execution reach and access to secrets. When an attacker can reuse a trusted process path, they can blend into normal operations while moving toward credential theft, privilege escalation, or lateral movement. That is why NHI governance must include process lineage monitoring, least-privilege execution paths, and tight control over utilities that can invoke scripts or sub-processes.
This issue also connects to the broader NHI visibility gap. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, and that lack of visibility makes indirect execution far harder to spot and contain. The same risk model appears in Ultimate Guide to NHIs, which shows how mismanaged non-human identities multiply exposure, especially when execution rights and secrets are loosely governed. For control mapping, organisations should align process-monitoring and anomalous execution detection with the NIST Cybersecurity Framework 2.0 and related identity controls.
Organisations typically encounter the operational impact only after a trusted automation path is abused in an incident, at which point proxy execution becomes unavoidable to investigate and remediate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-08 | Proxy execution often exploits weak workload execution boundaries and trust in allowed utilities. |
| OWASP Agentic AI Top 10 | A-04 | Agentic systems can be coerced into indirect execution through trusted tool or process paths. |
| NIST CSF 2.0 | DE.CM-1 | Detection depends on monitoring processes, command paths, and anomalous execution behavior. |
| NIST Zero Trust (SP 800-207) | DP-3 | Zero Trust assumes no process path is inherently trusted without continuous verification. |
| MITRE ATLAS | T1620 | ATLAS documents indirect execution patterns used to hide malicious behavior in trusted workflows. |
Restrict which utilities can launch code and monitor child-process chains from NHI-bearing workloads.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
