DET0148: Detection Strategy for Forged SAML Tokens
DET0148 is a detection strategy for forged SAML tokens, mapped to ATT&CK technique T1606.002. The business significance is identity trust: if an adversary...
Analyst context for executives and security teams
DET0148 is a detection strategy for forged SAML tokens, mapped to ATT&CK technique T1606.002. The business significance is identity trust: if an adversary has a valid SAML token-signing certificate, they may create tokens with arbitrary permission claims and lifetimes, affecting access across supported related environments such as SaaS, IaaS, Office Suite, and Windows. For leaders, this is less about a single endpoint alert and more about whether the organization can prove its identity federation trust chain is monitored, auditable, and rapidly revocable during an incident.
Executive priority
Prioritize this as an identity and cloud-security resilience issue. Security leaders should ask whether token-signing certificates are inventoried, protected, monitored for misuse, and covered by incident response playbooks. Because the supplied ATT&CK object has no official detection text, teams should not assume coverage from generic authentication logging alone; they should validate whether federation, cloud, and SaaS audit evidence can support investigation of suspicious SAML token claims, unusual token lifetimes, and certificate-trust changes.
Technical view
The related ATT&CK technique is SAML Tokens under credential access. Detection validation should focus on identity-provider and relying-party evidence that can show abnormal SAML assertion properties, unexpected claims, unusual validity periods such as altered NotOnOrAfter values, and activity associated with SAML token-signing certificates. SOC and IR teams should test whether logs from identity federation, SaaS, IaaS, Office Suite, and relevant Windows components are retained and correlated well enough to reconstruct authentication events and certificate trust changes. Because the detection strategy object itself does not provide official detection logic, local baselining and environment-specific federation architecture are required.
Likely telemetry
- Identity provider authentication and federation logs
- SAML assertion or token validation audit records where available
- Token-signing certificate inventory, configuration, and change logs
- SaaS, IaaS, and Office Suite sign-in and audit logs
- Windows authentication or federation-related event logs where applicable
Detection direction
- Validate whether the SOC can observe SAML token attributes relevant to forged-token abuse, especially permission claims and token validity periods.
- Correlate sign-in activity with federation trust configuration and token-signing certificate changes rather than treating cloud logins in isolation.
- Baseline normal token lifetimes and claims for high-value applications; investigate deviations that cannot be explained by approved policy.
- Review false-positive sources such as legitimate token lifetime policy changes, certificate rollover, federation migration, and administrative maintenance.
- Confirm retention and searchability across identity provider, SaaS, IaaS, Office Suite, and Windows-related telemetry because the related technique spans those platforms.
Mitigation priorities
- Inventory SAML federation relationships and token-signing certificates, including ownership, rotation process, and emergency revocation path.
- Restrict and monitor administrative access to federation configuration, certificate material, and token lifetime policy settings.
- Ensure certificate rollover, trust changes, and token policy changes generate auditable events reviewed by security operations.
- Prepare incident response procedures for suspected token-signing certificate compromise, including trust revocation, certificate replacement, session review, and downstream application coordination.
- Use compliance and audit programs to require evidence of federation configuration monitoring, certificate governance, and authentication log retention.
Analyst notes and limits
This take is based on the supplied DET0148 detection strategy metadata and its relationship to ATT&CK T1606.002 SAML Tokens. The source object has no official description, platforms, tactics, or detection text, so the practical guidance is derived conservatively from the related technique description and related platform context.
No claim is made that this detection strategy has complete coverage or that any specific product can detect forged SAML tokens. The supplied fields do not include analytic logic, data source mappings, mitigations, or procedure examples. Organizations must validate feasibility against their own identity provider, federation architecture, logging depth, and retention.
Detection Strategy for Forged SAML Tokens
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1606.002 | SAML Tokens Sub-technique | This object detects SAML Tokens. |
All related ATT&CK context
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 | a5ccf5a23180… |
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 DET0148Open 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.