Malvertising: Forced Redirects, Fake Download Ads and How They Get Through
How malicious ads reach legitimate websites and apps through programmatic advertising, how forced redirects and app-open hijacks work, and what readers, publishers and advertisers can do.
Malvertising is malicious or deceptive code delivered through the advertising system itself. Nobody has to hack the website: the site sells an ad slot, the slot is filled by an automated auction, and the winning creative carries the payload. That is why it turns up on large news sites, search results and popular apps, places readers have learned to trust.
This guide covers how malicious ads reach those pages, the payloads in circulation, and what readers, publishers and advertisers can each do. Software already installed on your device that injects ads is a different problem, covered in What Is Adware?.
How an ad slot gets filled
Understanding the delivery path explains why screening misses so much.
- The page loads an ad library, usually Google Publisher Tag plus a header-bidding wrapper such as Prebid.js.
- Header bidding runs an auction in the browser, sending the slot to a dozen or more supply-side platforms at once.
- Each platform resells to demand-side platforms, which bid for advertisers. Between the publisher and the advertiser there can be several resellers, each listed (or not) in the publisher's
ads.txtfile. - The winner's creative is delivered as HTML and JavaScript that runs inside an iframe on the page, or in some formats inside the page itself.
The whole chain completes in a few hundred milliseconds, and the publisher usually never sees which creative won. A typical news article in our own phone-emulated tests in October 2026 contacted 150 to 220 third-party domains, most of them part of this machinery.
The payloads
| Payload | What the visitor sees | What it is after |
|---|---|---|
| Forced redirect | The page jumps to a prize, survey, fake virus alert (scareware) or app store page with no tap | Scam leads, app installs, affiliate commission |
| App-open hijack | A shopping or betting app opens on its own | Affiliate attribution on purchases that follow |
| Fake download ad | A sponsored search result for a popular tool | Infostealer or remote-access malware |
| Notification farming | "Click Allow to verify you are not a robot" | Permission to push ads and scams later |
| Tech support lure | A full-screen alert with a phone number | A paid "repair" call or remote access; see Tech Support Scams Explained |
| Drive-by exploit | Nothing visible | Code execution through a browser bug; rare today on patched browsers |
Forced redirects
A forced redirect creative sets top.location (or window.location when it runs in the page itself) as soon as it runs. Browsers have narrowed when that is allowed. Announced for Chrome 64 and shipped in Chrome 68 in 2018, Chrome stopped iframes from a different origin than the page from navigating the top window unless the user had interacted with that frame, showing an infobar instead, and it also blocked tab-unders, where a link opens a new tab while the original page is swapped for an ad. The HTML sandbox attribute gives publishers a further switch: allow-top-navigation-by-user-activation permits navigation only after a real tap.
Redirect creatives respond by looking for code paths those rules do not cover:
- Same-origin frames. A header-bidding wrapper or ad add-on that renders creatives into a same-origin ("friendly") iframe or directly into the page gives the creative the page's own authority.
- Browser bugs. Confiant documented a campaign it called eGobbler in April 2019 that used a bug in Chrome for iOS to get past the pop-up blocker and ad-frame sandboxing. Confiant estimated more than 500 million user sessions were exposed in six days; Chrome 75 fixed the bug.
- In-app templates on the web. Mobile ad creatives are often built for in-app ad SDKs and call the SDK's bridge to open a link. When the same template runs in a mobile browser and finds no bridge, its fallback can be a plain page navigation.
In one capture from October 2026 on a Malaysian news site, an ad template built for in-app placement sent the article tab to an ad click tracker with no tap at all. The DevTools Protocol initiator stack showed the template's own navTo function called from its startup code, with no event listener in the chain. It fired on two of seven loads with an older Android browser profile and on none of eight loads with newer Android and iPhone profiles, which is the device targeting that makes these campaigns hard to reproduce on demand.
App-open hijacks
Shopping apps register their web domains so that a link to them opens the app (Android App Links, iOS Universal Links), and they also accept their own link schemes from other apps. An ad that navigates to such a link opens the app. When the link carries an affiliate ID, the app records it, and the affiliate earns commission on what the visitor buys during the program's attribution window. Shopee's affiliate terms strictly prohibit ads that redirect to Shopee without a click or touch, but the visitor pays the same price either way, so few report it.
Fake download ads
Search ads are bought directly, with no publisher in between, and impersonation works well there. Malwarebytes documented a 2023 campaign that bought a sponsored result for KeePass and sent visitors to ķeepass.info, a Punycode domain (xn--eepass-vbb.info) almost identical to the real keepass.info, which served a malicious installer carrying the FakeBat loader. In December 2022 the FBI warned that criminals were buying search ads that impersonated brands and recommended an ad-blocking extension as one defence.
Notification farming
A page that asks you to "click Allow to continue" is asking for permission to send push notifications from its domain. Once granted, that domain can send ads and scam alerts to the device at any time, including after you leave. Revoking it is a browser setting, covered in Browser Hardening Guide.
Why screening misses it
Ad networks and publishers scan creatives, and malicious ones are built to pass.
- Cloaking. The creative fingerprints the visitor: operating system and version, browser, country, whether it is in an emulator or headless browser, whether the page is visible. Scanners get the clean version.
- Delayed activation. The payload switches on hours after approval, or only between certain times.
- Supply chain depth. A creative bought through the fourth reseller in a chain answers only to that reseller's checks.
- Obfuscation. Payload code is packed, string-encoded, or loaded as base64 passed to
eval, so reviewers and filter maintainers cannot read it quickly.
What readers can do
| Defence | Effect |
|---|---|
| A content blocker (uBlock Origin on Firefox, uBlock Origin Lite on Chrome, Safari content blockers on iOS) | Blocks the ad request before the creative runs |
| A filtering DNS resolver | Blocks ad and redirect domains in every app, covered in How to set up encrypted DNS |
| Open shopping apps' links in the browser | Stops web links from launching the app: Settings, Apps, the app, Open by default |
| Deny notification prompts from sites you do not need alerts from | Removes the permission notification farms are after |
| Use a bookmark or type the address for software downloads | Avoids sponsored search results entirely |
| Keep the browser and operating system updated | Closes the bugs that sandbox escapes rely on |
If an app opens on its own while you are inside another app, the cause is an ad in that other app. Recent apps shows which one was open just before.
What publishers and advertisers can do
Publishers:
- Prune
ads.txt. Each reseller line is another party that can sell into your slots. Remove resellers you cannot name a reason for; thesellers.jsonfiles they publish show who they actually pay. - Sandbox ad frames. Render third-party creatives in cross-origin frames with a
sandboxthat omitsallow-top-navigationand usesallow-top-navigation-by-user-activationwhere a click-through must work. Never combineallow-scriptswithallow-same-originon a frame that shares the page's origin, since that frame can remove its own sandbox, and leave outallow-popups-to-escape-sandbox. Frames rendered by Google Ad Manager follow Google's settings; the sandbox is yours to set on your own wrappers and add-ons, which is where creatives written into the page or into same-origin frames come from. - Scan on the client. Creative-security services inspect ads as they render in real visitors' browsers, which is where cloaked payloads reveal themselves.
- Watch for no-tap navigations. A small script that reports top-level navigations not preceded by user input catches redirect creatives in production.
Advertisers: buy through short, transparent supply paths, check ads.txt and sellers.json against the impressions you are billed for, and treat clicks with no preceding user interaction as invalid traffic.
Related guides
Sources & further reading
- Require user gesture for framebusting in cross-origin iframes (Chrome Platform Status)
- Expanding user protections on the web (Chromium Blog)
- Cyber Criminals Impersonating Brands Using Search Engine Advertisement Services to Defraud Users (FBI Internet Crime Complaint Center)
- Clever malvertising attack uses Punycode to look like KeePass's official website (Malwarebytes)
- Massive eGobbler Malvertising Campaign Leverages Chrome Vulnerability To Target iOS Users (Confiant)
- IAB Tech Lab ads.txt specification (IAB Tech Lab)
- The iframe element: sandbox attribute (WHATWG HTML Standard)
- Shopee Affiliate Program Terms and Conditions (Shopee)