What Is an Exploit Kit? How They Work

A user opens a news site they read every day and clicks nothing unusual. One of the ads on the page is malicious, and it quietly redirects their browser, in the background, to a server they never chose to visit. That server runs a script that reads the browser version, the operating system, and the plugins installed, finds an unpatched flaw in an outdated plugin, fires the matching exploit, and drops a ransomware payload on the machine. The user saw a normal web page. No download prompt, no warning, no file they chose to open. The whole sequence took a second or two, and it was driven by an exploit kit.

An exploit kit is automated attack software, hosted on a web server, that profiles each visitor's browser and silently runs the right exploit for whatever known vulnerability it finds, then delivers a payload. It packages reconnaissance, exploitation, and malware delivery into one tool that anyone can rent, which is why exploit kits powered some of the largest drive-by download campaigns of the last decade.

This guide covers what an exploit kit is, the stages of an attack, the vulnerabilities they target, the named kits that defined the era, why their use has fallen since 2017, and how defenders detect and prevent them. It is written for blue teamers who have to recognize a drive-by compromise that the user never knowingly triggered.

What is an exploit kit?

An exploit kit is a toolkit that attackers use to automatically find and exploit vulnerabilities in a visitor's system in order to deliver malware. It is software running on a malicious or compromised web server, not a single exploit. The kit holds a collection of exploits for known software flaws and the logic to decide which one to fire against each visitor, so a single deployment can compromise a wide range of machines without the attacker touching any of them directly.

The defining trait is automation. The operator does not pick a target and craft an attack by hand. They stand up the kit, drive traffic to it, and the kit does the rest: it fingerprints each browser, matches the system against its library of exploits, runs the one most likely to succeed, and installs the payload. This turns mass compromise into a hands-off, repeatable operation.

Exploit kits made serious attack capability rentable. They were sold and leased on criminal markets as a service, often with dashboards, support, and update cycles, so an operator with no ability to write an exploit could still run a campaign that dropped malware on thousands of machines. That commoditization is what made them a defining threat of the early-to-mid 2010s.

How an exploit kit attack works

A drive-by exploit kit attack follows a recognizable chain, and the victim's only action is visiting a page.

1. Redirect to the kit. The victim lands on a compromised legitimate site or sees a malicious ad (malvertising), and a hidden redirect silently sends their browser through to the exploit kit's landing page. The user does not click anything that looks like a link to a malicious site.
2. Fingerprint the system. The landing page runs a profiling script that enumerates the browser, its version, the operating system, and installed plugins, then compares that profile against the exploits the kit holds. This decides whether the visitor is exploitable and which exploit to use.
3. Fire the matching exploit. If a known unpatched flaw is present, the kit serves the exploit for it. The exploit abuses that vulnerability to run attacker code in the browser or a plugin, with no download prompt and no user interaction.
4. Deliver the payload. Once code execution is achieved, the kit downloads and runs the final payload, the actual malware the campaign is built to install, commonly ransomware, a banking trojan, or a loader for further infection.

The result is the scenario from the opener: a fully automated infection where the victim only ever loaded a web page. Many later kits added an evasion layer, checking whether the visitor is a security researcher, a sandbox, or a virtual machine, and refusing to serve the exploit if so, which keeps the kit's exploits out of analysts' hands.

Vulnerabilities exploit kits target

Exploit kits live and die by known, patchable vulnerabilities. They almost never use a brand-new flaw against the general public, because a single working exploit reused across thousands of visitors is far more economical. The targets historically clustered in the browser and its add-ons.

• Browser plugins. The classic targets were Adobe Flash Player, Oracle Java (the Java Runtime Environment), and Microsoft Silverlight. These were installed almost everywhere, frequently out of date, and rich in memory-corruption bugs, which made them ideal.
• The browser itself. Internet Explorer in particular was a recurring target, with several kits built around IE vulnerabilities.
• Document readers. Adobe Reader and similar software extended the reach to flaws outside the browser proper.

