Okta Detection Update
A detection release for Okta, published November 11, 2026. Four new rules look at successful Okta sign-ins for the signs of an account takeover with a valid password: a scripting tool or HTTP library instead of a browser, a script that poses as a browser but skips the Okta sign-in page, a proxy or anonymizing VPN, and a country or internet provider new to the user. Until now, a takeover with a working password raised no Okta alert. All twelve existing Okta rules are upgraded: each alert names the person who acted, what they changed and where the request came from, every event raises its own alert, and a person's first sensitive change in 30 days is scored high enough to open an incident.
No action is needed: the rules sync to every instance with Okta connected automatically.
Rollout and requirements
- Rollout. All sixteen rules are published to the default rule set and reach each instance through resource sync within about two hours. No configuration is needed. They apply to events from release on, not retroactively.
- Data source. The rules read the Okta System Log, collected by the Okta Events application (Okta). The sign-in rules read successful sign-in events (
user.session.start); the others read the admin and security events listed below. Instances without Okta are unaffected. - Learning. Each rule's "first time in 30 days" starts counting at release. In the first weeks, every administrator's first sensitive change and every user's first scripted, proxied or new-country sign-in counts as new, so expect more Okta alerts and incidents at first. The volume settles as the 30-day history fills.
The attack
An attacker who already has a working password, from an old breach, a phishing page or credential stuffing, does not need to break anything. On an account that signs in with a password alone, one successful sign-in is a takeover, and Okta then opens every application it signs the user in to. Shared and partner accounts, which often have no MFA because several people use them, are the first to fall.
The sign-in looks routine: there are no failures to count and no lockout. What gives it away is how it was made. Credential-stuffing and account-takeover tools sign in with an HTTP library, or copy a browser's user agent and post the password straight to Okta's authentication API, and they route through anonymizing services. In April 2024 Okta reported a spike in credential stuffing against its customers routed through Tor and, for millions of requests, residential proxies; the orgs it reached usually had sign-on policies that allowed requests from anonymizing proxies.
With an administrator's account, the attacker goes further. In the help-desk social-engineering attacks Okta reported in August 2023, the attackers used compromised super administrator accounts to grant higher privileges to other accounts, reset the authenticators of other administrators, and in some cases removed the second-factor requirement from authentication policies. Each of those is an ordinary admin event, which is why an alert that does not say who made the change, to what and from where tends to be closed unread.
New detections
| ID | Rule | Change | Severity | Fires when |
|---|---|---|---|---|
| 102211 | Okta_Scripted_Client_Login | New | High | A successful Okta sign-in comes from a scripting tool or HTTP library whose user agent has not signed the user in during the last 30 days. |
| 102212 | Okta_Browser_Login_Without_Widget | New | High | A user signs in successfully through the authentication API (/api/v1/authn) with a browser user agent, but without the header the Okta sign-in page sends, from an IP address the user has not signed in this way from in 30 days. A real browser sign-in carries that header; a script that copies a browser's user agent does not. |
| 102214 | Okta_Proxy_Login | New | Medium | A user signs in successfully through a proxy or an anonymizing VPN that Okta identified, from an IP address the user has not signed in this way from in 30 days. Apple iCloud Private Relay is not reported. |
| 102213 | Okta_User_Login | New | Context | Records every successful sign-in by a user on the user's timeline. A sign-in from a country or an internet provider the user has not used in 30 days, or from a provider no one in the organization has used in 30 days, is marked as new and adds to the user's score. |
At release, Okta_Scripted_Client_Login matches user agents that begin with Go-http-client, python-requests, python-urllib, python-httpx, aiohttp, curl/, Wget, libwww-perl, okhttp, axios, node-fetch, undici, PostmanRuntime, Apache-HttpClient, Ruby, Faraday, PowerShell, Mechanize, Scrapy or Hydra. A new version of the same tool sends a different user agent, so it counts as new.
All four rules are keyed on the user who signed in. An account that signs in the same way every day is reported once, not on every sign-in. The signals add up in the user's risk score for the day: when several of them point at the same user on the same day, their combined score opens an incident.
Each sign-in alert names the user, the IP address, network (ASN), internet provider, city and country, the user agent, the request URI and the Okta session ID, with Okta's own proxy, tunnel, risk and threat findings for the sign-in. The alert text reads, for example:
user@example.com signed in to Okta from scripting client python-requests/2.32.3 at 192.0.2.10 (AS64500 Example Hosting, Ashburn, United States)
Improved detections
The twelve existing rules match the same Okta events as before. What changed:
-
Clear alert text. Each alert names the person who acted, the user, group, application, policy, network zone or token affected, and the IP address, internet provider, city and country the request came from. Alerts that read only "Okta MFA Reset or Deactivated" now name the affected user, the factor and the source. A role grant reads, for example:
admin@example.com granted admin role Application administrator to User Jane Doe [user@example.com] from 192.0.2.10 (Example ISP, London, United Kingdom) -
Every event kept. Repeated changes by the same person, such as several role grants in a row, raise separate alerts instead of one.
-
First-time priority. For the sensitive changes, the first time in 30 days that a person triggers the rule (10 days for an Okta-detected threat) is marked as new and scored high enough to open an incident. Routine repeats by the same person stay at the rule's own severity.
| ID | Rule | Okta events | Severity | First-time priority |
|---|---|---|---|---|
| 101920 | okta_admin_role_assigned_to_user_or_group | user.account.privilege.grant, group.privilege.grant | Medium | Yes |
| 101919 | okta_api_token_created | system.api_token.create | Medium | Yes |
| 101918 | okta_api_token_revoked | system.api_token.revoke | Medium | Yes |
| 101917 | okta_application_modified_or_deleted | application.lifecycle.update, application.lifecycle.delete | Medium | Yes |
| 101916 | okta_application_sign_on_policy_modified_or_deleted | application.policy.sign_on.update, application.policy.sign_on.rule.delete | Medium | Yes |
| 101913 | okta_policy_modified_or_deleted | policy.lifecycle.update, policy.lifecycle.delete | Medium | Yes |
| 101912 | okta_policy_rule_modified_or_deleted | policy.rule.update, policy.rule.delete | Medium | Yes |
| 101914 | okta_network_zone_deactivated_or_delete | zone.deactivate, zone.delete | High | Yes |
| 101911 | okta_security_threat_detected | security.threat.detected | High | Yes, 10 days |
| 101915 | okta_mfa_reset_or_deactivated | user.mfa.factor.deactivate, user.mfa.factor.reset_all | Medium | No |
| 101910 | okta_unauthorized_access_to_app | "User attempted unauthorized access to app" | Medium | No |
| 101909 | okta_user_account_locked_out | "Max sign in attempts exceeded" | Medium | No |
These rules are keyed on the person who acted, so the alert and any incident land on the administrator who made the change, not on the user it affected. For okta_security_threat_detected, that is the user Okta flagged. MFA factor resets, refused application access and account lockouts are common in daily use: they add to a person's score without opening an incident on their own.
What the rules do not cover
The new sign-in rules do not fire for:
- failed sign-ins. A run of them that locks an account raises
okta_user_account_locked_out; - a user agent, or for the browser and proxy rules an IP address, that the user has signed in with this way in the last 30 days;
- a script that sends both a browser's user agent and the sign-in page's header, or one that signs in through a flow other than
/api/v1/authn; - a proxy or VPN that Okta does not identify, and Apple iCloud Private Relay.
Okta_User_Loginstill marks a country or provider new to the user; - a stolen Okta session used without a new sign-in;
- API calls made with an API token, which are not sign-ins.
Triage guidance
A new sign-in alert. Treat a scripted, browser-without-sign-in-page or proxied sign-in to an account without MFA as a possible takeover until the account owner confirms it.
- Check the account. Is it a shared, partner or service account? Does its sign-on policy require MFA? A password-only account with one of these sign-ins is the case to act on first.
- Confirm with the owner. Ask whether they, or a script of theirs, signed in at that time from that address. A user on a corporate VPN or a privacy service that Okta flags matches the proxy rule.
- Contain. In the Okta Admin Console, clear the user's sessions, reset the password, and enroll or require MFA.
- Follow the session. Search the Okta index for the session ID in the alert to see which applications the session opened through single sign-on, then end the sessions in those applications, which keep their own.
- Expected automation. If your own scripts or integrations sign in to Okta as a user, tell your Fluency contact so their alerts can be recognized.
An admin-change alert. Confirm with the administrator named in the alert that they made the change. If they did not, treat their account as compromised: clear its sessions, reset its password and factors, and review the other changes made from the same session or address, especially admin role grants, MFA resets, sign-on policy and network zone changes, and any identity provider added to the org.
To find these alerts, search behavior events by rule name. The rules are also listed by name on the Behavior Rules page (v1: Behavior Rules).
References
- Okta Security, How to Block Anonymizing Services using Okta, April 27, 2024.
- Okta Security, Cross-Tenant Impersonation: Prevention and Detection, August 31, 2023.
- Okta Developer, Event types.