Definition
A drive-by download is malware that ends up installed on a device simply because someone visited a webpage. No file was knowingly opened, no installer was run, no attachment was clicked. The victim’s only action was loading a page, the same completely ordinary action they take dozens of times a day.
What Makes It Work
The web works by letting a page run code in a visitor’s browser: that’s not a bug, it’s the entire mechanism behind every interactive website. The assumption everyone quietly makes is that this code is confined to a sandbox: it can animate a menu or validate a form, but it can’t reach outside the browser and touch the underlying device. A drive-by download happens when that sandbox has a real flaw, in the browser itself or in a plugin the browser loads, and a page’s code uses that flaw to step outside the boundary it’s supposed to be confined to. What breaks isn’t the user’s judgment; it’s the technical isolation between “displaying content” and “running arbitrary code on the host,” which is the actual security property the browser sandbox exists to guarantee.
Where It Actually Shows Up
- A legitimate site that’s been compromised, silently serving malicious code alongside its normal content to visitors who have no reason to suspect anything: the exact delivery mechanism behind watering hole attacks.
- Malvertising: a malicious ad served through an otherwise legitimate, reputable ad network, which most sites embed without individually vetting every ad that gets served through it.
- Outdated browsers or browser plugins carrying a known, publicly disclosed flaw that simply hasn’t been patched yet on the visitor’s device: the single most common enabling condition.
Why It Keeps Succeeding
Patching browsers and plugins across a large population of individual devices is genuinely inconsistent. Some people update immediately, many don’t for weeks or months, and a single unpatched machine is all this technique needs. Worse, the usual security advice people are trained on (“don’t click suspicious links,” “don’t open unexpected attachments”) simply doesn’t apply here. A compromised legitimate site or a malicious ad on a trusted network carries the visitor’s existing, earned trust; there is no suspicious link to hesitate over, because the page itself looks completely normal.
How to Detect It
- Browser and endpoint isolation or sandboxing that contains exploitation attempts even against a flaw that hasn’t been patched yet, rather than relying on patching alone to be complete and current at all times.
- Monitoring for unexpected outbound network connections immediately following ordinary web browsing activity: a legitimate page loading images and scripts doesn’t normally trigger a connection to unfamiliar infrastructure.
- Maintaining a real inventory of browser and plugin versions across the organization’s devices, so actual exposure to known, disclosed flaws is a known quantity rather than a guess.
Impact by Scenario
| Scenario | Realistic impact |
|---|---|
| Fully patched, sandboxed browser on a low-privilege user account | Exploitation attempt likely fails or is contained; limited to no lasting compromise |
| Outdated browser or plugin with a known, unpatched flaw | Successful, silent malware installation with no user awareness that anything happened |
| Infected device runs under a high-privilege account (e.g. a shared administrative workstation) | Malware inherits that privilege level, turning a single-device compromise into a much larger foothold |
| Infected device sits on a flat, unsegmented internal network | The initial infection becomes a launching point for further lateral movement, not a contained incident |
Why a Business Should Care
The most important thing to communicate to a client about this specific technique is that it requires no employee mistake at all: no one clicked anything they shouldn’t have, no one was fooled by a convincing email. That reframes the conversation about controls: security-awareness training, while genuinely useful against phishing and social engineering, does essentially nothing against this technique, because there was never a decision point for a trained employee to get right or wrong. The mitigation has to be technical (patching discipline and browser isolation), not behavioral, and a client budgeting only for training while skipping patch management is leaving this specific door wide open.
A Worked Example
(Generalized from common assessment patterns. Company and identifiers below are invented; no real system, client, or data is referenced.)
During a routine security assessment for a mid-sized logistics company, Solheim Freight, the assessment team inventories browser and plugin versions across a sample of employee workstations as part of standard endpoint hygiene checks. Roughly a fifth of sampled machines are running a browser version with a publicly disclosed, patched-in-a-later-release memory-corruption flaw. The fix exists and has been available for months; it simply hasn’t been deployed to these specific machines.
The team doesn’t need to develop or run a live exploit against the flaw to make the finding real: the version number itself, cross-referenced against the public disclosure for that flaw, is sufficient proof that these specific machines are currently exposed to any page, compromised legitimate site or malicious ad, capable of using it. The finding is reported as a patch-management gap with a demonstrated, named exposure, not a hypothetical “keep your browser updated” recommendation.
Severity Calibration
Severity here tracks two things, neither of which is the delivery method’s cleverness: what privilege level the exploited browser process (and by extension the malware it drops) could act with, and what that specific device could reach on the network afterward. A patched, sandboxed browser on an isolated low-privilege account represents a much lower real ceiling than the identical unpatched flaw reached from an unsegmented, high-privilege workstation. The vulnerability class is the same; the demonstrated blast radius is not.
Prevention & Response
The real fix is disciplined, largely automated browser and plugin patching, deployed promptly and verified, not left to individual users’ judgment, combined with browser isolation or sandboxing technology that contains an exploitation attempt even during the window before a patch is deployed. Ad networks serving content to managed corporate browsing environments are worth vetting or restricting specifically because malvertising is a real, recurring delivery path for this technique.
The common inadequate response is leaning entirely on security-awareness training as if this were a user-judgment problem. It structurally isn’t: there’s no suspicious link to train someone to avoid, because the page was never suspicious-looking in the first place.
Related Attacks & Vulnerabilities
- Watering Hole Attack: the targeting strategy that most often puts this exact delivery mechanism in front of a specific, chosen audience rather than random visitors.
- Malware: the broader category of payload a drive-by download typically installs once the underlying browser or plugin flaw has been exploited.