Detecting and Mitigating System Binary Proxy Execution (T1218)

Many defenses lean on trust. A binary signed by Microsoft is assumed to be fine, so it runs, and nobody looks at what it was asked to do. MITRE ATT&CK tracks the abuse of that assumption as T1218, System Binary Proxy Execution. It sits in the Stealth tactic and covers Linux, macOS and Windows.

This is a parent technique with 14 documented sub-techniques, from Compiled HTML Files and Mshta to Regsvr32, Rundll32 and Electron applications. If you understand the pattern here, the individual guides become much easier to apply.

How attackers use it

MITRE describes adversaries bypassing process and signature based defenses by proxying execution of malicious content through signed or otherwise trusted binaries. On Windows, these are often Microsoft signed files, either downloaded from Microsoft or already native to the operating system. Binaries with trusted digital certificates can typically run on Windows systems protected by signature validation. Several default Microsoft signed binaries can be used to run other files or commands.

On Linux, MITRE says adversaries may abuse trusted binaries such as split to proxy execution of malicious commands.

The sub-techniques share one shape. A legitimate tool has a feature that loads or runs something else: a DLL, a script, a help file, a web address. The attacker supplies the something else. The signed tool does the running.

Why it works

Three things make this hard to catch.

• Signature checks pass, because the binary is genuine.
• Allow lists often name these binaries as trusted, since the operating system uses them every day.
• The process name alone tells you little. The same file that registers a driver in a normal install can load a remote scriptlet in an attack.

The signal is in the arguments, the parent process, the files and modules around it, and the network traffic that follows.

How to detect it

The MITRE detection strategy for the parent technique has an analytic per platform.

• Windows: execution of trusted Microsoft signed binaries such as rundll32.exe, msiexec.exe or regsvr32.exe used to run externally hosted, unsigned or suspicious payloads, through command line parameters or network retrieval.
• Linux: trusted system binaries such as split, tee, bash or env used in uncommon sequences or chained behaviors that do not fit normal script behavior.
• macOS: system binaries such as osascript, bash or curl used to download or run unsigned code or files together with application proxying.

To make that real, collect these data sources:

1. Process creation with full command lines and parent process. On Windows that is Sysmon event ID 1 or Security event 4688 with command line auditing on.
2. Network connections made by system binaries, such as Sysmon event ID 3. Most of these tools should rarely touch the internet.
3. Image loads for those processes, such as Sysmon event ID 7, to see unexpected DLLs.
4. File creation events, to link a newly written file to the proxy run that follows it.

Tuning

Start with a short list of binaries you can explain. For each, write down the normal parent, normal arguments and normal destinations in your environment. Then alert on departures. A rule such as "any rundll32 launch" will bury you. A rule such as "rundll32 with a URL, a script protocol or a path under a user profile" will not.

How to reduce the risk

MITRE lists five mitigations for the parent technique.

• Exploit protection. Attack Surface Reduction features can block methods of using trusted binaries to bypass application control.
• Filter network traffic. Use network appliances to filter ingress and egress traffic with protocol based filtering, and configure endpoint software to filter network traffic.
• Privileged account management. Restrict execution of particularly vulnerable binaries to the privileged accounts or groups that need them.
• Execution prevention. Use application control to prevent execution of binaries that are susceptible to abuse and are not needed.
• Disable or remove the feature or program. Many native binaries may not be necessary in your environment.

A rollout order that works

1. Turn on command line capture for process creation and confirm events arrive in your log store.
2. Inventory which proxy-capable binaries ever run in your fleet. Many will show zero use.
3. Run application control in audit mode for the unused ones, review what it would have blocked, then enforce.
4. Add egress rules for the binaries that should never reach the internet.
5. Revisit the list when you roll out new management tooling, since it may introduce legitimate use.

Check your own environment

Is command line capture on? This read-only command (Windows, cmd.exe) checks the policy value behind Security event 4688:

reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled

Is process creation auditing on?

auditpol /get /subcategory:"Process Creation"

Which application control rules are active? (Windows, PowerShell)

Get-AppLockerPolicy -Effective | Select-Object -ExpandProperty RuleCollections

Then ask these questions:

• Does any allow rule trust a binary just because Microsoft signed it?
• Which of the 14 sub-technique binaries can you remove or block today?
• Are Linux and macOS hosts covered by process telemetry at all?

Using the sub-technique guides

Each of the 14 sub-techniques has its own guide with the specific binary, the detection chain MITRE describes and the mitigations that apply. A reasonable reading order is by exposure in your fleet. If you run Windows workstations, start with the ones that can load remote content, such as Mshta, Regsvr32 and Rundll32, then work through the ones you can simply remove, such as Odbcconf, Verclsid and Mavinject when you do not use App-V. For Linux and macOS, read the detection analytics above and ask whether your telemetry sees the processes they name.

Quick check

Sources

• MITRE ATT&CK, T1218: https://attack.mitre.org/techniques/T1218