AN1375: Analytic 1375
A process creates a brand‑new logon session/token (LogonUser*/LsaLogonUser) and then assigns/impersonates it (SetThreadToken/ImpersonateLoggedOnUser) to run actions under that freshly created security context. Chain: (1) suspicious command or script block (e.g., runas /netonly, PowerShell P/Invoke of LogonUser) → (2) ETW/API evidence of LogonUser*/SetThreadToken → (3) Security 4624 New Logon (often LogonType=9 NewCredentials or 2/3 from a non‑interactive parent) with no interactive desktop → (4) sysmon 1 process(es) executing with the new LogonId/SID different from the parent process → (5) optional privileged ops/lateral movement.
Analyst context for executives and security teams
This analytic matters because it focuses on a Windows behavior where a process creates a new logon session or token and then impersonates it to perform actions under a different security context. For leaders, the practical issue is not the API call alone; it is whether the organization can prove when identities are being used in unusual, non-interactive ways that may bypass normal user activity assumptions.
Executive priority
Prioritize this as an identity and Windows monitoring validation item. It can affect incident scoping, privileged access oversight, and audit confidence because the same host may show activity under a newly created LogonId or SID that differs from the parent process. Security leaders should ask whether SOC and IR teams can correlate command/script activity, Windows logon events, API/ETW evidence, and process execution into one timeline.
Technical view
For Windows environments, validate whether detections can correlate the chain described by MITRE: suspicious command or script activity such as runas /netonly or PowerShell use of LogonUser, ETW/API evidence of LogonUser*/LsaLogonUser followed by SetThreadToken or ImpersonateLoggedOnUser, Security Event 4624 new logons such as LogonType 9 NewCredentials or non-interactive type 2/3 patterns, and Sysmon process creation where child activity runs with a new LogonId or SID different from the parent. No ATT&CK tactic mapping or relationship context was supplied, so this should be treated as a behavior-focused detection analytic rather than a full intrusion scenario.
Likely telemetry
- Windows Security Event 4624 New Logon records, including LogonType, LogonId, SID, account, host, and parent context where available
- Sysmon Event ID 1 or equivalent process creation telemetry with parent process, command line, user, SID, and LogonId
- PowerShell script block or command-line telemetry where enabled
- ETW or API-level telemetry for LogonUser*, LsaLogonUser, SetThreadToken, and ImpersonateLoggedOnUser where available
- Process lineage and session context data sufficient to compare parent and child security context
Detection direction
- Validate correlation across command/script execution, API or ETW evidence, Windows logon events, and subsequent process execution rather than alerting on a single event in isolation.
- Tune for non-interactive or unusual parent processes creating new logon sessions, especially LogonType 9 NewCredentials or type 2/3 patterns without an expected interactive desktop context.
- Check whether process telemetry preserves LogonId and SID fields; without them, defenders may miss the parent-to-child identity context change described by the analytic.
- Review expected administrative workflows that legitimately use runas or alternate credentials to reduce false positives while preserving visibility into unusual parent processes and privileged follow-on activity.
- Use any optional privileged operations or lateral movement observed after the new token/session as context for triage, not as a required condition because the supplied analytic describes it as optional.
Mitigation priorities
- Ensure Windows security auditing and process creation logging are configured to retain logon session and identity context needed for investigation.
- Enable or validate PowerShell and command-line visibility where organizational policy permits.
- Assess whether ETW/API-level collection is available for sensitive logon and impersonation APIs in high-value Windows environments.
- Document legitimate administrative use of alternate credentials so SOC teams can distinguish expected operations from unusual identity context changes.
- Include this behavior in incident response playbooks for Windows identity misuse investigations, especially when scoping activity by account, SID, and LogonId.
Analyst notes and limits
This Glexia take is based only on the supplied MITRE detection analytic AN1375. The object provides a detailed behavioral chain but no official detection text, tactics, mitigations, procedures, groups, software, or relationship context. The highest-value defensive action is therefore telemetry validation and correlation testing in the local Windows environment.
The source does not provide confirmed adversary use, attribution, impact, prevalence, detection logic, or non-Windows platform applicability. Local baselining is required to separate legitimate administrative impersonation or alternate-credential workflows from suspicious activity.
Analytic 1375
A process creates a brand‑new logon session/token (LogonUser*/LsaLogonUser) and then assigns/impersonates it (SetThreadToken/ImpersonateLoggedOnUser) to run actions under that freshly created security context. Chain: (1) suspicious command or script block (e.g., runas /netonly, PowerShell P/Invoke of LogonUser) → (2) ETW/API evidence of LogonUser*/SetThreadToken → (3) Security 4624 New Logon (often LogonType=9 NewCredentials or 2/3 from a non‑interactive parent) with no interactive desktop → (4) sysmon 1 process(es) executing with the new LogonId/SID different from the parent process → (5) optional privileged ops/lateral movement.
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 | 4e385a2066e1… |
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 AN1375Open 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.