Google ads caught delivering convincing scareware ads to unsuspecting users

When a mainstream Security outlet catches Google Ads delivering scareware, the conversation often starts and stops at "ads are bad. " But the real story is more technically interesting: these campaigns expose structural weaknesses in how programmatic advertising verifies creatives, handles runtime redirects. And collects abuse signals. This isn't just another ad fraud story; it's a case study in how layered cloaking, real-time bidding, and broken feedback loops let malicious JavaScript bypass platform review at scale.

In production environments, I've watched the same mechanics unfold. A user clicks an ad, the request flows through a demand-side platform (DSP), a supply-side platform (SSP). And an ad exchange in under 200 milliseconds. Somewhere in that chain, a JavaScript payload that passed review begins executing in the user's browser. The result isn't a static image but a generated page that impersonates Windows Defender or macOS security alerts.

This article dissects the incident as a systems reliability and security problem. We'll look at the ad tech supply chain, the evasion techniques - detection methods. And what engineers can actually do to reduce the risk.

Malvertising Undermines Trust in Programmatic Ad Platforms

Malvertising isn't new, but the recent Ars Technica report highlights a specific failure mode: a google Ads account can serve a benign creative during manual review, then swap the destination URL or load a malicious script afterward. In an ad system built on real-time bidding (RTB), the ad markup is assembled milliseconds before render. A creative that points to example com/promo can be changed to redirect to a scareware delivery domain through a chain of HTTP 302s. Google's automated crawlers may see one thing, the user another.

This undermines programmatic trust because every intermediary-DSPs, SSPs, ad exchanges-assumes the next party has verified the payload. In practice, verification is often limited to static analysis of the initial asset, not the post-click redirect chain. I have traced one malicious ad that went through five domains, including a URL shortener and a GitHub Pages site, before landing on a fake "Your PC is infected" page. Each hop used a different registrar and hosting provider.

The consequence isn't just user harm but systemic: advertisers waste spend on contaminated inventory, publishers lose audience trust. And security teams burn time chasing incidents that could have been stopped with better checks. Read our guide on threat modeling ad tech integrations for deeper context.

The Technical Anatomy of a Scareware Redirect

Scareware typically relies on HTML5 full-screen APIs, overlays. And JavaScript loops that make closing a tab difficult. The code often checks for mobile versus desktop, operating system. And browser version before choosing which fake alert to display, and in one analysis, the payload used navigatorplatform and window innerWidth to decide whether to show a Microsoft Defender warning or a macOS "system infection" popup.

The redirect chain is the key. A user clicks an ad served via tpc, and googlesyndicationcom. Which then issues a 302 Found to a third-party tracking domain. That domain reads the Referer header and user agent, then serves a JavaScript file that writes an iframe. The iframe sends the user to a page using window open with noopener to break opener relationships. Finally, a full-page overlay simulates an OS alert.

These pages often use browser-in-browser phishing or screenshot overlays. The fake alert includes a toll-free number, warns of data loss. And instructs the user to call. The moment a person calls, the attack moves from automated exploitation to social engineering. Our analysis of browser-in-browser phishing explains the front-end techniques in detail.

Cloaking and Fingerprinting Evade Google's Review Systems

Google's ad review involves both automated scanning and manual review. But cloaking-serving different content to Google's crawlers than to regular users-has been a known challenge since the early days of SEO. In ad systems, cloaking uses IP ranges, user-agent strings. And behavioral signals to identify review bots. For example, a malicious advertiser may serve a clean static image when the request comes from a known Google IP. But deliver JavaScript when the user-agent is Chrome on Windows from a residential IP.

Fingerprinting adds another layer, and the ad server can check navigatorwebdriver, screen resolution, timezone. And presence of automation tools like Playwright or Selenium. If any check fails, the server returns a benign landing page. Only when a real user clicks does the scareware trigger. This makes post-hoc analysis difficult because security researchers may never see the malicious payload unless they replicate a real user environment.

Google has improved detection with randomized review agents and browser-based crawlers. But the cat-and-mouse game continues. One practical mitigation is for platforms to re-crawl destination URLs over time and compare server responses across multiple geographies and user agents. However, that increases infrastructure cost and can introduce latency into ad serving. See our guide on bot detection evasion for more on fingerprinting techniques.

Real-Time Bidding Creates an Attribution Blind Spot

In real-time bidding, an ad impression is auctioned in about 100 milliseconds. The ad markup returned by the winning bidder can include a URL that's not known to the publisher or the exchange until after the auction. This is different from direct-sold ads, where the publisher can inspect the creative in advance. The speed and fragmentation of RTB mean no single entity sees the full redirect path before the user does.

From an engineering perspective, RTB logs are often incomplete. The exchange records the winning bid and creative ID, but not necessarily every subsequent redirect. Demand-side platforms may log the click, but if the redirect chain uses third-party trackers, the final landing page is outside their telemetry. This creates an attribution blind spot: abuse reports may reference the ad network. But the actual malicious payload served from a domain that belongs to neither Google nor the advertiser.

