How T1134 access token manipulation hides privileged activity in normal logons
MITRE ATT&CK technique T1134, Access Token Manipulation, sits under the Stealth tactic (TA0005), which ATT&CK defines as an adversary trying to "hide and conceal their actions, appearing as normal behavior." For a detection engineer, the difficulty is that a process may appear to run under a different account while no matching logon event explains it. The technique covers 5 sub-techniques, and the mappings on this page target Enterprise ATT&CK v20.0, so detection content should name that version explicitly. Expect to see the technique across intrusions where an adversary already holds some privilege and wants its activity to blend into ordinary administrative or service behavior rather than generate a new, suspicious account context.
The practical question is which account context is expected for a given process, and which token changes are legitimate. Start by inventorying the processes on your Windows fleet that are permitted to impersonate or duplicate tokens, such as backup agents, endpoint management tools, service accounts and scheduled jobs. Record the user, integrity level and parent process you expect for each. Any deviation from that baseline becomes a candidate for investigation, and the baseline itself is an asset you will need to maintain as software changes. Confirm with your platform and endpoint teams which of these tools the organization actually runs, since an incomplete inventory produces either noise or blind spots.
Plan for the decisions that follow from detection. Decide who triages a token-related alert, what evidence is preserved before a host is isolated, and whether a privileged account must be reset when a token misuse is confirmed. Map these decisions to the ATT&CK mitigations User Account Management (M1018) and Privileged Account Management (M1026), and confirm with your identity team how administrative accounts are scoped and rotated. Use a private cyber range to rehearse these steps against telemetry from your own sensors before relying on them in production.
Which Windows telemetry reveals token manipulation and which open-source collector captures it
This table maps the three telemetry sources that matter most for T1134 on Windows to the signal each one produces and the open-source collector that captures it. Read each row as a question to answer in your own environment: does the field exist, is it complete, and does it reach your analysts. The data components listed are those ATT&CK references for Stealth techniques, so confirm field availability before relying on any row.
| Telemetry source | Signal for token manipulation | Open-source collector | Field check before relying on it |
|---|---|---|---|
| Process Creation (DC0032) | Child process running under an account that differs from its parent, or a process started with a token whose user or integrity level does not match the expected parent context | Sysmon process creation events forwarded by Wazuh agents, or Security Onion via Winlogbeat | Confirm the user and integrity level fields are populated and that Sysmon configuration logs every process creation for the hosts in scope |
| Process Access (DC0035) | Access to another process handle that requests token-related rights, such as rights used to open or duplicate a process token | Sysmon process access events forwarded by Wazuh agents, or Security Onion for network-side correlation | Confirm process access logging is enabled for sensitive processes such as LSASS, and that the requested access mask is recorded |
| OS API Execution | Calls to token-handling Windows APIs by a process that does not normally use them, which can show as abnormal API activity in endpoint telemetry | Velociraptor for hunting on endpoints, with results reviewed in Wazuh or Security Onion | Confirm your endpoint product or Velociraptor artifact set exposes API-level telemetry, since this source is not always present by default |
| Windows Security event logs | Logon and privilege events that show a token with elevated privileges being used, which supports the process-level signals above | Wazuh agents forwarding Windows Security event logs to the Wazuh manager | Confirm the audit policy for logon and privilege use is enabled and that the events arrive in the Wazuh manager at the expected rate |
| Sysmon configuration | The rule set determines which process creation and process access events exist at all, so gaps here become blind spots for every row above | Sysmon agent configuration deployed by the Wazuh or Security Onion operations team | Review the configuration against the hosts in scope and test that expected events appear after a controlled change |
Sigma and Wazuh detection ideas for access token manipulation on Windows
These ideas detect access token manipulation on Windows, where a process takes on the security context of another account. Each idea is written as Sigma logic, deployed through Wazuh and mapped to ATT&CK v20. Tune every threshold against your own host baseline, and validate each rule in a cyber range before it alerts analysts.
Parent and child account mismatch
Flag process creation events where the account running a new process differs from the account or logon session of its parent, outside known launchers such as service control and task scheduling. Start with a short look-back window and a narrow host group, then widen it once the baseline is clear. Check the parent image, integrity level and whether an elevation prompt preceded the event. Expect false positives from backup agents, endpoint security products and service accounts that spawn child processes under different identities. Maintain an allowlist keyed to image path and signer, not to process name alone.
Token-handling calls against other processes
Use Process Access telemetry to alert when a process opens another process with access rights linked to duplicating or impersonating tokens, especially when the source image is unsigned, lives in a user-writable path or is not normally a管理 tool. This is the core signal for token theft under T1134. Expect noise from endpoint detection agents, debuggers, crash reporters and backup software, all of which open other processes legitimately. Set a per-host threshold once the allowlist is stable, and review each new source image before adding it.
Privileged logon after process creation
Correlate a process creation event with a special privilege logon for the same account on the same host within a short window. An unexpected privileged logon that follows a non-administrative process is a strong lead for token misuse. Tune the window to your environment, and exclude known administrative sessions and scheduled maintenance. Expect false positives from patch management, remote administration tools and service restarts that legitimately produce privileged logons. Review the user, source host and parent process together before escalating.
Sub-technique specific lineage patterns
Write separate rules for the sub-techniques that leave distinct traces, such as parent process identifier spoofing, where the recorded parent does not match the expected process lineage for that image. Lineage rules should compare the image with its typical parents, so a service host spawning an interactive shell stands out. Expect false positives from software installers and vendor agents with unusual launch chains. Document the expected parent for each high-value image, and revisit the list when software changes.
Versioned Sigma rules and validation
Express each rule in Sigma, convert it for Wazuh, and record the ATT&CK version it targets, which for this page is v20. Map detection strategies to data components and the User Account Management and Privileged Account Management mitigations, using the enterprise-attack 20.0 STIX bundle as the reference. Replay each rule in a cyber range, confirm the alert fires, and reconfirm after every ATT&CK release, since mappings can change.
How to validate that the token manipulation detection fires
This sequence proves, in a lab or cyber range, that each T1134 sub-technique test produces an alert the SOC can act on, and it leaves a record of the evidence and the tuning effort that keeps the detection trustworthy over time.
Agree scope and rules of engagement
The detection owner, the SOC lead, the cyber range operator and the host owner agree in writing which hosts, accounts and time windows are in scope, who can stop the exercise, and how test accounts are created and removed afterward. The test host must be a monitored endpoint that forwards Windows event telemetry to the Wazuh or Security Onion stack that the SOC uses. The step is done when the signed scope note names the test host, the test identities and the abort contact, and the SOC confirms that log forwarding for that host is healthy before the first test begins.
Map each sub-technique to a test case
The detection engineer lists the five T1134 sub-techniques from the ATT&CK version the team targets and writes one test case per sub-technique. Each case states the expected telemetry, such as Process Creation, Process Access or OS API Execution, the expected alert name and the analytic it should trigger. Test cases are described in plain language and reviewed by a second engineer, so that the expected evidence is agreed before anything runs. The step closes when every sub-technique has a case with an expected data source and an expected alert, and any sub-technique without a usable data source is flagged as a visibility gap.
Run each test against the monitored host
The red team or emulation operator runs each approved test case on the monitored host, one at a time, and notes the start and end times in the exercise log. Running cases individually makes it possible to tie each alert to a single action. The operator does not improvise beyond the approved case. The step is done when every case has a recorded start time, end time and operator name, and any test that could not be run as written is logged with the reason.
Confirm the alert reaches the SOC queue
The SOC analyst checks the case management queue or ticketing system for an alert generated by each test window, and confirms the alert was routed to the correct queue with the correct severity. A detection that writes to a local log but never reaches an analyst is a failed test. The analyst records whether the alert arrived, how long it took to appear and whether the enrichment fields (host, user, process and parent process) were populated. The step is done when each test case is marked as detected, partially detected or missed, with the reason recorded for anything other than detected.
Record event IDs, timestamps and alert fidelity
For each detected case, the analyst records the Windows event IDs that supported the alert, the event timestamps, the alert identifier and a fidelity judgment: whether the alert contained enough context to triage without re-querying the raw logs. The evidence is stored in the exercise record with the ATT&CK version, rule version and test case ID. The step is complete when every detected case has a stored evidence entry that another engineer can reproduce from the log store, and the record shows the rule version that fired.
Measure false positives after tuning
After the first run, the detection engineer reviews benign activity from the same host over a period the SOC agrees on, counts alerts that were not caused by a test, and adjusts exclusions only where the reason is documented, such as a known service account or a signed administrative tool. Each tuning change is recorded with the reason and the count of alerts before and after. The step is done when the false-positive count and the tuning log are approved by the SOC lead, and the team confirms that the tuning did not remove the test alerts that were detected in the previous step.
Re-run tests after ATT&CK version updates
When MITRE publishes a new ATT&CK version, the detection owner compares the T1134 entry and its sub-techniques against the previous version using the release notes and the STIX bundle for the targeted domain, and records any renamed, deprecated or revoked items. Affected test cases are updated and the full set is re-run on the monitored host. The step is complete when the mapping document names the new ATT&CK version, every change is logged, and the re-run results are compared with the previous exercise record.
Which ATT&CK mitigations reduce token manipulation risk
ATT&CK maps two account-focused mitigations to T1134 Access token manipulation and its sub-techniques. Both work by limiting which accounts can hold tokens with elevated rights, so an attacker who steals or duplicates a token has less to gain. Confirm each control against your own Windows estate, since the mapping describes intent rather than your configuration.
Restrict privileged account use
User Account Management (M1018) and Privileged Account Management (M1026) both point at the same question: which accounts are allowed to run with high privileges at all. Start by listing every account that holds domain admin, local administrator or backup operator rights on servers and workstations. Confirm that day-to-day accounts do not carry those rights, and that administrative work runs from separate, named accounts. Ask your team to show where that separation is enforced, not just documented.
Limit who can hold elevated tokens
Token manipulation depends on an attacker finding a process running under a privileged security context and then reusing that context. Reduce the number of places where such contexts exist. Review which service accounts run interactive sessions, which administrators log on to ordinary workstations, and where privileged sessions remain open after work ends. Illustrative example: an administrator who signs in to a user workstation with a domain admin account creates a high-value token on a machine that many people can reach.
Review group membership on a schedule
Privileged group membership tends to grow quietly through exceptions that are never removed. Set a recurring review of membership in the groups that grant administrative rights, and record who approved each addition and when it expires. Compare the results with your identity provider and directory logs, so that accounts added outside the approved process are visible. Confirm the review cadence and owner in writing, because ATT&CK does not prescribe either.
Separate tier 0 administration
Tier 0 assets include domain controllers, identity infrastructure and the accounts that manage them. Keep those administrative sessions off standard endpoints and away from the paths that normal users take. Where your estate allows it, use dedicated administrative workstations for tier 0 work and restrict which accounts can log on to domain controllers interactively. Check whether your directory design supports this model, and confirm the exact control with your Windows administrators.
Audit privileged logon scope
Mitigations only hold if you can see where privileged accounts actually log on. Pull a list of interactive and network logons by privileged accounts across a sample of servers and workstations, and compare it with the access policy you intended. Mismatches show where a control is missing or where a legacy setting still grants rights. Ask for the logon rights assignments in local and domain policy, since their presence on a system is what determines where a privileged token can appear.
Triage steps when a token manipulation alert fires
Start by confirming who and what is involved, because every later step depends on it. The analyst should answer three questions first: which account held the token before and after the event, which process on the host performed the change, and whether that process ran under the expected parent. Pull the Process Creation records for the process and its parent from Wazuh or your Sysmon pipeline, and note the integrity level and the user context. If the alert fired on a Process Access event, confirm which process was the source and which was the target, since a token change on a high-value process such as a service host or an identity agent carries more weight than the same change on a user tool.
Next, decide whether the activity matches an approved administrative task. Ask the change owner or the service desk whether a maintenance window, a scheduled job, a software installer or a backup agent was running on that host at that time. Compare the event against your change records and against the expected behavior of any privileged tooling you have approved. If no approved task explains it, treat the alert as suspicious and move on without waiting for confirmation. Record the decision and the evidence used, because auditors and incident reviewers will ask how a benign explanation was reached.
Then pivot through logon and process trees to see what happened before and after the token event. Look for the logon session that the process belongs to, any network logons or remote service starts around the same time, and child processes spawned by the suspicious process. Ask whether the same account authenticated to other hosts within a short window and whether any new service or scheduled task appeared. If the picture points to an active intruder, isolate the host from the network through your endpoint platform or firewall, keeping management access open, and only after evidence capture is confirmed. Preserve volatile data with Velociraptor or a Wazuh active response collection before reimaging, and record hashes and timestamps for each artifact. Finally, review related accounts, especially any privileged accounts that were used or that share group memberships with the affected account, and confirm that User Account Management and Privileged Account Management controls still reflect your intended design.
How to rehearse token manipulation detection in a private cyber range
A private range for T1134 needs a Windows domain that resembles production closely enough to produce the same logon, privilege and process patterns. The goal is not a large lab but a faithful one: a domain controller, a small set of member workstations and servers, a Wazuh manager receiving endpoint telemetry, and a Security Onion sensor watching the segment. Confirm each component's version against the vendor documentation before the exercise, because collection settings change between releases.
- Windows domain: Include standard user, administrator and service accounts so that token context varies realistically between tests.
- Sysmon-configured endpoints: Deploy Sysmon with a configuration agreed with the detection team, covering process creation and process access events, and record the exact configuration hash in the range log.
- Wazuh manager: Confirm that the agents forward the Windows event channels and Sysmon channel to the manager and that rule updates are version-controlled.
- Security Onion sensor: Place it so it can see authentication and remote management traffic between hosts, and verify that its retention covers the full exercise window.
- Time and identity baseline: Synchronize clocks across every host and snapshot the domain state so each run starts from the same point.
Before the first exercise, ask the range provider to confirm in writing which telemetry is collected, how long it is retained and where the evidence is stored.
Injects are the controlled actions that the exercise team performs to test each detection idea. They are described here in words only, and the exact scenario for each inject is agreed in writing with the client before the exercise starts, including the hosts involved, the accounts used and the stop conditions. Each inject should map to one detection idea, so that a missed alert points to a specific gap rather than a general failure.
- Privilege context change: A process runs under an account that holds different privileges from its parent, and the detection should flag the change in token context.
- Cross-process access to a privileged process: A process requests access to another process owned by a higher-privilege account, which should appear in process access telemetry.
- Token use by an unexpected parent: A process that does not normally request token operations performs one, which should be visible through process creation and OS API activity.
- Benign administrative look-alike: A legitimate administrative task produces similar events, so the team can measure false positives and tune the rule.
- Negative control: A run with no token manipulation confirms that the detections stay quiet during normal activity.
For each inject, record the expected alert, the expected time window and the accounts involved, so that the results can be compared against the detection logic.
A detection is only useful if it reaches an analyst quickly, carries enough context to act on and hands over cleanly to containment. The range should measure these qualities as carefully as the alert itself. Agree the target timings with the client in advance, since acceptable alert latency depends on the monitoring model and the staffing of the security operations team.
- Alert timing: Record the time between each inject and the alert in Wazuh or Security Onion, and compare it with the timing agreed for the exercise.
- Analyst notes: Require the analyst to record the account, host, parent process and the reason the alert was triaged as suspicious or benign.
- Enrichment check: Confirm that the alert includes the user, the host and the process lineage, because token activity without context is hard to judge.
- Handover to containment: Test the path from analyst to the incident owner, including who can disable the account, isolate the host or reset credentials, and how long that takes in the exercise.
- Lessons and tuning: Log each gap as a change request with an owner, and rerun the affected inject after the rule is updated.
At the close of the exercise, ask the team to confirm which controls they would expect to operate in production and which need evidence from a further test.
Questions SOC leads and detection engineers ask about T1134
How do I separate token changes from normal service account behavior?
Start by building a baseline of which service accounts, hosts and parent processes legitimately change or impersonate tokens during a normal business week. Record that baseline in your SIEM as a lookup or allowlist, then alert when an account, host or parent process falls outside it. Review the baseline after every change window, because new backup jobs, deployment tools and scheduled tasks will add legitimate activity. Keep the allowlist narrow and owned by a named team so that exceptions are reviewed rather than accumulated. Confirm the exact fields your Windows telemetry provides before you write the logic, since the signal depends on which process and account attributes you collect.
Which Windows telemetry is most useful for detecting T1134?
Three data components from the ATT&CK model carry most of the signal for this technique: Process Creation, Process Access and OS API Execution. Process Creation with full command line and parent process context shows which binaries run under which identities. Process Access shows when one process requests handles to another, which is often where token work becomes visible. OS API Execution helps where your endpoint tooling exposes API calls, so confirm that your EDR product provides it before you depend on it. Pair these with logon and privilege records from the Windows Security log. Verify your audit policy and endpoint agent configuration, because gaps in either will quietly remove the detections you planned.
How do I tune detections for backup and endpoint security tools?
Backup agents, endpoint protection and management consoles often run as privileged services and interact with many processes, so they will generate the most noise. Inventory each tool, its service account, its install path and its expected parent processes, and document them in the detection rule's metadata. Then scope exceptions to the specific account, host group and binary combination rather than to a whole vendor or directory. Ask each vendor which privileges their agent requires and how it accesses other processes, and treat any answer you cannot verify in your own environment as an open item. Re-run the tuned rule during a maintenance window to confirm that legitimate jobs stay quiet and that a deliberate test in the range still alerts.
How often should we re-test T1134 detections after ATT&CK releases?
Re-test after each ATT&CK release that touches your mapped techniques, and at least after changes to your telemetry or endpoint tooling. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and releases can rename, deprecate or revoke techniques. Check the release notes to see whether T1134, its sub-techniques or their data components changed, and compare your detection mappings against the STIX bundle for the version you target. Record the ATT&CK version in each detection's metadata so that reviewers can tell which mapping a rule was built against. The review cadence itself is a governance decision for your team, so agree it in writing with your detection owners.
How should we handle T1134 sub-techniques that produce few signals?
Sub-techniques with sparse telemetry need a different strategy than high-volume ones. First, confirm whether the signal is absent or whether your sensors simply do not collect it, because those two situations call for different fixes. Where telemetry is missing, record the gap as a known risk with an owner and a plan to close it. Where telemetry exists but alerts are rare, build detections around the combination of identity, host and process context rather than around a single event, and test them in a cyber range so you know the rule fires. Document which sub-techniques have coverage, which rely on partial coverage and which have none, so that leadership sees the true state.
What should a cyber range rehearsal of T1134 detection include?
A useful rehearsal tests whether your telemetry, rules and response steps work together, not whether an attacker can succeed. Illustrative scope: a scripted scenario agreed in writing, run in an isolated range that mirrors your Windows build and endpoint tooling, with a defined start and stop time. Score each stage on three questions: did the expected telemetry arrive, did the rule fire with the right context, and did the analyst follow the runbook. Record gaps, assign owners and rerun the scenario after fixes. DeployOpen runs private cyber ranges and security testing under fixed scopes agreed in writing, so the boundaries of any exercise are defined before work starts.
Can our own team run T1134 detection work, or do we need outside help?
Many teams can build and maintain T1134 detections in-house if they have Windows telemetry, a SIEM and someone who owns the rules. Outside help is most useful for specific gaps: designing the telemetry pipeline, validating detections in a range, or independent testing of the controls. DeployOpen plans, implements, tests and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. Ask any provider to show which tasks they will hand over to your staff so that the detections remain yours after the engagement ends.
Which T1134 mitigations should we confirm first?
Start with User Account Management (M1018) and Privileged Account Management (M1026), since ATT&CK maps both to this technique. User Account Management concerns how accounts are created, changed and removed, so confirm that service accounts have documented owners and that dormant or unused accounts are reviewed. Privileged Account Management concerns how elevated rights are granted, monitored and limited, so confirm which accounts hold the rights that allow token work and whether their use is logged and reviewed. Map each control to your own policy and to the control language of any framework you are assessed against, and describe the evidence in your own words. Independent auditors and certification bodies, not DeployOpen, decide whether the controls satisfy a given requirement.
How DeployOpen builds token manipulation detections and range exercises
DeployOpen starts every T1134 Access token manipulation engagement with a written scope that names the Windows hosts, domain controllers and privileged accounts in play, the telemetry sources that are already collected, and the sub-techniques the client wants covered. The scope also states which ATT&CK version the mapping targets, because the technique and its sub-techniques can change between releases, and which of the five sub-techniques are in and out of the first phase. Before any rule is written, the team confirms with the client that process creation events, process access events and any OS API execution telemetry actually reach the Wazuh manager or the Security Onion stack, and that the audit policy on endpoints records what the detections depend on. Gaps found at this stage are listed as prerequisites in the statement of work, not discovered halfway through the build.
Detections are written as Sigma rules first, then converted to the client's Wazuh rule format and tested against the events they will see in production. Each rule is tied to the ATT&CK detection strategy it addresses and records its data components, expected false positives and the administrative actions that legitimately use token operations, such as service accounts, backup agents and endpoint management tools. Those exclusions are reviewed with the client's identity team so that they are narrow and documented. In a private cyber range, DeployOpen then runs a purple team exercise in which the defenders' alerts are compared against a scripted set of token manipulation behaviors, and the gaps are logged as tuning or coverage actions with owners and due dates agreed in writing.
Evidence is the last step and the one most often skipped. For each validated detection, DeployOpen documents the rule logic in plain language, the ATT&CK mapping and version, the exercise date, the events observed, the alert produced, and the response steps the SOC followed. These records feed the client's detection program and can be reused in internal reviews or in preparation for a compliance assessment, where the mitigations User Account Management and Privileged Account Management are often asked about. DeployOpen does not issue audit reports or attestations; the client's assessor decides what the evidence supports. Clients should ask for the evidence format, retention location and retest schedule to be stated in the quote before work begins.
