AN1351: Analytic 1351
A process explicitly forges its parent using EXTENDED_STARTUPINFO + PROC_THREAD_ATTRIBUTE_PARENT_PROCESS (UpdateProcThreadAttribute → CreateProcess[A/W]/CreateProcessAsUserW) or other Native API paths, resulting in **mismatched/implausible lineage** across ETW EventHeader ProcessId, Security 4688 Creator Process ID/Name, and sysmon ParentProcessGuid. Often paired with privilege escalation when the chosen parent runs as SYSTEM.
Analyst context for executives and security teams
This analytic focuses on Windows processes that appear to lie about their parent process. For leaders, the practical issue is trust in process lineage: many SOC triage decisions, incident timelines, and compliance evidence depend on knowing what launched what. If an attacker or unauthorized tool can make a process look like it came from a trusted SYSTEM-level parent, weak lineage validation can delay containment and make investigations less reliable.
Executive priority
Prioritize this where Windows endpoint visibility is a key control for ransomware readiness, privilege-escalation investigation, or audit evidence. Ask whether the organization can independently reconcile process creation records across Windows Security events, ETW, and endpoint tooling rather than relying on a single parent-process field. The business value is faster incident decision-making and fewer blind spots in investigations involving suspicious privilege context or implausible process ancestry.
Technical view
Validate detection logic for Windows process parent spoofing where a process uses extended startup attributes or native API paths that result in mismatched lineage. The supplied description highlights inconsistencies among ETW EventHeader ProcessId, Security 4688 Creator Process ID/Name, and Sysmon ParentProcessGuid. SOC and detection teams should test whether their data pipeline preserves these fields, correlates process GUIDs and PIDs correctly over time, and flags implausible parent-child relationships, especially when the apparent parent runs as SYSTEM. No ATT&CK tactic or relationship context was supplied, so detections should be treated as behavior-oriented enrichment rather than mapped to a specific campaign or objective.
Likely telemetry
- Windows process creation events, including Security Event ID 4688 where enabled
- ETW process event data containing EventHeader ProcessId context
- Sysmon process creation data, especially ParentProcessGuid and related parent-process fields
- Endpoint detection and response process lineage graphs, if they retain raw parent and creator identifiers
- Privilege context for parent and child processes, including whether the apparent parent is running as SYSTEM
Detection direction
- Correlate multiple process-lineage sources instead of trusting a single parent-process field.
- Look for mismatches or implausible lineage between ETW process identifiers, Security 4688 Creator Process ID/Name, and Sysmon ParentProcessGuid.
- Tune for legitimate software that may create processes through unusual launch mechanisms to avoid excessive false positives.
- Pay special attention to cases where a lower-trust process appears to choose a SYSTEM process as parent, because the official description notes this behavior is often paired with privilege escalation.
- Validate PID reuse handling and timestamp ordering, since incorrect correlation can create false lineage mismatches.
Mitigation priorities
- Ensure Windows process creation auditing and endpoint telemetry needed for lineage reconciliation are enabled and retained.
- Standardize collection of Security 4688, ETW-derived process data, and Sysmon or equivalent endpoint process GUID telemetry where operationally appropriate.
- Harden privileged process and administrative execution paths so suspicious parentage involving SYSTEM context receives priority review.
- Use incident response playbooks that require analysts to verify process ancestry across multiple evidence sources before closing privilege-related alerts.
- Document telemetry coverage and known gaps for compliance and investigation readiness.
Analyst notes and limits
This object is a detection analytic, not a technique entry. The supplied ATT&CK fields identify Windows as the platform and describe forged parent-process lineage using extended startup information, parent-process attributes, CreateProcess variants, CreateProcessAsUserW, or other Native API paths. Because no relationships, tactics, or official detection text were supplied, the take is framed around defensive validation and telemetry requirements rather than threat attribution or campaign behavior.
No official detection content, ATT&CK tactic, related technique, adversary relationship, or mitigation relationship was provided. Local environment baselines are required to distinguish malicious or unauthorized parent spoofing from legitimate software behavior. This summary does not assert active exploitation, customer exposure, or guaranteed detection coverage.
Analytic 1351
A process explicitly forges its parent using EXTENDED_STARTUPINFO + PROC_THREAD_ATTRIBUTE_PARENT_PROCESS (UpdateProcThreadAttribute → CreateProcess[A/W]/CreateProcessAsUserW) or other Native API paths, resulting in **mismatched/implausible lineage** across ETW EventHeader ProcessId, Security 4688 Creator Process ID/Name, and sysmon ParentProcessGuid. Often paired with privilege escalation when the chosen parent runs as SYSTEM.
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 | 043494c0cb9b… |
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 AN1351Open 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.