---
name: harden-windows-boundaries
description: "Defensive hardening methodology for Windows trust boundaries and access tokens: the UAC and integrity-level boundary between medium and high integrity, token theft, duplication, and impersonation, parent-PID spoofing, and Active Directory SID-History injection (MITRE ATT&CK T1134, T1134.001, T1134.002, T1134.003, T1134.004, T1134.005, T1548.002). Signals come from the Windows Security log (4688, 4672, 4673, 4674, 4624, 4648, 4703, 4765, 4766) and Sysmon (EID 1, 10, 13). Gives the events that reveal an illegitimate token or integrity transition, a hunt, rule sources, and a hardening plan for UAC, privilege rights, Credential Guard, and AD trusts. Use when hardening UAC and integrity levels, reviewing SeImpersonatePrivilege or SeDebugPrivilege holders, enabling Credential Guard or lsass PPL, configuring SID filtering on a trust, hunting token-impersonation or SID-History abuse, or closing the medium-to-high integrity gap."
---

# Windows Trust-Boundary and Token Hardening - Defensive Methodology

> **Tier 2 - methodology skill.** No bespoke UMBRASEC detection rule ships with this skill yet. It gives the defender's method, the log sources and signals, the hunt, and the hardening, and points to public rule sources. Promotion to Tier 1 (a sourced, tuned UMBRASEC rule) is tracked in [COVERAGE.md](https://github.com/umbrasec-labs/umbra-blue/blob/main/COVERAGE.md). Do not treat the content below as citing a UMBRASEC rule; there is none for this threat yet.

## TL;DR

