How exploitation for client execution starts on the endpoint
T1203 Exploitation for Client Execution is the technique where an adversary exploits a vulnerability in a client-side application, such as a document reader, browser, or media viewer, so that attacker-supplied code runs with the privileges of the user who opened it. In MITRE ATT&CK version 20.0, it sits under the Execution tactic (TA0002), whose goal is to run malicious code or instructions on a system. It matters because it turns an ordinary user action, opening a file or loading a page, into code execution inside the organization, often before any authentication or privilege control has been crossed. At a high level, the technique shows up where users routinely consume untrusted content: a malicious document attached to an email, a crafted spreadsheet or PDF delivered through a file share, or a web page that targets a vulnerable browser component or plug-in. The exploited application usually runs normally from the operating system's point of view, so the first sign is often not a suspicious process but a side effect: a crash report, an unexpected child process, an unusual module load, or an outbound connection made by a program that does not normally make one. Because that telemetry is indirect, the SOC lead should not expect a single clean alert. Treat an unexpected crash in a document viewer or browser as a lead to investigate, not as a benign event.
Before any detection work, confirm three things in your own environment: which client applications are exposed to untrusted content, whether their crash and error logging is enabled and forwarded to your SIEM, and whether endpoint telemetry records the parent and child relationship of those applications. Ask your endpoint and application owners for the versions in use and the patch state of each, since exploitation depends on a specific vulnerable build. Check the ATT&CK version your detection mappings target, because MITRE can rename or deprecate technique content between releases, and the current T1203 entry should be read against the version you adopt.
Which telemetry reveals T1203 on Linux, macOS and Windows
This table maps each telemetry source to the signal it produces for T1203 Exploitation for Client Execution and the open-source collector that captures it. Read each row as a question: what does a client application such as a browser, PDF viewer or office suite do that it should not normally do? The main takeaway is that no single source is sufficient, so pair process lineage with error records and outbound network activity.
| Telemetry source | Signal for T1203 | Open-source collector | Platform notes |
|---|---|---|---|
| Process Creation (DC0032) | Client application such as a browser, PDF reader or office suite spawns an unexpected shell, script host or downloader as a child process | Wazuh agent on Linux and Windows; Sysmon-style process logging on Windows; auditd on Linux | Linux and macOS lineage depends on audit rule scope; confirm parent-child capture in your own build |
| Application Log Content (DC0038) | Crash, abnormal termination or repeated error records from a viewer or browser that occur just before an unexpected process starts | Wazuh log collection from application and OS logs; Windows Application event log forwarded to Wazuh | Application logs vary widely by vendor and version, so map each client to the fields it actually writes |
| Network Connection Creation (DC0082) | Outbound connection from a viewer or browser to a host or country it does not normally contact, or to a raw IP address | Zeek connection logs and Suricata alerts at egress; Sysmon network events on Windows | Encrypted traffic limits content inspection, so rely on destination, timing and volume |
| Command Execution (DC0064) | Interpreter command lines launched by a client process, including encoded or downloaded arguments | Wazuh command capture where enabled; Sysmon command line field on Windows | Command line visibility depends on logging configuration and may be absent on macOS by default |
| File Creation (DC0039) | New executable or script written to a user temp or download directory shortly after a client application opens a file | Wazuh file integrity monitoring on monitored paths; Sysmon file create events on Windows | Path coverage must include browser cache and temp directories for each user profile |
| Network Traffic Content (DC0085) | Inspectable payloads or file transfers from a client session that match known malicious patterns | Suricata rules and Zeek file analysis at a monitored segment | Useful mainly for unencrypted or TLS-terminated segments; confirm inspection points with your network team |
Detection ideas for client exploitation in Sigma, Wazuh and Zeek
Exploitation for client execution usually shows up as a normal user application behaving abnormally. The four ideas below focus on process lineage, file writes, crash behavior and outbound connections, which together give defenders several independent signals to correlate. Each card names the threshold to tune, the baseline to build first and the benign activity that will trigger it.
Client app spawning shells
Flag when a document reader, browser, office suite or media client creates a command interpreter or script host as a direct child process. Process Creation telemetry from Sigma-compatible sources, forwarded to Wazuh or Security Onion, is the main input. Tune on parent and child pairs, not on the child alone, since shells are common under many parents. Baseline the pairs seen over two to four weeks per endpoint group. False positives come from installers, plugin helpers, print drivers and browser extensions that legitimately launch scripts, so allowlist by signed publisher and install path.
Document and browser file writes
Alert when a browser, PDF reader or office process writes executables, scripts, DLLs or archives to user-writable or startup locations. File Creation telemetry is the key data component. Set the threshold on file extensions combined with the writing process, and suppress known download directories that users rely on. Baseline which client applications write which extensions to which paths. Expect noise from legitimate downloads, auto-updaters that stage packages in temp folders and developer tools that generate build output, so review the stage path before escalating.
Crash followed by child processes
Look for a client process that crashes or restarts unexpectedly and is followed within a short window by new child processes from the same parent lineage. Application Log Content, such as crash reporter entries, and Process Creation telemetry provide the two halves of the signal. Set the window narrowly and count repeated crashes per host so a single crash does not trigger alerts. Baseline crash rates per application version, since a bad release can crash often without any attack. False positives include browser tab crashes, update restarts and plugin failures, so correlate with patch and version inventory before escalation.
Client outbound connections to rare destinations
Alert when a client process such as a browser, PDF reader or office application opens outbound connections to destinations that are rare across the fleet, especially to newly registered domains or unusual ports. Network Connection Creation telemetry from Zeek connection logs or endpoint sensors supports this. Tune on destination rarity and count, and build a baseline of domains per application over several weeks. Expect false positives from content delivery networks, license checks, update servers and cloud-hosted SaaS, so maintain allowlists by application and confirm the owning vendor for each destination.
How to validate that a T1203 detection fires
This sequence proves that a T1203 detection fires on the telemetry a client-side exploitation event would produce, using a benign stand-in in a private range. It ends with a measured time to alert, false positive rate and list of gaps tied to the ATT&CK version the rule targets.
Scope the emulation and approve the stand-in
The detection owner and the range lead agree in writing which client applications, operating systems and user roles are in scope, and which benign stand-in will represent client-side behavior. The stand-in should be a vendor-safe test artifact or a harmless process chain that a document viewer or browser child process would plausibly produce, with no exploit code, payloads or evasion. Record the ATT&CK version the rule maps to, so results are tied to that release. The step is done when the approval and version are signed off in the test record.
Define the expected alert and its fields
Write down what the rule should produce before anything runs. For T1203 this usually means a Process Creation event where a client application such as a browser, PDF reader or office suite spawns an unexpected child process, plus any Application Log Content or Network Connection Creation events the rule correlates. List the required fields, including parent image, child image, user, host, command line and destination where relevant. The step is done when the expected alert, its severity and its field list are documented and reviewed by a second analyst.
Stage the lab telemetry pipeline
Confirm that the endpoint agent, the log collector and the SIEM or Wazuh manager in the private range are receiving the event sources the rule depends on, on Linux, macOS and Windows as applicable. Check that the Sysmon, auditd or endpoint sensor configuration captures process creation with parent and child relationships, and that the clock is synchronized across hosts so timestamps can be compared. The output is a short health check showing every expected source is present and parsed. Do not proceed if any field the rule needs is missing or empty.
Replay the benign telemetry on the test host
The range operator runs the approved stand-in on an isolated test endpoint so the client application produces the process and network events the rule expects. The run is logged with start time, host, user, and the stand-in identifier so it can be matched to the events later. Keep the activity inside the range network with no outbound traffic to production or the internet. The step is done when the run record and the raw events are archived together.
Confirm the rule fires with correct fields
Search the SIEM or Wazuh alerts for the test window and compare each alert against the expected definition from step two. Check that the rule fired, that the alert names the correct technique and version, and that each required field is populated with the values the stand-in produced. A rule that fires with wrong or blank fields counts as a failed test, even if an alert appears. The output is a pass or fail entry per expected field.
Measure time to alert and false positive rate
Calculate the elapsed time between the replayed event and the alert appearing in the queue, using the timestamps from the endpoint and the SIEM. Then run the rule against a baseline period of normal client activity from the range to count benign matches and divide by the events reviewed to get a false positive rate. Record both figures with the sample size, because a rate from a small sample has limited meaning. Ask the detection owner to set an acceptable threshold before the test, not after.
Record gaps and retest after tuning
List every expected event, field or variant the rule missed, along with the cause, such as a missing log source, an unparsed field or a logic condition that is too narrow. Assign each gap an owner and a retest, then rerun the sequence after tuning. Map the final result to the ATT&CK version and the mitigations in scope, including Update Software and Application Isolation and Sandboxing, so auditors can trace the evidence. The step is complete when the report is filed and the open gaps have named owners.
Where detection and prevention can break the chain
Defenders have four places to see T1203 Exploitation for client execution, and each one gives a different kind of evidence. The first is delivery: the document, web page, or message that carries the exploit into a client application such as a browser, PDF reader, office suite, or mail client. Email and web gateway logs, proxy logs, and endpoint file-write events show the payload arriving, but they rarely prove that it was exploited. The second is client process behavior: the application itself starts acting outside its normal pattern, for example by writing to unexpected locations or loading code it does not usually load. The third is child process creation, where the client spawns a shell, script host, or unfamiliar binary. The fourth is outbound traffic, where the compromised client connects to a host it has never contacted before. Process Creation and Network Connection Creation are the data components that most often reach a SIEM from these points, while Application Log Content depends on what each client writes to its own logs.
Detection coverage varies by client application and operating system, so a rule set written for one browser or document reader does not transfer to the others. Before relying on any Sigma or Wazuh rule, list the client applications your organization actually runs on Linux, macOS, and Windows, then check which of those applications produce process, network, and application logs that reach your collection pipeline. Treat each gap as a decision: enable logging, accept the risk with a named owner, or compensate with a control at another point in the chain. Ask each vendor to confirm in writing which events and fields its client logs, and test that statement on your own builds, because versions, configuration profiles, and enterprise policies change what is recorded. Confirm vendor logging support in your own environment rather than assuming it from documentation alone.
Prevention works best when it is layered over this visibility. Update Software reduces the number of exploitable flaws in clients, and Application Isolation and Sandboxing limits what a compromised client can reach, so an exploit that succeeds still has less room to act. Use the detection points above to confirm that these controls are doing their job: sandbox denials, blocked child processes, and failed update checks should appear in your logs and be reviewed. Plan for the case where prevention fails by deciding in advance which alerts page an analyst, which can be queued for review, and which client hosts can be isolated without interrupting the business.
Preventive controls: Update Software and Application Isolation and Sandboxing
Exploitation for client execution depends on a vulnerable client application processing attacker-controlled content. The two core controls below shrink the window in which that application is vulnerable and limit what a successful exploit can reach, while the supporting controls show whether the core controls are working.
Patch cadence for client software
The Update Software mitigation targets the browsers, document viewers, office suites, media players and runtimes that users open every day, because these are the applications T1203 typically abuses. Build an inventory of client software on each platform, set a patch cadence for each class of application, and track the elapsed time between a vendor release and deployment. Ask who approves exceptions to the cadence, whether exceptions expire, and how exposed versions are reported. Confirm the exact mitigation mapping for T1203 in the ATT&CK version you target.
Sandboxed client profiles
Application Isolation and Sandboxing limits what a compromised client can do after attacker code runs inside it. Where the platform supports it, run browsers and document readers under restricted profiles that limit file system writes, child process creation and access to credentials stored on the host. Test each profile against business workflows before rollout, because broad exceptions erode most of the benefit. Keep a register of which applications run sandboxed and which do not, and review that register after each major application upgrade.
Plugin and macro restrictions
Extensions, add-ins, macros and embedded scripts widen the attack surface of client applications and can give untrusted content a path into a parser. Keep an allow list of browser extensions and Office add-ins, block macros in files that arrive from outside the organization, and handle plugin updates with the same change control as application updates. Confirm which Execution Prevention controls your ATT&CK version maps to T1203, and test that blocks still allow approved business documents to open.
Audit coverage for patch and isolation
The Audit mitigation proves that the preventive controls work. Enable process creation logging on endpoints so responders can see when a client application starts an unexpected child process, and keep software inventory and patch-status records that tie each application version to a timestamped deployment. Without these records, you cannot show an auditor or an incident responder which versions were exposed on a given date. Check the ATT&CK release notes when the mapping changes between versions.
User training on untrusted content
The User Training mitigation addresses the moments when a user opens a document, follows a link or accepts a permission prompt from a client application. Train users to report unexpected dialogs, repeated permission requests and documents from unknown senders, and give them a fast path to report. Training supports patching and isolation but does not replace them. Measure it by the reports users send to the security team and by how quickly those reports are triaged.
What to do when a T1203 alert fires
Start by establishing which client application was exploited and at what version, because that answer decides whether this is a patch gap, a malicious document or a sign of a wider campaign. Pull the process creation record for the parent application (a browser, PDF reader, office suite or media player, depending on what fired the alert) and note the executable path, version string and the user context it ran under. Confirm the version against the vendor's advisory for the affected release, and ask the patch owner to confirm whether that build was supposed to be current. Then isolate the host from the network through your EDR or network access controls, but keep it powered on so that memory and process state remain available for analysis.
Preserve evidence before anyone reboots, reimages or clears the user profile. Capture the crash reports, the application's temporary and cache directories, the downloaded file or document, and the relevant Application Log Content entries that show the file or URL that opened the exploited process. Hash each artifact and record who collected it and when. Next, check for follow-on execution: any child process spawned by the parent application, new files written to user-writable paths, and any new scheduled tasks, services or run keys created in the window after the crash. Correlate outbound Network Connection Creation events from the host for the same window, and check whether any destination is new, rare or already present in your threat intelligence feeds.
Determine whether the same document or URL reached other users. Search your mail gateway, proxy and web logs for the same file hash, sender, subdomain or URL path, and check which accounts opened it. Treat any additional hit as a separate triage with its own isolation decision. Coordinate with the patch owner early so that the fixed version, the rollout date and any compensating controls, such as disabling a plugin or restricting a file type, are agreed in writing and tracked against the affected population. Finally, record what the alert missed and what it caught, including the telemetry gaps and the time to detection. Feed those lessons into detection tuning for the T1203 analytics in your ATT&CK v20 mapping, so that the next alert carries the version, parent process and file context needed to triage it faster.
Rehearsing T1203 detection in a private cyber range
This lab uses a small topology: one or more client endpoints running a Linux distribution and a macOS build, a log collector, and a Wazuh or comparable host telemetry pipeline forwarding process and file events to a central analytics node. The range is isolated from production networks and uses synthetic user accounts. Injects represent the *outcome* of a client-side event, such as a document-reader process spawning an unexpected child process or a browser-hosted application writing a file to a user profile, rather than any exploit content. Facilitators script these events in advance so the expected detection can be checked against the known inject.
- Topology: two or three endpoints, a collector and an analytics node, all in a segregated range network with no outbound path to production.
- Injects: an office-style application launching a shell-like child process, a parent-child mismatch alert seed, and a file written to an unusual path after user interaction.
- Expected signals: Process Creation records that show parent application, child process, user context and command line, plus File Creation events for the written artifact.
- Good alerts: a rule fires within the agreed window, names the affected host and user, and links the parent application to the child process in a single timeline entry.
- Good handoff: the responder confirms the endpoint, isolates it according to the runbook and passes the parent application, hashes and timestamps to the platform team.
Before the exercise, confirm with your own platform team which Sigma rules and Wazuh decoders are deployed, and check the ATT&CK version each mapping targets.
The Windows lab mirrors a typical enterprise desktop estate: a domain-joined workstation, an application host running common document and browser software, a domain controller for identity context, and a central log pipeline. The range is built so that the endpoint sensor, event log forwarding and any application isolation or sandboxing controls in use are the same as production, because those controls shape what telemetry is produced. Injects again describe client-side outcomes only, such as a reader process spawning a script host or a browser process writing into a startup or user temp location.
- Topology: a domain controller, two workstations and an application host, with event forwarding to a Security Onion or Wazuh manager.
- Injects: a document application spawning a command interpreter child, a browser process writing an executable-type file to a temp path, and an outbound connection from the reader process to a lab-controlled address.
- Expected signals: Process Creation with parent image and integrity level, File Creation in the user profile, and Network Connection Creation tied to the originating process.
- Good alerts: correlated detections link process, file and connection events on one host, and the sandbox or isolation control reports whether it blocked the action.
- Good handoff: the responder preserves volatile data through the agreed collection tool, records whether the sandbox allowed or denied the action, and hands over the case with process tree and file hash.
Confirm with the client which endpoint controls are in scope for the exercise, since the results only reflect the controls that are actually installed.
The network view treats the range as a set of flows rather than a set of hosts. A sensor such as Zeek or Suricata sits on a monitored segment between the client subnet and a lab-controlled external simulator, and Security Onion or a similar platform correlates its records with endpoint alerts from the other tabs. This view is useful because a client-side event often ends in an outbound connection that the endpoint alone may not explain. Injects are limited to benign connection patterns, such as a client contacting an unexpected destination after a simulated user action, with no payload.
- Topology: a monitored client segment, a tap or mirror port, a lab-controlled egress simulator and a correlation node, all within the isolated range.
- Injects: a client connecting to a newly registered lab domain shortly after a simulated document event, and repeated small transfers that resemble beaconing.
- Expected signals: Network Connection Creation records with source process context where available, and protocol metadata that shows the destination, timing and volume.
- Good alerts: the network detection references the same host and time window as the endpoint alert, so analysts can join the two without manual searching.
- Good handoff: the network responder blocks the lab destination at the agreed control point, records the flow identifiers and passes them to the endpoint responder.
Agree in writing which network sensors, retention periods and egress simulators the exercise will use, because detection depth depends on what the range actually captures.
Questions SOC leads ask about T1203 detection
How do I separate client exploitation from ordinary application crashes?
Treat a crash as a lead, not a verdict. Exploitation usually shows a crash followed by unexpected child processes, script interpreters or network connections from the client application, while a plain crash ends with a fault record and no follow-on activity. Correlate Application Log Content (crash and fault events) with Process Creation and Network Connection Creation for the same process ID within a short window, and review the parent-child lineage before escalating. Confirm the exact fields your endpoint agent records, since they differ by platform and agent version.
Which ATT&CK data components should I prioritize for T1203?
Start with the components ATT&CK most often references for Execution techniques: Process Creation (DC0032), Network Connection Creation (DC0082) and Application Log Content (DC0038). Process Creation shows what a browser, document reader or office application launched, Network Connection Creation shows outbound connections it opened, and Application Log Content adds crash and application-level events. File Creation (DC0039) helps when a payload is written to disk. Check each component against the detection strategies in the ATT&CK version you target before building rules.
How should we handle ATT&CK version changes in our detection library?
Record the ATT&CK version every detection maps to, and review mappings whenever MITRE publishes a release. ATT&CK v18 moved detections into detection strategies with DET IDs and analytics, and later releases can rename, deprecate or revoke techniques. Pull the matching STIX bundle from the attack-stix-data repository, diff the T1203 entries and update your Sigma or Wazuh rule metadata accordingly. Assign one owner to this review so mappings do not drift silently.
How can we test T1203 detection without using live exploits?
Test the telemetry path, not the exploit. In a private cyber range, generate benign events that match the behavior the rule describes, such as a document viewer spawning an unexpected child process or a client application opening an unusual outbound connection, using approved test tooling or scripted simulation. Measure whether the expected events arrive in Wazuh or Security Onion, whether the Sigma rule fires, and whether the alert reaches the right queue. Keep a written test plan with pass and fail criteria, and confirm your range rules of engagement with the team that owns it.
How do we stop noisy software updaters from flooding the queue?
Build allowlists from observed behavior, not from names alone. Updaters legitimately spawn child processes and make outbound connections, so tune rules by signed publisher, install path, parent process and expected destination domains, and review the allowlist on a fixed schedule. Use the mitigation Update Software to keep clients patched, which reduces the number of exploitable paths and therefore the number of alerts worth tuning around. Record every exception with an owner and a reason so auditors can see why it exists.
What does Application Isolation and Sandboxing change for detection?
Sandboxing limits what a compromised client can do, which changes the signals you should expect. In a well-configured sandbox, an exploit may still crash the client or attempt a child process that the sandbox blocks, so blocked actions appear in logs as denials rather than successful executions. Ask your endpoint or sandbox vendor which events are logged when a control blocks an action, and include those denial events in your correlation logic. Confirm the exact behavior in your own environment during testing.
Can our own team run this detection program, or do we need outside help?
Many SOC teams can run the detection core internally if they already operate a SIEM, an endpoint agent and a Sigma pipeline. The skills that most often need reinforcement are endpoint telemetry tuning, cyber range exercise design and mapping detections to ATT&CK versions. DeployOpen implements and documents self-hosted open-source platforms in your own infrastructure and runs cyber range exercises, so a fixed-scope engagement can cover the build, the test plan and the handover, with ongoing support available as a retainer. Agree the scope in writing before work starts.
How DeployOpen builds T1203 detections and range scenarios
DeployOpen approaches T1203 Exploitation for client execution as a fixed-scope engagement inside the client's own environment, covering telemetry, detection logic, validation and range rehearsal. The work is agreed in writing before it starts, and ongoing support is available as a retainer.
How we scope
- Agree in writing which Linux, macOS and Windows client applications and endpoint groups fall inside the T1203 detection scope.
- Confirm which telemetry sources exist today, such as process creation, application log content and network connection creation, and where gaps remain.
- Record the ATT&CK version the detection mapping targets, so later technique changes can be traced to specific rules.
How we build
- Write detection logic for suspicious child processes spawned by document readers, browsers and other client applications, described in plain language and mapped to open-source rule formats.
- Deploy and tune the rules in the client's SIEM or Wazuh stack, with network-side signals from Zeek or Suricata where the client's data sources allow.
- Document Update Software and Application Isolation and Sandboxing controls, and check whether they are configured as the client's policy states.
How we hand over
- Deliver rule files, data source mappings, test results and runbooks that the client's security team can maintain without DeployOpen.
- Run a private cyber range exercise that replays benign and simulated T1203 activity so the client's analysts can confirm alerts fire and triage correctly.
- Provide a written record of known blind spots, false positive tuning decisions and the telemetry each detection depends on.
How we support
- Review detection coverage when new ATT&CK releases rename, deprecate or revoke techniques that the rules reference.
- Re-run range scenarios after client application upgrades, since patch cycles can change process behavior and alert noise.
- Offer continuous testing and tuning as a retainer, with the scope and frequency agreed in writing before work begins.
