---
{
  "title": "Exploitation for Client Execution",
  "summary": "Client application exploitation uses a vulnerability in software that processes content on an endpoint.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1203"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1203: Exploitation for Client Execution",
      "url": "https://attack.mitre.org/techniques/T1203"
    }
  ],
  "editorialVersion": 2
}
---

## Content processing can expose a client weakness

Exploitation for client execution uses a vulnerability in software that processes content on an endpoint. A document reader, browser, or other client application may encounter crafted material that causes behavior outside its intended design. The relevant weakness and required interaction depend on the application and vulnerability.

This differs from a user knowingly launching an executable or enabling an intended scripting feature. [[user-execution]] can be part of the surrounding sequence, but the investigator should establish whether a software flaw, ordinary functionality, or another mechanism caused execution.

## A document leads to an unexpected process

In a fictional office, an employee opens an externally received document. The reader crashes, and endpoint telemetry shows a new process performing unexplained actions. The analyst preserves the document, checks the application version, and examines the process sequence, crash information, file changes, and network activity.

A crash alone does not prove exploitation. Corrupted files and software defects can cause harmless failures. A child process alone may also have a legitimate explanation. The combined evidence and application context determine whether exploitation is supported.

If a known vulnerability is suspected, consult the vendor's advisory and verify that the relevant version and conditions apply. Avoid attributing an exploit from a filename or a generic crash signature without sufficient evidence.

## Distinguish delivery from execution

Receiving a document establishes delivery. Opening it establishes interaction if supported by records. Demonstrating unauthorized code execution requires additional evidence. Keep those stages separate when explaining the incident and affected population.

The same message may have reached many recipients, but not every recipient necessarily opened the content or experienced the same result. Review available interaction and endpoint evidence rather than declaring all recipients compromised automatically.

[[phishing]] explains one delivery context. [[command-and-scripting-interpreter]] may describe later execution, while [[digital-forensics]] supports careful handling of the received artifact.

## Recover the endpoint and the application

Contain harmful activity as justified and preserve relevant evidence before cleanup where practical. Correct the affected application weakness, review actions taken under the user's authority, and investigate credentials or data potentially exposed through the resulting access.

Updating the application addresses the vulnerability but does not necessarily remove an already running payload or invalidate stolen access. Define recovery checks for the endpoint and related identities.

For practice, compare a harmless document crash with a fictional document followed by confirmed unauthorized execution. Identify the version, artifact, process, and effect evidence needed to distinguish them. [[incident-response]] and [[incident-reporting]] keep the response aligned with what the evidence actually establishes.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]