Drive-by Downloads Guide: Compromised Sites, Exploit Kits and Browser Defences

A drive-by download is malware delivered to a computer simply because the user visited a web page, either silently through a browser or plug-in exploit, or by a page that tricks the user into running a file they did not mean to install. The user does not open an email attachment or go looking for software: the website, an advert on it or a script it loads does the work. MITRE ATT&CK tracks the technique as T1189 Drive-by Compromise. This explainer covers how compromised and malicious sites deliver payloads, what happened to exploit kits, why the threat has shifted towards social engineering in the browser, and the layered browser and endpoint defences that stop it. It is for endpoint, SOC and IT teams who manage browsers at scale.

Key takeaways

• The website is the delivery vehicle. Legitimate sites that have been compromised, malicious adverts, poisoned third-party scripts and attacker-run look-alike sites all serve drive-by content.
• Exploit kits peaked and declined. Automated browser and plug-in exploitation was common in the Flash and Java era; with those plug-ins gone and browsers auto-updating, most drive-by activity now relies on fake updates and lures that persuade the user to run a file.
• Patching the browser is the biggest single control. Fast automatic updates, sandboxing and Site Isolation remove most of the silent-exploit path; what remains is mostly zero-day or n-day exploitation of unpatched browsers.
• Reputation and script controls catch the user-assisted path. SmartScreen or Safe Browsing with bypass disabled, ASR rules and application control stop downloaded files from running.
• Isolation and EDR are the safety net. Remote browser isolation keeps risky content off the endpoint, and EDR catches the browser spawning unexpected processes.

What it is

In everyday terms, a drive-by download is like picking up an infection by walking into the wrong shop: you did nothing obviously risky, but the premises were contaminated. In security terms there are two forms:

• Silent exploitation: script on the page fingerprints the browser and, if a vulnerable version is found, exploits it to run code with no user action beyond the visit. ATT&CK links this to T1203 Exploitation for Client Execution.
• User-assisted download: the page shows a convincing prompt, such as a fake browser update, missing font or document viewer, and the user runs the file. This leads to T1204.002 Malicious File.

ATT&CK v20 lists the delivery routes for T1189: a legitimate website compromised to inject code; script files served from a publicly writable cloud storage bucket that an attacker modifies; malicious adverts bought through legitimate ad networks (T1583.008 Malvertising); and user-controllable content such as cross-site scripting. It also notes abuse of browser push notification permissions. When the compromised site is chosen because a specific community visits it, the campaign is a watering hole, covered separately in the Watering Hole Attacks Guide.

How it works

A typical chain has four stages. Defenders can break it at any one of them.

1. Staging: the attacker prepares infrastructure and content (ATT&CK T1608.004 Drive-by Target), for example by injecting script into a content management system, a compromised plug-in or theme, a third-party library or an ad creative.
2. Redirection and filtering: the injected code sends visitors through one or more redirects. Filtering by country, browser, operating system, referrer or whether the visitor looks like a security scanner keeps the payload hidden from researchers.
3. Delivery: either an exploit runs against the browser, or a lure page offers a download.
4. Execution and follow-on: the payload, often a loader, infostealer or remote access tool, runs and reaches out to command and control. Infostealers turn one visit into stolen browser sessions, saved passwords and tokens; see the Infostealer Threat Guide.

Delivery routes compared

Exploit kits: history and decline

Exploit kits were commercial toolkits that packaged browser and plug-in exploits behind a landing page and sold access as a service. They were most active in the first half of the 2010s, when Adobe Flash Player, Java browser plug-ins and older Internet Explorer versions gave them a large, slowly patched target. Their decline followed the removal of those targets: browsers moved plug-ins out (Flash reached end of life at the end of 2020), auto-update became the default, and sandboxing raised the cost of each working exploit chain. The NCSC still advises treating plug-ins such as Java, Flash and Silverlight as a major route to compromise and removing them where not needed. Silent drive-by exploitation has not disappeared, but today it is mostly targeted use of browser zero-days, which the Zero-Day and Exploited Vulnerabilities Guide covers.

Why it matters

Drive-by delivery bypasses email security entirely and reaches users through sites they trust, including on unmanaged and home networks. Fake update and trojanised installer campaigns are a common first step towards ransomware and credential theft. Because the payload often steals browser-held sessions and tokens, one visit can expose SaaS, cloud and developer credentials, including those of service accounts saved in a browser profile.

Browser and endpoint defences

Two limits are worth knowing. SmartScreen does not protect against malicious files on internal UNC or SMB shares, per Microsoft's documentation. And the NCSC advises against disabling JavaScript wholesale, because it breaks the modern web; targeted controls work better.

Rolling out the controls

