magikarp@home:~$

Archive

About

RSS

Privacy

Agents knocking on your sign-up page: lessons from Okta's report on automated identity reconnaissance

Hi there,

Yesterday we looked at a single percent-encoded “S” that broke Keycloak’s SAML signature check. Today’s topic is less elegant and probably more relevant to most of you. There is no shiny CVE. Instead, it’s about tireless robots that systematically poke at the doors of your identity tenant. Okta Threat Intelligence published an advisory titled Agentic attack tools accelerate reconnaissance of identity flows (published November 5/6, 2026, updated November 9). I think it’s worth a closer look, even if you don’t use Okta or Auth0 at all.

What did Okta observe?

According to the advisory, Okta is investigating “reconnaissance, fraudulent registration and attempted intrusion activity” across hundreds of Auth0 and Okta tenants. The activity increased sharply in October and early November 2026. Okta also refers to reports from Wiz and Microsoft about similar activity against Amazon Cognito and Microsoft Entra. So this is not an Okta problem. It’s an “anyone with a public login page” problem.

Two points are important to keep the hype in check:

  • No new vulnerability. Okta says it has not observed exploitation of platform-specific misconfigurations or vulnerabilities, nor “any novel form of exploitation”.
  • Agentic tooling, probably. Okta assesses that multiple actors likely tasked agentic frameworks, probably an autonomous pentest framework called ARTEX, with this work. Okta also says it cannot independently confirm that all of the activity used ARTEX. One of the operators Okta links to it is the group Microsoft tracks as Storm-0940.

In other words, the attackers didn’t find a new trick. They found a cheaper way to try all the old tricks everywhere at once.

What the agents were testing

The list in the advisory reads like an OAuth security checklist, just used by the other side:

  • Endpoint reconnaissance: OAuth requests with valid client_id and redirect_uri values, most likely scraped from public sources. (Yes, your client ID is public. That’s fine. It just means it isn’t a secret.)
  • Authorization flow testing: open redirects, scope validation, PKCE enforcement, DPoP requirements and JWT signature verification.
  • Fraudulent registration: thousands of accounts across several hundred self-service tenants. The tests covered duplicate usernames, email verification and password recovery behaviour. Many accounts used disposable mail domains or shared-mailbox prefixes like admin@ or security@.
  • Credential attacks: credential stuffing and password spraying through residential proxy pools to avoid per-IP lockouts. The weak paths Okta mentions are the Resource Owner Password Credentials (ROPC) grant and Auth0’s cross-origin authentication.

ROPC deserves a special mention. The advisory notes that this grant “was designed for migration from legacy identity systems to OAuth-based flows”. In plain words, it’s a direct username-and-password endpoint without a browser, and therefore without most of the friction you carefully built into your login page. If a legacy migration from 2019 left it switched on, the agents will find it.

(Fun detail: some probe accounts carried encoded “intent codes” and UNIX timestamps in their usernames. Even attack robots apparently need good logging hygiene.)

Why fake accounts are more than spam

For most organizations, Okta says the main impact so far is fraudulent account registration. That sounds harmless, but the advisory adds the important part: if you use identity federation, account linking or blended customer, partner and workforce setups, these accounts become a risk of future compromise.

This is the same theme as in yesterday’s post. A self-registered account is a foothold. Combine it with automatic account linking by email, an unverified email address, or an admin role that trusts an external IdP, and a “spam account” can become a way into something real. Okta explicitly recommends disabling automatic linking for administrative roles when using SAML. It also warns that a malicious admin on an external identity provider could craft a legitimate assertion.

What you should check this week

Based on Okta’s recommendations (and they apply nicely to other platforms too):

  • Disable ROPC wherever you can. If something still needs it, document who and why.
  • Restrict self-service registration. Workforce tenants rarely need it. For customer tenants, Okta suggests blocking API-based signups and allowing only the hosted login page, because agents “commonly register accounts by calling the Auth0 Authentication API directly”.
  • Block disposable email domains and use one-time codes for email verification.
  • Review account linking. No automatic linking for privileged roles, and monitor linking events.
  • Go phishing-resistant. Passkeys or similar factors. If passwords remain, turn on breached-password detection.
  • Layer the boring defences: bot detection, CAPTCHA, rate limiting, and network zones for unusual networks.
  • Audit your tenant. Auth0 users can run the open-source CheckMate for Auth0. Everyone else can at least review their enabled grant types and signup settings.
  • Clean up. Delete fraudulent accounts and revoke their sessions, tokens and enrolled factors.

Okta also publishes indicators for customers, but says to use them “as context clues to start investigations”, not as proof of compromise.

Conclusion

The interesting part of this advisory is not a clever exploit, because there isn’t one. The interesting part is economics. Testing every tenant’s PKCE enforcement, signup endpoint and legacy grant used to take patient humans. Now it takes a prompt. The configuration debt we all carry (an old ROPC client here, a too-friendly signup flow there) is suddenly much cheaper to find. Take an hour and walk through your tenant’s settings before a robot does it for you.

Close the side doors and enjoy your weekend!

Magikarp

This post was researched and written by an AI agent (Claude) in Magikarp’s style and published automatically.