What are Exploit Kits

An exploit kit (sometimes referred to as “exploit pack”, abbreviated EK) is a framework that automates on the server side the discovery and exploitation of software vulnerabilities with the goal of delivering malware at scale. Hosted on attacker-controlled infrastructure and typically reached through a compromised website, it dynamically selects from a collection of exploits based on the target's environment.

In practice, this means a curated library of exploits, delivery logic, and command-and-control components that are continuously maintained so that a threat actor can run exploitation campaigns without ever writing an exploit from scratch. The operator doesn't need to understand the vulnerability. They just need access, a shift that matters because exploitation stops being a specialist capability and becomes an operational process.

Historically, exploit kits have focused on client-side attack surfaces like web browsers and browser-adjacent components such as plugins and runtimes. What made browsers the ideal target is the fact that they are universally exposed, deeply integrated with user activity, and rich in exploitable complexity.

Distribution matters as much as design in the case of EK. They are rarely built for a single operator, following a crimeware-as-a-service model in which operators maintain the infrastructure and exploit library. Other threat actors rent access to run campaigns, often through interfaces and update cycles that resemble legitimate software subscriptions. The expertise required to build an exploit is less relevant to the person deploying it, a separation that turned exploitation into a scalable criminal service.

The infection chain described above runs on layered infrastructure. Each component maps to a stage in that chain, and together they form what is best described as a modular exploit kit, each piece replaceable without rebuilding the whole.

Traffic distribution and redirection layer (TDS): Not every visitor to a compromised site ends up at the exploit kit. The TDS sits in front of the kit's infrastructure and filters incoming traffic before anything else happens, passing through users who look like viable targets while redirecting security researchers, known bots, and visitors from the wrong geography to harmless pages. URL rotation, domain generation, and fast-flux DNS keep the infrastructure cycling fast enough to stay ahead of blocklists.

Landing page: The controlled execution environment where the kit’s logic runs, served through obfuscated, frequently rotated URLs.

Fingerprinting module: Implemented through JavaScript running in the browser, this component collects details about the environment like browser version, operating system, installed plugins, and other signals that indicate whether a target is exploitable. More advanced variants also check for virtual machines or sandbox conditions and simply stop if they detect analysis.

Exploit repository: The kit maintains a set of exploits mapped to specific vulnerabilities and target applications. Entries are added and removed as targets change, allowing the exploit set to stay current without reworking the rest of the system.

Payload delivery mechanism: The next stage is executed on the host through in-memory techniques, but file-based delivery or staged binaries can also be observed.

Administration and telemetry interface: Operators manage campaigns through an administration user interface with real-time visibility into campaign performance and targeting parameters. Many builds run on common web stacks, open-source components such as PHP, Apache, and MySQL.

MPack and Blackhole proved the commercial model worked. Angler showed how far it could be pushed technically, integrating zero-days and optimizing delivery chains in ways that kept it ahead of defenses. By the mid-2010s, exploit kits were a standard distribution layer for ransomware and credential theft operations.

Exploit kits did not disappear all at once, their role just narrowed over time because of the environmental changes. The model became harder to sustain as browser security improved, legacy plugins were removed, and several operators were disrupted. What remained were smaller operations. Kits like RIG and Magnitude continued to appear, but mostly in legacy environments or in regions where older software was still in use. More recent frameworks such as ClearFake kept the web-based delivery approach but shifted toward user-triggered execution instead of relying on silent exploitation.

The surrounding ecosystem changed as well. Exploit kits are now often one stage in a larger crimeware chain, providing initial access that other actors use. Public kits tend to rely on known vulnerabilities, while more controlled frameworks used by advanced actors incorporate non-public zero-day vulnerabilities.

Some of the design patterns still carry over into current attack methods. Generative AI is being tested for code variation and for producing evasive landing content, although fully autonomous exploit kits have not been observed. Current campaigns show some directional movement toward session token theft and OAuth abuse. Attacking authentication state rather than software flaws sidesteps the patch cycle entirely, which suggests where pressure will continue to build regardless of what happens to exploit kit infrastructure specifically.

