Malware delivery via the browser: drive-by downloads and the exploit-kit era

For about a decade, visiting a web page was enough to lose control of your computer. Not clicking a link in the page, not running a downloaded file, not approving a dialog. Loading the page. The HTML came down, an invisible iframe pulled in a script, the script measured your browser and the plugins bolted onto it, found one that was out of date, and used a memory-corruption bug to run code of the attacker’s choosing. By the time the page finished rendering, a downloader was already on disk and reaching out for its second-stage payload. No interaction. The industry called it a drive-by download, and for a while it was the single most productive way to spread malware at scale.

What makes the period worth studying now is not the exploits themselves, most of which are dead, but the machine that grew up around them. Drive-by downloads were industrialized. You did not need to write a Flash exploit; you rented a kit that bundled a dozen of them, kept them fresh, fingerprinted each visitor to pick the one most likely to land, and handed you a control panel with conversion rates. The economics looked like an ad network because the delivery mechanism was an ad network. Then, over four or five years, the whole thing collapsed, killed less by arrests than by the slow removal of the attack surface it depended on. That arc, from a clever trick to a $60-million-a-year business to near-extinction, is the subject here.

The sections that follow start with the mechanism: what actually happens between a page load and code execution, and why a plugin was the weak point rather than the browser. Then the redirect chain and the landing page, where the fingerprinting lived. Then the kit economy of 2010 to 2016, with Blackhole and Angler as the reference points. Then the decline, which has specific causes and dates. The post closes on what replaced drive-by downloads once the browser stopped being exploitable for free, because the demand for browser-delivered malware never went away, only the method did.

What a drive-by download actually is

The phrase covers two situations that share a name and not much else. One is a download the user authorizes without understanding it: a fake “your video player is out of date” prompt, a bundled installer that quietly adds three more programs, a dialog the user clicks through to make it go away. That is social engineering with a download attached, and it never required a software vulnerability. The other is the download that happens with no user action at all, where malicious code exploits a bug in the browser or one of its plugins and executes without consent. The two blur together in casual usage, but the unauthorized, no-click version is the one that defined the exploit-kit era, and it is the one this post means by “drive-by download.”

The mechanics rest on one fact about the mid-2000s web. The browser itself was a fairly hard target. The interesting attack surface hung off the side of it, in the plugins that the browser handed untrusted content to without much supervision. Flash Player, the Java Runtime Environment, Microsoft Silverlight, Adobe Reader rendering PDFs inline, various ActiveX controls. Each of these parsed complex, attacker-controlled file formats in native code, each shipped on a huge fraction of desktops, and each updated on its own slow schedule that most users ignored. A page could instantiate any of them and feed them bytes. That is the whole game: the page is a delivery vehicle for a malformed SWF, JAR, or PDF that triggers memory corruption in the plugin, and the plugin runs with the user’s privileges.

*The drive-by chain in five steps. The accent is on the plugin: the browser handed untrusted content to native plugin code that parsed complex file formats, and that is where the memory corruption lived.*

Two technical building blocks made the exploit half reliable. The first was the use-after-free, a class of memory bug where the program frees an object but keeps a pointer to it, then uses that stale pointer after the memory has been reallocated for something the attacker controls. Internet Explorer’s DOM and Flash’s ActionScript runtime were full of these. The second was heap spraying, a delivery technique rather than a bug. Using JavaScript or ActionScript, the attacker allocates hundreds of megabytes of identical blocks on the heap, each one a long run of harmless padding followed by the shellcode. The point is statistical. When the use-after-free hands control to some semi-arbitrary heap address, the odds are high it lands inside the sprayed region and slides into the payload. Spraying turned an unreliable corruption into a near-certain code-execution primitive, and it was the silver bullet for IE and Flash for years.

