MITRE ATT&CK T1203 Exploitation for Client Execution: Detecting and Containing Exploited Apps

When a browser, document reader or office application is exploited, code runs inside a process every user is expected to run, so detection has to rely on what that process does next rather than on the file it opened. MITRE ATT&CK T1203 Exploitation for Client Execution covers adversaries exploiting vulnerabilities in client applications to execute code. ATT&CK describes three groups: browser-based exploitation reached through drive-by compromise or spearphishing links, office applications reached through phishing attachments or downloads, and common third-party applications such as document readers. In ATT&CK v20 the technique sits in the Execution tactic (TA0002) and applies to Windows, macOS and Linux. This guide covers the post-exploitation behaviour chain ATT&CK recommends hunting, exploit protection and isolation settings, how to prioritise client patching, and how to respond. It is for detection engineers, endpoint engineers and vulnerability managers. The user-driven counterpart, where the user runs the payload themselves, is in the T1204 User Execution guide, and exploit classes are in the Memory Corruption Vulnerabilities Guide; this page does not repeat them.

Key takeaways

• Watch the client process, not the exploit. ATT&CK's v20 analytics chain a crash or abnormal load, a file written to a user-writable path, an unexpected child process and new outbound connections from the same application.
• Browser exploits may need no click. ATT&CK notes browser exploitation often does not require any user action beyond visiting a page, while office exploits require the user to open the file.
• Three mitigations carry the load. ATT&CK lists exploit protection (M1050), application isolation and sandboxing (M1048) and updating software (M1051).
• Client patching needs its own clock. Browsers, office suites and readers are reached from email and the web every day, so they belong at the front of the patch queue, ideally within days as the NCSC advises.
• Crash telemetry is a security signal. Application crash events from browsers and office apps, followed by child processes, are among the few traces an exploit leaves.

What T1203 looks like in practice

ATT&CK records dozens of groups, campaigns and malware families using T1203. The examples show which client applications attackers have favoured and how the exploit arrives.

The pattern matters for defence: several of the office exploits ATT&CK records target vulnerabilities disclosed and fixed years before they were used, which makes patch coverage on long-lived desktops as important as speed on new flaws.

How T1203 differs from neighbouring techniques

• T1204 User Execution: the user runs a malicious file or link; no vulnerability is needed. T1203 needs a software flaw.
• T1190 Exploit Public-Facing Application: server-side exploitation for initial access. T1203 targets client software on endpoints. See the T1190 Exploit Public-Facing Application Defensive Guide.
• T1068 Exploitation for Privilege Escalation: often follows T1203 to escape a browser sandbox or gain SYSTEM. See the T1068 Exploitation for Privilege Escalation guide.

Detection: the exploited client behaviour chain

ATT&CK v20 publishes detection strategy DET0287 for T1203, with one analytic per platform. Each describes the same cause and effect chain, adapted to the platform's logs.

Exploits that succeed cleanly may not crash the application, so treat the crash as a severity booster rather than a required condition. The child process and the network step are the parts that almost always occur.

Tuning notes

• Parent list: browsers, Office applications, PDF readers, email clients, archive tools and any line-of-business client that opens external files.
• Expected children: browsers legitimately start helper processes and updaters; record their signed paths and exclude only those exact binaries.
• Time window: correlate crash, file write, child and connection within a few minutes; a long window links unrelated events.
• Crash volume: baseline crash rates per application version. A sudden rise in crashes of one reader or browser version across several users can indicate a campaign.

See the Sysmon Guide for event configuration and the EDR Evasion and Defence Guide for keeping the endpoint agent trustworthy after an exploit lands.

Prevention and hardening

Exploit protection (M1050)

ATT&CK names Windows Defender Exploit Guard and control flow integrity checking as examples. On Windows, exploit protection settings are applied per application and can be exported as XML and deployed through Intune, other MDM tools using the ExploitProtectionSettings policy, Configuration Manager or Group Policy. Microsoft's documentation lists mitigations that support an audit-only mode, including arbitrary code guard, block low integrity images, block untrusted fonts, code integrity guard, disable Win32k system calls, do not allow child processes, export and import address filtering, and validate stack integrity. Before deploying, Microsoft advises monitoring crashes (event IDs 1000 and 1001) and hangs (1002), collecting user-mode dumps and using a test device group.

On macOS and Linux, rely on the platform's built-in protections and keep applications on vendor-supported versions that ship with them enabled. The Exploit Mitigations Guide explains how ASLR, DEP and control flow integrity work.

Isolation and sandboxing (M1048)

• Browser sandboxes: ATT&CK notes browser sandboxes mitigate some impact but sandbox escapes still exist. Keep sandboxing features on and block policies that disable them.
• Protected View: Microsoft documents that Office opens internet files, files from unsafe locations and files that fail validation in a read-only Protected View, and that administrators can stop users leaving it.
• Remote or isolated browsing: for high-risk roles, browser isolation or virtualisation separates untrusted content from the endpoint.

