Skip to content
Okta Forensics

This tool is not affiliated with, endorsed by or sponsored by Okta, Inc. Okta is a trademark of Okta, Inc. Other names are trademarks of their respective owners.

System Log WebAssembly

Was our Okta tenant compromised?

Drop your Okta System Log export (JSON from the API, CSV from the Admin Console, SIEM exports) and get a verdict, the findings, an incident timeline and a remediation checklist. Analysed in your browser with WebAssembly — nothing is uploaded.

Drop your Okta System Log export here

JSON or JSON Lines from /api/v1/logs, CSV from Reports › System Log, EventBridge / Splunk / Elastic exports — gzip, folders and ZIP archives work as-is. Several files are merged and de-duplicated.

A synthetic export of a fictional incident (helpdesk social engineering → admin takeover → rogue IdP → AWS) — no real data.

100% client-side: logs are analysed by WebAssembly in your browser and never uploaded.

How to get your data

From zero to a verdict in about two minutes: pull the Okta System Log, then drop the files here. Export the whole org, not a filtered view.

  1. 1. CollectRun the API script or download the CSV
  2. 2. DropDrop the files, the folder or a ZIP onto this page
  3. 3. Stays in your browserAnalysed locally by WebAssembly, never uploaded

Prerequisite: an API token created by a read-only administrator (Security › API › Tokens). Pulls the whole org for the last 90 days as raw JSON, with every field.

  1. Set your Okta domain and the token (replace the two values):

    bash / zsh
    export OKTA_DOMAIN="<your-org>.okta.com"
export OKTA_API_TOKEN="<read-only API token>"

  2. Paste in Terminal (bash or zsh). Each page is saved in okta-system-log/ in the current folder:

    bash / zsh
    out=okta-system-log; mkdir -p "$out"
start=$(date -u -v-90d +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ)
end=$(date -u +%Y-%m-%dT%H:%M:%SZ)
url="https://${OKTA_DOMAIN}/api/v1/logs?since=${start}&until=${end}&limit=1000"
n=0
while [ -n "$url" ]; do
  n=$((n+1)); f="$out/okta-system-log-$(printf %04d $n).json"
  curl -sS --fail -D "$out.headers" \
    -H "Authorization: SSWS ${OKTA_API_TOKEN}" \
    -H "Accept: application/json" \
    "$url" > "$f" || { rm -f "$f"; break; }
  url=$(tr -d '\r' < "$out.headers" | grep -i '^link:.*rel="next"' \
        | sed -E 's/^[Ll]ink: <([^>]+)>.*/\1/')
  sleep 1
done
rm -f "$out.headers"; ls -l "$out"

  3. Drop the okta-system-log folder onto this page (or zip it first). A busy org means many pages of 1,000 events: let it run.

Gotchas

  • Don't filter by user or event type: a helpdesk reset or an admin role grant is logged under someone else's name, so a filtered export can look clean.
  • The System Log keeps 90 days: export now. Timestamps are UTC, and the tool shows UTC by default.
  • An API token carries its creator's rights: create it as a read-only administrator, from an account the attacker cannot control, and revoke it after the export.

What this tool does

The Okta System Log records every sign-in, MFA challenge, session, admin change and application access of an Okta org as LogEvent records (eventType, actor, client, target, outcome, authenticationContext, securityContext, debugContext).

This tool reads a System Log export in your browser, correlates the events across users, sessions and IP addresses, and tells you whether they show an identity attack — with a verdict, the findings and their evidence, an incident timeline and a remediation checklist.

What it detects

  • MFA fatigue / push bombing: bursts of Okta Verify pushes or rejections, escalated when a push is finally accepted.
  • Helpdesk social engineering: a password or factor reset by an admin, followed by a new factor enrolled — critical when it comes from a new network, a hosting provider or an anonymizer.
  • Session hijacking: the same externalSessionId used from several networks (ASNs) or browsers, Okta roaming detections, ThreatInsight hits, proxy / Tor sign-ins.
  • Admin abuse and persistence: Super administrator and admin role grants, API token creation, new or modified identity providers (inbound federation), deactivated authenticators and policies, weakened security settings.
  • Password spraying and guessing: many accounts tried from one IP with few attempts each, or many failures on one account — escalated when a sign-in succeeds.
  • Sensitive app access after suspicious activity (AWS, Microsoft 365, Google Workspace, GitHub, Salesforce, the Okta Admin Console…), with a link to the matching log-analysis tool.

Detection rules

Detections are data, not code: each rule is a Sigma-like filter, threshold, sequence or follow-up condition on System Log fields, with a severity and MITRE ATT&CK techniques. The rule set is versioned with the tool.