Heap spraying had a sharper cousin, JIT spraying, that mattered specifically because of Flash. Modern runtimes compile hot code paths to native machine code at runtime, and that generated code has to live in executable memory. An attacker who can get the JIT to compile a function full of carefully chosen constant values can smuggle shellcode into those constants, and because the JIT marks the page executable, the payload sits in attacker-influenced executable memory regardless of the defenses meant to stop exactly that. ActionScript’s JIT made Flash a productive target for this, which is part of why Flash, not the browser, carried most of the exploit-kit weight.

The redirect chain and the gate

A victim almost never went straight from a compromised page to an exploit server. The traffic moved through a chain, and the chain existed for two reasons: to launder the connection so the exploit server’s address stayed hidden, and to filter visitors so the operator only spent exploits on targets worth exploiting.

It started with traffic. Sometimes a legitimate site was compromised and a one-line script or invisible iframe was injected into its pages, so every visitor unknowingly pulled content from the attacker’s infrastructure. Sometimes the traffic came from malvertising, a malicious ad bought through a real ad network and served on real publishers, which is how a 2016 campaign managed to push the Angler kit through ad slots on major news sites without compromising those sites at all. Either way the injected element pointed not at the exploit kit but at an intermediary called a gate.

The gate’s job was triage. It looked at the incoming request, checked the User-Agent string to confirm a Windows desktop browser, and dropped anything that did not match: mobile devices, Linux, crawlers, anything that smelled like a researcher’s sandbox. Only the survivors got redirected onward to the exploit kit’s landing page. Chains could run several gates deep, each hop adding a layer of indirection between the visible compromised page and the exploit server that actually held the malware. This structure is also why drive-by infrastructure shares so much DNA with the redirect networks discussed in malicious redirects and traffic-distribution systems; the TDS was the routing layer, and the exploit kit was one of its possible destinations.

*The hop the victim never sees. The gate filters traffic so exploits are spent only on Windows desktops with the right profile, and it keeps the exploit server one layer removed from anything a defender can find on the compromised page.*

That filtering instinct is the same one anti-bot vendors industrialized later, pointed the other way. An exploit kit dropped sandboxes to avoid analysis; a modern anti-bot stack drops automation to protect a site. The signals overlap heavily, which is why a lot of techniques from this era resurface in phishing-kit cloaking and in sandbox-evasion fingerprinting. The kit operator and the defender are both asking the same question on the first request: is this a real, exploitable, valuable human, or is it something I should hide from?

The landing page and the fingerprint

The landing page is where the decision got made. It was an HTML document, delivered invisibly, whose only purpose was to measure the visitor and then serve the single exploit most likely to succeed. Serving the wrong one was worse than serving nothing. A failed exploit could crash the plugin and tip off the user, and worse, it burned the exploit by handing a working sample to whatever security product was watching. So the landing page profiled first and committed second.

Angler is the best-documented example, and its landing page had a recognizable structure that researchers took apart repeatedly. There was a layer of visible English text, often lifted from a real site, so that anyone who happened to view the page saw something innocuous. Underneath that sat heavy obfuscation: deobfuscation routines that unpacked base64 and decrypted strings at runtime, so the page’s real logic never appeared in the source as shipped. And inside those encrypted strings were the URLs and the exploit selection logic, the references to Flash, Silverlight, and Internet Explorer payloads that the page would reach for depending on what it found.

What it found came from fingerprinting. The script enumerated the browser type and version, then walked through the plugins and read their version numbers: Flash Player build, Java Runtime version, Silverlight, the PDF reader. Plugin version detection was straightforward because plugins advertised themselves to JavaScript by design. With the versions in hand, the kit consulted its table of exploits, each keyed to a version range it could defeat, and picked one. A fully patched machine produced no match, and the chain quietly ended with nothing delivered, which is precisely why patch status was the whole ballgame.

Angler pushed the fingerprinting further than its competitors by checking who the visitor was, not just what they ran. It used an Internet Explorer information-disclosure bug, CVE-2013-7331, which let a page probe the local filesystem for specific paths through an ActiveX object. The kit looked for the files and drivers that analysis tools, antivirus products, and virtualization leave behind. If it detected VMware, common sandboxes, or the fingerprints of security software, it concluded a researcher was on the other end and declined to serve the exploit, showing a benign page instead. This is sandbox evasion built into the delivery layer, and it is the direct ancestor of the environment checks malware still runs before it unpacks.

