ADFS hijacking is the theft or abuse of an Active Directory Federation Services trust to impersonate users and issue fraudulent sign-in tokens. Attackers compromise federation configuration, signing keys, or token issuance paths, then mint valid claims that bypass normal authentication controls and can extend access across connected cloud and on-premises systems.
What ADFS Hijacking Means in Practice
ADFS hijacking is not just account theft. It is abuse of the federation trust itself, which means the attacker can impersonate users by issuing tokens that other systems are willing to accept as legitimate.
Because the trust boundary sits between identity providers and relying applications, compromise here can outlive a single password reset or session invalidation. The attacker is no longer trying to break each application individually, but to exploit the federation layer that those applications rely on for sign-in assurance.
How Federation Trust Gets Abused
The most dangerous part of ADFS hijacking is that the adversary targets the components that define who can mint tokens, how those tokens are signed, and which claims are accepted downstream. Once those controls are altered or stolen, the attacker can generate sign-in artifacts that appear structurally valid to connected services.
This makes ADFS hijacking especially effective in hybrid environments. A single compromised federation path can bridge on-premises identity infrastructure and cloud applications, turning a local identity breach into broad authentication abuse across multiple trust domains.
Why It Is Hard to Spot
Federation abuse often blends into normal sign-in activity because the resulting tokens can look legitimate to the applications that receive them. The security problem is not only theft of access, but the attacker’s ability to operate through an approved trust relationship instead of repeatedly bypassing controls one application at a time.
That is why exposure assessment has to go beyond endpoint compromise. Organisations need to understand where federation services are deployed, which applications depend on them, and whether token-signing material, configuration stores, or administrative paths can be reached from exposed management surfaces or compromised privileged accounts.
What Good Defenders Focus On
Defence against ADFS hijacking depends on protecting federation configuration, signing material, and the administrative pathways that can alter token issuance. It also requires validating the trust chain around relying parties, because downstream access may remain available even after the original intrusion point is removed.
Recovery should include review of token issuance logs, federation configuration changes, and any authentication events that may have used fraudulent claims. If compromise is confirmed, organisations should treat the event as an identity trust incident, not just a server compromise, and review whether sessions, secrets, or privileged credentials tied to the federation path need rotation.
Risk and Threat Considerations
ADFS hijacking is high impact because it converts a compromise of federation infrastructure into trusted token issuance. That can let an attacker bypass normal authentication, impersonate users at scale, and maintain access even when individual accounts are remediated.
Failure mechanism: The attacker steals or alters federation trust material, then signs or issues tokens that downstream services accept because they trust the federation authority rather than the original login event.
Impact: The result can be broad unauthorized access across connected cloud and on-premises systems, with persistence that is harder to detect than ordinary password abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Federation token issuance and trust between services maps to service-to-service authentication assurance. |
| IA-5 — Authenticator Management | ADFS hijacking often depends on theft or abuse of signing material and token issuance credentials. | |
| AU-2 — Event Logging | Detecting ADFS hijacking depends on logging token issuance, trust changes, and administrative actions. | |
| Recommendation — Apply IA-9 to verify and constrain federation trust paths that issue tokens to connected services. Protect, rotate, and revoke federation signing material under IA-5 when compromise is suspected. Log federation configuration changes and token issuance events so abuse can be investigated quickly. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Federation abuse shows why downstream access should not rely on tokens alone as proof of trust. |
| Recommendation — Require continuous verification for access decisions instead of trusting federation tokens by default. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Token-signing material and federation secrets are credential-like assets attackers steal to hijack ADFS trust. |
| T1550 — Use Alternative Authentication Material | Forged federation tokens let attackers authenticate with alternate material instead of the original login flow. | |
| T1134 — Access Token Manipulation | ADFS hijacking culminates in the creation or abuse of token material that grants trusted access. | |
| Recommendation — Hunt for theft and misuse of federation secrets as part of credential-access detection. Map suspicious token use to alternate-authentication abuse and review downstream sign-ins. Investigate anomalous token creation or reuse as a sign of access-token manipulation. | ||
| CIS Controls v8 | CIS-5 — Account Management | Federation trust abuse often turns privileged identity and access paths into broad account takeover. |
| Recommendation — Limit and review administrative access paths that can change federation trust or signing configuration. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Federation token abuse is conceptually aligned with assurance failures in token-based sign-in flows. |
| V7 — Session Management | Forged federation tokens can sustain sessions that should have been invalidated after compromise. | |
| Recommendation — Validate token trust assumptions and issuer controls in federated sign-in implementations. Invalidate and reissue sessions after federation compromise is suspected. | ||
Practitioner Guidance
What to watch for: Treat unexplained federation configuration changes, unexpected token-signing activity, and anomalous claims issuance as high-priority signals. These are often more meaningful than a single suspicious login because the abuse path is the trust fabric itself.
Governance implication: Federation services need explicit ownership, tighter administrative control, and post-incident review processes that assume compromise may have affected more than one system. In practice, recovery should verify both the federation layer and every relying application that accepts its tokens.