A drive-by attack is a cyberattack that infects a device simply by visiting a compromised or malicious website, often without any click or download. Technically, it uses browser flaws, script injection, or malicious redirects to deliver malware, steal data, or stage follow-on intrusion across endpoints and identities.
How Drive-By Attacks Work
Drive-by attacks exploit the ordinary act of browsing. A compromised page, malicious ad chain, or injected script can trigger exploitation in the browser or its plug-ins without asking the user to approve a download, which makes the initial infection path fast and low-friction.
The attack usually depends on a weakness in the browser stack, a vulnerable extension, or a malicious redirect path. Because the user experience can look normal until execution begins, drive-by attacks are especially effective against systems that are not tightly patched or that still allow unsafe web content handling.
Why Drive-By Attacks Are Dangerous
The danger is not just that malware can land on an endpoint, but that the browser often has direct access to session cookies, saved credentials, enterprise web apps, and local trust relationships. Once a drive-by payload executes, attackers can move from a single browser foothold to data theft, credential capture, and follow-on intrusion.
Drive-by attacks also scale well for adversaries because they can be delivered through common web infrastructure and blended into legitimate traffic. That means a user does not need to visit an obviously suspicious site for risk to exist, and a single exposed browser vulnerability can affect many devices at once.
Common Delivery Paths and Exploitation Conditions
Typical delivery paths include compromised websites, malicious advertisements, watering-hole pages, and redirect chains that send users into exploit code. The attacker’s goal is usually to reach a vulnerable browser component before the page is fully recognised as unsafe.
Exploitability increases when browser versions lag behind current fixes, when script execution is overly permissive, or when endpoint protections do not block exploit staging and payload retrieval. Modern attacks may combine multiple steps, such as browser exploitation followed by credential theft and then lateral movement into internal systems.
For a broader view of how compromised browsers and stolen access can become part of a larger intrusion chain, see the The State of NHI & AI Agent Breach Report 2026, which documents how attackers commonly expand from initial compromise into secret theft and lateral movement.
Detection, Containment, and Recovery After a Drive-By Attack
Detection often starts with endpoint telemetry, browser crash or exploit signals, unusual outbound connections, suspicious child processes, and unexpected downloads or script activity. After suspected exploitation, organisations should review affected endpoints for persistence, credential exposure, and any signs that the browser was only the first stage of compromise.
Containment usually requires isolating the device, removing malicious browser artefacts, and checking whether the attacker harvested sessions, tokens, or stored passwords. The recovery process should include post-incident review of web access logs, endpoint alerts, and identity activity that may reveal whether the compromise extended beyond the browser.
Authoritative alerting and exploitation tracking are often published through CISA cyber threat advisories, which are useful when matching observed behaviour to known exploit patterns and active threats.
Risk and Threat Considerations
Drive-by attacks matter because they collapse the distance between ordinary browsing and device compromise. The main risk is that a normal-looking page visit can become an entry point for malware delivery, credential theft, and further intrusion before the user or defender realises anything happened.
Failure mechanism: The browser processes untrusted content, malicious redirects, or injected code in a way that triggers exploit execution before content is safely constrained or blocked.
Impact: Attackers can gain code execution, steal browser-resident secrets or sessions, and use the compromised endpoint as a launch point for deeper access.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1189 — Drive-by Compromise | Directly models infection through a malicious website visit. |
| Recommendation — Map web-delivered compromise to T1189 and hunt for browser-based staging and payload delivery. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Drive-by attacks deliver malware through web content and exploit chains. |
| SI-4 — System Monitoring | Browser exploitation needs endpoint and network detection to spot the attack chain. | |
| Recommendation — Apply SI-3 to block, detect, and contain malicious code delivered via the browser. Use SI-4 to monitor browser crashes, exploit signals, and suspicious outbound activity. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Drive-by attacks often depend on unpatched browser and plug-in weaknesses. |
| CIS-10 — Data Recovery | Compromised endpoints may need restoration after browser-based infection. | |
| Recommendation — Prioritise CIS-7 to patch browsers and related components quickly. Use CIS-10 to ensure infected endpoints can be restored and validated after compromise. | ||
Practitioner Guidance
Why practitioners should care: Drive-by attack risk is reduced less by user vigilance alone and more by strong browser hygiene, secure configuration, and rapid patching. If browsers or plug-ins remain exposed, the attack surface stays open even when users avoid obviously suspicious downloads.
What to watch for: Focus on unexpected browser crashes, exploit-like telemetry, unusual script loading, and outbound connections that begin immediately after a page visit. Those signals can indicate that the web session was used as the initial compromise path rather than as ordinary browsing.
Practitioner takeaway: Treat the browser as an execution environment, not just a viewing tool, and assume that a single untrusted page can become an endpoint incident if hardening and detection are weak.