Forge Web Credentials
Forged web credentials exploit a trust relationship used to create accepted authentication material.
What it means
Forged web credentials exploit a trust relationship used to create accepted authentication material. Compromise of signing or assertion authority can affect more than one user.
MITRE ATT&CK catalogs this behavior as T1606, within credential access. The technique describes a behavior; assigning the label does not by itself prove an actor identity or successful compromise.
An investigation example
A service accepts unusual credentials after evidence of compromise involving an authentication signing relationship.
Evidence to examine
Review issuer trust, signing key exposure, accepted claims, sessions, and the resources accessed through those credentials.
A common analytical pitfall
A valid signature is not proof of authorized issuance if the signing authority was compromised.
Response considerations
Recover trusted issuance and verification, protect relevant keys, and investigate sessions accepted under the affected trust relationship.
A credential can be accepted under a broken trust assumption
A fictional application accepts a session token that appears structurally correct and passes a configured verification step. If the verification key is compromised or the validation process is flawed, an attacker may create a credential the service accepts without a legitimate issuance event. This differs from merely stealing and replaying an existing user's token.
Investigators should compare acceptance with issuance records where available. A valid-looking token without a corresponding expected issuance can be a useful clue, but missing logs or retention gaps are alternative explanations. Correlate key access, configuration changes, and the resulting application activity before concluding forgery.
The specific credential format matters. Cookies, signed tokens, and federated assertions have different validation contracts. The receiver must consume the intended verified content and enforce issuer, recipient, timing, and purpose rules as applicable. A signature check is only one part of that contract.
Review the issuer-to-receiver relationship
For a classroom exercise, draw a fictional issuer, its signing capability, and two receiving applications. Identify who may issue credentials, which keys each receiver trusts, and how a key rollover changes acceptance. Explain why an unexpected key or a credential intended for another receiver should be rejected.
Containment can require changing trust configuration and rotating affected signing material, not only resetting one user's password. Coordinate the transition because legitimate credentials may also stop working. A useful report states the evidence for unauthorized issuance or acceptance, the affected trust scope, and the recovery actions needed to restore it. Avoid assuming a syntactically correct token is genuine or that all anomalous sessions imply cryptographic forgery.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
MITRE ATT&CK T1606: Forge Web Credentials