*The kit branches on a single question and serves the benign page on any "no." Fingerprinting the environment was both targeting and evasion: it picked the exploit most likely to land and refused to hand a working sample to anything that looked like analysis.*

The exploit mix tells you where the value was. When Cisco Talos took apart an Angler operation in October 2015, roughly three-quarters of the exploits served were Flash, around a fifth were Internet Explorer (notably CVE-2014-6332, a long-lived IE memory bug), and Silverlight made up a small slice. Flash was the workhorse for the same reasons it kept appearing in every kit: enormous install base, a JIT to spray against, a steady supply of fresh memory-corruption bugs, and an update cadence users ignored. Adobe’s Pixel Bender image-processing component alone produced CVE-2014-0515, a buffer overflow that multiple kits adopted within days of disclosure.

The kit economy, 2010 to 2016

Drive-by downloads existed before there was a market for them. Google’s 2008 study “All Your iFRAMEs Point to Us,” which crawled billions of pages over ten months, found that around 1.3 percent of search queries returned at least one result pointing to a drive-by page, and identified millions of URLs initiating downloads. That paper is the moment the problem got measured at web scale, and it predates the kits that would make it an industry. What changed around 2010 was packaging. The exploits got bundled, rented, and sold with support contracts.

Blackhole set the template. It appeared in 2010, written by a Russian developer who went by Paunch, and it was sold the way software-as-a-service is sold: a monthly rental, reportedly in the $500 to $700 range, that bought you a hosted kit kept current with fresh exploits and an admin panel showing your infection statistics. The convenience is the entire story. A criminal with traffic but no exploit-writing skill could now run drive-by campaigns by paying rent. By 2012, Blackhole was the most prevalent web threat by a wide margin; Sophos attributed something like 28 percent of web threats it detected to it, and other vendors put the share far higher. The model worked until October 2013, when Paunch was arrested in Russia. He was later sentenced to seven years. Blackhole did not survive the loss of its single maintainer, because the value was in the upkeep, and the upkeep stopped.

*The arc. Blackhole built the rental model, Angler perfected the targeting, and the whole category fell away between 2016 and 2017 as arrests removed operators and Flash's removal took away the attack surface.*

Angler inherited Blackhole’s market and ran it better. By 2015 it was the most capable kit in circulation, fastest to adopt new exploits, including same-week integration of Flash zero-days, and built around the three-tier infrastructure Talos documented: proxy servers that faced victims, a central exploit server reached over an unusual port that held the actual payloads, and a health-monitoring server that ran checks and pulled logs. The separation let operators burn and rotate proxies without exposing the core. The numbers from the Talos analysis are the ones worth keeping. A single Angler instance targeted roughly 90,000 victims a day. Of the users actually served an exploit, about 40 percent were compromised. Around 62 percent of payloads were ransomware, against an average ransom near $300 and a payment rate around 2.9 percent. Run those figures across the operation and Talos estimated a single actor could clear roughly $34 million a year, with the broader Angler ecosystem worth on the order of $60 million annually.

The traffic side of that operation has a detail that stays with you. Talos found Angler pulling visitors from more than 15,000 unique referer domains, the overwhelming majority used fewer than ten times each, scattered across news sites, real-estate listings, adult sites, and obituary pages on small-town newspapers, the last apparently chosen because the readers skewed older and less likely to keep Flash patched. The targeting was demographic. The kit went looking for the unpatched, and it knew where they read.

