Malvertising: How Trusted Ads Deliver Malware

She opened The New York Times on a Tuesday morning in March 2016. A marketing director in Chicago, coffee still brewing, skimming the news before a 9 a.m. call. She read three articles. She didn’t click any ads — she barely noticed them. She closed the browser and started her day.

By early afternoon, her machine was showing her a ransom note.

The attackers hadn’t targeted her specifically. They hadn’t broken into the Times’ servers. They hadn’t sent her a phishing email. They’d bought an ad slot in the Times’ ad network, disguised it as a legitimate campaign, and used it to push malicious code to every browser that loaded the page. The New York Times’ own security team spent the day trying to understand what had happened. The malicious ad had slipped through their network, exploited an unpatched browser vulnerability using the Angler exploit kit, and installed ransomware before the page had fully loaded.

The Times didn’t serve the malicious ad directly. They sold the slot. The network filled it with something they had no way to review in time.

This is malvertising: malware delivered through advertising networks to readers of completely legitimate, high-quality websites. The attack doesn’t require the publisher to make a mistake. It doesn’t require you to click anything. It requires only that you load a page and that your browser has an unpatched vulnerability. Both of those things are true for most people, most of the time.

The short answer: Malvertising is malware pushed through the ad slots on real, reputable websites. Attackers buy ad inventory, pass an approving benign creative, then swap in code that exploits an unpatched browser and installs a payload as the page loads. No click needed. The single most effective defence is a content blocker like uBlock Origin: if the ad never loads, the malicious ad never runs. Back it up by keeping your browser and OS patched, removing Flash and Java, and adding DNS-level filtering.

Jump to:

Why “I only visit safe sites” doesn’t protect you

This is the belief that malvertising shatters. It’s reasonable — the logic is that malware lives on sketchy websites, so staying on reputable ones keeps you safe. For many threats, that’s largely true. For malvertising, it’s exactly wrong.

The whole premise of a malvertising attack is that it operates through the infrastructure of legitimate publishers. The New York Times has a dedicated security team. The BBC has one. MSN has one. None of them served malware intentionally, and none could prevent it in the moment, because the malware didn’t come from them. It came from an ad network they’d contracted with. That network sourced the ad from an exchange the publisher had no direct relationship with. And that exchange accepted a bid from an advertiser who had passed initial automated review.

The publisher is the face of what you’re reading. They’re not the source of most of the code running in your browser when you read it.

The second belief malvertising challenges is that you need to click something to get infected. You don’t. Drive-by downloads — the technical term for the attack vector — require no user action. The ad loads. The malicious code in the ad runs. The code checks your browser and installed plugins for known vulnerabilities. If it finds one, it downloads and executes a payload without triggering any visible prompt, any download dialog, anything you’d notice.

You read an article. You close the browser. Your machine is already compromised.

How online advertising actually works

Malvertising is hard to stop for a reason rooted in how ads load. A lot happens in the roughly 100 milliseconds between when you request a web page and when the ads appear on it.

Publishers — websites, news outlets, media companies — sell ad space on their pages. But most of them don’t manage this process themselves. They contract with ad networks to fill their inventory. The ad network aggregates available space across many publishers and sells it to advertisers.

The modern ad ecosystem goes further than that. Most major publishers connect to programmatic ad exchanges: open marketplaces where any qualified buyer can bid on ad inventory in real time. When you load a page, your browser sends a request to the publisher’s server. The publisher’s server fires a request to the ad exchange. In effect it says: “I have a visitor with these attributes (age range, geography, interests, device type) who will see this ad slot. What will anyone pay to reach them?” Hundreds of potential buyers submit bids automatically, in milliseconds. The highest bidder wins. The ad loads.

The entire auction completes before the page finishes loading. You never see it happen.

Here’s the structural problem: the publisher may have a direct relationship with one or two ad networks. Those networks connect to open exchanges with thousands of registered buyers. The identity verification on many of those buyers ranges from minimal to perfunctory. The publisher doesn’t know who’s serving you an ad. The exchange may not know in any meaningful depth. Automated scanning can catch known-malicious code — but attackers design their campaigns specifically to pass automated review.

