AN0421: Analytic 0421
Forged SAML tokens can appear as SaaS logins where authentication succeeded without MFA, or where tokens contain claims inconsistent with the user profile. Look for concurrent sessions across different geographies with the same SAML assertion ID.
Analyst context for executives and security teams
This analytic highlights a high-value identity risk: SaaS access that appears legitimate because it is backed by a SAML token, but the token may be forged or inconsistent with normal identity-provider behavior. For leaders, the practical issue is whether the organization can prove that SaaS logins were actually brokered through expected MFA and identity controls, rather than simply trusting the presence of a successful SAML authentication event.
Executive priority
Prioritize this as an identity and cloud/SaaS assurance question: can security teams validate MFA enforcement, SAML claim integrity, and abnormal concurrent access across geographies for critical SaaS applications? The business value is strongest for incident decision-making, audit evidence around access controls, and resilience of identity-dependent operations. If logs cannot connect SaaS sessions, SAML assertion details, user profile attributes, MFA status, and geography, executives may have limited evidence during a suspected account or federation compromise.
Technical view
For SOC, detection engineering, and IR teams, validate whether SaaS authentication logs expose successful logins without MFA, SAML assertion IDs, token claims, user profile attributes, session identifiers, source IP/geolocation, and timing. The supplied analytic specifically calls out forged SAML tokens appearing as SaaS logins with successful authentication but no MFA, claims inconsistent with the user profile, or concurrent sessions from different geographies using the same SAML assertion ID. Because ATT&CK does not provide a separate detection implementation here, teams should treat this as detection logic guidance that must be adapted to each SaaS provider and identity architecture.
Likely telemetry
- SaaS authentication and session logs
- MFA status or authentication method fields for SaaS logins
- SAML assertion identifiers where available
- SAML token claim fields or normalized identity attributes
- User profile and directory attributes used to validate claims
Detection direction
- Confirm whether successful SaaS logins without MFA are expected, exception-based, or anomalous for the application and user population.
- Correlate SaaS login events with identity provider events to identify SaaS sessions that lack a corresponding expected authentication flow.
- Compare SAML token claims against authoritative user profile or directory attributes to identify inconsistencies.
- Look for reuse of the same SAML assertion ID across concurrent sessions, especially from different geographies.
- Tune for legitimate travel, VPN egress, proxy infrastructure, mobile networks, and administrative exceptions to reduce false positives.
Mitigation priorities
- Ensure critical SaaS applications require MFA through the approved identity provider where policy supports it.
- Reduce or tightly govern MFA bypasses, federation exceptions, and legacy authentication paths for SaaS access.
- Improve identity and SaaS log retention so investigation teams can reconstruct SAML-backed sessions and MFA status.
- Maintain authoritative user profile data so claim mismatches can be evaluated reliably.
- Establish incident response playbooks for suspected federated identity abuse, including session revocation and review of affected SaaS access.
Analyst notes and limits
This object is a detection analytic for SaaS environments focused on suspicious SAML-backed logins. No ATT&CK tactic, related technique, mitigation relationship, or formal detection pseudocode was supplied, so the take is intentionally framed around validation and telemetry readiness rather than a specific rule.
The supplied ATT&CK fields do not identify a specific SaaS product, identity provider, adversary, tactic, or active exploitation context. Local log schemas, MFA policies, SAML claim availability, and geolocation reliability will determine whether this analytic can be implemented effectively.
Analytic 0421
Forged SAML tokens can appear as SaaS logins where authentication succeeded without MFA, or where tokens contain claims inconsistent with the user profile. Look for concurrent sessions across different geographies with the same SAML assertion ID.
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 | ae9633309444… |
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 AN0421Open 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.