---
{
  "title": "Access Token Manipulation",
  "summary": "Access token manipulation changes or adopts operating-system security contexts.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1134"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1134: Access Token Manipulation",
      "url": "https://attack.mitre.org/techniques/T1134"
    }
  ],
  "editorialVersion": 2
}
---

## A process can act under another security context

Access token manipulation changes or adopts operating-system security contexts so activity runs with authority different from its original context. In Windows, access tokens describe security information used in access decisions. Legitimate impersonation and service operation use these mechanisms, while abuse can support unauthorized access or higher-privilege actions.

The word token here does not necessarily mean a web access token or browser cookie. Understanding which system issued the token, what it represents, and where it can be used prevents an investigator from applying the wrong revocation or evidence assumptions.

## Investigate identity and execution together

In a fictional endpoint case, a program launched by a staff account performs an action recorded under a more privileged context. The analyst examines the process sequence, security identifiers, privileges, relevant logon sessions, and evidence of the protected operation.

A change in context is a question to explain, not automatic proof of theft. Some services intentionally impersonate a client or create work under another account. The investigator compares the behavior with the application's design and approved administrative activity.

Where endpoint telemetry exposes token-related behavior, correlate it with process and authentication records. Do not infer the exact mechanism from a display name alone. A product may summarize several underlying actions into one alert, and the raw evidence may support a narrower conclusion.

## Establish the prerequisites and effects

Different token-related methods require different permissions or access. Avoid assuming that every standard user can adopt any privileged token. Determine what authority the originating process already had and which additional authority the observed transition provided.

The resulting action may matter more than the unfamiliar API call. Was protected data read, another process started, or a remote resource accessed? Document those effects separately from the hypothesis about how the context was obtained.

[[authorization]] explains why the effective security context matters. [[logs-and-telemetry]] helps identify which records can show the transition and where sensor coverage limits the analysis.

## Scope the response

Preserve process and session evidence while it remains available. Restrict the affected host or identity as justified by the incident, and investigate the access that enabled the manipulation. Changing a human password alone may not explain or remove a locally active privileged process.

For practice, create a fictional service that legitimately impersonates a user to read an authorized document. Compare it with an unrelated program gaining access to a protected directory. List the process, identity, and resource records needed to distinguish them. Explain one conclusion that cannot be drawn when only a final username is visible. Map supported behavior through [[mitre-attack]] without claiming a specific actor from the technique alone.

## Related concepts

- [[incident-response]]