The result is that the ad slot on the New York Times’ website is effectively open to any buyer. They need only pay for it and appear legitimate enough to pass automated screening. That’s the attack surface.

How the attack is constructed

Attackers approach this methodically. The first step is gaining access to the ad ecosystem. This usually means one of three things. They buy an existing ad account whose credentials were stolen. They register a shell company with enough surface-level legitimacy to pass advertiser verification. Or they exploit a compromised legitimate advertiser account. The barrier to entry is lower than it should be, because ad networks have historically prioritised scale over rigorous buyer vetting.

The attacker then creates an ad creative — the banner or video or display unit you’d see on a page. The initial creative is benign. It passes automated review because it is, at the moment of review, exactly what it appears to be. This is the move that makes malvertising particularly hard to catch: the ad that gets approved is not the ad that delivers the malware.

Once the campaign goes live, the attacker swaps the payload. They update the ad’s behavior — not the visual content, but the code the ad executes when it loads in your browser.

Some techniques are more sophisticated. Steganography — hiding data inside image files — has been used to smuggle malicious code past scanners that examine ad content. The ad banner is a completely normal-looking image. But embedded within the image data, invisible to visual inspection, is a payload that a companion piece of malicious JavaScript extracts and executes. Scanners looking at the image see an image. They don’t see the malware.

Other attacks simply embed malicious JavaScript directly in the ad unit. That JavaScript runs as part of the page’s normal rendering process. It checks your browser version, your installed plugins, your operating system. It’s looking for known vulnerabilities — unpatched browser engines, outdated PDF readers, anything with a published exploit available. If it finds a match, it sends a request to the attacker’s server, retrieves the appropriate payload for your specific configuration, and runs it.

No click. No download dialog. No warning.

The exploit kit ecosystem

Behind the technical execution of most malvertising attacks is a class of tools called exploit kits. These are sophisticated software packages sold and rented on criminal markets. They automate the entire process of identifying browser vulnerabilities and delivering the matching payloads.

Angler was the exploit kit that powered the 2016 New York Times attack. By the standards of its era, Angler was exceptionally capable. It exploited vulnerabilities in Adobe Flash, Microsoft Silverlight, and Internet Explorer, and it rotated domain infrastructure so aggressively that blocklists couldn’t keep up. Angler handled geographic targeting (some campaigns delivered payloads only to US or UK IP addresses to maximise the value of each infection), evasion, and obfuscation. It was available as a service on criminal markets, allowing attackers without deep technical expertise to run sophisticated campaigns.

Law enforcement took down the infrastructure behind Angler in late 2016. RIG rose to fill the gap. Less technically innovative than Angler, but persistent — RIG-based campaigns continued to be documented into 2024, exploiting browser engine vulnerabilities and delivering ransomware and banking trojans. Magnitude focused heavily on ransomware delivery and operated for years through compromised ad networks. Neutrino was active for several years before its operators reportedly retired it; the codebase circulated underground afterward.

These aren’t exotic government-grade tools. They’re crime-as-a-service platforms. An attacker doesn’t need to understand how a browser vulnerability works to exploit it. They need to rent the kit and buy the ad inventory.

The incidents

The 2016 New York Times incident is the most cited malvertising case, in part because it was so cleanly documented. Malwarebytes’ security researchers identified the campaign in real time. They traced it to the Angler exploit kit operating through the DoubleClick and AppNexus ad networks. They confirmed that readers who loaded the Times’ homepage received a ransomware payload, a variant called CryptoWall. The Times took the ads down once the campaign was identified. But the damage was already done to anyone who loaded the affected pages while the campaign was live.

Spotify ran into malvertising in 2011 — earlier than most people remember these attacks happening. Users reported browser windows opening unprompted, attempting to install software they hadn’t requested. Spotify confirmed the issue, acknowledged that malicious ads had been served through their ad network, and removed them. The attack relied on users having Adobe Flash installed, which was essentially universal at the time.

