Okta Cross-Tenant Impersonation: Rogue IdP Persistence

TL;DR. With admin rights, an attacker can add an identity provider they control as a trusted inbound IdP, map its usernames to real users, and then sign in as those users from outside, without their passwords or MFA. In the System Log look for system.idp.lifecycle.create and system.idp.lifecycle.activate by an unexpected actor, followed by user.authentication.auth_via_IDP sign-ins through that IdP. Deactivating the IdP is urgent, but first capture its configuration and every user it signed in as.

The technique

Okta can trust external identity providers for sign-in: a partner's SAML IdP, a social login, or another Okta org. This inbound federation is a legitimate feature. In the hands of an attacker with administrator access it becomes a master key.

Okta Security documented the pattern in 2023 under the name cross-tenant impersonation. After taking over Super Administrator accounts through helpdesk social engineering, the threat actor configured a second identity provider, controlled by them, as a "source" IdP in an inbound federation relationship (sometimes called Org2Org), and manipulated the username of targeted users in that source IdP to match real users in the victim org. The result: SSO into the victim's applications as those users (Okta Security: Cross-Tenant Impersonation). The same article notes that compromised Super Administrator accounts were used to grant privileges to other accounts and, in some cases, to remove second-factor requirements from authentication policies.

MITRE ATT&CK tracks trust changes of this kind as T1484.002, Domain or Tenant Policy Modification: Trust Modification.

Why it is so effective as persistence: resetting the passwords and factors of the compromised admins does nothing to it. The IdP keeps working until someone removes it.

What it looks like in the System Log

Order	eventType	Actor	Target	What to capture
1	`user.session.access_admin_app`	compromised admin	Admin Console	IP, ASN, session
2	`system.idp.lifecycle.create`	compromised admin	the IdP	name, id, `requestUri`
3	`system.idp.lifecycle.activate`	compromised admin	the IdP	time it went live
4	`system.idp.lifecycle.update`, `system.idp.key.create`	compromised admin	the IdP	later changes, new signing keys
5	`user.authentication.auth_via_IDP`	impersonated user	the IdP	every user who signed in this way
6	`user.session.start`	impersonated user	—	session created by the assertion
7	`user.authentication.sso`	impersonated user	applications	what they reached

Okta Security's list of events to monitor for this campaign includes system.idp.lifecycle.create and user.authentication.auth_via_IDP (source). Routing rule changes and account-linking or just-in-time provisioning settings also matter: they decide which users an IdP can sign in as. Their exact event names depend on how the change was made, so search the admin session of the attacker for everything it did, not just IdP events.

The name will not help you. An attacker names the IdP something plausible ("Partner SSO", "Azure AD backup"). What gives it away is who created it, from where, and when, relative to the rest of the incident.

How the analyzer flags it

Rule	Events	Severity
`persistence.idp_created`	`system.idp.lifecycle.create`, `system.idp.lifecycle.activate`	high
`persistence.idp_modified`	`system.idp.lifecycle.update`, `system.idp.key.create`, `system.idp.key.update`, `system.idp.lifecycle.read_client_secret`	medium
`app.sso_after_suspicious`	SSO into sensitive apps by a user involved in a high finding, within 24 h	high

A new IdP is always reported, because it is rare enough in most orgs that a human should confirm each one. Combined with another high rule (a Super Administrator grant, a helpdesk reset then enrollment), it makes the verdict Likely compromised. The walkthrough of the fictional sample shows a "Partner SSO" IdP created from a VPS and used to sign in as a service account.

Investigation checklist

Inventory all IdPs in the Admin Console (Security › Identity Providers) and compare with the system.idp.lifecycle.create events in your export. Any IdP older than 90 days will not appear in the log; ask its owner.
For each suspicious IdP, capture: creation and activation events, the actor, its configuration (issuer, certificate, username mapping, account-linking and JIT settings), and routing rules that point to it. Screenshot or export before touching anything.
List every user.authentication.auth_via_IDP through it, including the target users. Each one is an impersonated identity whose actions you must review.
Follow each impersonated session: externalSessionId → SSO targets → downstream application logs. If AWS or Microsoft 365 was reached, continue with AWS Forensics or M365 Forensics.
Check for JIT-created users: new users provisioned by the IdP will appear as lifecycle events around the first sign-in.

Remediation

Deactivate, then delete, the rogue IdP, after capturing its configuration.
Review IdP routing rules and account-linking settings so that no external IdP can sign in as existing users unless that is intended and documented.
Clear the sessions of every user who signed in through it, and revoke their sessions in downstream apps.
Remove the admin access that made it possible (see roles and API tokens).
Restore any sign-on or MFA policy the attacker weakened.

For prevention, Okta's recommendations for this campaign include phishing-resistant authentication for admins, re-authentication for admin sign-ins, Protected Actions for sensitive admin operations, and custom admin roles instead of standing Super Administrator rights (Okta Security). An alert on system.idp.lifecycle.create in your SIEM costs nothing and fires rarely.