Angler’s end came with the Lurk arrests. In June 2016, Russian authorities arrested a group accused of using the Lurk banking trojan to steal around $45 million from Russian banks. Within about a week, Angler vanished. Cisco Talos and later Kaspersky tied the two together: the Lurk gang had built Angler, used it privately at first to deliver their own trojan, then rented it out once their banking fraud became less profitable. Arrest the operators and the kit they personally maintained goes dark. This is the same structural fragility that killed Blackhole, and it is worth noting that exploit kits, despite the SaaS veneer, kept depending on a very small number of irreplaceable people. The deeper history of these kits, Nuclear and Neutrino and RIG alongside Angler, is its own subject covered in the rise and fall of the browser exploit kits.

Why it declined

It would be tidy to say law enforcement killed the exploit kits, and the arrests mattered, but they are not the main cause. Operators are replaceable in principle, and a profitable enough business regenerates its talent. What did not regenerate was the attack surface. Drive-by downloads at scale needed a large population of users running exploitable plugin versions, and across 2015 to 2017 that population shrank faster than the kits could adapt, for several independent reasons that happened to land at once.

Browser vendors took the plugins away. Chrome removed support for NPAPI, the old plugin architecture that Java, Silverlight, and others depended on, completing the removal in Chrome 45 in September 2015 after a staged deprecation that began blocking plugins by default earlier that year. That single change cut Java and Silverlight off from the largest browser overnight. Flash got a stay of execution because Chrome bundled its own sandboxed Flash through the newer PPAPI interface, and that word, sandboxed, is the second cause. Running Flash inside a sandbox and behind click-to-play, where the plugin would not execute content until the user explicitly allowed it, broke the no-click premise that defined the attack. A drive-by that requires a click is just a download.

The browsers themselves also got materially harder. Through this period Chrome, Firefox, and eventually Edge ran serious bug-bounty programs and shipped exploit mitigations that turned the cheap, reliable techniques into expensive, fragile ones. Heap spraying stopped being a silver bullet as allocators were hardened and isolation improved. The supply of usable new exploits thinned, and the kits, which lived on a steady drip of fresh bugs, started serving stale ones that up-to-date browsers shrugged off. By mid-2017, the reporting consensus was that a patched, current browser was simply not exploitable by the kits still operating, and exploit-kit deployment fell by around 62 percent across 2017.

Then Flash died on a schedule. Adobe announced in July 2017 that Flash Player would reach end of life on December 31, 2020, with Apple, Google, Microsoft, Mozilla, and Facebook coordinating to disable it in their browsers by that date. Adobe began blocking Flash content from running on January 12, 2021, and Microsoft moved to remove the component from Windows entirely. The single most productive exploit-kit target was put on a public countdown and then switched off. Take Flash out of the equation, where three-quarters of Angler’s exploits had lived, and the math behind the whole business stops working. The decline of drive-by downloads is, more than anything, the story of Flash’s removal, with browser hardening and the plugin purge clearing away what was left.

What replaced it

The demand never went anywhere. Criminals still wanted to turn a page visit into a foothold on an endpoint; they just lost the free exploit that did it for them. So the method moved back to the user. The dominant browser-delivered malware technique of the early 2020s is the fake update: a compromised site, often with good search ranking, shows the visitor a convincing prompt that their browser is out of date and offers a download. There is no memory-corruption exploit anywhere in the chain. The payload is a script or archive the user is tricked into running. SocGholish, tracked since the late 2010s and still active through 2024, is the reference example, distributing a JavaScript payload disguised as a browser update through drive-by compromise of legitimate sites, then handing off access to ransomware crews and initial-access brokers.

This is the authorized-but-deceptive branch of the original definition, the one that never needed a software bug, and it now carries the traffic that drive-by exploits used to. The fingerprinting and gating survived almost unchanged; a fake-update operation still triages visitors, still cloaks from researchers, still routes through traffic-distribution systems. What got cut out was the exploit. Where Angler probed for an old Flash build to corrupt its memory, SocGholish probes for a user it can talk into double-clicking. The infrastructure is a direct descendant; the exploitation primitive is gone. Some of the same crews that fed drive-by exploits also ran the browser-side card skimmers covered in Magecart and web skimming, and the overlap in injection and cloaking tradecraft is not a coincidence.

