The history of anti-detect browsers: from multi-accounting to fingerprint spoofing

A normal browser tries to be one consistent person. It carries one user-agent, one set of fonts, one canvas signature, one timezone, and it does its honest best to look the same on every visit so that the web works. An anti-detect browser does the opposite. It tries to be many people, convincingly, from a single machine, and to make each of those people look like a different real device sitting in a different home. The question that produced this whole tool category is narrow and practical: how do you run fifty Facebook ad accounts, or two hundred sneaker checkout sessions, or a thousand scraper sessions, without the site noticing that all of them share a device?

The answer turned into an industry. It started in places nobody advertises on a résumé, drifted into affiliate marketing where multi-accounting is the business model, and ended up as a stack of venture-shaped companies selling Chromium forks by subscription. The interesting part is not the marketing. It is the technical migration underneath: spoofing that began as a JavaScript layer painted over a normal browser, and was steadily forced down into the rendering engine itself, because the detection moved down with it.

This post traces that line. It opens with the carding-forum origin and the first tools that called themselves antidetect. Then the affiliate and multi-accounting crossover that made the category a product. Then the commercial generation, Multilogin and the browsers that chased it, and the shift from Firefox patches to engine-level Chromium forks. Then the fingerprint-harvesting economy that fed all of it, the Genesis Market takedown that exposed the supply chain, and the scraping crossover where anti-detect engines met Puppeteer and Playwright. The through-line is a single arms race, and it has been running on a four-to-six-year cycle that keeps getting shorter.

2014-2016: the carding origin

The first tools that wore the word “antidetect” were not built for marketers. They were built for fraud. Fingerprinting had become the thing standing between a stolen credit card and a successful purchase, because banks and payment processors had started recording the device that placed each order. A fraudster who logged in from the same browser fingerprint that had just been flagged got caught. So the requirement was obvious: a way to present a different, plausible device for each session, ideally a device that matched the victim whose card you were using.

The name most associated with that early period is Vektor T13, the handle of Dmitry Momot, who circulated a Firefox-based antidetect tool that some users trace back to around 2016. The original project was source code for a Firefox build that could rewrite the values a website reads when it tries to identify a device. Over time Momot moved away from the browser-only approach and toward virtual-machine emulation, on the reasoning that a browser cannot change everything: there are identifiers below the browser, in the operating system and the hardware, that a browser patch never touches. That observation turned out to be the central tension of the entire category, and it was already visible at the start.

The plumbing that made commercial-scale fraud practical showed up alongside the tools. In April 2016 a tool called BrowserAutomationStudio, BAS for short, appeared on a piracy forum under the handle “Atabas.” BAS is a visual automation IDE for driving Chrome without writing code, and it became the workhorse of credential stuffing and mass account registration. Its fingerprint module, FingerprintSwitcher, was introduced in February 2017 on BlackHatWorld. The pitch was simple. Instead of randomizing a fingerprint and hoping the random values are internally consistent, FingerprintSwitcher gave you access to a database of real fingerprints harvested from real devices, so the values it presented were coherent by construction.

That distinction, real-and-coherent versus random-and-spoofed, is the one that separates a tool that survives detection from a tool that gets caught on the first correlation check. It is worth holding onto, because every generation that follows is a different attempt to win that same argument.

2016-2019: the affiliate and multi-accounting crossover

Fraud built the techniques. Affiliate marketing made them a market. The reason is structural: large parts of performance marketing depend on running many accounts that the platform wants you to run as one. An affiliate testing twenty ad creatives across Facebook, Google, and a dozen native networks needs twenty clean accounts, because the platforms ban linked accounts and treat one flagged account as grounds to flag the rest. The same logic applies to e-commerce sellers running multiple storefronts, to social media agencies managing client accounts, and to anyone whose livelihood is one-device-many-identities. Multi-accounting is against the terms of service of almost every platform that matters, and it is also a large, semi-legitimate, money-making activity. That gap is exactly the market an anti-detect browser sells into.

So the tools changed costume. The same fingerprint-spoofing capability that hid a carder now hid a media buyer’s tenth ad account, and the vocabulary shifted from “antidetect” to “multi-accounting” and “profile management.” The product became a dashboard: spin up a browser profile, give it a fingerprint, attach a proxy, log into the account, and keep that profile’s cookies and storage isolated from every other profile so the platform never sees the overlap. Proxy integration stopped being optional. An anti-detect profile without a matching residential IP is a device claiming to be in Ohio while its packets arrive from a datacenter in Frankfurt, and that mismatch is one of the first things any detector checks.

*The whole product in one picture: one machine, many isolated profiles, each profile a self-consistent bundle of fingerprint, proxy, and cookie jar that should look to a server like a separate device in a separate place.*

