Bonus farming on instant-account signups

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 server-side call to POST /v1/evaluate. An example response (an excerpt) for a session like the ones above, with the new account's ID sent as accountId:

{
  "decision": "block",
  "risk_score": 94,
  "reasons": [
    "proxy_detected",
    "antidetect_browser",
    "multi_account_device"
  ],
  "network": {
    "vpn": false,
    "proxy": true,
    "datacenter": false,
    "tor": false,
    "residential": false
  },
  "device": {
    "antidetect": true,
    "automation": false,
    "tampering_score": 0.9,
    "linked_accounts": 11,
    "multi_account": true
  }
}

Two fields carry most of the weight. network.proxy is true while network.datacenter is false: the exit is a consumer address relaying someone else's traffic, which is invisible to any tool that treats "not a datacenter" as "clean". A proxy is a block on its own by default. (network.residential is false whenever proxy or datacenter is true, so it says nothing about the ISP behind a proxy.) And device.antidetect is a statement about the browser environment rather than about the fingerprint value, so a fresh profile per account does not reset it: the spoofing itself is what gets flagged.

device.linked_accounts appears only when you send accountId. It is per-customer and hash-only: it counts how many of your accounts this device has been seen with, never anyone else's, and adds multi_account_device once that count passes one. A profile tool that really does mint a new device each time keeps this at 1, which is why the proxy and fake-browser signals, not the count, carry the block.

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.

If you send the email field, a disposable domain adds disposable_email, which lifts an allow to review and never blocks on its own. Start in watch mode: log each decision and let every signup through until the log matches what finance and KYC already know, then enforce.

On the console's Rules tab, a rule changes the decision only for the signal it names. "Multi-accounting = Review" sends an otherwise clean linked device to review and leaves the response above a block, because the proxy and fake-browser signals keep their default weight.

The arithmetic

The figures below are a worked model, not a measurement. Replace the model values with yours; the structure is what matters.

Gross exposure is €20 × 1,400 = €28,000 in bonus liability, plus 1,400 × €1.80 = €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. Maskbreak publishes no detection rate because none has been measured.

The reason to model it this way: two of the biggest levers are yours before any detection product, the bonus value and the length of the campaign window. Halving the window can move exposure more than a better filter does, 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.

How each tool shows up, and what an app should do about it, is in the antidetect browser directory and the antidetect detection write-up. For the broader pattern, see the bonus abuse and multi-accounting playbooks.

The regulatory angle

For a regulated institution, mass fake registration is not only a bonus loss. Fake accounts are the raw material for mule networks, an onboarding spike has to be explained to whoever reviews your AML monitoring, and a KYC queue that stretches from hours to days has its own consequences under onboarding obligations. That often moves the case for screening at registration from the marketing budget to the compliance one. Maskbreak adds evidence before KYC runs; it does not replace KYC, document checks or transaction monitoring. (This is a framing, not legal advice.)