A few exploit kits never fully died. RIG and a handful of others kept limping along, serving aged Internet Explorer exploits to the long tail of users still running IE on unpatched Windows, and they found occasional life delivering through Internet Explorer bugs even after Flash was gone. But that is a niche feeding on stragglers, not an industry. The mass-market, any-visitor, no-click drive-by download that defined 2010 to 2016 depended on conditions that no longer exist: a giant install base of separately-updated native plugins, parsing attacker-controlled file formats, outside any meaningful sandbox, on browsers that handed them untrusted content without a second thought.

The shape of the whole thing

The drive-by era is a clean case study in how an attack surface, not an attacker, determines what is possible. For a decade the surface was enormous and soft: hundreds of millions of desktops running plugins that were native-code parsers of complex formats, updated on a schedule users ignored, wired directly into every web page. Given that surface, industrialization was inevitable. The kits were just the market discovering the most efficient way to harvest it, complete with rental pricing, conversion funnels, and demographic targeting down to the obituary pages of small-town papers. The arrests of Paunch and the Lurk gang made for dramatic endings, but they removed operators from a business whose foundation was already being demolished underneath them.

What actually ended the era was a series of unglamorous engineering and product decisions stacked close together: NPAPI removed, Flash sandboxed and put behind click-to-play, browsers hardened through bounties and mitigations, and finally Flash itself scheduled for deletion and switched off on the last day of 2020. None of those was aimed specifically at exploit kits. They were the slow professionalization of the browser as a platform, and the drive-by download was collateral. The lesson the defenders took was the one worth keeping: you do not have to out-run every exploit if you can remove the thing the exploits attack. The plugins went, and the no-click drive-by went with them, leaving behind a fake-update prompt that has to ask the user for the click the old exploits never needed.

---

Sources & further reading

• Provos, Mavrommatis, Rajab, and Monrose (2008), All Your iFRAMEs Point to Us — the USENIX Security paper that first measured drive-by downloads at web scale, including the ~1.3% of searches returning a malicious result.
• Kaspersky / Securelist (2009), Drive-by Downloads. The Web Under Siege — early survey of the mechanism, obfuscated-JavaScript redirects, and the plugin targets of the period.
• Wikipedia, Drive-by download — the authorized-versus-unauthorized distinction and the three-stage attack model.
• Palo Alto Unit 42 (2016), Understanding Angler Exploit Kit, Part 1 — the redirect chain, gates, landing page, and payload-encryption mechanics explained in detail.
• Cisco Talos (2015), Angler Exposed — the operational teardown with the 90,000-victims-a-day, 40% conversion, and ~$34M/$60M revenue figures.
• Forcepoint X-Labs, Angler Exploit Kit: Operating at the Cutting Edge — Angler’s landing-page structure and its CVE-2013-7331 sandbox-detection trick.
• Krebs on Security (2013/2016), Meet Paunch / Blackhole Author Gets 7 Years — the Blackhole rental model, Paunch’s arrest, and sentencing.
• Wikipedia, Blackhole exploit kit — pricing, 2012 prevalence share, and the timeline around the 2013 arrest.
• Zscaler (2014), Nuclear Exploit Kit and Flash CVE-2014-0515 — the Pixel Bender buffer overflow and how kits weaponized it.
• Wikipedia, Heap spraying — the spray technique, its use against IE and Flash, and the 2009 ActionScript-spray milestone.
• The Register (2016), Lurk Trojan takedown also took out Angler — the arrests that coincided with Angler’s disappearance and the Lurk-Angler link.
• Chromium Project, NPAPI deprecation: developer guide — the staged removal of NPAPI plugins, completed in Chrome 45 (September 2015).
• Microsoft Learn, Adobe Flash end of support on December 31, 2020 — the coordinated browser-vendor EOL and the January 2021 content block.
• CIS (2024), CTAs Leveraging Fake Browser Updates — SocGholish and the fake-update technique that inherited the drive-by delivery role.