The leading commercial name of this era is Multilogin. The Estonian company behind it incorporated in 2014 and put the product on the market in 2015, and for years it was the default answer when someone asked which anti-detect browser to buy. Multilogin’s first engine, Stealthfox, was a Firefox build. It masked the obvious surfaces, user-agent, canvas, WebGL, fonts, and isolated cookies and storage between profiles, which was enough for the detection of the time. The interesting limitation, in hindsight, is what it did not control. Stealthfox spoofed the values a website reads through JavaScript and through the browser’s reported metadata, but it did not reach down to the TLS handshake or the deeper behavioral signals that detection vendors would soon be reading. The history of browser fingerprinting and the history of anti-detect browsers are the same arms race seen from opposite ends, and at this point the defenders were about to add a layer the spoofers could not paint over from the top.

2019-2021: the commercial generation

The market filled in fast once the model was proven. GoLogin entered in 2019 with a Chromium fork it called Orbita; its native engine rolled out in December 2019. Dolphin Anty arrived in 2021, built by Denis Zhitnyakov and aimed squarely at the affiliate and ads community where it caught on first. Octo Browser launched in 2022 and positioned itself explicitly against the incumbent, offering comparable fingerprint quality at a fraction of Multilogin’s price. AdsPower, Incogniton, Kameleo, MoreLogin, and a long tail of others filled out a category that now had real subscription revenue and real competition on price and engine quality. The names rotate; the shape does not.

Two technical choices defined this generation. The first was Chromium over Firefox. The web’s traffic is overwhelmingly Chrome, so a profile that wants to disappear into the crowd should be Chrome-shaped, and the detection signal space for Chromium is the one detectors invest in most. Multilogin’s own answer was Mimic, a heavily modified Chromium fork that replaced Stealthfox as the flagship, with Stealthfox kept around for the cases that genuinely needed a Firefox identity. GoLogin’s Orbita, Octo’s engine, and most of the others made the same bet.

The second choice was how to spoof. There are two ways to make a browser lie about its fingerprint, and the difference between them is the entire plot of the next few years. The shallow way is to inject JavaScript that intercepts the properties a fingerprinting script reads, replacing navigator.hardwareConcurrency or the return value of a canvas toDataURL call with something else before the script sees it. The deep way is to patch the browser engine itself, so the spoofed value is what the engine genuinely produces, with no JavaScript interception layer to detect. Every serious tool started shallow and was pushed deep.

*The shallow approach overrides a getter, which leaves a seam a script can probe. The deep approach changes what the engine returns, so the spoofed value carries no JavaScript-visible tell. The whole category migrated rightward.*

The engine-level turn and why it happened

A JavaScript override is detectable because JavaScript can inspect itself. If a tool replaces navigator.hardwareConcurrency with a proxy or a redefined getter, a fingerprinting script can ask that getter to describe itself. Native browser functions, when you call toString() on them, return a string containing [native code]. An overridden function does not, unless the tool also patches toString, and then toString itself becomes the thing to probe, and so on down a recursion of patches that each leave their own seam. Castle’s reverse-engineering of the Undetectable browser shows exactly this: for the non-Chromium profiles it spoofs in JavaScript, calling toString().toString() peels back the masking and reveals obfuscated code where native code should be, and forcing an exception inside document.getElementsByTagName surfaces a stack trace naming the tool’s own injected functions. The lie is in the call stack.

Patching the engine removes that surface. If a modified Chromium build genuinely reports eight CPU cores because its C++ was changed to report eight, there is no JavaScript getter to interrogate, no toString to betray it, no injected function name in the stack. This is why the same Undetectable analysis notes that the Chrome-based profiles do their spoofing inside the chromium_framework binary rather than through injected script. It is the difference between repainting a car and re-stamping the VIN. For canvas and WebGL the better tools went further than swapping values. Multilogin’s engines, and others like them, inject noise rather than a static fake, perturbing the rendered output slightly on each read so it varies the way a real device’s output varies across machines, instead of returning one frozen value that a detector can blocklist on sight.

The reason the whole category was forced into this migration is that detection stopped trusting any single value and started correlating them. The modern detection question is not “is this canvas hash on a blocklist.” It is “do all of these signals describe the same plausible device.” A GPU renderer string that says Apple silicon paired with a user-agent that says Windows is a contradiction no real machine produces, and correlation catches it whether or not either value individually looks suspicious. Castle’s published method is blunt about this: collect as many signals as possible and check them against each other, because an anti-detect browser only has to slip on one correlation to expose the whole profile as fabricated. That is a much harder target than any single spoof, and it is why a tool can spoof fifty-five parameters correctly and still get caught on the fifty-sixth it did not know to align. The deeper history of how this entropy-versus-stability tension developed is its own story, told through the Panopticlick experiment and what it proved about how few bits it takes to make a browser unique.