The unifying theme is that these are publicly documented vulnerabilities, each with an assigned CVE identifier and, in nearly every case, a patch already available. The exploit kit's entire business model depended on users who had not applied that patch. A fully updated system with no vulnerable plugins gives the kit nothing to fire, which is why patching is the single most effective defense.

Named exploit kits

A handful of kits dominated the landscape and are worth knowing by name, because they show how the market worked and how it ran on rented capability.

These kits operated as a service. Operators leased access, the authors maintained the exploit library and the infrastructure, and campaigns were driven by separate affiliates pushing traffic through malvertising and compromised sites. The arrest of the Blackhole author and, later, the disruption of the group behind Angler showed how dependent the ecosystem was on a small number of operators.

Why exploit kit activity has declined

Exploit kits are not the force they were at their peak. From around 2017 onward their use fell sharply, and the reasons are concrete rather than coincidental.

• The plugins disappeared. The targets that made kits viable went away. Browser vendors deprecated and then removed support for the plugin technologies that kits relied on, and Adobe Flash Player reached end of life at the end of 2020. With the vulnerable plugins gone, most exploit-kit exploits had nothing to land on.
• Browsers auto-update. Modern browsers patch themselves silently and quickly, collapsing the window between a vulnerability being disclosed and the population being fixed. The kits depended on users staying unpatched for months; that window largely closed.
• Law enforcement disrupted the operators. The arrest of the Blackhole author and the takedown of the infrastructure behind Angler removed key players, and the commoditized market never fully recovered.
• Attackers moved to easier delivery. With drive-by exploitation harder, criminals shifted to phishing and malicious documents, tricking users into running the malware themselves rather than exploiting a browser flaw.

The technique is not extinct. Kits still operate, particularly through malvertising against the unpatched, and the model can reappear wherever a widely installed, slow-to-patch piece of software develops exploitable flaws. But the era of the exploit kit as a dominant, commodity threat has passed, and that history is itself a lesson in how patching and removing risky software shut down an entire attack class.

How to detect an exploit kit

Because the victim does nothing visibly wrong, detection means watching the network and the endpoint for the chain itself, not for a user mistake.

• Watch for redirect chains in web traffic. A user landing on a benign site followed by an automatic redirect to an unfamiliar domain serving obfuscated script is the signature of a kit's delivery. Web proxy and DNS logs are where this shows up.
• Inspect for exploit-kit landing pages. Network detection signatures and intrusion detection systems carry rules for the heavily obfuscated JavaScript that kit landing pages use to fingerprint and exploit. A hit on one is a strong, early signal.
• Watch the browser's process behavior. A browser or a plugin process spawning a command shell, writing an executable, or making an unexpected outbound connection is the post-exploitation step. Endpoint detection and response tooling flags exactly this parent-child and behavioral anomaly.
• Pivot on the payload's indicators. Once the malware lands it generates its own traffic and artifacts. The command-and-control domains, dropped file hashes, and registry changes become indicators of compromise that confirm the infection and scope it across the environment.

The unifying principle is that an exploit kit leaves a multi-stage trail across the web proxy, DNS, and the endpoint, even when the user noticed nothing. The defender who correlates the redirect, the landing page, and the post-exploit behavior sees the attack the user never did.

How to prevent exploit kits

Prevention is unusually effective against exploit kits because they depend on known flaws and risky software, both of which a defender can remove.

• Patch aggressively, browsers and plugins first. Exploit kits target unpatched, publicly known vulnerabilities. Timely patching of the browser, its add-ons, and document readers removes the flaws the kit needs and is the single highest-impact control.
• Remove or restrict risky plugins. Uninstall Flash, legacy Java in the browser, and other plugins that are not genuinely required. Software that is not installed cannot be exploited.
• Block malvertising and malicious domains. Ad blocking, DNS filtering, and web reputation filtering cut the redirect path that delivers victims to the kit in the first place.
• Run modern, auto-updating browsers. A current browser that patches itself silently closes the unpatched-window the kit relies on, and removes the plugin attack surface entirely.
• Layer endpoint defenses. Behavioral antivirus and EDR catch the payload and the post-exploitation activity even when an exploit gets through, providing a backstop behind patching.