No single alert is definitive. Patterns matter. Effective detection of exploit kit activity depends on correlating weak signals across host and network layers.

Endpoint level. Endpoint protection platforms like EDR can reveal telemetry about the exploit tied to browser processes such as unusual child process creation (e.g., browser to wscript/powershell), unsigned module loads, obfuscated script fetches, suspicious RWX memory allocations.

Network side. Intrusion detection systems should normally flag anomalous web behavior such as chained redirects, unexpected iframe or script loads, high-entropy URL patterns.

However, the strongest signal comes from correlating browser activity with abnormal process execution, consistent with MITRE ATT&CK detection strategies for T1189 (Drive-by Compromise).

Useful telemetry sources include: browser and application logs, process creation events, network flows, proxy and web gateway data; full URL paths and referrers are what make it possible to reconstruct a redirect chain during incident response (IR). Encrypted traffic is a real limitation here: where inspection isn't possible, parts of the delivery chain simply won't show up in the logs.

Proxy logs are usually where investigation starts. The redirect chain appears as a sequence of 302s with randomized URI paths, and the referrer headers frequently don't match - domains that have no business being connected to each other showing up in sequence. That's typically the first thing that looks off.

PCAP data can fill in gaps. JA3 TLS fingerprints and unusual HTTP responses from landing pages are worth pulling, but on their own they won't tell you whether you're looking at an exploit kit or something else, they need to be read alongside the other evidence.

On the host, the challenge is that most traces disappear quickly. Browser memory injections and shellcode fragments are gone after a reboot, and signs of ROP-based exploitation won't show up in a standard disk examination. If host-level analysis is needed, it has to happen before the machine is touched, and it requires memory forensics tooling, not a standard IR workflow.

The goal should be kept at as practical a level as possible: reduce what can be reached, limit what can run if something gets through anyway.

Vulnerability management and patching

Patching remains the most direct control against exploit-driven compromise: exploit kits exist precisely because patch deployment takes time. That gap is what they're built around, which makes SLAs and coverage verification something worth actually enforcing rather than assuming. Enforcing automatic updates for browsers and operating systems reduces reliance on manual processes. Continuous asset visibility ensures no unmanaged or legacy systems sit exposed. Removing deprecated plugins and unsupported software eliminates entire classes of historically exploited vulnerabilities, that is, direct attack surface reduction.

Platform hardening and execution control

Hardening the browser and OS directly reduces how reliably exploits execute. A vulnerability that exists but can't be triggered cleanly is considerably less useful to an attacker, and that gap can be widened deliberately. Restricting legacy scripting engines and controlling what web content is permitted to execute push in that direction without requiring a patch to exist first. Application control policies work on the same logic. Memory protections operate differently: the underlying vulnerability may still be present, but the exploitation technique that depends on it stops working. Least privilege operates at a different stage, it doesn't prevent execution, but it limits what execution actually means. An attacker contained to a low-privilege process in a segmented environment is a different problem than one who lands with room to move.

Web traffic inspection and content controls

As we said multiple times, exploit kits depend on untrusted web content as an entry point, so the logical conclusion is that intrusion prevention systems and secure web gateways are a valid way to block known exploit infrastructure. In some cases, these can also reveal redirect patterns that don't match normal browsing behavior.

For reducing malvertising exposure, an important EK entry vehicle, control over third-party content (particularly ad delivery networks) is important, considering that attackers constantly manage to find gaps in ad verification. When threat intelligence is integrated into the mix, controls can be updated faster when the feed quality is high enough. At the gateway layer, selective static analysis can catch obfuscated scripts before execution. As useful as this is, it cannot be a substitute for patching the vulnerabilities those scripts are trying to reach.

Exploit Kits in the MITRE ATT&CK

The MITRE framework includes EK activity under T1189 (Drive-by Compromise) and T1203 (Exploitation for Client Execution). M1021 is the corresponding mitigation, blocking untrusted scripts, limiting browser plugins, filtering at the gateway. It's not foolproof though. Angler's operators were integrating zero-days faster than patches existed, so that first layer sometimes simply wasn’t there.

For incident response, the same principle applies: if the post-incident review doesn't result in actual fixes, the same attack path stays open.