There is a hard floor to all of this, and Vektor T13 named it years before the commercial tools ran into it. A browser can change what the browser reports. It cannot change the TLS stack the operating system uses to negotiate the connection, or the timing characteristics of the real hardware, or the network-level signals that arrive before a single line of JavaScript runs. TLS fingerprinting reads the ClientHello the browser sends during the handshake, and a modified Chromium build whose TLS layer does not exactly match the Chrome version it claims to be produces a signature that gives it away below the application layer entirely. The same applies to HTTP/2 fingerprinting, which reads the frame and settings ordering of the connection itself. These are signals an anti-detect browser cannot reach by editing what navigator returns, and they are exactly where detection went once the JavaScript surface got hard to win on.

The fingerprint economy underneath

Spoofing a fingerprint convincingly is hard. Replaying a real one is easier, which is why a supply chain grew up to harvest and sell real fingerprints, and that supply chain is the connective tissue between the carding origin and the commercial present.

Bablosoft’s tooling is the clearest example. FingerprintSwitcher draws on a database of more than 50,000 fingerprints collected from real desktop and mobile devices, and the company’s PerfectCanvas technology takes the idea to its logical end: rather than compute a fake canvas, it renders the canvas on a real remote device and pipes the byte-for-byte result back to the local browser, so the canvas a detector reads was genuinely produced by a real machine, just not the one it is talking to. The harvesting side of this is not hypothetical. Group-IB documented a campaign it tracked as ScreamedJungle, active from May 2024, that injected Bablosoft collection scripts into more than 115 compromised Magento storefronts, where a script gathered system data including fonts, plugins, keyboard layout, WebGPU data, media devices and battery information and posted it to a Bablosoft collection endpoint. One slice of that campaign, Italian e-commerce traffic across nine compromised sites, was estimated to be capable of collecting over 200,000 fingerprints a month.

The criminal apex of the fingerprint economy was Genesis Market, and its takedown is the clearest public document of how the whole thing fit together. Genesis sold “bots,” which in its vocabulary meant a victim’s complete browser identity: cookies, saved logins, autofill data, and the device fingerprint, all bundled together. It shipped a custom browser, distributed as a Chromium extension, that loaded a purchased victim’s fingerprint and session so a buyer could resume the victim’s logged-in sessions and sail past device-recognition checks at the bank or the retailer. The scale was substantial. At seizure the full database held around 1.5 million bots covering more than 2 million identities, with over 460,000 bots listed for sale.

*Why replay beats synthesis: a fingerprint pulled from a real device is internally consistent across every entropy source, so an operator who buys one sidesteps the correlation checks that catch a synthetically spoofed profile.*

The takedown came on 4 April 2023, in an operation named Cookie Monster led by the FBI and the Dutch National Police across seventeen countries, with around 120 arrests. Genesis was the criminal extreme, but the economics it ran on are the same economics the legitimate-looking tools run on. A real fingerprint is internally consistent across every entropy source because a real device produced it, which is precisely what defeats the correlation checks that catch a synthetic one. That is why operators in the bot ecosystem treat fingerprints as priced commodities rather than throwaway values, and why “use a real one” beat “generate a good fake” as the dominant strategy across both the criminal and the commercial sides of the line.

2022-2026: the scraping crossover

For most of its life the anti-detect browser was a human tool. A person sat at the dashboard, opened a profile, logged into an account, and clicked around. The scraping world, meanwhile, had its own separate lineage of stealth, built on top of browser automation rather than profile management. Those two lines converged, and the convergence is most of what is new since 2022.

The automation side started with puppeteer-extra-plugin-stealth, an open-source plugin from the developer known as berstend that bolted evasions onto Puppeteer. It patched the obvious automation tells, the navigator.webdriver flag, the headless quirks in navigator.languages and the plugin list, and it did so with JavaScript injected before page scripts ran. It was the same shallow approach the anti-detect browsers had already started outgrowing, and it aged the same way: the patches became signatures, and detectors learned the seams. The deeper account of why those plugins keep losing is its own post, but the short version is that a known patch is a known thing to look for.

Two events reshaped this. The first was Google unifying headless and headful Chrome. Before Chrome 112 in 2023, headless was a separate implementation with its own quirks, and a long catalog of small discrepancies told you a browser was headless. The new headless mode shares the main Chrome codebase, so those discrepancies largely vanished and the user-agent no longer carries the telltale HeadlessChrome token unless you leave it there. A correctly launched new-headless Chrome has a near-genuine fingerprint out of the box, which pulled the floor out from under a whole class of detection and a whole class of stealth patches written to hide from it.

