The Password Reset That Came From an Auth0 Dev Tenant

The email was a password reset confirmation. Clean branding. Professional template. The sender domain had been registered since 2003. SPF passed. DKIM passed. DMARC passed under a p=reject policy. ARC passed. Composite authentication returned compauth=pass. The two embedded links pointed to auth0[.]com, one of the most widely used identity platforms on the internet.

Link scanners rated everything clean. The one detail that mattered was four characters long: dev-.

A Production Password Reset From a Development Tenant

The message arrived from stentech[.]com, a manufacturing domain registered in 2003 with AWS Route53 DNS and a properly configured M365 environment. The email was routed through Office 365 outbound protection. Every authentication protocol confirmed the message was sent by authorized infrastructure.

The body followed standard Auth0 password reset template styling with StenTech branding. "If this was you, confirm the password change." No personalization, no recipient name, no account-specific details. Generic text designed to apply to anyone.

The two call-to-action links both pointed to dev-gb18votbfqwgpba7.us.auth0[.]com. The first linked to /u/reset-password/change. The second to /u/reset-verify, a path that does not appear in Auth0's standard Universal Login documentation. A dev- prefixed tenant is Auth0's designation for free-tier or development environments. It has no place in a production password reset workflow. The attacker either provisioned a throwaway Auth0 dev tenant or compromised an existing one, then configured it to harvest credentials submitted through the reset flow.

Why Every Scanner Said Clean

This is the core challenge with identity platform abuse. The links resolve to auth0[.]com, a domain with impeccable reputation that serves thousands of legitimate organizations. URL reputation engines evaluate the root domain, not the tenant prefix. auth0[.]com is trusted. Therefore dev-gb18votbfqwgpba7.us.auth0[.]com inherits that trust, even though the dev tenant behind it is attacker-controlled.

The sending domain compounds the problem. stentech[.]com is a real company with a 20+ year registration history, a strict DMARC policy, and legitimate M365 infrastructure. This maps to T1078.004 (Valid Accounts: Cloud Accounts). The attacker compromised an established M365 account and used it as the delivery vehicle, inheriting every trust signal the domain had built over two decades.

No attachments to scan. No newly registered domains to flag. No failed authentication to trigger alerts. The entire attack operated inside legitimate infrastructure from end to end.

See Your Risk: Calculate how many threats your SEG is missing

The Behavioral Signals That Authentication Cannot See

Themis, the IRONSCALES Adaptive AI engine, evaluated the message beyond its authentication results. The sender had no prior communication history with the recipient organization. A manufacturing company sending Auth0 password resets to employees at an unrelated company is a behavioral anomaly that no protocol check evaluates. The generic body with zero personalization, combined with the first-time sender signal, pushed the confidence score past the quarantine threshold.

The dev- tenant prefix is the kind of detail that automated detection needs to parse at a granular level. It is not enough to evaluate whether a URL points to a trusted root domain. The subdomain, the path, and the tenant designation all carry signal. A dev-prefixed identity tenant in a production password reset is as suspicious as a same-day-registered domain, but it arrives wrapped in the reputation of a platform that processes billions of legitimate authentications.

Indicators of Compromise

MITRE ATT&CK Mapping