Okta inbound federation trust abuse: one edit and the IdP asserts any user
An attacker who can edit a trusted inbound identity provider in Okta can rewrite its username transform and sign in as any internal user, including admins, with no password and no MFA. You contain it by severing the trust, not by resetting the impersonated users.
Okta trusts an inbound identity provider to assert who a user is. The dangerous part is not that a rogue provider might appear. It is that a provider you already trust can be edited to assert the wrong people.
How the attack works
Inbound federation lets an external identity provider assert an identity, and Okta maps each incoming assertion onto an internal account through a username transform. An attacker who can edit that federation, not only add a new one, rewrites the transform on an already-sanctioned IdP so an assertion they sign resolves to any internal username they choose, including an administrator. They then sign an assertion from their own infrastructure, and Okta mints a session for that user. No password is entered and no MFA factor is challenged on the Okta side, because what is being verified is the trust, not a credential. This is the trusted-relationship problem, T1199, used to establish valid accounts, T1078, and it rides on a change to the authentication process, T1556.
Why it works
The abuse hides inside a legitimate federation. Adding a brand-new rogue provider stands out as an unknown IdP. Editing a sanctioned one does not: the provider is supposed to be there, so the only evidence is a configuration change and a set of sign-ins that resolve to internal users who should never route through it. Downstream applications never question the session, because Okta issued it as a normal federated authentication. The root cause is treating a federation’s identity mapping as an ordinary setting rather than Tier 0 trust, and allowing a transform that can resolve an external assertion to any internal user.
How to detect it
The signal is not a new provider. Watch the System Log for changes to a trusted IdP’s username transform and attribute mapping, then correlate with federated sign-ins that resolve to internal accounts which never legitimately authenticate through that provider, succeeding with no factor challenge on those accounts. A federated authentication that lands on a privileged user, with no preceding interactive auth and no MFA, through a provider whose config just changed, is the tell. Compare each IdP’s configuration against a known-good baseline so a mapping change is visible on its own.
How to shut it down
You cannot fix this at the user layer, because federation never used the impersonated user’s password or factor. Suspend or sever the trusted IdP so it can no longer assert identities, revoke the sessions it already minted, and restore the username transform from a known-good baseline. Then scope the damage from the System Log: pull the IdP update event and every federated authentication through that provider for the window the altered transform was live, to enumerate exactly which internal users it asserted and follow what each minted session reached. Resetting the impersonated administrator does nothing while the altered trust keeps asserting anyone it likes. For the durable fix, gate identity-provider administration to a minimal set behind phishing-resistant authentication, remove transform logic that can resolve to arbitrary internal users, and alert on every IdP configuration change.
Practice it
We built this as a GraphLattice Range scenario so responders can spot the change to a trusted identity provider, sever the trust rather than chase the impersonated users, and restore the mapping and the sessions for the whole tenant.