RuleBase severityATT&CK
MFA fatigue / push bombing
mfa.push_fatigue		HighT1621
Helpdesk reset, then a new factor enrolled
mfa.helpdesk_reset_then_enroll		HighT1656, T1098.005, T1556.006
Password or factors reset by another user
mfa.factor_reset_by_admin		LowT1098
MFA bypass attempt
mfa.bypass_attempt		MediumT1556.006
Session used from several networks
session.multi_asn		HighT1539, T1550.004
Session used by several browsers
session.multi_user_agent		MediumT1539, T1550.004
Session roaming detected by Okta
session.roaming		MediumT1550.004
Password spraying
access.password_spray		HighT1110.003
Password guessing on one account
access.brute_force		MediumT1110.001
Sign-in through an anonymizer
access.anonymizer		MediumT1090.003, T1078.004
Sign-in from a hosting provider
access.hosting_provider		MediumT1078.004
Okta ThreatInsight hit
threat.threatinsight		MediumT1110
User reported suspicious activity
threat.user_reported		High
Breached credential used
threat.breached_credential		MediumT1078
Super administrator granted
admin.super_admin_granted		HighT1098.003
Admin role granted
admin.role_granted		MediumT1098.003
API token created
admin.api_token_created		MediumT1098.001
Okta support access / impersonation
admin.support_access		MediumT1078.004
New identity provider (inbound federation)
persistence.idp_created		HighT1484.002
Identity provider modified
persistence.idp_modified		MediumT1484.002
Authenticator deactivated
defense.authenticator_disabled		HighT1556.006
Policy or rule disabled
defense.policy_disabled		MediumT1556.006
Policy changed
defense.policy_modified		LowT1556
Security settings changed
defense.security_settings_changed		MediumT1562
Sensitive app opened after suspicious activity
app.sso_after_suspicious		HighT1021.007, T1550.001

Limitations

  • The System Log keeps 90 days: older activity is gone unless it was streamed or exported.
  • A clean verdict only covers what is in the export: a filtered or partial export can miss the attack.
  • Detections are heuristics: VPN users, travelling staff and helpdesk work can trigger findings. Confirm each one with the people involved.
  • Baselines (new country, new device) are computed from the export itself, so a short export gives little history.
  • debugContext.debugData fields (risk, behaviors, threatSuspected) are not a stable contract and vary between orgs and Okta releases.

FAQ

Are my logs uploaded anywhere?

No. The analyzer is Rust compiled to WebAssembly and runs in a Web Worker in your browser; files are read locally in chunks. There is no upload endpoint.

How large an export can it handle?

Exports are streamed in 4 MB chunks (gzip is decompressed on the fly), so multi-GB files work; what limits you is the memory needed for the events themselves. Very large exports list the evidence and the most recent events.

Which Okta events matter most in a compromise?

user.session.start and user.authentication.auth_via_mfa (sign-ins), system.push.send_factor_verify_push and user.mfa.okta_verify.deny_push (push fatigue), user.mfa.factor.reset_all / activate (factor changes), user.account.privilege.grant (admin roles), system.api_token.create, system.idp.lifecycle.create (inbound federation) and user.authentication.sso (app access).

How do I spot session hijacking in Okta?

Group events by authenticationContext.externalSessionId: a session used from two networks (securityContext.asNumber) or two browsers is suspicious, especially right after sign-in. Okta also logs security.session.detect_client_roaming.

Is this an official Okta tool?

No. It is an independent tool, not affiliated with or endorsed by Okta, Inc. It reads the log format documented in Okta's public developer documentation.

The verdict says compromised — what now?

Preserve the logs, contain the accounts involved (clear sessions, reset factors and passwords, revoke admin roles, tokens and unknown IdPs), then investigate the applications that were accessed. The remediation tab lists the steps for your findings, and Okta's security guidance (sec.okta.com) documents detections and hardening for these attacks.

Okta Detection False Positives: VPNs, Mobile, Tuning
Why Okta identity detections misfire on corporate VPNs, mobile networks and helpdesk work, what the analyzer cannot see, and how to verify each finding.
oktadetection-tuningincident-response
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.
oktaincident-responsesystem-log
Okta Password Spraying Detection in the System Log
Detect password spraying, brute force and credential stuffing against Okta: failure patterns per IP and user, ThreatInsight events, and the success to hunt.
oktapassword-attacksincident-response

This tool is not affiliated with, endorsed by or sponsored by Okta, Inc. Okta is a trademark of Okta, Inc. Other names are trademarks of their respective owners.