The 2016 mass campaign identified by Malwarebytes struck several major publishers at once. BBC Online, The Huffington Post, AOL, and MSN all served malvertising from the same campaign in the same period. The attack exploited vulnerabilities in Adobe Flash and Microsoft Silverlight to deliver ransomware. It was not a targeted attack against any one publication. It was a programmatic buy against high-traffic inventory — the attackers wanted volume, and these sites provided it.

Malvertising continued to evolve as Flash was deprecated and eventually killed. Attackers moved to exploiting browser engine vulnerabilities directly, targeting PDF readers, and abusing JavaScript capabilities. The tooling changed; the fundamental attack model did not.

By 2023, researchers documented a significant shift in malvertising strategy: search result ads. Attackers purchased Google Search sponsored placements for high-intent queries like “download VLC,” “7-Zip free,” and “OBS Studio download.” The sponsored links at the top of search results pointed to domains crafted to resemble the real software projects, such as vIc-player.com instead of videolan.org. Landing pages served modified installers with bundled malware. Often it was an information stealer like Vidar or RedLine, designed to harvest browser cookies, saved passwords, and session tokens. Users searching for legitimate software and clicking the top result were downloading malware.

This variant is particularly insidious because it targets active download intent. Users at that moment expect to download something. The friction of “a file is being downloaded” that would alarm a careful user in another context is not alarming when you’re actively trying to download something.

Why ad networks struggle to prevent this at scale

The honest answer is that the scale is incomprehensible. Google’s ad network alone processes billions of individual ad transactions every day. Manual review of each ad at that volume isn’t possible. Automated scanning is the only viable approach, and automated scanning has structural weaknesses.

Signature-based detection — looking for known-malicious code patterns — fails against adversaries who modify their payloads for each campaign. The change doesn’t need to be large. Attackers vary variable names, rearrange function structure, encode strings differently. Each variation is technically new code. Signatures targeting the old version don’t match.

Behavioral analysis, running ad code in a sandbox and watching what it does, is more robust but slower and resource-intensive. And sophisticated attackers design around it. The malicious behavior triggers only after a delay, or only against IP addresses in certain geographic ranges, or only on browsers with characteristics that distinguish real users from scanners. The sandbox doesn’t look like a real user. The malware knows.

Confiant, a firm that specialises in ad quality and security, documented over 130 distinct malvertising campaigns in its 2023 annual report. DoubleVerify’s research consistently finds that a meaningful share of ad impressions across the open web involve some form of ad fraud or unsafe content. The malvertising portion varies by campaign, but it is not a rounding error.

The economics work in the attacker’s favor. A successful malvertising campaign runs for days or weeks before detection. It reaches readers across dozens or hundreds of publishers. Each infected machine can yield ransomware payments, stolen credentials sold on underground markets, or access to banking sessions worth hundreds of dollars each. The attacker’s cost is ad inventory — which they’re buying with stolen payment methods or laundered funds anyway — and whatever they paid to rent the exploit kit. The return on a successful campaign is substantial.

What happens on your machine

Let’s be concrete about the sequence, because understanding it makes the defenses make sense.

You open a news article. Your browser requests the page. The page’s HTML loads and begins to render. The page contains references to ad slots — these are essentially instructions to your browser to go fetch content from a third-party ad server. Your browser dutifully makes those requests. The winning ad from the real-time auction loads into the ad slot.

That ad contains JavaScript. Your browser executes it, because JavaScript in web content runs by default. The JavaScript fingerprints your environment: browser version, installed plugins, operating system, screen resolution, whether you’re in a sandboxed environment. It sends this information to the attacker’s server and receives instructions back.

If your browser has a known vulnerability the attacker’s exploit kit can target, the kit sends the appropriate shellcode. This code exploits the vulnerability — overwriting memory in a way that redirects execution to attacker-controlled instructions. The attacker’s code now runs with whatever privileges your browser process has.

That code downloads an executable payload from a remote server and runs it. What it is depends on the campaign. The payload might be ransomware or a banking trojan that intercepts your transactions. It might be an information stealer that harvests your saved passwords and session cookies, or a botnet agent that puts your machine to work in a criminal network.

