How the attack works
A signup bonus turns account creation into a priced transaction. If an account is worth €20 and the cost of producing one is under €20, the gap is the attacker's margin and the only question left is throughput. Everything below exists to raise throughput.
A working stack has four layers, and each one defeats a specific control:
- Residential proxy pool — each registration exits through a different real consumer ISP address, usually in a bonus-eligible country. Defeats per-IP velocity limits and geo rules, and returns nothing on a datacenter blocklist because it is not a datacenter.
- Antidetect browser (Kameleo, GoLogin, Multilogin and the second tier) — a separate profile per account with its own canvas, WebGL, font list, screen metrics and timezone. Defeats device fingerprinting, which is specifically the control most platforms rely on to catch repeat signups.
- Disposable or catch-all email with plausible name formatting. Defeats naive "is this Mailinator" string matching, and passes the confirmation click because the mailbox is real.
- Scripted form fill with human-shaped timing — enough jitter to clear behavioural heuristics tuned for obvious automation.
Run together, these produce registrations with a unique IP, a unique device fingerprint and a working inbox. There is no repeated value anywhere for a rules engine to count, which is why the attack is usually discovered by finance rather than by the fraud stack.
Why the usual defences miss it
IP reputation answers "has this address misbehaved before". A residential proxy exit is a real subscriber line in a real suburb, so the honest answer is no. Reputation is strongest on datacenter ranges and public VPN exits and structurally weakest here.
Device fingerprinting answers "have I seen this browser before". An antidetect profile is a genuinely new browser environment each time, so again the answer is no — and it is truthful. The tool is not being fooled; it is being asked a question that no longer discriminates.
Email validation answers whether a mailbox exists and accepts mail. Catch-all domains and long-lived disposable providers both pass.
KYC catches this eventually, which is the problem: it runs after the account exists, costs money per check, and the bonus liability was booked at registration. A backlog is the normal outcome, not a sign anything malfunctioned.
The common thread is that each control asks a question the attacker has already paid to answer. What has not been paid for is the relationship between the connection and the browser at the moment of the request.
What the verdict returns
Screening at the registration form — before the confirmation email is even queued — is one request. The response for a session like the ones above:
{
"decision": "block",
"risk_score": 94,
"reasons": [
"antidetect_browser",
"residential_proxy",
"browser_tampering"
],
"network": {
"vpn": false,
"proxy": true,
"datacenter": false,
"tor": false
},
"device": {
"antidetect": true,
"tampering": true,
"linked_accounts": 11,
"multi_account": true
}
}Two fields carry most of the weight. network.proxy is true while network.datacenter is false — that combination is the residential proxy signature, and it is invisible to any tool that treats "not a datacenter" as "clean". And device.antidetect is a statement about the browser environment rather than about the fingerprint value, so a fresh profile per account does not help: the spoofing itself is the signal.
device.linked_accounts is per-customer and hash-only. It counts how many of your accounts this device has touched, never anyone else's.
Routing, and the mistake worth avoiding
A verdict is not a policy. The routing that works on a signup form:
block— refuse at form submission with a generic error. Do not explain which signal fired; that is free tuning feedback for the attacker.review— let the account through and route it to enhanced KYC or a bonus hold. This is where a plain VPN lands.allow— normal flow, no added friction.
The mistake is refusing on review. A large, entirely legitimate population uses a VPN full time, and in a cross-border consumer product that population skews toward exactly the customers you spent money acquiring. Holding the bonus rather than the account costs a real customer nothing and removes the attacker's entire revenue.
The arithmetic
The figures below are a worked model, not a measurement. Replace the four inputs with yours; the structure is what matters.
| Input | Model value | Yours |
|---|---|---|
| Bonus per new account | €20 | — |
| Fake registrations in a campaign window | 1,400 | — |
| Bonus liability booked at registration | €28,000 | — |
| KYC cost per manual review | €1.80 | — |
Gross exposure is the first three multiplied out: €28,000 in bonus liability, plus €2,520 in KYC processing on reviews that were never going to convert. The recoverable share depends entirely on your catch rate, which is a number you have to measure on your own traffic rather than take from a vendor page — ours included.
The reason to model it this way: the sensitivity is almost all in the bonus value and the window length, not in the catch rate. Halving the campaign window is often a bigger lever than any detection product, and it costs nothing to try first.
Why antidetect browsers break device fingerprinting
Antidetect browsers are commercial products — Kameleo, GoLogin, Multilogin and a long second tier — built to present a different, internally consistent device to every site. They randomise or pin canvas and WebGL output, font enumeration, screen metrics, hardware concurrency, timezone and dozens of smaller attributes, and they keep each profile stable so a single account can return convincingly.
For a platform whose multi-account defence is "same device fingerprint, same person", this is a complete bypass rather than a degradation. The counter is not a better fingerprint. It is looking for the evidence that an environment is being managed — inconsistencies between layers that a real browser has no reason to produce, and that a spoofing tool has to produce in order to spoof at all. That signal survives the profile being new, which is the property that matters here.
We publish what we actually see, tool by tool, in the antidetect detection write-ups.
The regulatory angle
For a PSD2-regulated institution, mass fake registration is not only a bonus loss. Account-opening velocity outside filed AML monitoring patterns is a reportable anomaly, and a KYC queue that stretches from hours to days has its own consequences under onboarding obligations. That reframes the spend: the case for screening at registration is usually made on the compliance line rather than the marketing one, because the bonus is recoverable and a filed exception is not.