1. Baseline: inventory browsers, versions and extensions across the estate; remove unsupported browsers and legacy plug-ins, keeping a separate browser only for any unmigratable legacy app, as NCSC suggests.
2. Patch cadence: enforce auto-update with a relaunch deadline (for example 24 to 72 hours) and track version compliance. See the Patch Management Guide.
3. Reputation with no bypass: enable SmartScreen or Safe Browsing and the prevent-bypass policies first for a pilot ring, review the false positives reported, then extend.
4. ASR in audit mode: deploy the script and prevalence rules in Audit, review AsrScriptExecutableDownloadAudited and AsrUntrustedExecutableAudited events in advanced hunting for two to four weeks, add narrow exclusions, then switch to Block. Roll back by returning a rule to Audit, not by removing it.
5. Harden browsing: enable enhanced security mode in Balanced, block notification prompts and restrict extensions to an allowlist.
6. Isolate the residual risk: send uncategorised and newly registered domains to isolation or a read-only view rather than blocking everything.
7. Control software sources: provide a self-service catalogue so users have no reason to download installers from search results, and back it with application control. See the Application Allowlisting Guide.

Choosing controls by organisation size

• Small organisations: managed auto-updating browsers, built-in reputation with bypass disabled, standard users without local admin, and protective DNS cover most of the risk at little cost.
• Large organisations: add ASR or equivalent execution controls, application control, isolation for risky categories and EDR detections tuned for browser child processes. An enterprise browser may suit some groups; see the Enterprise Browser and Browser Security Guide.
• Isolation versus blocking: blocking uncategorised sites is cheaper but generates help desk tickets; isolation keeps users productive at the cost of licences and some rendering issues. Many teams isolate only uncategorised and high-risk categories.

Detection and measurement

• Process signals: browser processes launching wscript.exe, cscript.exe, mshta.exe, powershell.exe or cmd.exe; files with Mark of the Web executed from Downloads shortly after a browser visit.
• Network signals: visits to newly registered domains followed by a download, redirect chains through several unrelated domains, and DNS lookups for known malicious infrastructure.
• Browser signals: SmartScreen or Safe Browsing block events, users who repeatedly trigger warnings, and out-of-date browser versions.

Useful metrics: percentage of endpoints on the current browser version within 72 hours of release; ASR block events per 1,000 endpoints and the false-positive rate; count of reputation warnings bypassed (target zero once prevent-bypass is enforced); share of software installs coming from the approved catalogue; mean time from browser-spawned suspicious process to containment.

Framework mapping

Common misconceptions

• "Only shady sites are dangerous": compromised legitimate sites and malicious adverts on mainstream sites are standard routes in ATT&CK's own description of T1189.
• "Exploit kits are gone, so drive-bys are gone": the silent-exploit share fell, but fake update and trojanised installer lures delivered the same way are common.
• "Antivirus will catch it": loaders change quickly; reputation, execution controls and behaviour detection matter more than signatures.
• "Users who see a warning will stop": without prevent-bypass policies many click through, which is why Microsoft recommends enabling them.
• "Disable JavaScript to be safe": NCSC advises against it; harden JIT and isolate instead.

Failure patterns that recur: browsers left waiting for a user restart for weeks, so "auto-update" never applies; reputation enabled but bypass allowed; users with local admin rights who can install anything a page offers; broad ASR exclusions for whole folders such as Downloads; and website owners loading third-party scripts from CDNs without Subresource Integrity, turning their own site into a delivery vehicle.

Related concepts

• Watering hole attacks: targeted drive-bys against a chosen community. See the Watering Hole Attacks Guide.
• Malvertising and SEO poisoning: paid and search-driven routes to malicious downloads. See the Malvertising and SEO Poisoning Guide.
• HTML smuggling: assembling a payload inside the browser to evade gateways. See the HTML Smuggling Guide.
• Content Security Policy: site-side control over which scripts load. See the Content Security Policy Guide.
• Browser extensions: a related browser-borne risk. See the Browser Extension Security Guide.

Practitioner checklist

• Enforce automatic browser updates with a relaunch deadline and report version compliance weekly.
• Remove unsupported browsers and legacy plug-ins; restrict extensions to an allowlist.
• Enable SmartScreen or Safe Browsing with prevent-bypass policies for sites and downloads.
• Deploy ASR script, prevalence and obfuscation rules in Audit, tune, then Block.
• Enable Edge enhanced security mode (Balanced) or equivalent JIT restrictions for unfamiliar sites.
• Remove local admin rights from standard users and back them with application control.
• Route uncategorised and newly registered domains to isolation or block, and use protective DNS.
• Alert in EDR on browsers spawning script hosts or shells.
• For your own websites, pin third-party scripts with Subresource Integrity and enforce a Content Security Policy.

Standards and references

• MITRE ATT&CK: T1189 Drive-by Compromise
• NCSC: Managing web browser security
• Microsoft Learn: Available Microsoft Defender SmartScreen settings
• Microsoft Learn: Attack surface reduction rules reference
• Microsoft Learn: Browse more safely with Microsoft Edge
• Chromium: Site Isolation
• Google: Safe Browsing
• Sansec: Polyfill supply chain attack

Related NHI Mgmt Group resources: Watering Hole Attacks Guide · Malvertising and SEO Poisoning Guide · Remote Browser Isolation Guide · Infostealer Threat Guide · Man-in-the-Middle Attacks Guide