The second event was the realization that the automation protocol itself is the tell. Driving Chrome through the Chrome DevTools Protocol leaves observable side effects, and the cleanest of these is the Runtime.enable leak: enabling the CDP Runtime domain causes the browser to serialize JavaScript objects in a way that does not happen otherwise, and a page can trip that serialization, for instance by reading the stack property of an Error at the right moment, to learn that a debugger-grade protocol is attached. No amount of fingerprint spoofing hides this, because it is not a fingerprint. It is a behavior of the control channel. That pushed the newest frameworks toward avoiding CDP altogether. nodriver, the successor to undetected-chromedriver, drives the browser through operating-system-level input instead of the DevTools Protocol, so there is no Runtime.enable to leak and no protocol seam to find. Castle’s account of the arc puts it plainly: the work stopped being about masking automation with evasive patches and became about rethinking the automation architecture so there is nothing at the protocol level to detect.

This is where the two lineages meet. The commercial anti-detect browsers, having spent years pushing their spoofing down into the Chromium engine, exposed automation endpoints. Multilogin, Kameleo and the others now ship local APIs and SDKs that let Selenium, Puppeteer or Playwright drive a profile, so a scraper gets the engine-level fingerprint spoofing of a paid anti-detect browser and the programmatic control of an automation library at the same time. The human multi-accounting tool and the headless scraping stack turned out to want the same thing, which is a browser that is simultaneously controllable and indistinguishable from a real one. The patched-from-source approach, in tools like Camoufox’s patched Firefox, and the question of patching Chromium from source versus runtime injection, are the current front of exactly the same migration that started when Stealthfox spoofed canvas in JavaScript a decade earlier.

What the line shows

The anti-detect browser is the same idea rebuilt three times for three audiences, and each rebuild pushed the technique one layer deeper into the machine. Carders needed to look like a stolen card’s owner, so they spoofed what the browser reports. Affiliates needed fifty clean accounts, so the spoofing became a product with a dashboard and a proxy field. Scrapers needed automation that survives, so the spoofing fused with the automation library and dropped below the JavaScript layer into the engine and now below the engine into the control protocol. At every step the detectors followed the spoofers down, from blocklisting single values, to correlating many of them, to reading the TLS handshake and the HTTP/2 frames and the serialization side effects of the debug protocol, signals that sit beneath everything a browser can be told to report.

The structural fact that has not changed since Vektor T13 said it is that a browser can only lie about the browser. The honest part of the machine, the operating system’s network stack, the real hardware timing, the way the control channel actually behaves, keeps leaking the truth, which is why the most reliable strategy across the whole history was never to synthesize a perfect fake but to capture and replay a real one. That is also why the most consequential events in this history are a law-enforcement seizure and a database of 50,000 harvested fingerprints rather than any clever piece of spoofing code. The tools were always downstream of the supply of real device identities. Detection works by finding the seam between the borrowed identity and the machine actually presenting it, and that seam has gotten narrower and moved lower with every generation, but it has not closed. The cycle that opens a new gap and then closes it used to run four to six years. The headless unification and the CDP-leak research landed inside eighteen months of each other, and the next gap will open faster than the last one did.

---

Sources & further reading

• Castle (2024), Overview of anti-detect browsers — definition of the category, the JavaScript-versus-engine spoofing split, and the correlation-based detection model.
• Castle (2024), Anti-detect browser analysis: how to detect the Undetectable browser — reverse-engineering of JS-level lies, the toString().toString() tell, and the chromium_framework engine-level path.
• Castle (2025), From Puppeteer stealth to nodriver: how anti-detect frameworks evolved — the chronology from JS-injection stealth to CDP-free automation and the Runtime.enable serialization leak.
• Castle (2026), Fingerprint harvesting in the bot ecosystem — real-versus-synthetic fingerprints, the replay economy, and the supply chain feeding automation tools.
• Group-IB (2024), Fingerprint heists — the ScreamedJungle harvesting campaign, Bablosoft BAS and FingerprintSwitcher history, PerfectCanvas, and CustomServers.
• Multilogin (2024), What is Stealthfox browser — the Firefox-based first engine, its masking surfaces, and its succession by the Chromium-based Mimic.
• BleepingComputer (2023), FBI seizes stolen credentials market Genesis in Operation Cookie Monster — the 4 April 2023 takedown, the bot-and-fingerprint bundles, and the custom browser.
• Eurojust (2023), Takedown of online market that sold stolen account credentials (Operation Cookie Monster) — the seventeen-country operation, arrest counts, and scale of the Genesis inventory.
• Chrome for Developers (2023), Chrome Headless mode — the Chrome 112 unification of headless and headful into one codebase.
• DataDome (2024), What is the VektorT13 anti-detect browser — background on the early Firefox-based antidetect lineage and the move toward VM-based emulation.
• GoLogin (2019), Meet the new antidetect browser Orbita — the December 2019 launch of GoLogin’s Chromium-based engine.