Windows enforces several trust boundaries that an attacker with a foothold tries to cross without a legitimate elevation: the integrity-level boundary (a medium-integrity user process should not become high or SYSTEM integrity except through a UAC consent prompt), the token boundary (a process should run under its own token, not a duplicated or impersonated copy of a more privileged one), the process-lineage boundary (a child's parent should be its real creator, not a spoofed one), and the Active Directory trust boundary (a principal from one domain should not carry the SIDs of a privileged group in another). The native tell is a cross-token mismatch. Enable **Audit Process Creation** with command line and compare **Event ID 4688** fields: when the new process runs under a different token than its creator, the Target Subject fields (`TargetUserSid`, `TargetUserName`, `TargetLogonId`) are populated, which is the direct signal of create-process-with-token. Pair it with Sysmon Event ID 1 where the child's `User`, `LogonId`, or `IntegrityLevel` does not match the parent's, with 4672 showing sensitive privileges assigned to a logon that should not have them, and with 4765/4766 for SID-History changes on domain controllers. Then harden the boundaries so a crossed one is useless: strip `SeImpersonatePrivilege`, `SeDebugPrivilege`, `SeAssignPrimaryTokenPrivilege`, and `SeTcbPrivilege` from accounts that do not need them, set UAC to **Always notify** and keep `LocalAccountTokenFilterPolicy` at its default, protect lsass with RunAsPPL and Credential Guard so a stolen token has nothing to steal next, and enable SID filtering on trusts.

## What it looks like, defender view

In normal operation these boundaries are crossed in a few predictable ways. Elevation across the integrity boundary is explicit: an administrator triggers a UAC consent prompt, `consent.exe` runs, and the new high-integrity process is parented to a known elevation path. A process runs under its own logon session, so its token owner and logon ID match its parent's, and 4688 leaves the Target Subject fields empty because creator and target share one token. Sensitive privileges such as `SeImpersonatePrivilege` are held by a fixed, enumerable set of service accounts (IIS, SQL) and admins. SID-History exists only on accounts that were genuinely migrated between domains, and it changes only during a migration window.

A boundary attack breaks one of those invariants. Token impersonation or theft shows a service-account or SYSTEM process spawning a shell or unknown binary under a token whose owner and logon ID are not its own, often with no matching new-logon event because impersonation reuses an existing session rather than creating one. Create-process-with-token shows a 4688 whose Target Subject fields are populated and differ from the Subject (creator) fields, meaning the parent launched the child under a stolen or duplicated token. Parent-PID spoofing shows a process whose recorded parent is a trusted, innocuous binary that would never plausibly launch it, used to inherit a better token and to evade lineage-based rules. A UAC bypass shows an auto-elevating trusted binary (`fodhelper.exe`, `computerdefaults.exe`, `eventvwr.exe`, `sdclt.exe`) spawning a high-integrity child with no `consent.exe` in the lineage, moments after a current-user registry handler key was written. SID-History abuse shows a 4765 adding a privileged SID to an account outside any migration. This skill explains each path only to the depth needed to catch and close it, and ships no token-manipulation or UAC-bypass tooling.

## Log sources and signals

Instrument two planes: the Windows Security log for the native token and privilege events, and Sysmon for the process-lineage and integrity detail the Security log does not carry. On domain controllers add the SID-History audit events. A gap on either plane is a blind spot, because the impersonation path is clearest in Sysmon lineage while the create-with-token and privilege-assignment paths are native Security events.

- **Event ID 4688, Process creation.** Enable `Include command line in process creation events`. The decisive fields for this skill are the **Target Subject** set (`TargetUserSid`, `TargetUserName`, `TargetLogonId`), which Windows populates only when the new process runs under a different token than its creator, and `TokenElevationType` (`%%1936` Type 1 full token, `%%1937` Type 2 elevated via Run-as-administrator or auto-elevation, `%%1938` Type 3 limited), plus `MandatoryLabel` (the integrity SID, for example `S-1-16-16384` System, `S-1-16-12288` High, `S-1-16-8192` Medium, `S-1-16-4096` Low, `S-1-16-20480` Protected Process), `NewProcessName`, and `ParentProcessName`. A populated Target Subject that differs from the Subject is the create-process-with-token tell; a Type 2 process with no `consent.exe` in its lineage is the UAC-bypass tell.
- **Event ID 4672, Special privileges assigned to new logon**, and **4673/4674, a privileged service was called / an operation was attempted on a privileged object.** Watch `PrivilegeList` for `SeImpersonatePrivilege`, `SeAssignPrimaryTokenPrivilege`, `SeDebugPrivilege`, `SeTcbPrivilege`, and `SeCreateTokenPrivilege`. A logon or process acquiring these outside your known admins and service accounts is the token-manipulation precondition.
- **Event ID 4624 and 4648.** For impersonation, note that pure in-process impersonation (DuplicateTokenEx then ImpersonateLoggedOnUser) creates no new logon session and so emits no 4624, which is itself diagnostic. Where a new session is created, `LogonType 9` (NewCredentials, the runas /netonly path), the `ElevatedToken` field, `ImpersonationLevel`, and `LinkedLogonId` distinguish an elevated or impersonated context. 4648 records explicit-credential use that does not match an interactive admin.
- **Event ID 4703, a user right was adjusted** (Audit Token Right Adjusted subcategory). This fires on `AdjustTokenPrivileges` and is noisy, so use it as hunt corroboration rather than a standalone alert.
- **Event ID 4765 and 4766 on domain controllers, SID History was added / failed to be added to an account.** Any 4765 outside a planned migration is the T1134.005 trust-boundary signal; pair with 4662 for the directory writes that back it.
- **Sysmon.** **Event ID 1, ProcessCreate** carries `IntegrityLevel`, `User`, `LogonId`, `ParentImage`, `ParentUser`, and `OriginalFileName`. The core signal is a mismatch between a child's `User`/`LogonId`/`IntegrityLevel` and its parent's, or an integrity jump through an implausible parent. **Event ID 10, ProcessAccess** catches handle opens to `lsass.exe` tied to token theft via `GrantedAccess` and `CallTrace`; note that many default Sysmon configs filter `PROCESS_QUERY_LIMITED_INFORMATION`, so confirm your config does not suppress the access masks you need. **Event ID 13, RegistryValueSet** catches the UAC-bypass handler writes under `HKCU\Software\Classes` (`ms-settings\shell\open\command`, `mscfile\shell\open\command`, `Folder\shell\open\command`, `exefile\shell\runas\command`, and the `DelegateExecute` value that several bypasses clear).

What normal looks like: 4688 Target Subject fields empty for the vast majority of process creations; sensitive privileges in 4672 confined to a known account list; child process tokens and integrity matching their parents; elevation preceded by `consent.exe`; and SID-History static. Deviation from each of those baselines is the alertable condition.

## Detection approach

Alert on the boundary transition, not on any single binary name, and lead with the highest-precision native signal.

**Cross-token process creation (highest precision).** Alert on any 4688 whose Target Subject fields (`TargetUserSid`, `TargetLogonId`) are populated and differ from the Subject fields, excluding the handful of legitimate launchers in your environment that intentionally start processes under another token (scheduled-task and service infrastructure, some RMM tooling). This is the most direct native indicator of create-process-with-token and needs little tuning once the known launchers are baselined.

**Token and integrity mismatch in lineage.** Correlate Sysmon Event ID 1 where a child's `User` or `LogonId` differs from its parent's, or where a medium-integrity parent produces a high- or SYSTEM-integrity child outside the `consent.exe` elevation path. Treat a service account (for example a web or database host) spawning an interactive shell under SYSTEM integrity as high priority.

**UAC bypass (keep it narrow).** Alert on a Sysmon Event ID 13 write to one of the HKCU Classes handler keys above immediately followed by an auto-elevating binary spawning a high-integrity child with no `consent.exe` between them. This is the detection the sibling `detect-windows-privesc` skill covers in depth; here it is one layer among the boundary signals.

**SID-History injection.** Alert on every 4765 on a domain controller and reconcile it against your migration change record; outside a migration, treat it as a trust-boundary compromise.

There is no tuned UMBRASEC rule for any of these yet. For public, maintained starting points, the SigmaHQ repository ships Windows rules you can tune against your baseline: process-creation rules under [rules/windows/process_creation](https://github.com/SigmaHQ/sigma/tree/master/rules/windows/process_creation), registry-set rules covering the UAC auto-elevate handlers under [rules/windows/registry/registry_set](https://github.com/SigmaHQ/sigma/tree/master/rules/windows/registry/registry_set), process-access rules for lsass handle abuse under [rules/windows/process_access](https://github.com/SigmaHQ/sigma/tree/master/rules/windows/process_access), and Security-log builtin rules under [rules/windows/builtin/security](https://github.com/SigmaHQ/sigma/tree/master/rules/windows/builtin). The authoritative configuration references are Microsoft Learn's audit-policy pages for [Audit Process Creation](https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4688), [Audit Sensitive Privilege Use](https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-sensitive-privilege-use), and [Audit Token Right Adjusted](https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-token-right-adjusted), and the [User Account Control security policy settings](https://learn.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-security-policy-settings).

## Threat hunt

For the quiet attacker who impersonates one token or injects one SID and waits, the per-event alerts may not fire. Hunt instead:

1. Over a long window, pull every 4688 with populated Target Subject fields, project `SubjectUserName`, `TargetUserName`, `TargetLogonId`, `NewProcessName`, and `TokenElevationType`, and build the real set of launchers that start processes under another token. Anything outside that known set is a finding; rank by the privilege of the target token.
2. Enumerate which principals actually hold `SeImpersonatePrivilege`, `SeAssignPrimaryTokenPrivilege`, `SeDebugPrivilege`, `SeTcbPrivilege`, and `SeCreateTokenPrivilege` across your fleet (local security policy / `whoami /priv` collection or your config-management inventory), and grade the list against need. An over-granted privilege is the precondition that makes token manipulation cheap, so treat each unexpected holder as a finding in its own right.
3. Join Sysmon Event ID 1 parent-child pairs and flag every case where `IntegrityLevel`, `User`, or `LogonId` steps up from parent to child without passing through `consent.exe`. Rank by how implausible the parent-to-child relationship is.
4. List every account carrying SID-History and reconcile against migration records; a privileged SID (Domain Admins, Enterprise Admins, or a high-RID built-in) in the SID-History of an account that was never migrated is a trust-boundary finding.
5. Correlate: an over-privileged service account (step 2) that spawned a cross-token or integrity-jumping child (steps 1 and 3) is a full local boundary crossing; a privileged SID-History entry (step 4) is a cross-domain one. Close those chains first.

Both 4688 Creator Process and Sysmon ParentImage report the *claimed* parent, so a hunt built on lineage alone can be defeated by parent-PID spoofing (step 3 assumes an honest parent); corroborate with token and privilege evidence from steps 1 and 2 rather than trusting lineage by itself.

## Hardening

Shrink each boundary so that crossing it buys the attacker little. Mappings below use control codes grounded in the UMBRASEC guide ([foundation.html](https://umbrasec.dev/guide/foundation.html), [identity-and-access.html](https://umbrasec.dev/guide/identity-and-access.html)); a cell is left blank where no single control maps cleanly.

| Control | What it does | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 |
|---|---|---|---|---|
| Strip sensitive privilege rights and tier admin access | Remove `SeImpersonatePrivilege`, `SeDebugPrivilege`, `SeAssignPrimaryTokenPrivilege`, and `SeTcbPrivilege` from accounts that do not need them, and separate admin tiers so a crossed token reaches little | Restrict administrative privileges (ML2+) | A.8.2 Privileged access rights | PR.AA-05 Least privilege |
| Set UAC to Always notify and keep `LocalAccountTokenFilterPolicy` default | Preserve the medium-to-high consent boundary and the admin-approval-mode split token; do not disable remote UAC filtering | Restrict administrative privileges (ML2+) | A.8.2 Privileged access rights | PR.AA-05 Least privilege |
| Application control (WDAC / AppLocker) | Block the auto-elevating LOLBins and unapproved token or bypass tooling from running at all | Application control | A.8.19 Software on systems | PR.PS Platform Security |
| Patch the OS and kernel boundary | Close local-privesc and token-abuse bugs and vulnerable drivers; on 24H2, enable Administrator Protection where supported | Patch applications; Patch operating systems | A.8.8 Technical vulnerabilities | ID.RA; PR.PS Platform Security |
| Protect lsass with RunAsPPL, Credential Guard, and VBS | Isolate secrets in VTL1 so a stolen or impersonated token finds no further credentials to loot | - | A.5.17 Authentication information | PR.AA-01 Identities and credentials |
| SID filtering on domain and forest trusts | Discard foreign SID-History and privileged SIDs crossing a trust, closing the cross-domain boundary | - | A.5.15 Access control | PR.AA-05 Least privilege |

## Honest limitations

Pure in-process token impersonation (DuplicateTokenEx then ImpersonateLoggedOnUser, with no new process) generates no new-logon event and may leave no distinctive native event at all, so it can be invisible to the Security log and visible only through the downstream action the impersonated context performs. Parent-PID spoofing defeats any detection that trusts lineage: both 4688 Creator Process and Sysmon ParentImage report the spoofed parent, and only the Microsoft-Windows-Kernel-Process ETW provider (comparing the event-header PID against the payload parent) or an EDR with kernel process-creation callbacks sees the real creator. The cross-token 4688 signal depends on Target Subject auditing being present and on the attacker using CreateProcessWithTokenW or CreateProcessAsUser rather than pure impersonation. 4703 is too noisy to alert on alone. SID filtering has legitimate-migration exceptions that must be managed, not blanket-disabled. Layer the native, lineage, and privilege-inventory signals, and lean on hardening (least privilege, lsass protection, UAC consent) so that a boundary crossed quietly still yields little. Baseline every rule in your own environment before enforcing.

## ATT&CK and D3FEND

- MITRE ATT&CK: [T1134 Access Token Manipulation](https://attack.mitre.org/techniques/T1134/) with sub-techniques [.001 Token Impersonation/Theft](https://attack.mitre.org/techniques/T1134/001/), [.002 Create Process with Token](https://attack.mitre.org/techniques/T1134/002/), [.003 Make and Impersonate Token](https://attack.mitre.org/techniques/T1134/003/), [.004 Parent PID Spoofing](https://attack.mitre.org/techniques/T1134/004/), and [.005 SID-History Injection](https://attack.mitre.org/techniques/T1134/005/); [T1548.002 Abuse Elevation Control Mechanism: Bypass User Account Control](https://attack.mitre.org/techniques/T1548/002/).
- MITRE D3FEND (inferred countermeasure relationships for [T1134](https://d3fend.mitre.org/offensive-technique/attack/T1134/) and [T1548.002](https://d3fend.mitre.org/offensive-technique/attack/T1548.002/)): D3-PSA Process Spawn Analysis and D3-SCA System Call Analysis for the cross-token and integrity-jump detection; D3-EAL Executable Allowlisting for application control over the LOLBins; D3-HBPI Hardware-based Process Isolation for Credential Guard and VBS; D3-CH Credential Hardening for lsass protection; and D3-LFP Local File Permissions for the UAC handler and auto-elevate surface.
- Public rule sources: [SigmaHQ Windows rules](https://github.com/SigmaHQ/sigma/tree/master/rules/windows) (process_creation, registry/registry_set, process_access, builtin/security directories above).

**Scope note.** This is a defensive skill. It explains the trust-boundary and token techniques only to the depth needed to detect and harden against them, maps to public rule sources rather than shipping a bespoke rule, and provides no token-manipulation, impersonation, or UAC-bypass tooling. UMBRASEC publishes defense, not offense.