AN0718: Analytic 0718
Forged web credentials may manifest as anomalous SAML token issuance, OpenID Connect token minting, or Zimbra pre-auth key usage. Defenders may see tokens issued without normal authentication events, multiple valid tokens generated simultaneously, or signing anomalies in IdP logs.
Analyst context for executives and security teams
This analytic matters because forged web credentials can let an attacker appear as a legitimate user without the normal sign-in trail executives and responders expect to rely on. In practical terms, the key business question is whether the identity provider can prove that issued SAML, OpenID Connect, or Zimbra pre-auth credentials were backed by expected authentication activity and valid signing behavior.
Executive priority
Prioritize this as an identity assurance and incident response readiness issue. If tokens can be issued or accepted without clear authentication evidence, investigations, audit evidence, and access revocation decisions become harder. Security leaders should ask whether IdP token issuance, authentication events, and signing-related logs are retained, correlated, and reviewable during an incident.
Technical view
For SOC, detection engineering, and IR teams, validate visibility in Identity Provider telemetry for anomalous SAML token issuance, OpenID Connect token minting, Zimbra pre-auth key usage, tokens issued without corresponding normal authentication events, multiple valid tokens generated at the same time, and signing anomalies in IdP logs. Because ATT&CK provides no separate detection logic for this analytic, teams should treat the official description as the validation scope rather than a complete rule.
Likely telemetry
- Identity Provider authentication logs
- SAML token issuance records
- OpenID Connect token minting or issuance records
- Zimbra pre-auth key usage logs where applicable
- Token signing and certificate-related IdP logs
Detection direction
- Correlate token issuance with expected authentication events and flag tokens without a normal preceding authentication trail.
- Review for multiple valid tokens generated simultaneously or in unusual patterns for the same identity or application.
- Monitor IdP signing anomalies using available signing, certificate, and token validation logs.
- Tune carefully for legitimate federation, refresh, service-account, or automation behavior that may create token activity without an interactive login.
- Confirm whether Zimbra pre-auth logging is relevant before building coverage, since the supplied platform is Identity Provider but Zimbra applicability depends on the local environment.
Mitigation priorities
- Establish reliable collection and retention of IdP authentication, token issuance, and signing-related logs.
- Ensure incident response playbooks include token/session review and revocation decisions, not only password resets.
- Validate federation and token signing configurations through identity and access management governance processes.
- Use compliance and audit readiness efforts to prove that token issuance can be traced to expected authentication evidence.
- Prioritize remediation of visibility gaps before relying on detections for forged credential behavior.
Analyst notes and limits
This object is a detection analytic for the enterprise ATT&CK domain with platform scope limited to Identity Provider. It describes observable signs of forged web credentials but does not include an official detection query, tactic mapping, relationships, or related techniques in the supplied data.
No relationship context, tactic, vendor-specific telemetry, or official detection logic was supplied. Local IdP architecture, federation design, logging depth, and token lifecycle behavior are required to turn this into a precise detection or response procedure.
Analytic 0718
Forged web credentials may manifest as anomalous SAML token issuance, OpenID Connect token minting, or Zimbra pre-auth key usage. Defenders may see tokens issued without normal authentication events, multiple valid tokens generated simultaneously, or signing anomalies in IdP logs.
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 | df007ce0599e… |
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 AN0718Open 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.