Identity weaknesses played a material role in nearly 90% of breach investigations Unit 42 worked in the past year, and 65% of initial access is now identity-driven rather than malware-driven. The pattern that turns a single foothold into a full enterprise compromise almost always runs through the same machinery: the federation layer connecting on-premises Active Directory to cloud identity providers. APT operators have learned that this seam — the trust relationship most defenders treat as plumbing — is where they can move from a phished helpdesk account to global admin without ever tripping a malware alert.
This piece walks through how the abuse actually works in 2026: the specific federation primitives that get attacked, the named techniques (Golden SAML, Silver SAML, seamless SSO drift, PTA agent compromise, OAuth consent grants), the recent campaigns showing each pattern in the wild, and the detection surface defenders need to instrument. The picture that emerges is unflattering: the attacks aren’t novel, the affected configurations are well-documented, and yet the same patterns keep landing.
Why Federation Is the Pivot of Choice
Federation lets an identity verified in one trust domain access resources in another without re-authenticating. The trust is mediated by signed tokens — SAML assertions, OAuth/OIDC bearer tokens — and a small set of cryptographic keys held by the identity provider. Compromise the keys, the agents, or the configuration that issues those tokens and you bypass passwords, MFA challenges enforced at the IdP, and most behavioral controls. The token looks legitimate because, cryptographically, it is.
In a typical Microsoft hybrid deployment, the surface includes Active Directory Federation Services (ADFS) for SAML/WS-Federation, Entra Connect (formerly Azure AD Connect) for directory synchronization, Pass-through Authentication (PTA) agents that forward authentication to on-prem domain controllers, and Seamless SSO for desktop-to-cloud handoff. AWS, Okta, Google Workspace, and Salesforce environments add their own federated trusts — frequently chained, so a SaaS app trusts Entra ID, which trusts ADFS, which trusts on-prem AD. Compromise the lowest link and the entire chain falls.
The architectural problem is trust inheritance: when an identity is trusted on-premises, that trust extends automatically into Entra ID, and from there into Microsoft 365, Azure, and any third-party SaaS configured for SSO. A single domain admin account, or a single ADFS server, becomes the implicit master key for everything downstream.
Golden SAML: The Technique That Won’t Die
The canonical federation pivot is Golden SAML, named by CyberArk’s Shaked Reiner in 2017 and used in the wild for the first time by APT29 during the SolarWinds/Solorigate campaign. The attack does not exploit a SAML protocol vulnerability. It abuses the protocol working exactly as designed.
The mechanics: SAML assertions are signed by a token-signing certificate held by the IdP — for ADFS, that’s an X.509 certificate whose private key lives on the federation server, encrypted by a Distributed Key Manager (DKM) key stored in Active Directory. An attacker with admin on the ADFS server runs ADFSDump to extract the encrypted PFX and pulls the DKM key from AD with domain admin rights. With both, they reconstruct the signing key and use ADFSpoof or shimit to mint a SAMLResponse for any user, with any group claims, valid for any duration. AWS specifically clamps validity to roughly five minutes from issue, but most other relying parties do not. Password resets and MFA on the impersonated user have no effect — neither happens during a forged-token authentication.
Detection is genuinely hard. In a forged flow, the relying party logs a successful SAML sign-in but the ADFS server logs no corresponding Event ID 1200 (“The Federation Service issued a valid token”) and the domain controller logs no matching Event ID 4769 Kerberos service ticket request. The Correlation ID that normally ties IdP and SP events together is absent on the IdP side. The pattern to hunt is therefore the inverse of activity: SP sign-ins without IdP issuance events. That requires central log aggregation across both sides — exactly the visibility gap most hybrid deployments have.
Silver SAML, PTA Agents, and Other Variants
Migrating off ADFS to cloud-only Entra ID closes the Golden SAML door but opens others.
Silver SAML, disclosed by Semperis researcher Eric Woodruff in early 2024, is the same family of attack against Entra ID itself. When organizations supply their own externally-generated SAML signing certificate to Entra ID rather than using Microsoft’s auto-generated one, the private key exists outside Entra. An attacker who steals it — from a key vault, a developer’s workstation, or a backed-up repository — can forge SAML responses for any application configured with that certificate, signed identically to legitimate Entra-issued tokens. The detection signal is changes to the PreferredTokenSigningKeyThumbprint attribute in Entra ID audit logs, correlated against Add service principal credential events.
PTA agent abuse is more direct. The Pass-through Authentication agent runs on-prem and proxies cloud authentication requests to an on-prem domain controller. Code injected into the PTA agent process — documented in tools like AADInternals — can intercept and validate any password the attacker chooses, effectively turning the agent into a backdoor that accepts a master key for every synced account.
Seamless SSO uses a shared computer-account secret (AZUREADSSOACC) between on-prem AD and Entra ID. Compromise of that secret allows silent Kerberos-style ticket forgery for any synced user, frequently bypassing MFA when conditional access policies treat seamless SSO as a trusted authentication method.
OAuth consent and rogue federated domain abuse is the cloud-side endgame. Once an attacker has Entra global admin via any of the above paths, they can add a new federated domain backed by an attacker-controlled IdP — an approach CrowdStrike’s IR team flagged as a recurring pattern in late 2023 and continuing through 2025. Or they grant an attacker-owned multi-tenant app the Mail.Read or full_access_as_app Graph permission, which survives password resets, MFA enforcement, and even certificate rotation on the original federation server.
The Storm-0558 intrusion against Microsoft Exchange Online in summer 2023 used a related but distinct technique: a stolen 2016 MSA consumer-key forged tokens that the Exchange validation logic incorrectly accepted for enterprise tenants. The Cyber Safety Review Board’s March 2024 report concluded the intrusion was “preventable and should never have occurred” and triggered Microsoft’s Secure Future Initiative. The lesson is the same as Golden SAML: when the trust anchor is a key, key compromise is checkmate.
Recent Campaign Patterns
Three 2025–2026 campaigns illustrate how this tradecraft is being applied now.
Midnight Blizzard (APT29) continued exploiting credentials and OAuth applications obtained from its November 2023 Microsoft corporate breach through 2024 and into 2025. CISA Emergency Directive 24-02, issued April 11, 2024, ordered federal civilian agencies to reset credentials and audit privileged Azure accounts after Microsoft confirmed exfiltrated email metadata included authentication secrets. The initial access vector was a password spray against a legacy non-production tenant lacking MFA — an unremarkable foothold that became a federation-wide problem because the compromised account had OAuth grants into production.
APT28 (Fancy Bear / UAC-0001), in a January 2026 campaign documented by Trellix and CERT-UA, weaponized CVE-2026-21509 within 24 hours of disclosure to deliver an Outlook VBA backdoor (NotDoor) and a modified Covenant implant. The campaign used legitimate cloud storage (filen.io) for C2 — a pattern that turns federation-trusted egress paths into exfiltration channels because the traffic looks like normal SaaS use.
Helpdesk vishing campaigns flagged by the New York Department of Financial Services in an industry letter dated February 6, 2026, target federation enrollment directly. Attackers impersonate IT helpdesk staff to extract credentials and MFA codes, register attacker-controlled MFA methods, and enroll new devices that conditional access then trusts. The end goal is the same federation pivot, just sourced from social engineering rather than malware.
Reference: Federation Attack Techniques and Detection Signals
What Defenders Actually Need to Do
The defensive posture for federation abuse splits into three priorities, none of which are novel and all of which require executive backing because they cost real money or break real workflows.
Eliminate the on-prem federation server where possible. Microsoft’s official guidance since 2023 has been to migrate from ADFS to cloud-only Entra ID, ideally with Password Hash Sync as the authentication path rather than federation. The point isn’t that Entra ID is invulnerable — Silver SAML and Storm-0558 prove it isn’t — it’s that one well-instrumented control plane is easier to defend than two with a cryptographic bridge between them. For organizations that must keep ADFS, hardware security modules for the token-signing key are non-negotiable. An HSM means the key cannot be exported even by domain admin, which raises the bar from “extract a file” to “physical access to the HSM.”
Instrument the cross-domain log gap. Golden SAML detection requires that you can correlate ADFS Event 1200, DC Event 4769, and relying-party sign-in logs by Correlation ID across whatever SIEM holds them. Few organizations actually do this. Without it, a forged token is invisible. The Splunk Cloud Federated Credential Abuse analytic story and Microsoft Defender for Identity’s Golden SAML alerts are reasonable starting points, but they require the underlying logs to flow.
Treat federation administration as Tier 0. ADFS service accounts, Entra global admins, Entra Connect service accounts, and PTA agent hosts belong in the same trust tier as domain controllers. Privileged Access Workstations, just-in-time elevation via PIM, conditional access policies that block these accounts from non-PAW endpoints, and continuous review of who holds the role — these are the controls that prevent Stage 2 of the attack chain from completing. Most successful Golden SAML attacks succeed because the ADFS server was administrable from the same workstations that read email.
Frequently Asked Questions
Does moving fully to cloud-only Entra ID eliminate federation abuse risk? It eliminates Golden SAML and ADFS-specific paths. It does not eliminate Silver SAML (if you supply your own signing cert), illicit OAuth grants, rogue federated domain creation by a compromised global admin, or token-replay attacks of the type Storm-0558 used. The attack surface shrinks and centralizes; it doesn’t disappear.
Can MFA stop a Golden SAML attack? Only if MFA is enforced at the relying party rather than at the IdP. If MFA happens at ADFS or Entra during token issuance, a forged token bypasses it because forged tokens skip issuance entirely. Service-provider-side MFA — a separate factor enforced by Salesforce, AWS, or the application itself — does block forged-token use.
How long can a forged SAML token remain valid? Whatever the attacker chooses, with two exceptions. AWS rejects SAMLResponses generated more than five minutes prior. Some Entra-integrated apps honor token lifetimes set by conditional access. Most other relying parties accept whatever validity window is in the assertion, which is why long-lived forged tokens are a documented persistence mechanism.
Are CISA’s Midnight Blizzard directives still in effect? Emergency Directive 24-02’s specific deadlines have passed, but the underlying guidance — credential reset for any account whose credentials transited compromised Microsoft email, audit of privileged Azure accounts, deactivation of unused federated apps — remains the baseline expectation for affected organizations. CISA has continued issuing related advisories through 2025 and into 2026.
The Stance
Federation abuse is not an emerging threat. It is a mature, well-documented technique class that has been used by APT29, APT28, Storm-0558, and a steady drumbeat of financially motivated groups for nearly a decade. The reason it keeps working is that the architectural fix — collapsing trust to a single, instrumented, HSM-backed control plane — costs migration effort that organizations defer, while the detection fix requires log infrastructure that organizations underfund. The 2026 attacks look like the 2020 attacks because the deployments look like the 2020 deployments. The opportunity for defenders is unglamorous: shrink the federation surface, isolate what’s left to Tier 0, and instrument the cross-domain seam where forged tokens become invisible. None of that is novel. All of it works.
