Contain at the IdP: Ping OAuth client abuse fans out across apps

The identity provider is the trust root that vouches for users across many apps. A stolen Ping OAuth client secret or admin token sits there, so one compromised credential grants access across the whole federated estate at once.

How the attack works

A Ping admin token authenticates from a new host and reads OAuth client and connection configuration. Using a compromised client secret, the attacker mints client-credentials access tokens at the token endpoint, then presents them to several SP-connected applications, reaching data across more than one app at once. They also edit the OAuth client to add broader scopes, widening what its tokens can do. In ATT&CK terms this is T1528, Steal Application Access Token, with T1556, Modify Authentication Process.

Why it works

OAuth clients had broad scopes and long-lived secrets, with no alerting on token-endpoint anomalies, so a single stolen client secret behaved like a master key to every connected app.

How to fix it

Because Ping is the trust root, you contain there, not app by app. Rotate the OAuth client secret and admin credentials so no new tokens can be minted, then revoke active grants and sessions to invalidate the tokens already issued across every connected app at once. Per-user password resets and per-app firewall blocks chase the symptom while the client keeps minting. Scope the federated reach by joining Ping token-endpoint audit events with the SP application logs over the window, since configured scopes show only capability. As a class fix, scope OAuth clients to least privilege, shorten and rotate secrets, and alert on token-endpoint and client-config anomalies.

Practice it

We built this as a GraphLattice Range scenario so administrators can rehearse containing at the IdP, revoking grants and sessions, and scoping which apps the minted tokens reached.