Identity Anomaly Finder
Score Okta, Entra ID or CloudTrail sign-ins against each user's own baseline.
Generated sample data. Every user, IP and account in it is made up.
Your logs never leave this tab. Sign-in records hold names, IPs and locations, so nothing is uploaded or saved.
Tuning
How the anomaly checks work
Records are recognised per line: Okta by eventType, Entra ID by userPrincipalName with a status code, CloudTrail by eventSource and eventName. Each becomes one normalised event with time, user, IP, place, network, device family, action and outcome. Scores add up per user into the risk table; 60 or more is high and 30 to 59 is medium.
Accuracy and how it compares
Measured on 6 November 2026 with the same engine this page runs. Labels for the public sets come from the attack each capture records; the edge cases are ours.
| Test set | Before 6 Nov fixes | Now |
|---|---|---|
| Splunk attack_data identity captures: Okta, Entra ID and CloudTrail spray, brute force, MFA fatigue, travel and single-factor logins (16 files, commit c8af10d) | 8 of 16 correct | 16 of 16 correct |
| Panther test events for brute force, AWS console spray, Entra lockout and impossible travel, Okta, Entra and CloudTrail rows (panther-analysis bb00993) | 15 of 16 agree, 3 Entra rows unread | 18 of 19 agree |
| Labelled edge cases: unanswered pushes, password checks logged as MFA, Entra interrupts, distributed spray, office typos, near-threshold counts | 9 of 22 | 22 of 22 |
| Detection | This page | Elastic detection-rules | Sentinel, Panther, Sigma |
|---|---|---|---|
| Impossible travel | Over 900 km/h and 500 km; shared egress skipped | Entra: 500 km and 800 km/h | Panther: over 900 km/h at any distance. Sigma: Entra ID Protection risk events only |
| Password spray | 5 users from one IP in 60 min | Okta: 5 users, 15 attempts, 2 to 6 per user | Sentinel: 5 users per IP per 20 min. Panther AWS: 10 users in 60 min |
| Distributed spray | 8 users from 5 or more IPs with no successful sign-in, in 60 min | Okta: 5 IPs, 8 users, 25 attempts per hour | Sentinel: over 30 failures for one user from 3 locations |
| Brute force | 8 failures then a success or correct password; 10 with none | AWS root: 10 in 6 min. Entra: 30 for one user in 5 min | Panther: 20 per user or IP in 60 min. Sentinel: 10 before a success |
| MFA fatigue | 3 denials or 5 unanswered pushes in 60 min, then an approval | Okta: 5 push rejects in 10 min | Sentinel: 3 Entra MFA failures per IP per hour, or one user decline. Sigma: single events |
| Console login without MFA | Root or IAM user with MFAUsed: No | Same, first time per user | Panther and Sigma: same field |
Compared at Elastic detection-rules 5d9bba5, Azure-Sentinel 644883b, panther-analysis bb00993 and SigmaHQ 52f81d6. Entra codes checked against the Microsoft AADSTS reference; Okta event types against okta-developer-docs release 2026.45.1.
Known limits: a 40 km hop in two minutes does not alert (Panther fires; the 500 km floor matches Elastic). CloudTrail carries no location, so travel there needs enrichment first. One file is the whole history, so there are no peer groups or months of baseline. Okta failures without a reason count as credential failures.
Identity anomaly FAQ
Are my logs uploaded?
No. Parsing, baselines and scoring all run in JavaScript on this page. Sign-in logs hold names, IP addresses and locations, so nothing is sent or stored.
How is the baseline built?
By default the first 70 percent of the time span in your file is the learning window. For each user the page records countries, networks (ASNs), device types, apps, active hours and, for CloudTrail, the API actions they call. Sign-ins and calls in the remaining 30 percent are scored against that user's own history. Choose All vs all to score every event against the whole file instead.
Why did a VPN hop or a real trip not alert?
Impossible travel needs both a distance over 500 km and a speed over 900 km/h, so a long-haul flight with a normal gap passes. A hop between two networks that at least four users signed in from during the baseline, such as an office and a corporate VPN egress, is skipped and counted on the page. Both thresholds can be changed.
Which log formats work?
Okta System Log JSON from the API or an export, Microsoft Entra ID sign-in logs from Microsoft Graph (auditLogs/signIns), a Log Analytics SigninLogs export or a diagnostic-settings export to a storage account or Event Hub, and AWS CloudTrail files with a Records array. A JSON array or one JSON object per line both work, and the formats can be mixed in one paste.
Can this replace a UEBA product?
It covers the core baselines a UEBA starts from, on one file at a time. A production UEBA keeps months of history, peer groups and identity context, and runs continuously. Use this page to triage an export, test thresholds, or learn how the detections behave.
Field names follow the Okta System Log, Microsoft Graph signIn and AWS CloudTrail record formats as of October 2026. The sample data on this page is generated and fictional.