Okta Incident Timeline Example: A Fictional Walkthrough
A fictional Okta intrusion read event by event: helpdesk reset, attacker factor, Super Admin grant, rogue IdP and AWS access, with the analyzer's findings.
TL;DR. Everything in this article is fictional: the organisation, the people, the IP addresses (documentation ranges), the AS numbers (documentation range) and the domains (.example). It is the sample behind the Try a sample button on the analyzer: 160 System Log events over two days in which an attacker talks the helpdesk into resetting an IT admin's password and factors, enrolls their own Okta Verify from a VPS, grants Super Administrator to a service account, adds an inbound identity provider, and uses it to reach AWS. The analyzer's verdict is Likely compromised, with one critical and five high findings. This walkthrough shows how to read it.
The fictional setting
"Northwind Logistics" (northwind.example) runs a small Okta org: twelve accounts, an office network in Lyon, a few home workers, and apps such as Slack, Salesforce, Google Workspace, Jira and AWS IAM Identity Center. Three accounts matter:
| Account | Role in the story |
|---|---|
m.okafor@northwind.example | IT administrator (Super Administrator), off sick on the morning of the incident |
h.lambert@northwind.example | helpdesk agent |
svc-sync@northwind.example | directory sync service account; never signs in interactively |
Networks: the office (198.51.100.10, "Example Telecom", AS64496), home broadband (192.0.2.x, AS64497), and the attacker's VPS (203.0.113.77, "Example VPS Hosting Ltd", AS64511, Amsterdam).
September 14 and the morning of September 15 are ordinary working days: password sign-ins, Okta Verify pushes, SSO into apps, the occasional mistyped password.
The intrusion, event by event (2026-09-15, UTC)
| Time | eventType | Actor | Target / detail | Source |
|---|---|---|---|---|
| 13:58:40 | user.session.access_admin_app | h.lambert | Okta Admin Console | office |
| 14:03:12 | user.account.reset_password | h.lambert | m.okafor | office |
| 14:03:40 | user.mfa.factor.reset_all | h.lambert | m.okafor | office |
| 14:09:05 | policy.evaluate_sign_on | m.okafor | risk HIGH, new device / new country | VPS |
| 14:09:09 | user.session.start | m.okafor | password | VPS |
| 14:10:22 | user.mfa.factor.activate | m.okafor | Okta Verify enrolled | VPS |
| 14:10:51 | user.authentication.auth_via_mfa | m.okafor | Okta Verify push | VPS |
| 14:12:30 | user.session.access_admin_app | m.okafor | Okta Admin Console | VPS |
| 14:19:02 | user.account.privilege.grant | m.okafor | svc-sync, "Super administrator" | VPS |
| 14:26:47 | system.idp.lifecycle.create | m.okafor | IdP "Partner SSO" | VPS |
| 14:27:10 | system.idp.lifecycle.activate | m.okafor | IdP "Partner SSO" | VPS |
| 14:33:15 | user.authentication.auth_via_IDP | svc-sync | via "Partner SSO" | VPS |
| 14:33:16 | user.session.start | svc-sync | federation assertion | VPS |
| 14:35:18 | user.authentication.sso | svc-sync | AWS IAM Identity Center | VPS |
| 14:36:02 | user.authentication.sso | m.okafor | AWS IAM Identity Center | VPS |
| 15:41:08 | user.session.start FAILURE | m.okafor | INVALID_CREDENTIALS | home |
| 15:41:52 | user.session.start FAILURE | m.okafor | INVALID_CREDENTIALS | home |
Read it as a story: at 14:03 the helpdesk resets Maya's password and factors (a caller claimed to be her). Six minutes later "Maya" signs in from a Dutch VPS she has never used, enrolls a new Okta Verify, and within ten minutes is in the Admin Console. She makes a service account Super Administrator, creates and activates an inbound identity provider, and signs in as the service account through it. Both identities open AWS. At 15:41 the real Maya, back online at home, cannot sign in any more: her password was changed.
This is the pattern described in the helpdesk social engineering article and the cross-tenant impersonation article, compressed into 33 minutes.
What the analyzer reports
Verdict: Likely compromised. Statistics: 160 events, 12 users, 5 IP addresses, 24 sessions, from 2026-09-14 07:56 to 2026-09-15 15:41 UTC.
| Severity | Finding | Key | Why it fired |
|---|---|---|---|
| Critical (escalated) | Helpdesk reset, then a new factor enrolled | m.okafor | reset by h.lambert, then user.mfa.factor.activate within 24 h, from a hosting provider / new network |
| High | Sensitive app opened after suspicious activity | m.okafor → Okta Admin Console | Admin Console access after the critical finding |
| High | Super administrator granted | svc-sync | privilegeGranted = Super administrator |
| High | New identity provider (inbound federation) | Partner SSO | create + activate |
| High | Sensitive app opened after suspicious activity | svc-sync → AWS IAM Identity Center | SSO by an account involved in a high finding; links to AWS Forensics |
| High | Sensitive app opened after suspicious activity | m.okafor → AWS IAM Identity Center | same |
| Medium | Sign-in from a hosting provider | m.okafor | "Example VPS Hosting Ltd" matches the hosting list |
| Medium | Sign-in from a hosting provider | svc-sync | same network |
| Low | Password or factors reset by another user | m.okafor | informational context for the timeline |
The critical finding alone would make the verdict Likely compromised; four distinct high rules make it unambiguous.
Two details worth noticing:
- The IdP sign-in itself is not a separate finding.
user.authentication.auth_via_IDPis normal in orgs that use federation. It surfaces here through the hosting-provider rule and through the SSO-after-suspicious rule, becausesvc-syncwas the target of the Super Administrator grant. In a real case, list everyauth_via_IDPthrough a new IdP by hand. - The victim's failed sign-ins are not a finding either. Two failures are normal noise. They are still on the timeline, and in a real case they are the moment the user notices; ask when they called the helpdesk.
Working it in the interface
- Findings tab. Open the critical finding's evidence: three events (password reset, factor reset, factor activation). The actor on the first two is
h.lambert, on the thirdm.okaforfrom203.0.113.77. - Incident timeline. The evidence of every medium-or-higher finding, plus the admin actions of the accounts involved, in order: essentially the table above, built for you.
- Entities → IP addresses.
203.0.113.77(AS64511, Netherlands) has events for two users,m.okaforandsvc-sync. Click Events to see everything that IP did. - Entities → Sessions. The attacker's session for
m.okaforcontains the enrollment, the Admin Console access, the grant and the IdP creation: one session, the whole attack. - Remediation. Preserve logs; clear sessions; review admins; tighten helpdesk verification; reset factors and password; investigate AWS and revoke sessions there; revoke the Super Administrator grant; remove the IdP and review routing rules; block hosting providers at sign-in; contact the user; escalate to incident response.
What a responder would do next
- Contain in Okta: remove "Partner SSO", revoke
svc-sync's admin role, clear sessions for both accounts, re-enroll Maya in person. - Follow into AWS: both identities reached AWS IAM Identity Center at 14:35–14:36 from
203.0.113.77. CloudTrail is now the primary source; AWS Forensics reads it the same way. - Close the entry point: find out how the helpdesk verified the caller at 14:03, and change the process for administrator resets.
Try it yourself
Open the analyzer, press Try a sample, and follow the steps above. Then read the step-by-step analysis guide to do the same with your own export, or the investigation guide for the method.
The sample is generated by a script in the project (scripts/make-samples.py) that follows the System Log LogEvent schema from Okta's developer documentation and uses eventTypes from the event types catalog. Its IP addresses come from the RFC 5737 documentation ranges and its AS numbers from the RFC 5398 documentation range, so nothing in it points to a real network.