Safeguard
Security Guides•

System binary proxy execution (T1218): trusted tools used badly

T1218 covers attackers running malicious content through signed, trusted system binaries. See the examples, mitigations and detection ideas MITRE lists.

Safeguard Security Team
3 min read

System Binary Proxy Execution, MITRE technique T1218, is when an adversary runs malicious content through a signed or otherwise trusted binary that ships with the operating system. It helps attackers slip past process and signature based defences because the program that runs is a legitimate one.

The idea in plain words

Security tools often allow software that is signed by the operating system vendor. T1218 abuses that trust. Instead of launching its own program, the attacker asks a trusted one to load or run the payload for them.

MITRE places this technique in its Stealth tactic. Note that MITRE has been revising the structure of the matrix, so check the current page for the tactic name. The technique applies to Windows, Linux and macOS.

Examples MITRE lists

The page has 14 sub-techniques. A sample:

  • Compiled HTML File
  • Mshta
  • Msiexec
  • Regsvr32
  • Rundll32
  • InstallUtil
  • Electron Applications

On Linux, the page gives the split command as an example of a trusted binary that can be abused to run commands.

Mitigations from the page

  • Disable or remove native binaries the environment does not need.
  • Application control to block susceptible binaries that are not required.
  • Attack Surface Reduction rules to block ways of using trusted binaries to bypass application control.
  • Filter network traffic at appliances and endpoints, ingress and egress.
  • Restrict vulnerable binaries to privileged accounts that need them.
  • Restrict web based content, including risky downloads, JavaScript and browser extensions.

What detection looks like

MITRE's detection strategy is behavioural. On Windows, watch for binaries such as rundll32.exe, msiexec.exe or regsvr32.exe running externally hosted, unsigned or suspicious payloads through command line arguments or network retrieval. On Linux, look for trusted binaries like split, tee, bash or env used in chains that do not match normal system or script behaviour. On macOS, watch osascript, bash or curl downloading or executing unsigned code.

The common thread: the binary is normal, the arguments and parent process are not.

A small exercise

  1. Pick three binaries from the list that your servers never need.
  2. Check whether application control already blocks them for ordinary users.
  3. Look at your process logs for the last 30 days. Count how often each ran and from which parent.
  4. For any that run, decide whether the use is documented.
  5. Write an alert for the unexplained ones.

Why this links to APT reporting

CISA's Volt Typhoon advisory describes the group using built-in tools such as PowerShell, vssadmin, ntdsutil, wmic and netsh, and calls living off the land a hallmark of the group's activity. T1218 is one of several techniques in that family, and the defences overlap.

Quick check

Is blocking these binaries completely always possible?

Not always. Some are needed for normal work, so restrict by user and context and alert on unusual arguments.

Why not just allow anything signed by the vendor?

Because T1218 exists to abuse exactly that trust. Signature checks tell you who built a file, not what it is being asked to do.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.