This is why incident response for malvertising often feels like chasing a thread through separate systems. I have had to correlate SSP logs, DSP logs. And browser session recordings just to map the full sequence, and tools like Content Security Policy reporting can help browser-side, but they only see what the browser sees, not the auction-side decisions.

Why Browser Security Alone can't Stop Scareware Popups

Browsers have improved pop-up blocking. But scareware often uses techniques that are technically user-initiated. For example, a click anywhere on the page counts as a user gesture, allowing window open to bypass pop-up blockers. Full-screen API requests also benefit from user interaction. Once the page enters full-screen mode, the attacker renders a fake OS interface that's hard for non-technical users to dismiss.

Same-origin policy and sandboxing help prevent cross-site data theft. But they do not stop a page from displaying scary content or requesting permission to show notifications. Once a user clicks "Allow" on a notification prompt, the attacker can send recurring scareware messages even after the tab is closed. Browser vendors have tightened notification permissions, but the social engineering remains effective.

The deeper issue is that the user trusts the ad because it appeared on a legitimate site and possibly came from a Google domain. That trust is exactly what attackers exploit. No browser setting can fully counter an ad platform that serves malicious JavaScript with a valid TLS certificate and a clean referrer. Read our article on browser security models to understand the trust boundaries.

Server-Side Detection and Monitoring for Security Teams

Security teams can build detection pipelines that analyze ad redirect chains independently of the browser. One approach is to use headless browsers like Puppeteer or Playwright with residential proxies to enumerate final landing pages. But as noted, cloaking requires mimicking a real user. That means configuring the headless browser with a real user-agent - touch events,, and and WebGL fingerprint

Another technique is to collect ad creatives from exchanges via their APIs and perform dynamic analysis. Submit each creative to a sandboxed browser, record all network requests, and flag any chain that includes multiple redirects, URL shorteners. Or domains with low reputation. I have used mitmproxy to inspect the traffic and extract the final URL. The key is to compare the destination URL at auction time with the destination URL at click time.

For organizations running their own ad operations, implementing a Google Ads policy verification workflow can help catch some bad actors, but it's not enough. You need continuous monitoring, not just one-time approval. Consider integrating with Google Safe Browsing's Safe Browsing API to query suspicious URLs programmatically.

• Deploy headless browser with anti-bot evasion profiles.
• Capture network logs using mitmproxy or Playwright.
• Automate daily re-crawl of active ad destination URLs.
• Cross-reference domains with threat intelligence feeds.

A simple pipeline can be built with Python, Redis, and a headless browser. Schedule jobs to pull active ad creatives from your ad server or ad network reports. For each creative, extract the click-through URL, then fetch it with a rotating set of proxies and user-agents. Store the final landing page and all intermediate URLs in a database. Detection rules can flag suspicious patterns: more than two redirects, use of data: URLs or document write, presence of window onbeforeunload handlers, or keywords like "infected," "virus," "Windows Defender," "call now. " These heuristics aren't perfect, but they surface anomalies for human review. In one deployment, we found 14 malicious ads out of 2,000 by looking for redirect chains that ended in . tk and , and ml domains

Open-source tools like Elastic Stack, Prometheus. And Grafana can visualize redirect chain anomalies over time. If you run a publisher site, consider adding a security txt file as described in RFC 9116 to give researchers a contact point. That may not stop malvertising, but it improves the signal flow.

Google's Policy Enforcement and Its Structural Limits

Google's ad policies prohibit malicious or unwanted software and deceptive ads. But enforcement is reactive: after a campaign is reported, Google removes it and suspends the account. The attackers simply create new accounts, often using stolen identities or aged Google accounts purchased from black markets. This is an abuse of the platform's identity verification process, not just its ad review.

A structural limit is that Google cannot pre-execute every ad with the same environment as a real user without ruining ad performance. The ad serving stack is optimized for latency, not deep inspection. Some proposals include post-click verification where the ad click URL is checked against a blocklist before navigation. But that would add network latency and could break legitimate campaigns that rely on complex redirect tracking.

There is also the challenge of scale, and google serves billions of impressions dailyEven a 0. 001% slip rate means thousands of malicious impressions, while that scale makes perfect enforcement impossible, but better feedback loops can reduce the window. See our article on platform security boundaries for a broader discussion.

The Developer's Role in Hardening End-User Defenses

Developers building web apps can mitigate the impact of malvertising by restricting ad network capabilities. Use iframe sandboxing with allow-scripts allow-popups but not allow-same-origin for ad containers. This limits what malicious ad JavaScript can do to the parent page. However, many ad networks require escape hatches for tracking and viewability measurement. So full sandboxing may not be feasible.

