Attackers use drive-by targets to compromise users who visit a malicious or compromised site, often without obvious interaction beyond loading the page. Defenders should keep browsers and plug-ins patched, block risky web content, and watch for redirects, exploit kit behaviour, or unexpected downloads from sites that users should only be viewing.
How drive-by targets work in practice
Drive-by targeting is about catching users in a moment of ordinary browsing. The attacker does not need a user to install anything or approve a prompt if the page can trigger a browser flaw, a vulnerable plug-in, or a malicious redirect chain. That makes the technique attractive because the victim often thinks they only visited a normal site.
What makes the method effective is the path from trusted-looking content to silent exploitation. A compromised site, ad network, or injected script can route the browser through exploit infrastructure, deliver a payload, or lead the user to a download that appears routine. The browser becomes the delivery channel, so the attacker is relying on the visitor’s normal web activity rather than social engineering that demands a reply.
MITRE ATT&CK Guide for Defenders is useful here because the technique maps naturally to browser exploitation, redirect abuse, and download-based intrusion patterns that defenders can hunt for in telemetry.
What attackers are trying to gain
The immediate goal is usually initial access, followed by code execution, credential theft, or the installation of malware. In a drive-by scenario, the page visit is the trigger, but the real objective is to move from a browser session into a foothold on the endpoint or into the user’s account context. That can open the door to lateral movement, persistence, or a follow-on phishing step that looks more credible after the first compromise.
Attackers also use drive-by targets because they scale. A single compromised page or malicious advertisement can reach many visitors, and the attacker only needs one vulnerable browser, extension, or content-handling component to succeed. That makes patch lag and inconsistent browser hardening especially valuable to the attacker.
The State of NHI & AI Agent Breach Report 2026 is relevant because browser-driven compromise often becomes a broader credential and session theft problem once the initial foothold is established.
MITRE ATT&CK Enterprise helps defenders connect drive-by delivery to the later stages that usually matter most, especially execution, credential access, persistence, and lateral movement.
Reducing exposure from drive-by attacks
Defence starts with reducing the number of ways a web page can turn into execution. Keeping browsers and plug-ins patched matters because the attack succeeds only when the browser stack can be tricked into doing more than rendering content. Blocking risky web content, limiting unnecessary plug-ins, and tightening download handling all reduce the chance that a visit turns into code execution.
Controls should also focus on the web path itself. URL filtering, content inspection, and sandboxing can interrupt redirect chains and expose malicious content before it reaches the user. When possible, browser isolation or stronger content separation gives you a cleaner boundary between ordinary browsing and the internal environment.
NIST SP 800-53 Rev 5 Security and Privacy Controls supports this approach through control families for patching, configuration, monitoring, and system integrity.
NIST Cybersecurity Framework 2.0 also fits because this is a protect-and-detect problem: reduce exposure, then detect unusual browser behaviour, redirects, and unexpected downloads quickly.
Risk and Threat Considerations
Drive-by attacks are risky because the user’s normal browsing behaviour becomes the attack trigger. If the browser, plug-in, or web-handling component is vulnerable, a routine visit can produce compromise with very little visible friction, which makes these attacks hard for users to recognise and easy for adversaries to scale.
Failure mechanism: The attacker abuses a browser or content-processing weakness, often through redirects, malicious scripts, or exploit kit behaviour, so the page visit itself becomes the exploitation event.
Impact: Successful exploitation can lead to malware delivery, credential theft, session compromise, or a deeper endpoint foothold that supports later movement and persistence.
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 CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1189 — Drive-by Compromise | Directly covers malicious web pages used to compromise visitors. |
| Recommendation — Map browser exploit telemetry to T1189 and hunt for compromise after suspicious page visits. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Browser and plug-in patching is central to reducing drive-by exposure. |
| Recommendation — Prioritise patching for browsers and plug-ins under CIS-7 based on exploit exposure. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Drive-by attacks often depend on unpatched browser and content-handling flaws. |
| SI-3 — Malicious Code Protection | Blocking risky web content and downloads aligns with controlling malicious payload delivery. | |
| Recommendation — Apply SI-2 to remediate browser and plug-in vulnerabilities on a rapid cadence. Use SI-3 to block or quarantine malicious web content and download payloads. | ||
| NIST CSF 2.0 | DE.CM-09 — Monitoring for anomalies and events | Unexpected redirects and downloads require monitoring for anomalous browser activity. |
| Recommendation — Monitor browser and web proxy activity for redirects, exploit patterns, and unusual downloads. | ||
Practitioner Guidance
What to verify: Confirm that browser fleets, plug-ins, and download policies are actually enforced, not just documented. A patch baseline is not enough if unsupported extensions or inconsistent user settings still allow risky content paths.
What to measure: Track browser exploit detections, redirect anomalies, and unexpected file downloads from sites that should only be viewed, not interacted with. Those signals are often more useful than waiting for endpoint malware alerts.
Decision rule: If a user reports only visiting a page but an endpoint shows a new process, download, or browser crash, treat it as a possible drive-by event and investigate the page path, not just the endpoint itself.
Practitioner takeaway: Drive-by attacks succeed when web browsing is allowed to behave like execution, so the practical defence is to narrow what the browser is allowed to load, render, and download.