During an investigation into a large-scale automated account creation attack targeting one of our customers, we observed a burst of suspicious registration activity.
In less than a week, the attackers attempted more than 80,000 registrations.
While investigating the registrations, we identified several unusual email domains being used during the verification process. These domains were not part of any public disposable email service and appeared to belong to a custom email infrastructure.
Pivoting on this infrastructure led to an unexpected discovery.
One of the servers associated with the email service exposed a misconfigured administrative panel without authentication.
The dashboard provided a real-time view into the attackers’ verification infrastructure, exposing internal operational metrics such as:
- verification success rates
- email domains used by the service
- real-time verification requests
- internal worker activity
This type of visibility into attacker infrastructure is extremely rare. Instead of inferring how the attack operates, we were able to directly observe how their automated email verification pipeline works at scale.
An exposed attacker dashboard
One of the servers associated with the email infrastructure exposed an administrative interface without authentication.
The panel provides a real-time overview of the system operating the email verification service.
The interface exposes several internal operational metrics, including:
- total verification requests
- verification success rate
- email polling statistics
- worker activity
- recently processed verification codes
The presence of these metrics provides a rare opportunity to observe how an automated verification pipeline operates from the attacker’s perspective.
Some values in the screenshot, such as the exact verification success rate, have been intentionally partially obscured.
These metrics relate to the internal monitoring of the attackers’ infrastructure and can be easily misinterpreted without the full context of how defensive systems operate. In practice, detection systems like Castle generate multiple signals and risk scores, and customers may apply different mitigation strategies depending on their workflows. Suspicious accounts are not always blocked immediately during registration, and may instead be handled through downstream controls such as delayed enforcement or account monitoring.
A real-time view into the verification pipeline
Beyond the web interface, the dashboard also relies on an API that exposes internal statistics about the verification system.
Example response returned by the API (domains partially anonymized):
{
"verification": {
"success":<num_success>,
"fail":<num_fail>,
"success_rate":"<perc_success>"
},
"requests": {
"verification":51360
},
"pop3": {
"total_connections":88409
}
}
These metrics provide a direct view into how the attackers process verification emails at scale and are also reflected in the monitoring dashboard.
These metrics illustrate the operational scale of the infrastructure. The system continuously polls mailboxes, extracts verification codes from incoming emails, and exposes them through an API that the automation can query in real time during the account creation flow.
The email infrastructure behind the attack
The dashboard and associated API responses also reveal the email domains used by the verification system.
To avoid providing visibility to the operators, the domain names are partially anonymized in the examples below.
Examples:
fe<anon>[.]com
jo<anon>[.]com
ju<anon>[.]com
lu<anon>[.]com
ru<anon>[.]com
The domains follow a consistent naming pattern:
[random letters]mail.com
Each domain is used to generate large numbers of unique email addresses during the registration process.
Example addresses observed in the system include:
firstnameLastname1234@fe<anon>[.]com
firstnameLastname5678@ru<anon>[.]com
Unlike public disposable email providers, these domains appear to be part of a custom email infrastructure operated by the attackers specifically to handle verification emails generated during automated account creation.
Mapping the email infrastructure
Looking at the DNS configuration of these domains reveals several clear correlations.
Shared MX infrastructure
All domains use the same MX structure, mail.<domain>:
For example:
fe<anon>[.]com → mail.fe<anon>[.]com
ju<anon>[.]com → mail.ju<anon>[.]com
Resolving these mail hosts shows that they point to the same backend server. This indicates that the different domains are backed by a single centralized mail system responsible for receiving verification emails and making them available to the automation pipeline.
The domains also share the same DNS provider and nameserver pair, further strengthening the infrastructure linkage between them.
Taken together, these signals create a strong infrastructure fingerprint suggesting the domains are operated as part of the same verification service.
How the verification pipeline operates
The exposed dashboard also reveals how the system processes incoming verification emails.
The infrastructure appears to operate as a centralized email verification pipeline supporting the automated account creation workflow.
The process can be summarized as follows:
During registration, the automation generates email addresses using the attacker-controlled domains. When the target website sends a verification email, it is received by the centralized mail server.
The system then continuously polls the mailboxes, extracts verification codes from incoming emails, and exposes them through the API so that the automation can complete the verification step.
The dashboard also shows that multiple workers are used to scan mailboxes in parallel.
Example worker statistics (anonymized):
fe<anon>[.]com workers: 3
jo<anon>[.]com workers: 3
ju<anon>[.]com workers: 3
Each worker performs thousands of mailbox scans during the lifetime of the service, allowing the system to process verification emails in near real time during the automated registration flow.
What the attack looks like in production traffic
While the exposed dashboard reveals how the attackers process verification emails, the traffic observed on the protected application shows how the automated registrations are performed.
The attack combines several evasion techniques designed to make automated sessions resemble legitimate mobile users:
- realistic mobile browser fingerprints
- simulated human interaction events
- fingerprint randomization
- large residential proxy networks
- very low activity per IP address
Individually, these signals can resemble normal user traffic. Detecting the attack requires analyzing the combination of these behaviors across sessions.
Browser fingerprint spoofing
Most registration attempts claim to originate from modern mobile browsers.
A typical user agent observed during the attack:
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Mobile Safari/537.36
The browser fingerprint attributes are globally consistent with this identity.
For example, WebGL renderer values observed during the attack include:
Mali-G77
Adreno (TM) 740
Mali-G710
These GPUs are commonly found on Android devices and align with the claimed mobile browser profile.
The bots also apply canvas fingerprint randomization techniques, producing slightly different canvas outputs across sessions.
Across the attack we observed a wide variety of fingerprints, suggesting the automation framework rotates or generates fingerprints between sessions.
Human-like interaction patterns
The bots also attempt to simulate realistic user behavior during the registration flow.
Examples of observed interactions include:
- touch events triggered during page interaction
- keystroke events while filling registration forms
- typing speeds within typical human ranges
At first glance the combination of fingerprint and interaction behavior appears consistent with legitimate mobile users.
However, deeper analysis reveals subtle inconsistencies in both behavior and fingerprint attributes that allow these sessions to be identified as automated. These inconsistencies are not trivial and typically cannot be detected using simple heuristics.
Residential proxy infrastructure
The attack traffic is distributed across a large residential proxy network. Requests originate from thousands of IP addresses belonging to major US internet providers.
The graph below shows the number of events observed over seven days from the top ISPs involved in the attack.
Most requests originate from:
- Comcast
- Spectrum
- AT&T
Each IP address typically performs only one or two registrations before disappearing. This strategy makes traditional rate limiting largely ineffective. Blocking individual IP addresses does not significantly reduce the attack volume because the automation continuously rotates through new residential addresses.
Detection and mitigation strategies
Organizations facing similar attacks should rely on a combination of detection signals rather than a single indicator.
The techniques observed during this investigation highlight several areas where defenders can improve detection.
Behavioral analysis
- Subtle inconsistencies in interaction patterns, event timing, and navigation flows can reveal automated sessions even when bots attempt to simulate human behavior.
- Even when automation generates realistic touch and keyboard events, longer session sequences often expose patterns that differ from genuine user behavior.
Device and browser consistency checks
- Sophisticated bot frameworks increasingly spoof browser fingerprints that appear globally consistent with real devices.
- However, small inconsistencies can still appear when comparing attributes that should normally remain consistent with each other.
Infrastructure correlation
- Attackers frequently rely on clusters of domains that share the same MX configuration, mail servers, or DNS infrastructure.
- Identifying relationships between these domains can reveal attacker-controlled email verification systems used to automate account creation at scale.