Reducing what can follow an exploit

Attack surface reduction rules block the child processes most exploits rely on. Microsoft Defender examples are "Block all Office applications from creating child processes" (d4f940ab-401b-4efc-aadc-ad5f3c50688a), "Block Adobe Reader from creating child processes" (7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c) and "Block Office applications from creating executable content" (3b576869-a4ec-4529-8536-b80a7769e899). Other EDR products offer equivalent behaviour rules.

Updating software (M1051)

The NCSC advises installing updates promptly, ideally within a few days, turning on automatic updates for the operating system, browser, office apps and document readers, and checking that automatic updates are still working. Prioritise vulnerabilities listed in the CISA Known Exploited Vulnerabilities catalogue. See the Patch Management Guide and Browser Security Hardening Guide.

Implementing T1203 coverage

1. Inventory client software: list every browser, office suite, reader and file-handling client by version across the estate, including user-installed copies.
2. Close the patch gap: fix stalled update channels and remove unsupported versions before tuning detections, since old flaws remain heavily used.
3. Deploy the behaviour chain in log-only mode: implement the platform analytic, review two weeks of hits and build exclusions for signed helpers.
4. Pilot exploit protection and ASR rules: enable audit-only mitigations and ASR audit mode on a test device group, watch crash and audit events, then enforce in rings (IT, security and help desk first).
5. Promote to alerting: alert on any client application child process from the high-risk list plus a network connection, and raise severity when a crash preceded it.
6. Roll back: disable a problem mitigation for the affected application only, retest and re-expand, as Microsoft advises.

Small organisations without a SOC gain most from automatic updates, Protected View and ASR rules. Larger estates should split the patch target by application class and track it as a separate metric from server patching.

Responding to an exploited client

• Isolate early: a client exploit with a child process and outbound connection means code is running; isolate the host through EDR.
• Find the trigger: identify the URL, attachment or file the application had open, and look for other users who received or visited it.
• Collect the crash evidence: keep application crash dumps, the triggering file, browser history and the process tree; they help confirm the vulnerability and the patch that fixes it.
• Check for escalation: look for privilege escalation or sandbox escape following the child process.
• Revoke sessions: sign the user out of cloud services and revoke tokens, since browser exploitation can expose session cookies.
• Patch and verify: confirm the fixed version is installed across the estate, not just on the affected host.

Where identity fits

An exploited browser runs in the context of a user who is already signed in to SaaS applications, so the attacker may reach session cookies and tokens without needing a password. Session revocation and token binding matter as much as cleaning the endpoint. Developer workstations deserve attention too, because their browsers and clients often hold cloud CLI credentials and API keys that are non-human identities in their own right.

Measuring it

• Client patch latency: median days from vendor release to 95 percent installation, per application class.
• Unsupported client versions: count of endpoints running end-of-life browsers, office suites or readers (target zero).
• ASR and exploit protection coverage: percentage of Windows endpoints with the client child process rules in block mode.
• Behaviour chain alerts: weekly count of client application to high-risk child alerts, and the share confirmed malicious.
• Time to isolate: minutes from alert to host isolation for confirmed exploitation.

Common failure patterns

• Patching servers first, desktops last: client applications reached from email and the web wait behind server change windows.
• Unmanaged readers and browsers: user-installed copies that never receive central updates.
• Crash events never collected: application error logs left on the endpoint, so a burst of exploit crashes goes unseen.
• Broad exclusions: excluding a whole browser or office application from ASR rules to fix one plug-in.
• Endpoint-only response: reimaging the host but leaving the user's cloud sessions active.

Framework mapping

Practitioner checklist

• Inventory every client application and version, including user-installed copies.
• Set and measure patch targets for browsers, office suites and readers separately from servers.
• Collect application crash events and Sysmon process, file and network events from endpoints.
• Deploy the ATT&CK client exploitation behaviour chain for each platform you run.
• Enable exploit protection in audit mode, then enforce in rings with per-application exceptions.
• Enforce ASR rules blocking Office and reader child processes.
• Keep Protected View and browser sandboxing on and stop users disabling them.
• Include session and token revocation in the client exploitation runbook.

Standards and references

• MITRE ATT&CK: Exploitation for Client Execution (T1203)
• Microsoft Learn: Enable exploit protection
• Microsoft Learn: Exploit protection reference
• Microsoft Learn: Attack surface reduction rules reference
• Microsoft Support: What is Protected View?
• NCSC: Keeping devices and software up to date
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: ATT&CK Execution Tactic Guide · T1204 User Execution · Memory Corruption Vulnerabilities Guide · Browser Security Hardening Guide · Patch Management Guide