How do attackers use drive-by targets?

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.

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.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?