Why T1218 system binary proxy execution slips past allow-lists
If your SOC relies on process-name allow-lists, T1218 System Binary Proxy Execution is the technique most likely to defeat them. The adversary runs a signed, vendor-supplied system binary on Windows, Linux or macOS and uses it to execute or load content of the adversary's choosing. The process that appears in telemetry is trusted by name, publisher and path, so a rule that asks only "is this a known good binary?" will pass it. Under the Stealth tactic (TA0005), which MITRE describes as adversary activity that hides and conceals actions by appearing as normal behavior, this is a direct route to running payloads without launching an obviously unfamiliar program.
The technique appears across intrusions because it is cheap to use and blends into administrative activity that already happens on most estates. Built-in utilities for installers, script hosts, debugging, package handling and module loading are present on almost every endpoint, and their legitimate use is common enough that a single invocation rarely looks suspicious on its own. ATT&CK organizes T1218 into 14 sub-techniques, each tied to a different proxy binary or behavior, so a detection written for one binary will not cover the others. This page targets Enterprise ATT&CK version 20.0, and the sub-technique list should be checked against that version before any rule is deployed.
The practical decision for your team is whether detection depends on the binary's identity or on what the binary does. Confirm which of the 14 sub-techniques are reachable in your environment, which of those binaries your administrators actually use, and which execution paths you can baseline. Then decide where you will collect process creation, module load and network connection telemetry so that a trusted name with unusual arguments, unusual parents or unusual network activity still raises an alert. Note that the sub-technique inventory and the data components used by detection strategies are version-specific, so record the ATT&CK version your rules target.
Which telemetry reveals T1218 and which open-source tool collects it
This table maps each data component ATT&CK links to T1218 to the signal a defender should look for and the open-source collector that captures it on Windows, Linux and macOS. Read it as a starting point, then confirm the exact mapping in the ATT&CK detection strategies for the ATT&CK version your rules target.
| Data component | Signal to look for | Collector on Windows | Collector on Linux and macOS |
|---|---|---|---|
| Process Creation (DC0032) | Signed system binaries launched with unusual parent processes, command line arguments or script hosts, which can indicate proxy use of a trusted binary | Sysmon process creation events forwarded through the Wazuh agent | auditd execve records or Auditbeat process events; macOS endpoint process logs |
| Network Connection Creation (DC0082) | A normally local system binary opening outbound connections it does not usually make, which can indicate it is fetching or relaying content | Sysmon network connection events, reviewed with Wazuh alerts or Zeek conn logs from a network sensor | Auditbeat socket or network events, Zeek conn logs, macOS endpoint network logs |
| Module Load (DC0016) | A system binary loading DLLs or libraries from unexpected paths or loading code it does not normally use | Sysmon image load events forwarded through the Wazuh agent | Limited native coverage; confirm what auditd and Auditbeat expose for your distribution before relying on it |
| Command Execution (DC0064) | Command lines that pass arguments, URLs or script paths to a trusted binary, which is the most direct evidence of proxy use | Process command line fields in Sysmon events, searched in Wazuh or Security Onion | Command line capture in auditd execve records or Auditbeat; macOS unified logs where enabled |
| File Creation (DC0039) (supporting) | Payloads or staged content written to disk shortly before or after a trusted binary runs | Sysmon file create events, collected through the Wazuh agent | auditd file watch rules or Auditbeat file events on defined directories |
| Mapping check | Confirm which data components and detection strategies ATT&CK currently links to T1218 and its sub-techniques | Review the ATT&CK technique page and its detection strategies for the targeted version | Same check, then document any gaps where a component has no collector in your estate |
Detection logic for T1218 that SOC teams can tune
T1218 System binary proxy execution works because a trusted, signed binary does the work on the adversary's behalf. The cards below describe four detection ideas that focus on what those binaries do after they start, so SOC teams can tune each one against their own host baseline before writing it as a Sigma rule for Wazuh or Security Onion.
Trusted binary spawning unusual children
This idea watches for a signed system binary that starts a child process it does not normally start on your hosts. Build the expected child list per binary from a baseline period, then alert on children outside that list, especially shells, scripting hosts or unsigned executables launched from user-writable paths. Tune the threshold on the count of distinct new child images per host per day, not on single events. Common false positives include software updaters, endpoint agents and management tools that launch helpers during patching. Confirm each exception by parent path, signer and change record. Write the logic as a Sigma rule on Process Creation (DC0032) telemetry, then validate it against the Wazuh or Security Onion log source you actually collect.
Trusted binary making outbound connections
System binaries rarely need internet access, so a binary that opens outbound network connections is a strong signal for proxy execution. Use Network Connection Creation (DC0082) telemetry from Zeek or Suricata logs joined to the originating process image. Set the threshold on first-seen destinations per binary and on connections to public addresses, and suppress known update endpoints by domain or address range that your team has approved. Management agents, cloud CLIs and browser helper processes are frequent false positives, so record the approved destinations per host group before enabling the alert. Review every exception in a change ticket so that a silent exclusion does not hide new behavior.
Trusted binary loading unexpected modules
This idea compares the modules a trusted binary loads with the modules it loaded during a baseline. Module Load (DC0016) events that bring in a DLL, shared object or script host component outside the baseline can indicate that the binary is being used to run code it does not normally run. Tune on the count of new module paths per binary and flag modules loaded from user-writable or temporary directories first. Expect false positives from software that ships its own runtime, from security tools that inject inspection modules and from application upgrades. Confirm each new module against the vendor's published file list and the file's signature before adding it to an allow list.
Parent-child baselines per host group
A single global baseline hides differences between a domain controller, a build server and a user workstation. Build parent-child baselines per host group, keyed by the parent process, the child process and the group, and review them after each patch cycle. Use the baseline to scale thresholds, so that a rare pair on a workstation group is alerted on while the same pair on a build group is expected. Ask your team to confirm the group definitions with asset owners, because a host placed in the wrong group will generate noise or blind spots. Store baseline versions alongside the ATT&CK version you target, so that mapping changes in later ATT&CK releases do not silently change your alert logic.
How to validate the T1218 detection before you trust it
This sequence proves that the T1218 detection sees benign proxy-execution activity, forwards the telemetry to the SIEM, raises an alert that reaches the right queue, and leaves a per-sub-technique record that shows where coverage is still weak. It turns a rule that looks correct on paper into evidence the team can defend in an audit or an incident review.
Pin the ATT&CK version and scope
The detection owner lists the T1218 sub-techniques in scope for each platform the rule covers, using the Enterprise ATT&CK 20.0 technique and sub-technique pages as the reference. The list names the ATT&CK version, the platform (Linux, macOS or Windows), and the data components the rule depends on, such as Process Creation and Module Load. Confirm the version against the ATT&CK updates page before work starts, because releases can rename, deprecate or revoke techniques. The step is done when the scope sheet is signed by the detection owner and the threat or purple team lead.
Write a benign emulation plan
The purple team lead drafts a plan that describes the behavior to be tested in plain language, without operational commands, for each sub-technique in scope. Each entry names the expected telemetry, the expected alert, the owner who will watch for it, and the cyber range or isolated lab where it runs. Engineers keep the plan separate from any production change window. A second reviewer checks it against the ATT&CK version the rule targets, so the plan does not test a retired or renamed sub-technique. The step is done when the plan has been reviewed and approved in writing.
Run the emulation in an isolated range
Authorized testers run the agreed benign actions on monitored hosts in the cyber range, one sub-technique at a time, while the observer records start and end times and the host name. Hosts are reset between runs so that residue from one test does not explain the result of the next. The observer logs anything unexpected, such as a sub-technique that behaves differently on the target OS build. The step is done when every planned action has a timestamped entry in the test log.
Confirm telemetry reaches the SIEM
The SIEM engineer searches the stack, which may include Wazuh, Security Onion, Zeek or Suricata depending on the environment, for the events generated by each run. The check confirms that process creation, module load and network connection records arrive with the expected fields and timestamps, and that clock skew between the endpoint and the SIEM is within the agreed tolerance. Missing fields are logged as coverage gaps. The step is done when each emulated action has a matching event record or a documented gap.
Check the alert fires and routes
The detection engineer confirms that the rule raised an alert for each run, that the alert carried the host, user and command context the analyst needs, and that it reached the intended queue, ticket system or on-call route. The engineer also tests the negative case, where a similar but expected administrative process should not raise a high-severity alert. The step is done when the alert identifiers and routing destinations are recorded next to each test entry.
Record results per sub-technique
The purple team lead writes a results table with one row per sub-technique and platform, showing whether telemetry arrived, whether the alert fired, whether it routed correctly, and the false-positive observations from the negative cases. Gaps are assigned to an owner with a target review date agreed by the team. The table is stored with the rule version, the ATT&CK version and the range build so an auditor or incident responder can trace the claim later. The step is done when the table is approved by the detection owner.
Schedule revalidation after changes
The detection owner sets a trigger list for rerunning the validation, including a new ATT&CK version, a change to the rule logic, a change to the logging agent or a change to the endpoint operating system build. Each rerun reuses the same plan so that results are comparable across versions. Teams that want continuous testing can agree the cadence in a retainer. The step is done when the trigger list is attached to the rule record in the detection repository.
How to tune T1218 rules without blinding the SOC
Tuning T1218 detections starts with a baseline of legitimate proxy binary use per host role, not with suppression. Build the baseline from your own telemetry: which signed system binaries run on build servers, domain controllers, developer workstations, and general user endpoints, which parent processes launch them, and under which accounts. A binary that is routine on a deployment server may be unusual on a finance workstation, so a single global allowlist usually hides more than it protects. Record the baseline per role in your Process Creation and Module Load data, and confirm with each application owner which proxy invocations their software actually needs. Where you cannot yet explain an invocation, treat it as unknown rather than benign.
Scope every exception as narrowly as the evidence allows. A defensible exception usually combines the signed path of the binary, the expected parent process, the user or service account, and the host role, so that a legitimate invocation from one application does not excuse the same binary launched from a user profile directory. Avoid exceptions keyed only on binary name, because name alone is easy to reproduce. Keep a written record for each exception with its owner, its business reason, and an expiry date. Review exceptions on a fixed schedule set by your change process, and retire any whose application has been removed or whose parent process has changed. Your Execution Prevention and Privileged Account Management controls should be reviewed alongside these exceptions so that a tuned rule is not the only barrier.
The core trade-off is coverage against analyst load. Broad rules catch more sub-techniques across Linux, macOS and Windows but produce alerts that analysts must clear, and fatigue quietly reduces the value of every alert. Narrow rules are quieter but leave gaps that an adversary can exploit by staying within the allowlist. Measure both sides: track alert volume per rule, the share of alerts closed as benign, and the number of confirmed detections that came from each rule, then adjust thresholds with those numbers in hand. Because ATT&CK revises technique mappings between releases, retest your T1218 rules after each ATT&CK update that changes mappings, and confirm the version you target against the MITRE ATT&CK updates page.
Preventive controls mapped to ATT&CK mitigations
MITRE ATT&CK maps two preventive mitigations to T1218 System binary proxy execution: Execution Prevention (M1038) and Privileged Account Management (M1026). Both reduce how often a trusted system binary can be used to run other code, and both need to be confirmed against the binaries and accounts present in your own environment.
Application control policy for system binaries
Execution Prevention (M1038) covers controls that block code from running based on policy, such as application allowlisting. For T1218, the useful question is which signed Windows, macOS and Linux binaries are allowed to launch child processes or load code from a path or argument you did not intend. Review the default allow rules for Microsoft-signed binaries first, since they are the ones most often proxied. Confirm in a test ring whether your control can restrict a binary's behavior, not only whether it can block the binary by name.
Rule scope for proxy-capable binaries
Allowlisting alone rarely covers every system binary that ATT&CK lists under T1218. Teams usually prioritize the sub-techniques that match binaries already present on their endpoints and tune rules around known administrative use. Document which binaries have a business need, which are blocked for standard users, and who approves exceptions. Treat each exception as a recorded decision with an owner and a review date, because an exception left in place is the most common gap a rehearsal exposes.
Reduced administrative rights
Privileged Account Management (M1026) limits who can run system binaries with elevated rights and where those rights are granted. Many proxy execution paths only matter when the user already holds local administrator or root rights, so restricting those accounts reduces the value of the technique. Inventory local administrators on each platform, separate day-to-day accounts from privileged accounts, and confirm that service accounts are not interactive. Check the result with an access review, not only with the policy document.
Just-in-time elevation for administrators
Where administrators still need elevated rights, time-bound elevation limits how long a privileged session can invoke system binaries. Confirm whether your identity or endpoint platform supports approval-based elevation, session logging and automatic expiry. Ask the platform owner which elevation events are written to your logs, because detection of T1218 depends on seeing the elevation and the child process together. Record the expiry period you choose as a policy setting in your own configuration.
Audit supports detection, not prevention
Audit (M1047) is listed for many Stealth techniques, but it records activity rather than blocking it. For T1218, enabling process creation and module load logging gives the telemetry that the detection rules depend on, and it does not stop a proxied command from running. Keep Audit in the plan as the evidence layer behind Execution Prevention and Privileged Account Management. Confirm coverage in your own environment, including which hosts forward logs and whether any gaps exist between endpoint and central collection.
What to do in the first hour after a T1218 alert fires
Start by confirming the parent and child process chain. A T1218 alert usually means a trusted, signed system binary was launched in a way that caused it to run other code on its behalf. Pull the full ancestry for the event: which process started the proxy binary, what command line it received, which user context it ran under, and what it spawned next. Check whether the child process is a script host, a network utility or an unfamiliar executable. Then compare the chain against the host's baseline, meaning what this binary normally does on this class of server or workstation, which administrative tools, software deployment agents and management consoles are expected to invoke it, and whether this change window or patch cycle explains the activity. Record the findings in the case before moving on, because the rest of the decisions depend on them.
Next, correlate the network and module events for the same process tree and time window. Look for outbound connections initiated by the proxy binary or its children that the host has not made before, and for DLLs or other modules loaded from unusual paths or without a valid signature. Compare these against your Network Connection Creation and Module Load telemetry for the same host, and check whether other hosts show the same parent and child pattern. If the chain overlaps with signed script or developer utility proxies, the related topics on T1127 Trusted developer utilities proxy execution and T1216 System script proxy execution describe the adjacent signals to check. Decide on isolation using a written rule agreed before an incident: isolate when the activity reaches a sensitive system, shows outbound traffic to unknown destinations, or cannot be explained by the baseline within the triage window. Confirm with your own runbook and change records that the isolation method is available on that platform.
Before isolating or rebooting, preserve volatile evidence such as running process lists, active network connections, loaded modules and logged-on sessions, since these are lost on restart. Then escalate to the incident lead with the process chain, affected accounts, time of first and last observed activity and the decisions taken so far. Ask your incident response lead to confirm who has authority to isolate production hosts, how evidence is handed to forensics, and which regulators or contractual parties require notification. Keep the evidence chain intact, and record every action with a timestamp so that the post-incident review can reconstruct the sequence.
Rehearsing T1218 detection and response in a private cyber range
This lab mirrors a set of Windows workstations and a server instrumented with Sysmon and forwarding events to a Wazuh manager. Facilitators use it to test whether signed system binaries launched in unexpected contexts, or loading modules they do not normally load, generate process creation and module load records that analysts can find. The range should match the production build of the endpoint agent and logging policy, so the rehearsal reflects what the client actually collects.
- Injects the facilitator controls: Scheduled injects that run a signed system binary under a different parent process, followed by a second inject that loads a module from an unusual path.
- Good detection: Process creation records carry the parent, command context and user, and a Wazuh rule or Sigma-derived analytic fires on the combination rather than on a single binary name.
- Good response: The analyst pivots from the alert to the parent process tree, confirms the user context and records whether the binary was used for its normal purpose.
- Telemetry check: Confirm that the Sysmon configuration in the range is the same version and filter set as production, since missing module load events are a common blind spot.
Check that each inject produces a traceable chain from the endpoint event to the Wazuh alert, with timestamps the analyst can correlate.
This lab covers Linux servers and macOS workstations, using auditd or the endpoint logging available on each platform. Proxy execution on these systems often shows up as a trusted interpreter or utility launching a process it would not normally start, so the signal depends on process lineage and audit rules that capture execution events. Facilitators should confirm which audit rules and unified logging filters are active before the exercise begins, because gaps in these settings are easy to miss.
- Injects the facilitator controls: A scripted sequence where a standard utility is used to start a child process from a non-standard location, run under a service account.
- Good detection: Execution records include the full ancestry and the executing account, and the SIEM rule distinguishes administrative use from use by a service that should not start that child.
- Good response: The analyst checks file integrity and recent changes in the directory where the child process ran, then determines whether the account is expected to perform that action.
- Coverage check: Verify that audit log forwarding into Wazuh or the chosen SIEM is working and that log rotation does not drop events during the exercise.
- Platform difference: Note where macOS logging retention differs from Linux, and document the gap instead of assuming parity.
End the session by confirming that the evidence needed for the investigation was present in the logs.
This segment places Zeek and Suricata on a mirrored span of the lab network so that facilitators can observe the outbound and lateral connections that often follow a proxy execution event. Host telemetry may show the binary launch, but network sensors show whether the process reached an unexpected destination, used an unusual protocol or transferred data. Sensor placement should match the real segmentation of the client environment, and the range should record which traffic is mirrored and which is not.
- Injects the facilitator controls: Timed connections from a lab host to an approved and an unapproved destination, shortly after a proxy execution inject on the endpoint lab.
- Good detection: Zeek connection and protocol logs are correlated with the host event by time and address, and a Suricata rule or Zeek script flags the unexpected destination.
- Good response: The analyst confirms the source host, reviews the connection history, and decides whether to block the destination at the firewall or isolate the host.
- Sensor check: Confirm the mirror port captures both directions and that Suricata rule sets are the versions the team intends to test.
- Correlation check: Verify that analysts can join network logs to endpoint alerts using the same host identifiers.
Review whether the network evidence alone would have been enough to start the investigation.
Questions SOC leads and detection engineers ask about T1218
How do I separate T1218 activity from normal software updates?
Start from the binary and its arguments, not the binary name alone. Signed Windows system binaries are routinely used by installers, patch tooling and management agents, so a rule that fires on the binary running at all will be noisy. Build an allowlist from your own baseline: record which parent processes, command-line patterns, signing certificates and destination hosts your patch and endpoint tools produce over a representative period. Then alert on deviations, such as a proxy binary launched by an office application, a script host, or a user session, or a network connection from a proxy binary to an address outside your management ranges. Review the allowlist with the change owners for your patch tooling so exceptions have a named owner and an expiry date.
How should we handle ATT&CK version changes in our detection library?
Tag every detection with the ATT&CK version it was mapped against, and review mappings whenever MITRE publishes a release. ATT&CK v18 replaced technique-level detections with detection strategies and analytics and deprecated data sources, so rules written against older data source names need re-mapping to the current data components. Releases can also rename, deprecate or revoke techniques and sub-techniques. Keep the ATT&CK STIX bundle for your target version in version control, diff it against the next release, and record which rule IDs are affected. The MITRE updates pages describe each release and are the place to check before scheduling a review.
How do we test T1218 rules without risk to production?
Test in a private cyber range that mirrors your endpoint telemetry pipeline, not in production. Deploy the same collection agents and log forwarding used on production endpoints, run the rule against a replay or a controlled exercise, and confirm the event reaches your SIEM with the fields the rule depends on, such as parent process, command line and signing data. Measure both detection and false positives against the benign software your baseline lists. Keep exercise tooling on isolated networks, document each run with its timestamp and expected outcome, and only promote a rule to production after the expected alerts and quiet periods are both confirmed.
How do we measure detection coverage for T1218 and its sub-techniques?
Measure coverage per sub-technique and per platform rather than as a single percentage. Map each of the 14 sub-techniques of T1218 to the rules, data sources and log fields that would reveal it, then mark which mappings were validated in a range exercise and when. Gaps usually appear where a platform lacks the telemetry, for example network connection data missing from a host. Report coverage as validated, mapped but untested, and not covered, with the ATT&CK version used. Review the matrix after each ATT&CK release and after any change to logging.
Which telemetry should we store for T1218 detection, and for how long?
Store process creation events with command line and parent process, module load events where your platform provides them, and network connection events from endpoints, along with the signing and file metadata needed to judge a binary. Retention depends on your investigation needs, your incident response obligations and any sector or contractual rules that apply to you, so confirm the required period with your legal, compliance and records teams rather than adopting a default. Also confirm storage cost and query performance at your event volume during a range exercise. Note that DeployOpen can help define the log schema and retention design, but the retention period itself is a decision for your organization.
Can our own team run T1218 detection and tuning without outside help?
Many SOC teams can run the detection lifecycle internally if they have endpoint telemetry, a SIEM with rule management, and people who understand Windows, Linux and macOS process behavior. The harder parts are usually building a trustworthy benign baseline, keeping mappings current across ATT&CK releases, and running repeatable range exercises without disrupting operations. Decide which of these your team can sustain, then scope any outside help in writing with named deliverables. DeployOpen works on fixed-scope engagements for implementing open-source detection platforms, testing and cyber ranges, and it can also provide ongoing support under a retainer if you want continuity.
What should we confirm about our endpoint agents before writing T1218 rules?
Confirm that your agents actually capture the fields your rules need, on every platform in scope. Check whether process creation events include full command line, parent process and user context, whether module load and network connection data are collected, and whether any filtering or sampling drops events before they reach the SIEM. Also confirm agent update cadence and how it changes event schemas, because a silent schema change can break a rule without raising an error. Validate each of these in your range before relying on the rule in production, and record the results alongside the rule.
How DeployOpen builds T1218 detections and range scenarios
DeployOpen plans, implements and tests the detection stack for T1218 System binary proxy execution inside your own environment, whether that is your cloud accounts, data centers or air-gapped network. The work covers the telemetry pipeline (endpoint agents, Sysmon-style process and module logging on Windows, auditd or equivalent on Linux and macOS, and network sensors such as Zeek or Suricata), the rule set, and the runbooks that analysts use when an alert fires. Each Sigma rule is written against a named ATT&CK version, so that a later release that renames or deprecates a technique can be traced to the exact rule it affects. Before work starts, we agree in writing which platforms, sub-techniques and log sources are in scope, and what the reader will receive at handover.
Validation is run as purple team exercises. DeployOpen's red team executes agreed test cases for the in-scope sub-techniques in a private cyber range, while the client's analysts work the alerts as they would in production. The output is a record of which cases produced an alert, which were missed, and why, such as a missing data source or a rule keyed to a single binary path. Range scenarios are built to mirror your own asset inventory and logging configuration, so results carry over to your environment. Ask whether the test cases are provided for your review and whether they can be rerun after each rule change.
DeployOpen does not issue audit reports, attestations or certifications. Where a compliance assessment is in view, we prepare the detection rules, test records and evidence that your independent auditor or certification body will review, and they decide whether those controls meet the requirement. Ongoing tuning, upgrades to new ATT&CK versions and repeat testing are available as retainers, separate from the fixed-scope build. Confirm with us which version of ATT&CK the initial rules target and who in your team owns the rule lifecycle after handover.
