Okta Super Admin Role and API Token Abuse in the Logs
Find Okta admin role grants, API tokens, weakened policies and support impersonation in the System Log, and remove the persistence an attacker left behind.
TL;DR. Once an attacker holds an Okta administrator, they make sure they keep it: a second Super Administrator (user.account.privilege.grant with debugData.privilegeGranted), an API token (system.api_token.create) that survives password and MFA resets, and weaker defences (policy.*, security.authenticator.lifecycle.deactivate, zone.*). List every admin action of the compromised account from its first suspicious sign-in, then of every account it promoted. Remove tokens and roles before you tell anyone the incident is contained.
Why admin persistence matters more than the entry point
The first compromised account is usually noticed and reset. What the attacker did with it in the meantime is what keeps them in. Okta Security's write-up of the 2023 campaign describes compromised Super Administrator accounts being used to assign higher privileges to other accounts, to reset authenticators of existing admins, and in some cases to remove second-factor requirements from authentication policies (Okta Security). Each of those actions is logged.
MITRE ATT&CK techniques in play: T1098.003 Additional Cloud Roles, T1098.001 Additional Cloud Credentials, T1556.006 Multi-Factor Authentication (weakening MFA).
Admin role grants
| eventType | Meaning | Field to read |
|---|---|---|
user.account.privilege.grant | a user's admin privileges changed | debugContext.debugData.privilegeGranted, target |
group.privilege.grant | a group was given admin privileges | then check who is in the group |
user.account.privilege.revoke | all admin privileges of a user revoked | who cleaned up, and when |
user.session.access_admin_app | Admin Console opened | first admin access from a new network |
The catalog notes that user.account.privilege.grant carries the list of privileges the user currently has (event types). The analyzer splits grants in two rules: Super administrator granted (high) when privilegeGranted mentions Super Administrator, and Admin role granted (medium) for every other role.
What makes a grant suspicious:
- the grantee is a service account or a dormant account that nobody signs in with interactively;
- the grantor signed in minutes earlier from a new network or after a factor reset;
- the grant happens outside your change process (no ticket, odd hour for that admin);
- a group is given admin rights and then someone is added to it.
API tokens
Okta's documentation is clear on the properties that make tokens attractive to attackers: a token has the permissions of the user who created it, it stays valid for 30 days and renews each time it is used, and it is only rejected once its creator is deactivated (Okta Help Center: API tokens). Resetting the creator's password or factors does not revoke it.
| eventType | Meaning |
|---|---|
system.api_token.create | a new API token was created |
system.api_token.revoke | a token was revoked |
system.api_token.request_outside_allowed_range | a token was used from outside its allowed network zone |
To see what a token did, Okta Security recommends querying on transaction.detail.rootApiTokenId (Okta Security). Every token created during the incident window should be revoked, then its activity reviewed.
The analyzer reports each creation as API token created (medium): tokens are routine for integrations, so this one needs context, and it becomes decisive next to a high finding on the same actor.
Weakening the defences
| eventType | Analyzer rule | Severity |
|---|---|---|
security.authenticator.lifecycle.deactivate, system.mfa.factor.deactivate | Authenticator deactivated | high |
policy.lifecycle.deactivate, policy.lifecycle.delete, policy.rule.deactivate, policy.rule.delete | Policy or rule disabled | medium |
policy.lifecycle.update, policy.rule.update, policy.lifecycle.overwrite | Policy changed | low |
security.threat.configuration.update, security.attack_protection.settings.update, security.session_protection.status.update, zone.update, zone.delete, zone.deactivate, zone.remove_blacklist | Security settings changed | medium |
A policy update is informational on its own because admins change rules all the time. The System Log records that the rule changed; open the policy in the Admin Console and compare with your documentation to see what changed (for example, MFA no longer required for a group).
Support impersonation
user.session.impersonation.grant and user.session.impersonation.initiate record support access being enabled and used. The analyzer reports them as Okta support access / impersonation (medium). The question to answer is simple: did someone on your team open a support case that needed it? If not, revoke the grant and find out who enabled it.
Investigation workflow
- Anchor on the compromised admin. From its first suspicious
user.session.start, list every event where it is the actor. The entity pivot in the analyzer does this in one click. - Build the "touched" list: every user it promoted, every token it created, every group it gave rights to, every IdP, policy, authenticator and zone it changed.
- Repeat step 1 for each promoted account. Attackers chain identities.
- Compare with the current state in the Admin Console (Security › Administrators, Security › API › Tokens). Anything created more than 90 days ago will not be in the log.
Remediation order
- Revoke the API tokens created during the incident (Security › API › Tokens).
- Revoke admin roles granted during the incident, starting with Super Administrator; then review every admin assignment.
- Clear the sessions of the accounts involved.
- Restore policies, authenticators, network zones and ThreatInsight settings.
- Remove unknown identity providers.
Why tokens first: a token lets an attacker re-grant a role you just removed, as long as its creator is active.
Long-term, Okta's guidance for this attack family includes fewer standing Super Administrators (custom admin roles scoped to the job), re-authentication for admin sessions, and Protected Actions on sensitive operations (Okta Security). The standard admin roles page is the place to decide who needs what.