TL;DR: A malvertising campaign used Google Search ads to steer victims to phishing pages, bypassing email-based controls and targeting account access rather than inboxes, according to Push Security. The pattern shows that browser-mediated identity attacks now require continuous detection at the point of interaction, not just perimeter filtering.
At a glance
What this is: Push Security describes a Google Search malvertising campaign that steered users to phishing infrastructure and bypassed email-based anti-phishing controls.
Why it matters: It matters because browser-delivered identity attacks can reach login flows, OAuth approvals, and account access without ever touching the inbox, so IAM and security teams need controls at the interaction layer.
Context
Malvertising is malicious advertising used to drive users toward phishing pages, fake login portals, or other hostile web content. In this case, the attack used Google Search ads to intercept users who were searching for a login path, which is a browser-mediated identity risk rather than a mail-delivered one.
The governance gap is that many identity programmes still assume phishing arrives through email and can be handled by inbox controls, message filtering, or user awareness training alone. When the entry point is search advertising and the decisive action happens in the browser, those assumptions no longer hold for IAM, SSO, MFA, or session protection.
Key questions
Q: What breaks when phishing moves from email into Google Search ads?
A: Email-only phishing controls lose their primary detection surface when the lure arrives through search advertising. The failure is not just delivery, it is trust in a browser journey that begins outside the mailbox, so teams need controls that inspect navigation, redirects, and login behaviour in real time.
Q: Why do sponsored search results increase account takeover risk?
A: They place a convincing link in front of users who are already trying to reach a service, which makes credential capture easier and user suspicion lower. That is especially risky for high-value accounts such as ad platforms, where stolen access can be monetised or used to launch further abuse.
Q: What are the signs that browser-based phishing detection is failing?
A: Weak detection usually shows up as dependence on static indicators, delayed alerts, and investigations that start only after a user has already entered credentials. If controls cannot observe rendered pages, JavaScript behavior, or user interaction, they will miss cloned login pages and toolkit-driven attacks. Another warning sign is reliance on blocklists that attackers can change quickly.
Q: Should security teams treat ad-platform accounts as a special case?
A: Yes. Ad-platform accounts can become launch points for malvertising, fraud, and wider credential theft, so they deserve stronger protection than ordinary low-reach accounts. That usually means tighter access governance, stronger authentication, and more aggressive monitoring of unusual campaign creation or login behavior.
Technical breakdown
How Google Search malvertising reaches login flows
Malvertising works by placing a malicious ad in front of a user who is already intent on reaching a service. In this case, the user searched for Google ads, clicked a sponsored result, and was redirected through one or more domains before landing on a phishing page that impersonated the target login flow. The attacker does not need to compromise the legitimate service itself; they only need to intercept the navigation path and present a convincing credential capture page before the user notices the mismatch. Practical implication: control the browser entry point, not only the inbox.
Practical implication: monitor and block risky browser destinations before credential entry or approval occurs.
Why browser-based attacks bypass email-centric identity controls
Email security controls are built to inspect messages, links, and attachments inside the mail channel. Search-delivered malvertising avoids that channel entirely, so the user arrives at the phishing page from a trusted browser path rather than a suspicious email thread. That shifts detection from message scanning to runtime web inspection, DNS reputation, and active page analysis. The key issue is not only the ad, but the fact that the authentication moment now occurs outside the control plane many programmes still assume is primary. Practical implication: treat browser traffic as an identity security surface.
Practical implication: extend identity detection to browser sessions, ad-click paths, and page-level analysis.
Why account takeover value is rising in ad-fraud and phishing campaigns
The article shows that attackers are targeting ad accounts and related browser access because those accounts can be monetised, resold, or used to launch further malicious advertising. That is a governance problem as much as a threat problem: a single compromised account can become a distribution point for wider credential theft, fraud, or partner abuse. The campaign also used transient infrastructure, including redirects and hosted phishing pages, which reduces the value of static blocklists. Practical implication: identity controls must account for account abuse as an attack platform, not just a victim state.
Practical implication: prioritise account protection for ad platforms and other high-reach browser-accessed services.
Threat narrative
Attacker objective: The attacker wanted to capture browser-entered credentials and account access that could be monetised, reused, or leveraged for further malicious advertising.
- Entry occurred when the victim searched Google for a login path and clicked a sponsored ad that led away from the legitimate service.
- Credential capture was attempted after a redirect chain delivered the user to a phishing page impersonating the Google Ads login flow.
- Impact was limited because the phishing form was blocked, but the campaign was built to harvest account access and reuse it in broader ad-fraud activity.
Breaches seen in the wild
- Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
- Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Browser-mediated identity risk is now a first-class control problem. This attack did not rely on email delivery, so inbox-centric anti-phishing assumptions were irrelevant at the point of compromise. When sponsored search results can front-run a login journey, identity programmes need to treat the browser as part of the trust boundary. The practical conclusion is that identity protection must extend to the interaction layer where users actually authenticate.
Search advertising has become a viable identity abuse channel. Attackers are using ad placement, redirects, and impersonation pages to turn ordinary search behavior into credential theft opportunities. That broadens the identity attack surface from mail, to browser, to the ad ecosystem itself. Organisations that expose high-value services through search-discoverable login paths need to assume that discoverability can be weaponised.
Transient phishing infrastructure weakens static detection models. The article describes domains that were spun up and taken down quickly, which makes blocklists and post-facto takedowns insufficient as primary controls. That pattern rewards real-time inspection of page content and behavior rather than dependence on known-bad indicators. The practitioner lesson is that runtime detection has to outrun campaign churn.
Identity abuse is being industrialised through account reuse and monetisation. The article ties malvertising to a broader ecosystem where stolen access and compromised ad accounts can be resold or repurposed for other criminal activity. That means the blast radius is not just one user or one session, but a reusable access commodity. The governance conclusion is that account access itself has become an attack asset, not a by-product.
From our research library:
- Roughly 1 in 3 phishing payloads are delivered outside email, through channels such as social media, search ads and messaging apps.
What this signals
Browser-mediated phishing is forcing identity teams to widen their detection boundary. If authentication starts from a search result rather than a mailbox, then user protection has to include sponsored links, redirect chains, and page rendering behavior. The practical shift is from message inspection to runtime interaction inspection, because the decisive risk appears after the click, not before it.
Search discoverability can now be part of the attack path. High-value applications that are easy to find through Google Search also become easier to impersonate through malvertising. IAM teams should treat login discoverability, browser trust, and authentication entry points as linked governance decisions rather than separate concerns.
For practitioners
- Harden browser-based login journeys Instrument the full path from search result to authentication page so suspicious redirects, lookalike domains, and hostile page behaviors are flagged before a user submits credentials.
- Reduce reliance on email-only phishing controls Extend phishing detection to browser traffic, sponsored results, and page-level inspection because search-delivered attacks will not appear in the mail pipeline.
Key takeaways
- This attack shows that phishing is no longer confined to email and that browser-delivered lures can reach the login step first.
- The campaign relied on sponsored search placement, redirects, and impersonation pages, which makes static blocklists and inbox controls incomplete.
- Security teams need runtime detection at the browser and login boundary because that is where the credential theft attempt actually occurs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The attack targets login flows through a fake browser entry point. |
| NHI-10 — Human Use of NHI | Users are interacting with browser-accessed accounts that attackers aim to abuse through malvertising. | |
| Recommendation — Inspect browser login journeys for fake authentication pages and block credential submission to lookalike domains. Limit human exposure to high-value NHI-backed accounts and watch for unusual login paths. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The campaign uses fast-changing infrastructure that defeats static discovery and tracking. |
| Recommendation — Maintain an up-to-date inventory of exposed login and redirect endpoints so hostile paths can be detected faster. | ||
| MITRE ATT&CK | TA0001;TA0006 — Initial Access; Credential Access | The core threat pattern is initial access through malvertising followed by credential capture. |
| Recommendation — Map malvertising detections to initial access and credential access to prioritise browser-delivered phishing controls. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on controlling who can reach and use identity-bearing browser sessions. |
| Recommendation — Apply PR.AA-05 to reduce exposure on high-value accounts and tighten authentication entry paths. | ||
Key terms
- Malvertising: The use of online ads to distribute malicious links or payloads. In this context it places cloned developer tool pages ahead of legitimate results, giving the attacker a trusted-looking entry point without needing an email campaign or direct social contact.
- Browser-native identity attack: An attack that succeeds inside the browser session rather than by compromising the operating system. The user may see a normal login page or application flow while the attacker steals credentials, relays authentication, or captures a valid session token without triggering endpoint-based detection.
- Redirect chain: A redirect chain is a sequence of intermediate links that forwards the victim from an initial lure to the final malicious page. Attackers use it to hide the destination, defeat static URL analysis, and exploit trusted services that are less likely to be blocked early.
- Sponsored-result impersonation: Sponsored-result impersonation is when attackers use paid search placement to mimic a legitimate login path or service entry point. The technique works because the ad appears in a trusted search context, which makes the malicious destination easier to click and harder to question in real time.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org