AN1253: Analytic 1253
A process (often after stealing/creating a token) calls CreateProcessWithTokenW/CreateProcessAsUserW or uses runas to spawn a **new** process whose security context (SID/LogonId/IntegrityLevel) differs from its parent. Chain: (1) suspicious command/API → (2) privileged handle or token duplication/open → (3) new child process running as another user / higher integrity → (4) optional follow‑on privileged/lateral actions.
Analyst context for executives and security teams
This analytic is about spotting Windows processes that are launched under a different security context than their parent, such as a different user SID, LogonId, or higher integrity level. For leaders, the value is in validating whether the SOC can see potential identity-context changes that may indicate privilege use, token misuse, or suspicious administrative process creation before follow-on privileged or lateral activity occurs.
Executive priority
Prioritize this as an identity and Windows endpoint visibility question: can the organization prove who started a process, under what logon context, and whether that context changed unexpectedly? This matters for incident response scoping, privileged access governance, audit evidence, and determining whether high-risk Windows activity is legitimate administration or requires investigation. Because ATT&CK provides no official detection logic or relationships here, use it as a validation target rather than as evidence of a specific threat campaign or control gap.
Technical view
For Windows environments, validate telemetry that links parent and child processes with user SID, LogonId, integrity level, command line, and process creation method where available. The supplied analytic describes a chain involving suspicious command or API usage, privileged handle or token duplication/open activity, and creation of a new child process as another user or at higher integrity. SOC and IR teams should focus on parent/child context mismatches, use of CreateProcessWithTokenW/CreateProcessAsUserW or runas where observable, and follow-on privileged or lateral actions. No ATT&CK tactics or relationship mappings were supplied, so detection engineering should avoid over-scoping this beyond the described Windows process-security-context behavior.
Likely telemetry
- Windows process creation events with parent/child process relationships
- User identity fields including SID and LogonId
- Process integrity level or equivalent privilege context
- Command-line telemetry for process starts, including runas where captured
- API or endpoint detection telemetry for CreateProcessWithTokenW/CreateProcessAsUserW where available
Detection direction
- Compare parent and child process security context, especially changes in SID, LogonId, or integrity level.
- Tune for legitimate administrative workflows that intentionally use runas or service/account transitions to reduce false positives.
- Correlate suspicious process creation with token or privileged handle activity when endpoint telemetry supports it.
- Treat context-changing process creation as higher priority when followed by privileged actions or remote activity, but do not assume maliciousness from the context change alone.
- Validate whether existing EDR, Windows logging, and SIEM normalization preserve the fields needed to compare parent and child security context.
Mitigation priorities
- First, confirm logging and endpoint telemetry coverage on Windows systems for process creation, identity context, and parent/child relationships.
- Second, review privileged access practices that rely on runas or alternate-user process creation so expected patterns can be baselined.
- Third, ensure incident responders can quickly determine whether a process context change was authorized administrative activity or suspicious behavior.
- Fourth, strengthen governance around privileged accounts and token-sensitive workflows, using local evidence rather than assuming this analytic alone proves compromise.
Analyst notes and limits
The object is a detection analytic, AN1253, for Windows. It describes behavior involving creation of a new process under a different security context from its parent, potentially after token-related activity. No official detection text, tactics, labels, aliases, or relationship context were supplied, so this take focuses on defensive validation and telemetry requirements rather than a specific ATT&CK technique chain.
This assessment is limited to the supplied ATT&CK STIX fields, external reference, and absence of relationships. It does not establish active exploitation, attribution, business impact, customer exposure, or guaranteed detectability. Local Windows logging configuration, EDR capability, SIEM field normalization, and administrative baselines are required to determine actual coverage and risk.
Analytic 1253
A process (often after stealing/creating a token) calls CreateProcessWithTokenW/CreateProcessAsUserW or uses runas to spawn a **new** process whose security context (SID/LogonId/IntegrityLevel) differs from its parent. Chain: (1) suspicious command/API → (2) privileged handle or token duplication/open → (3) new child process running as another user / higher integrity → (4) optional follow‑on privileged/lateral actions.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 1b89850af4af… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1253Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.