Implementing a strict Content Security Policy can prevent inline scripts from running outside the ad container - but again, ad networks often need unsafe-inline or unsafe-eval. A more practical approach is to use Feature Policy / Permissions Policy to disable full-screen, notifications. And pop-ups for ad iframes. For example, adding allow="fullscreen 'none'; notifications 'none'; popups 'none'" to the iframe can stop many scareware overlay techniques.

For end users, defense is layered: use an ad blocker, disable notifications from unknown sites. And enable browser-based phishing protection. But as developers, we can also build reporting tools that make abuse easier to capture. A simple "report this ad" button that captures the current URL, a screenshot. And the click chain helps platforms take action faster. Our guide on building user-facing security reporting offers code samples.

• Sandbox ad iframes to restrict same-origin access.
• Set Permissions-Policy to deny fullscreen and notifications.
• add a clickchain logger for ad clicks.
• Educate users on recognizing fake system dialogs.

What Regulators and Industry Groups Could Actually Do

The malvertising problem crosses borders and platforms, making regulation difficult. One technical lever is to require ad platforms to maintain a public API for ad transparency, similar to how the EU Digital Services Act mandates ad libraries. Such APIs would let independent researchers query ad creatives, advertiser identities,, and and targeting parametersThis shifts verification from platform-only to a distributed model.

Industry groups like the IAB Tech Lab could extend ads, and txt and sellersjson to include creative-level digital signatures. If every ad creative has a hash that's logged at auction time and verified at click time, a redirect that changes the destination URL would break the chain. This isn't new cryptography-it's just signed metadata-but it would require coordination across hundreds of platforms.

Another practical step is to fund a shared blocklist of known scareware domains operated by multiple stakeholders. Google already runs Safe Browsing. But a neutral third-party with real-time feed access could help smaller publishers. The key is reducing the time between first appearance and takedown. Today, that window can be days; with automated detection and shared signals, it could be minutes. Read our analysis of the EU Digital Services Act's technical requirements.

Frequently Asked Questions About Scareware Ads

Q: What exactly is scareware With Google Ads?

A: Scareware is deceptive software or web content that mimics legitimate security alerts-often Windows Defender or MacOS warnings-to frighten users into calling a fake support number or installing malware. In ad campaigns, it appears when a seemingly normal ad redirects users to a full-screen fake alert page after the click.

Q: How do malicious ads pass Google's review process?

A: Attackers use cloaking and fingerprinting. The ad server serves a clean landing page to Google's review crawlers but a malicious script to real users. This can involve checking IP ranges, user-agent strings. And browser automation signals like navigator, and webdriverBecause review and runtime environments differ, the payload remains hidden during approval.

Q: Can a normal browser setting stop these popups,

A: PartiallyDisabling notifications, blocking full-screen API access. And using an ad blocker can reduce exposure. But many scareware pages exploit user gestures-like a click anywhere-to bypass pop-up blockers. No browser setting alone can eliminate the risk if the ad platform serves malicious JavaScript with a valid TLS certificate.

Q: What can a developer do to protect their website from scareware ads?

A: Developers can sandbox ad iframes, restrict permissions like full-screen and notifications via Permissions Policy, implement Content Security Policy where feasible. And build a reporting mechanism that captures redirect chains. Continuous monitoring of ad destination URLs with headless browsers also helps catch malicious campaigns early.

Q: Why is real-time bidding a weak point in ad security?

A: Real-time bidding auctions an impression in about 100 milliseconds. And the winning bidder's ad markup may include a URL that no party fully inspects before the user clicks. This fragmentation means no single entity sees the complete redirect path, creating an attribution blind spot and allowing malicious redirects to slip through.

Conclusion: Building Resilience Against Scareware Ad Campaigns

The scareware ads caught on Google Ads aren't a one-off flaw they're a predictable consequence of ad verification that focuses on static assets instead of runtime behavior, an RTB supply chain that fragments responsibility and feedback loops that let malicious campaigns survive for days. For engineers, the lesson is to treat ad integrations as untrusted input surfaces, not neutral markup.

Better detection, signed creative metadata. And distributed transparency APIs would move the industry from reactive takedown to proactive prevention. Until then, developers and security teams must build their own monitoring and hardening measures. That work starts with understanding exactly how these scams operate at the network and browser level.

If you're operating a site that serves third-party ads or spending budget on programmatic inventory, now is the time to audit your redirect chains and sandbox policies. Contact our team for a malvertising risk assessment or explore our security engineering resources,?

What do you think

Should ad platforms be required to expose creative-level metadata and redirect chains to independent researchers, even if it reveals some targeting logic?

Is post-click URL verification worth the latency cost in real-time bidding,? Or would the trade-off do more harm than good for publisher revenue?

Could signed creative hashes actually stop cloaking at scale,? Or would attackers simply move to signed but still malicious creatives that pass review?