---
{
  "title": "System Script Proxy Execution",
  "summary": "System script proxy execution uses trusted scripts as intermediaries for untrusted behavior.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1216"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1216: System Script Proxy Execution",
      "url": "https://attack.mitre.org/techniques/T1216"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

System script proxy execution uses trusted scripts as intermediaries for untrusted behavior. A trusted script's input and capabilities are part of the security decision.


## An investigation example

A signed administrative script processes an unexpected external input and launches an unrelated executable.

## Evidence to examine

Review script version, arguments, input provenance, parent and child processes, and approved administrative use.

## A common analytical pitfall

Signature validity does not prove that the caller supplied benign data or used the script appropriately.

## Response considerations

Preserve the supplied content and execution chain and constrain unauthorized use without treating every signed script as safe.


## A legitimate script can delegate risky behavior

System-provided scripts may perform administration or invoke other components. An intruder can misuse their supported behavior as an intermediary for unauthorized execution. The trust question extends beyond the script's origin to the supplied arguments, referenced content, executing identity, and resulting actions. A trusted script is not an unconditional approval for every use.

This is distinct from an attacker simply writing a new script. The intermediary is an existing trusted component, while the misuse depends on how it processes input or delegates work. Investigators should preserve the script identity and version because behavior can change across systems and updates.

## A fictional unexpected delegation

An academy's endpoint events show a user-launched document starting a system script that then invokes another component with unfamiliar input. Analysts examine the full process chain, referenced files, account context, and subsequent activity. They compare it with approved administration and avoid treating the script name alone as proof of malicious execution.

Logging may capture only part of the delegation. A parent-child relationship can establish that one process started another, while detailed script or command telemetry may explain the input. State gaps rather than infer unseen arguments. Do not run a recovered sequence on a personal device to discover its effects.

## Model the delegation boundary

Create a fictional trusted script that normally reads an approved configuration and calls a helper. Identify which inputs and paths need protection. Then describe evidence that would show it consumed a different source. Use a paper scenario rather than an operational proxy-execution demonstration.

Defensive review should consider whether the script is needed, which users can invoke it, and which input sources it accepts. Changes need testing because legitimate workflows may depend on it. Address the authority that introduced the untrusted input as well as the intermediary, so response does not stop at one recognizable component.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[incident-response]]