Layered, these controls attack the kit at every stage: they cut the delivery path, remove the vulnerable software, close the patch window, and catch the payload if all else fails. Against a threat built entirely on known flaws and unpatched software, disciplined patch and software hygiene does most of the work.

Getting started with exploit kit investigation

If you want to build the skill, learn to read the network and endpoint trail a drive-by leaves behind.

1. Learn the attack chain. Internalize the redirect, fingerprint, exploit, payload sequence so you recognize it from fragments in the logs.
2. Read web and DNS logs. Practice spotting the malvertising redirect and the jump to an unfamiliar landing-page domain in proxy and DNS data.
3. Analyze obfuscated landing pages. Learn to deobfuscate the JavaScript a kit uses to fingerprint and exploit, since that is where intent is hidden.
4. Trace a full infection. Follow a case from the redirect through the exploit to the dropped payload and its command-and-control, so the whole pattern, and the indicators it leaves, is familiar.

Frequently asked questions

What is an exploit kit?

An exploit kit is automated attack software, hosted on a web server, that profiles a visitor's browser and silently runs an exploit for whatever known vulnerability it finds, then delivers a malware payload. It packages reconnaissance, exploitation, and delivery into one tool, so a single deployment can compromise many machines without the attacker acting against each one directly. Many were sold or leased as a service on criminal markets.

How does an exploit kit work?

A victim is silently redirected, usually from a compromised site or a malicious ad, to the kit's landing page. A profiling script fingerprints the browser, operating system, and plugins, then matches them against the kit's library of exploits. If an unpatched known flaw is present, the kit fires the matching exploit to run code with no user interaction, and downloads the final payload. The user only ever loaded a web page.

What is a drive-by download?

A drive-by download is malware that installs when a user merely visits a web page, with no download prompt and no deliberate action on their part. Exploit kits are the classic engine behind drive-by downloads: they exploit a browser or plugin flaw to execute code automatically. The defining feature is that the victim does not knowingly run anything; the infection happens in the background while they view a normal-looking page.

What vulnerabilities do exploit kits target?

Exploit kits target publicly known, already-patched vulnerabilities in widely installed software. The classic targets were browser plugins such as Adobe Flash Player, Oracle Java, and Microsoft Silverlight, along with Internet Explorer itself and document readers like Adobe Reader. Each flaw has an assigned CVE and usually an available patch, so the kit relies entirely on users who have not yet applied it.

Are exploit kits still a threat?

Their use has declined sharply since around 2017. The plugins they targeted were deprecated and Flash reached end of life at the end of 2020, browsers now auto-update and close the unpatched window, and law enforcement disrupted major operators. They are not extinct, some kits still run through malvertising against unpatched systems, but they are no longer the dominant commodity threat they were at their peak.

How do you prevent exploit kit attacks?

Patch the browser, its plugins, and document readers promptly, since kits only work on known unpatched flaws. Remove risky software like Flash and legacy Java that is not needed, run a modern auto-updating browser, and block malvertising and malicious domains with ad blocking and DNS filtering. Layer behavioral antivirus and EDR underneath to catch the payload if an exploit slips through.

The bottom line

An exploit kit is the automated, rentable engine behind drive-by downloads: hosted on a web server, it fingerprints each visitor's browser, fires an exploit for whatever known unpatched flaw it finds, and drops a payload, all while the victim does nothing but view a page. It worked because vulnerable plugins like Flash and Java were everywhere and slow to patch, and because the kits were sold as a service to operators who could not write an exploit themselves. That same dependence on known flaws is why the threat collapsed after 2017 once the plugins went away and browsers started auto-updating, and why it is so preventable: patch aggressively, remove risky software, and block the redirect path. The user never sees the attack, but the redirect, the landing page, and the payload all leave a trail, and the defender who looks across the proxy, DNS, and endpoint is the one who catches it.