The Auth0 Developer Tenant That Passed Every Security Check (Because It Was Real)

The phishing endpoint wasn't a lookalike domain. It wasn't a compromised WordPress site. It was dev-j7v60qq2v0qvkdx2.us.auth0.com, a real developer tenant on Auth0's identity platform, owned and operated by Okta, Inc. The DKIM signature was valid. DMARC passed. The sending domain, auth0user.net, has been registered to Okta since 2016. Every link scanner in the chain returned a clean verdict, because the destination was exactly what it claimed to be: genuine Auth0 infrastructure.

The email landed in the inbox of an employee at a global manufacturing firm. It asked them to verify an account they never created.

That's the attack. No spoofing required. No infrastructure to stand up. No domains to register. The attacker signed up for a free Auth0 developer tenant, pointed it at the target's email address, and let Okta's own transactional email pipeline do the rest. According to the FBI's 2024 Internet Crime Report, business email compromise and credential harvesting schemes accounted for over $2.9 billion in reported losses last year. Attacks like this one show why the number keeps climbing: the infrastructure is indistinguishable from legitimate traffic.

A Verification Email Nobody Requested

The email arrived from "RadarFlowStudio" with a sender address of no-reply@auth0user.net. The subject line was simple: "Verify your email." Inside, Auth0's own branding (pulled from cdn.auth0.com) rendered a polished verification card showing the recipient's exact email address and a "Verify Your Account" button.

The body contained a plaintext link to the Auth0 developer tenant subdomain, making the email look even more transparent. A footer read: "You're receiving this email because you have an account in dev-j7v60qq2v0qvkdx2." The recipient had no such account.

This maps to MITRE ATT&CK T1566.002 (Spearphishing Link) and T1598.003 (Spearphishing for Information), where the attacker uses targeted email delivery to prompt a specific action from the recipient.

The SendGrid Redirect Chain That Every Scanner Approved

The "Verify Your Account" button didn't link directly to Auth0. It ran through SendGrid's click-tracking infrastructure first: u37752131.ct.sendgrid.net, which performed a 302 redirect to the Auth0 tenant URL. This is standard behavior for transactional email platforms. SendGrid (owned by Twilio) wraps all links in click-tracking URLs, meaning the first hop in the chain was a domain with spotless reputation.

The redirect resolved to dev-j7v60qq2v0qvkdx2.us.auth0.com/u/email-verification?ticket=jaHhpEKStfo40fmNtxay2aORmSkmbm5Z. That endpoint served an Auth0-branded page with one of two outcomes: either "Email Verified" (confirming the address is live and the recipient clicked) or "Error: Your email address could not be verified."

Both outcomes serve the attacker. A successful verification confirms the email address is active, monitored, and the recipient is willing to click unsolicited verification links. A failed verification still logs the click, confirming the mailbox is live. This is classic reconnaissance through legitimate identity provider infrastructure, a pattern CISA has flagged repeatedly.

See how many attacks your current email security is missing.

Why DKIM, DMARC, and SPF Tell Three Different Stories

The authentication results on this email are a case study in why passing checks doesn't mean clean intent.

DKIM: Passed. The signature was valid for header.d=auth0user.net with selector s1. The message body hadn't been tampered with. This is expected, because Auth0's transactional pipeline legitimately signs outbound email on this domain.

DMARC: Passed. The header.from=auth0user.net aligned with the DKIM signing domain. The domain's DMARC policy is set to p=quarantine, and the message met all alignment requirements.

SPF: This is where it gets interesting. Two SPF evaluations ran at different hops. The first, at the Cisco IronPort gateway (esa.hc1333-60.eu.iphmx.com), returned SPF Pass for the originating IP 159.183.105.195 (an authorized Auth0 sending IP listed in em2867.auth0user.net's SPF record). The second evaluation, at Microsoft's protection.outlook.com edge, returned SPF Fail for 23.90.105.225 (the IronPort relay IP), which is not in the SPF record for em2867.auth0user.net.

This split SPF result is the kind of signal that gets buried in logs. The Verizon 2024 DBIR found that 68% of breaches involved a human element, and mixed authentication signals like this are exactly the kind of ambiguity that leads to inaction. The message passed enough checks to land in the inbox.

IRONSCALES flagged this email at 76% phishing confidence. Not because authentication failed (it mostly didn't) but because Themis identified behavioral patterns that authentication cannot evaluate: first-time sender to this mailbox, language patterns consistent with credential phishing, and community intelligence from similar incidents across the IRONSCALES network of 35,000+ security professionals. The email was classified as Credential Theft and quarantined before the recipient could interact with it.

Indicators of Compromise

Defending Against Identity Platform Weaponization

This attack didn't require the attacker to register a domain, configure a mail server, or build a credential harvesting page. They signed up for a free Auth0 developer account (available to anyone with an email address), created an application called "RadarFlowStudio," and triggered a verification email to the target. Total infrastructure cost: zero.

The pattern isn't unique to Auth0. Any identity platform with a free tier and transactional email capabilities (Firebase Auth, AWS Cognito, Azure AD B2C) can be weaponized the same way. Microsoft's 2024 Digital Defense Report documented a 146% increase in identity-based attacks year over year, and platform abuse is a growing contributor.

Here's what actually helps against this class of attack:

Flag unsolicited verification emails. If a user didn't sign up for a service, a verification email from that service is suspicious by definition. Policies that surface first-time senders from identity provider domains give SOC teams early visibility.

Don't trust authentication alone. DKIM pass plus DMARC pass plus a clean link scan does not equal safe. When the attacker uses the platform's own infrastructure, those checks confirm the platform is working correctly. They say nothing about intent.

Monitor for VERP patterns. The Return-Path on this email (bounces+37752131-912e-akihiko.sumi=akm.com@em2867.auth0user.net) encodes the target's full email address. VERP (Variable Envelope Return-Path) encoding in unsolicited email is a strong signal of automated targeting.

Deploy behavioral detection. Authentication tells you who sent the email. Behavioral analysis tells you whether that sender has any business emailing your users. That distinction is the difference between a clean inbox and a compromised account.