Okta Threat Intelligence is investigating a large set of reconnaissance, fraudulent registration and attempted intrusion activity across hundreds of Auth0 and Okta tenants.
The activity is large in scale and increased significantly during October and early November 2026. It is distributed across customers of both Auth0 and Okta, and third-party researchers (Wiz and Microsoft) have observed similar activity in Amazon Cognito and Microsoft Entra. We have not observed the exploitation of misconfigurations or vulnerabilities specific to any identity platform.
The threat activity includes scanning of public endpoints, fraudulent registration of accounts, and other common methods of identity attacks like credential stuffing. In most organizations, the most significant impact from this activity is the fraudulent registration of accounts. However, in cases where organizations leverage identity federation, account linking or other forms of blended customer, partner and workforce use cases, the presence of these accounts presents a risk of potential future compromise.
We assess that multiple actors have almost certainly tasked one or more agentic frameworks, likely the ARTEX multi-agent autonomous penetration testing framework, with broad-scale identity-centric reconnaissance and compromise attempts of web applications. A subset of the activity we observed is consistent with a specific ARTEX operator identified by Microsoft, Storm-0940. However, Okta cannot independently confirm all observed activity was performed using ARTEX specifically.
The agents in question attempt to exploit known (common) misconfigurations and attacks at significant speed and scale. We have yet to observe any novel form of exploitation.
We initially observed the patterns of activity described below against the customer identity tenants of cryptocurrency providers, but they have since expanded to other organizations.
This blog post aims to provide Auth0 and Okta customers with more context on the voluminous events appearing in their logs, on what attackers are likely trying to do, and on what specific configurations are most at risk.
Threat Analysis
The pattern of observed activity varies against each org/tenant, and appears to be customized on the fly according to the results of reconnaissance activity.
The most common features are:
Reconnaissance of public endpoints
We observed fraudulent OAuth requests in which the client_id and redirect_uri were populated with valid URLs from the sign-in pages of federated applications to Okta. It is highly likely this information was obtained by scraping public sources of data.
Attempts to manipulate authorization flows
We observed testing of OAuth flows to check whether the application allows the domains in OAuth redirects, whether the application properly verifies OAuth scopes, whether authorization requests require PKCE, whether requests require a valid DPoP header, or whether the application properly verifies the signature of JWTs (JSON Web Tokens).
Fraudulent account registration
We observed fraudulent registration of thousands of accounts across several hundred Auth0 and Okta tenants that support self-service registration. The email addresses used in account registration exhibited consistent patterns, as described below.
Credential stuffing and password spraying
Where agent testing exposed weak or exploitable authentication flows, such as Resource Owner Password Credentials (ROPC) grant or Auth0’s cross-origin authentication flow, we observed organizations being subject to probes that evaluated rate limits and repeated attempts to sign-in to accounts using common or known compromised credentials.
Fraudulent account registration
Wherever self-service registration is available, we observed fraudulent registration of test accounts across Auth0 and Okta tenants. We assess these accounts were likely registered to test how a targeted application responds to certain conditions, which were sometimes exploited during later activity. Tested conditions included, but were not limited to the following:
- Creating an account using a username that is already registered
- Checking whether a newly registered account requires the user to verify ownership of the email account supplied as a username
- Signing in via usernames (email addresses) that do not exist
- Recovering the password of an account that is or is not registered
- Recovering the password of an account from an email inbox that does not exist
The registered account email addresses exhibited the following patterns:
- Email addresses that do not exist - often marked to indicate this in the username (These “probe accounts” are further detailed below.)
- Common email prefixes used for shared accounts in workforce environments (These “shared mailboxes” are further detailed below.)
- Email addresses created using disposable email services (These “disposable accounts” are further detailed below.)
- Email addresses previously included in various leaked lists used in credential stuffing attacks
Probe accounts
In a sample of observed account registrations, information about the purpose of the account was encoded into the email address provided at account registration.
We observed user registration across multiple customers, for example, in which the new accounts conformed to a naming scheme that identified:
(a) the type of attack the account would be used to attempt, and
(b) a ten digit code that represents a UNIX timestamp for the time the user account was created.
So, for example:
i04probe1792451568@disposableemailservice[.]com
We assess the “i” in “i04” likely refers to the specific “intent” of the activity, meaning the technique the agent tried. 1792451568 is a UNIX timestamp for Monday, October 19, 2026 at 11:12:48 PM UTC, the precise time that the new account was created in the tenant.
Figure 1. Example probe email address
We assess that these identifiers were built into account names in an effort to more easily identify the purpose of the account in the tests we explain further below.
Shared mailboxes
In a large number of observed account registrations in Customer Identity and Access Management (CIAM) (customer identity) tenants, an actor(s) registered accounts with common email prefixes used for shared mailboxes in workforce environments. This was a pronounced pattern in a cluster of activity that targeted cryptocurrency exchanges.
We observed attempts to register new accounts at a targeted company domain using such generic terms as:
accounting@, admin@, billing@, careers@, compliance@, digital@, info@, investors@, ir@, legal@, marketing@, marketoperations@, membership@, noreply@, sales@, security@, support@
Figure 2. Example shared mailbox email format
In many cases, these email addresses were valid at the domain in question, and the sign up attempt resulted in emailed requests to verify the new account. We also observed events in which a staff member at the organization accidentally clicked on the link to verify the account registration.
While we have not observed it directly during this investigation, third parties have reported incidents in which attackers gained privileged access in a public application by successfully registering an account with a username that includes a domain name used for internal users.
Disposable accounts
We observed the registration of user accounts that used disposable email providers, with a clear preference for providers that provide well-documented (agent-friendly!) APIs.
The primary example is the mail[.]tm temporary mail service, which issues email addresses in the form of [account]@maxxspace[.]com. This API can be used to automate the generation and management of disposable email accounts without requiring an API key.
Credential stuffing and password spraying
We observed credential stuffing attempts against existing accounts in some of the same targeted applications as fraudulent registration activity. We also observed password spraying distributed across residential proxy pools. This pattern is consistent with an effort to evade per-IP lockout thresholds.
This is especially consequential in tenants that support cross-origin authentication (Auth0) or ROPC grant (in Auth0 or Okta). This grant type was designed for migration from legacy identity systems to OAuth-based flows, and is not fit for the current threat environment. Okta customers can refer to previous threat advisories on why these grant types are problematic.
The Storm-0940 connection
A subset of the total observed activity overlaps with a specific ARTEX operator Microsoft calls Storm-0940. Microsoft attributes Storm-0940 activity to a China state-aligned actor that used the agentic AI penetration testing framework ARTEX to target hundreds of organizations globally between September and October 2026. Notably, Storm-0940 performed a supply-chain attack on Entra customers via the compromise of secrets from ConnectWise, a US-based provider of software solutions for managed IT service providers.
ConnectWise disabled seven application integrations with Microsoft on October 17, 2026 after a secret used to connect its cloud backup service ("Cloud Backup", formerly "SkyKick") to Entra tenants was used to gain unauthorized access to Microsoft 365 environments.
The TTPs used by Storm-0940 are consistent with our own observations noted throughout this advisory:
“Storm-0940 used ARTEX to accelerate scanning and reconnaissance, password spraying, and OAuth application abuse at downstream victims.”
Source: Microsoft Threat Intelligence
Okta Threat Intelligence observed overlaps between the IPs shared by ConnectWise and Microsoft and some of the ARTEX activity we observed from October 9 to 23, 2026:
- 144.172.64.60
- 144.172.64.99
- 144.172.64.128
This specific infrastructure was used to attack Okta customers in the energy, defence industry, manufacturing, legal and public policy sectors.
We also observed passive reconnaissance of at least two other software providers that market their services to managed IT service providers - organizations similar to ConnectWise.
Our assessment is that Storm-0940 is one of multiple operators using a fork or derivative of ARTEX, each with different motives, that all conducted reconnaissance and intrusion campaigns during September and October 2026. Some of the similarities in these attacks may also be the result of using shared agent skills that can be integrated with these platforms.
Recommendations
Auth0
Run the open source CheckMate for Auth0 tool to identify risky tenant configuration before it can be discovered by offensive AI agents. CheckMate for Auth0 concretely recommends improvement in tenant security posture to mitigate all observed attacker behavior in this advisory.
Block signups via API when allowing signups via Auth0 Universal Login. Agents commonly register accounts by calling the Auth0 Authentication API directly, which can skip protections applied in Universal Login.
Implement detections to monitor your tenant for signups from disposable email domains favored by attackers. Further detections are provided in the Auth0 detection catalog on GitHub.
Monitor suspicious account linking behavior across your tenants to detect the potential account takeover of federated accounts.
Migrate away from passwords as the primary factor of authentication for users and move to phishing-resistant factors like passkeys.
If using passwords, block accounts that attempt to log in with breached credentials.
Delete fraudulently registered accounts and revoke sessions and tokens as soon as they are identified. Remove any attacker-enrolled factors. If you identify a large number of fraudulent users, engage Auth0 support for assistance.
Use Auth0 curated blocklist to block commonly-used attacker infrastructure.
Layer bot detection with CAPTCHA challenges, rate limiting, and the recommended controls above.
Use email verification methods like one-time passwords to prevent unwitting users from accidentally verifying the attacker’s email address.
Okta Workforce Identity
Allowing self-service registration is a prerequisite for many of the attacks described in this advisory. Disable or restrict it for workforce users.
Disable automatic linking for any roles assigned administrative permissions when using SAML as an identity provider. A malicious admin on an external identity provider could craft a legitimate assertion containing the identity of a privileged account within the service provider and gain privileged access. See the help documentation for more information.
Disable the ROPC grant flow whenever possible.
Enforce phishing resistant authentication by enrolling users in Okta FastPass or passkeys and enabling phishing resistance in app sign-in policies. Requiring phishing resistant factors fully mitigates risk introduced by allowing passwords as a factor while preventing attacks that rely on phishing.
Enable Okta ThreatInsight in log and enforce mode.
Deny or require higher assurance for requests from rarely-used networks. Okta network zones allow administrators to set policies that deny access to Okta-protected resources by geolocation (country), ASN, IP, or IP service category. IP service categories match IPs to known anonymizing services (VPNs, proxies).
When using SaaS applications, require that they:
Support centralized identity federation and authentication using single sign-on.
Implement and enforce SCIM wherever possible in apps to support automated access provisioning, deprovisioning, and entitlement management.
Support allowlisting by IP for interactive and non-interactive (non-human identities) user access.
Support specified logging and alerting for real-time detection and other monitoring.
Request support to run Threat Exposure Analyzer report against your orgs to determine gaps in identity security best practices.
Okta Customer Identity
Block registrations from disposable email domains by implementing Okta Workflows or Identity Threat Protection rules that evaluate the email domain in all new account registrations.
Migrate away from passwords as the primary factor of authentication for users and move to phishing-resistant factors like passkeys.
Disable the ROPC grant flow whenever possible.
If using passwords, block accounts that attempt to log in with breached credentials.
Layer bot detection with CAPTCHA challenges, rate limiting, and the recommended controls above.
Enable Okta ThreatInsight in log and enforce mode.
Okta customers can find the detailed indicators here. We recommend these indicators be used as context clues to start investigations, not as indicators that a compromise definitely occurred.
A note on estimative language
Okta’s Threat Intelligence teams use the following terms to express likelihood or probability as outlined in the US Office of the Director of National Intelligence, Intelligence Community Directive 203 - Analytic Standards.
Likelihood | Almost no chance | Very unlikely | Unlikely | Roughly even chance | Likely | Very likely | Almost certain(ly) |
Probability | Remote | Highly improbable | Improbable | Roughly even odds | Probable | Highly Probable | Nearly Certain |
Percentage | 1-5% | 5-20% | 20-45% | 45-55% | 55-80% | 80-95% | 95-99% |
Brett Winterford, Mathew Woodyard, Katie Nickels, Cody Labrecque, Yang Wang, and Jeremy Kirk also contributed to this research.
This advisory is provided for informational purposes only, without warranty or liability, does not constitute professional advice, and should not be relied upon to address every aspect of the subject discussed herein. Each customer remains solely responsible for consulting qualified advisors, evaluating its own cybersecurity risks, and selecting and implementing the security practices most appropriate for its specific operational needs.
