Notifications
Clear all
Topic starter
02/08/2026 11:27 am
TL;DR: Session theft, OAuth2 service app abuse, and Golden SAML lateral movement in an Okta-federated Azure environment produced no alerts, while only the downstream MFA deletion was detected, according to Panther. The result is a detection gap problem as much as an identity problem: if federated abuse is invisible, control confidence is overstated.
NHIMG editorial — based on content published by Panther: Through the Looking Glass, simulating an adversary in Okta
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: What fails when federated identity detections only catch the final account change?
A: The programme misses the earlier trust abuse that made the account change possible, so the attacker can operate inside the identity fabric before any alert fires.
Q: Why do OAuth-connected third-party apps create identity risk?
A: OAuth-connected apps extend trust beyond the organisation’s own perimeter into a vendor’s security posture.
Q: How do security teams detect forged SAML abuse in practice?
A: They correlate assertion issuance, certificate changes, unusual relying-party logins, and identity actions that occur without a matching human authentication event.
Practitioner guidance
- Map federation trust paths end to end Document how Okta sessions, OAuth service apps, and SAML assertions move between trust domains so the same access path can be monitored across the chain.
- Treat service applications as privileged identity actors Classify any service app with user management, factor management, or token minting scopes as privileged and review it with PAM-style rigor.
- Add detections for factor lifecycle abuse Monitor API calls that list, delete, or re-enrol MFA factors, and correlate them with service application identities and unusual user agents.
What's in the full report
Panther's full blog post covers the operational detail this post intentionally leaves for the source:
- Exact Okta API calls and response patterns used to enumerate users, groups, and enrolled MFA factors
- Stage-by-stage proof of concept for session theft, OAuth2 service app abuse, and Golden SAML authentication
- Detection examples that map specific log events to the attack chain and show where alerting was missing
- Suggested rule updates and investigation logic for improving coverage of factor deletion and federation abuse
👉 Read Panther's analysis of the Okta-to-Azure attack chain simulation →
Okta to Azure attack chains: are your detections seeing the full path?
Explore further
02/08/2026 12:43 pm
Federation telemetry is only useful if it covers the full trust chain. This simulation showed that detection can succeed at the final identity mutation and still fail at the access path that made the mutation possible. When session theft, OAuth2 service app abuse, and forged SAML assertions are invisible, the SOC is effectively observing the consequence rather than the attack. Practitioners should treat federated trust relationships as a single attack surface, not a sequence of isolated products.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when a service app deletes MFA factors and enables downstream federation abuse?
A: Accountability sits with the team that owns the service application, the identity platform team that approved its scopes, and the security function that defined monitoring and review thresholds. In federated systems, no single product owns accountability for the chain, so governance has to be explicit.
👉 Read our full editorial: Okta federated attack chains expose the limits of SOC visibility
