Forged claims at the source: hijacking Okta token issuance
An Okta inline hook lets an external endpoint join token issuance. Point it at attacker code and every token can carry group claims that were never assigned.
Okta inline hooks let an external endpoint participate in token issuance, and downstream apps trust whatever the resulting token says. That makes the token pipeline Tier-0.
How the attack works
With admin access, the attacker registers a token inline hook that points Okta at an endpoint they control during token minting. The endpoint returns commands that add elevated group and role claims to each token Okta is about to issue. A downstream app then grants admin based on a group claim that was never assigned in Okta, because it was injected by the hook. The attacker later edits the hook to inject only for their own sessions, reducing noise and evading broad detection. This maps to T1606, Forge Web Credentials, and T1556, Modify Authentication Process.
Why it works
Legitimate claims map to real group assignments, so the apps have no reason to doubt them. Whoever controls a hook controls what every token says, without ever touching a single user’s actual roles.
How to fix it
Do two things. Remove or repoint the rogue hook to stop new claim injection, then invalidate and reissue the tokens minted while the hook was live, because those already in circulation carry the forged claims. Revoking one session leaves the hook injecting for the next token. For the class, audit every inline hook and its endpoint, restrict who may register or modify hooks, require approved endpoints, and alert on hook create and update events. Scope the forgery from the hook execution events joined to issuance and downstream authorization logs.
Practice it
We built this as a GraphLattice Range scenario so responders learn that removing the hook is not enough without invalidating the tokens it forged.