Exploit kit campaigns are hard to detect because they combine high volume ad traffic, domain shadowing, filtering, and encrypted infrastructure to hide delivery paths. The attacker can selectively send only vulnerable hosts onward, which reduces obvious noise. That means defenders need visibility into redirects, certificate use, and patch state, not just email or download telemetry.
Why the delivery chain is hard to see
Exploit kits paired with malvertising are difficult to detect because the delivery chain is fragmented across ad networks, redirects, landing pages, and short-lived infrastructure. The apparent “noise” is ordinary web traffic until the attacker filters out non-targets, so defenders may only see a small fraction of the malicious path and not the whole campaign. That makes the attack blend into normal browsing behavior.
At the technical level, the campaign often depends on evasive mechanics such as domain shadowing, encrypted transport, and selective routing. Those choices are not just for resilience, they are designed to hide the relationship between the ad impression, the redirect chain, and the eventual exploit delivery, which makes simple blocklists or single-hop telemetry far less effective.
Why selective victiming defeats simple detection
The most effective part of the scheme is that it can profile visitors before delivering the payload. If the kit only forwards vulnerable browsers, outdated plugins, or specific geographies, the observable traffic looks sparse and inconsistent. Security teams then face a classic visibility problem: the attack is real, but the evidence is intentionally filtered so it does not appear at scale in the logs.
This also weakens common detection logic that depends on volume, repetition, or obvious malicious patterns. A campaign can expose only a few hosts to the exploit stage, which reduces the chance that email security, download scanning, or generic web filters will trigger. The defender needs correlation across redirects, certificate activity, and patch exposure rather than a single alert source.
What defenders need to inspect instead
The right response is to treat malvertising-driven exploit kits as a web delivery and browser-exploitation problem, not just a malware problem. That means watching redirect chains, inspecting where traffic lands after ad clicks, and correlating browser and plugin version data with suspicious outbound activity. It also means paying attention to TLS and certificate patterns, because encrypted infrastructure can conceal reuse across many transient hosts.
Campaigns of this type are easier to understand when matched against exploit infrastructure and known vulnerable software rather than against one-off URLs. For practical hunting, look for repeated delivery patterns, fast-changing domains, and signs that only a subset of users are being sent onward to the exploit stage. Public vulnerability intelligence such as the NIST National Vulnerability Database, the CISA Known Exploited Vulnerabilities Catalog, and FIRST EPSS help prioritize what to patch first, while MITRE ATT&CK Enterprise and MITRE D3FEND help map the attack path to defensive techniques.
Risk and Threat Considerations
Malvertising plus exploit kits create concentrated exposure because a single poisoned ad can reach many users, while only a narrow subset is actually exploited. That combination makes both campaign scale and victim selection harder to measure, so organisations can underestimate the scope of compromise until multiple hosts begin showing related browser or endpoint activity.
Failure mechanism: The attacker hides the exploit chain behind ordinary ad delivery, then uses filtering, redirects, and encrypted infrastructure to suppress visible noise and send only likely-vulnerable systems onward.
Impact: Defenders can miss active exploitation, delay patching of the most exposed browsers or plugins, and lose the chance to correlate the initial web visit with subsequent compromise indicators.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1189 — Drive-by Compromise | Malvertising-delivered exploit kits use web delivery and victim selection. |
| T1133 — External Remote Services | Encrypted infrastructure and redirectors obscure the delivery path. | |
| Recommendation — Map redirect chains and browser exploitation to drive-by compromise detections. Hunt for suspicious externally hosted infrastructure and chained redirects. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Exploit kits are a malware delivery mechanism requiring code-execution defense. |
| RA-5 — Vulnerability Monitoring and Scanning | Selective delivery makes patch exposure central to risk reduction. | |
| Recommendation — Apply malicious code protections at web and endpoint ingress points. Continuously identify and prioritise exploitable browser and plugin vulnerabilities. | ||
Practitioner Guidance
What to prioritise: Correlate web proxy, DNS, certificate, endpoint, and patch-state telemetry for the same user and host. If you only monitor downloads or email, you will miss the earlier redirect and filtering stages that make these campaigns effective.
What to verify: Check whether your controls can reconstruct the full navigation path, including intermediate domains and certificate changes, and whether vulnerable browser or plugin versions are still present on the fleet. If the answer is no, your detection coverage is incomplete.
Practitioner takeaway: Treat malvertising exploit kits as a multi-stage web-borne intrusion path, because the defender’s real challenge is not the final payload, it is proving which small fraction of users was intentionally selected for it.
Related resources from NHI Mgmt Group
- Why do stolen Kerberos tickets create such a difficult detection problem?
- Why do zero-day vulnerabilities create such a difficult detection and response problem for cloud security teams?
- Why do API connections between SaaS apps create such a difficult detection problem?
- Why do modular Linux malware frameworks with rootkit support create such a difficult detection problem?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