The entire sequence — from page load to malware execution — takes seconds. Nothing visible happens. No dialog box. No prompt. No file appears in your downloads folder in any obvious way. You finish reading the article.

The protection that actually works

An ad blocker. This is the most effective single control against malvertising, and it’s free. uBlock Origin, available for Firefox, Chrome, and Edge, blocks requests to ad network domains entirely. If the ad request never leaves your browser, no ad loads. No ad loads means no malicious ad loads. The attack has no surface to operate on.

This isn’t incidental protection — it’s total protection against this specific attack vector. The malvertising payload cannot execute code in your browser if it’s never served to your browser. uBlock Origin is open-source, maintained by an active community, and consumes fewer resources than running ads does. Install it.

Keep your browser updated. Exploit kits target known vulnerabilities with published patches. The window between when a vulnerability is disclosed and when a patch is released is when zero-day exploits operate. But a large fraction of malvertising campaigns exploit vulnerabilities that have patches available — the attacker is counting on the gap between patch release and when users apply it. Automatic browser updates close that gap. Enable them and don’t dismiss the prompts.

Update your operating system. Browser exploits sometimes escalate privileges using OS vulnerabilities. An up-to-date OS closes that escalation path.

Remove Flash, Java, and Silverlight. If these browser plugins are still present and enabled in any browser you use, disable them. All three are discontinued and no longer receive security patches. They were the primary exploit surface for malvertising campaigns throughout the 2010s, and any unpatched vulnerabilities in them will never be fixed. Modern browsers have removed support; check your browser’s plugin settings and confirm these are absent or disabled.

DNS-level filtering. Services like Cloudflare Gateway, NextDNS, or Quad9 block known-malicious domains at the DNS resolution level, before your browser ever makes a connection. Pi-hole provides the same capability if you want to run it locally. These don’t replace an ad blocker — they operate on a different layer — but they add another barrier. A malvertising payload that tries to call home to a known-malicious server gets blocked at DNS before any data moves.

Script blocking for high-security browsing. Extensions like uMatrix or NoScript give you granular control over which scripts execute on which domains. The tradeoff is friction — many websites partially break when you block third-party scripts. But for high-sensitivity browsing — accessing financial accounts, anything sensitive — the protection is substantial. You can allowlist domains you trust and default-deny everything else.

The harder question is whether to whitelist publishers when they ask. Many sites detect ad blockers and request you disable blocking to support their journalism. This is a legitimate concern — ad revenue funds free reporting, including from the publications whose readers have been hit by malvertising. Whether to comply is a judgment call. The security calculus is that the ad networks those publishers work with represent risk you cannot independently assess. Even if you trust the publisher, you can’t audit who they’ve contracted with, who those contractors work with, and who’s currently buying inventory on those exchanges.

The search ad variant deserves special attention

The 2023 shift toward search result malvertising changes the threat model in one important way: it targets users who are actively trying to download something. This makes the normal malware-defense instinct — don’t download unexpected files — insufficient. You expected a download. You initiated it. You clicked a result that appeared at the top of a Google search.

The protection here is different. When downloading software, go directly to the software’s official website rather than clicking search results — even sponsored ones. Type the URL or navigate from the software’s official documentation. Verify that the domain you’re downloading from matches the software’s actual home: videolan.org for VLC, 7-zip.org for 7-Zip, obsproject.com for OBS. The fake domains used in these campaigns are close but not exact — a character swapped, a hyphen added, a different TLD.

Sometimes a download just feels off. The file size is unusual, your antivirus flags it, the installer’s interface looks slightly wrong, or it asks for permissions the software shouldn’t need. When that happens, stop. Delete the file. Go to the official source and start over.

Malvertising through search results is increasingly how information stealers reach machines. The credentials and session tokens those stealers harvest feed credential stuffing attacks, account takeovers, and fraud. The chain from “I clicked a sponsored search result for a free download” to “someone accessed my bank account” is shorter than it looks.

What you can do right now

Want to see what data brokers expose about you? See what a scan finds → shows an example report: the kinds of sites that list your name, phone, and address. Once KnytX Shield launches it will find and remove these automatically. Join the waitlist to get in early.