AN0956: Analytic 0956
Token replay or impersonation in federated logins without interactive browser session or MFA prompts.
Analyst context for executives and security teams
This analytic points to a high-value identity risk: federated login tokens being replayed or used to impersonate a user without the normal signs of an interactive browser session or MFA challenge. For leaders, the practical issue is not just “detecting a login,” but proving that identity-provider telemetry can distinguish expected federated authentication from suspicious token use that may bypass normal user-facing controls.
Executive priority
Prioritize this as an identity and access management validation item. Federated identity is often a control point for business applications, cloud access, and compliance evidence; if token replay or impersonation is not visible, incident responders may struggle to determine whether access was legitimate. Security leaders should ask whether identity-provider logs capture enough session, token, MFA, and authentication-context detail to support investigations and audit defensibility.
Technical view
The supplied object is a detection analytic for the Identity Provider platform. SOC and detection teams should validate whether federated login events can be correlated with interactive browser activity, MFA prompts, authentication method details, session context, device or client indicators, and token/session reuse patterns. Because no official detection logic or ATT&CK tactic mapping is supplied, teams should avoid treating this as a ready-to-run rule and instead use it as a coverage requirement for identity telemetry and investigation workflows.
Likely telemetry
- Identity provider authentication logs
- Federated login and token/session issuance events
- MFA challenge, prompt, and satisfaction records
- Session context such as client type, user agent, device, source network, and authentication method where available
- Application sign-in records tied to federated identity assertions
Detection direction
- Validate that detections can identify federated logins occurring without expected interactive browser session evidence or MFA prompt evidence.
- Tune carefully for legitimate non-interactive or service-driven authentication patterns to reduce false positives.
- Correlate identity-provider events with application sign-ins and session activity to distinguish normal federation flows from suspicious token reuse or impersonation indicators.
- Confirm retention and field completeness before relying on this analytic for incident response or compliance evidence.
- Document known blind spots where the identity provider does not expose token, session, MFA, or client-context details.
Mitigation priorities
- Strengthen identity-provider logging and retention for federated authentication, MFA, and session events.
- Review federation and conditional access policies to ensure MFA and session controls are applied where business risk requires them.
- Establish incident response procedures for suspected token replay or impersonation, including session revocation and user/account review.
- Baseline legitimate federated and non-interactive authentication behavior before enforcing high-severity alerting.
- Use the analytic as a control-validation prompt rather than assuming detection coverage exists.
Analyst notes and limits
This object is an ATT&CK detection analytic, not a technique, and no relationship context is supplied. The most useful defensive interpretation is coverage validation for identity-provider telemetry around federated login token replay or impersonation, especially where expected browser and MFA evidence is absent.
Official detection logic, tactics, relationships, and implementation details are not provided. Local identity-provider capabilities, logging fields, federation architecture, and legitimate non-interactive authentication patterns are required to design or validate a reliable detection.
Analytic 0956
Token replay or impersonation in federated logins without interactive browser session or MFA prompts.
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 | f475e227ee3f… |
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 AN0956Open 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.