Malvertising AiTM phishing is bypassing Google Workspace defences

At a glance

What this is: This is a Push Security analysis of a malvertising AiTM phishing campaign that used a TradingView impersonation to capture Google Workspace credentials and live sessions.

Why it matters: It matters because identity teams need controls that can see browser-based session theft and search-delivered lures, not just email and static indicators.

By the numbers:

• 4 in 5 ClickFix attacks intercepted by Push were delivered via Google Search.

Context

Malvertising is paid-ad delivery used to push malicious traffic through search results rather than email. In this case, the lure impersonated TradingView and used a browser-to-browser phishing chain to reach Google sign-in, which makes the incident relevant to Google Workspace identity governance rather than just web fraud.

The important governance gap is that many organisations still treat phishing as an email problem. When the lure arrives through search, the clone page is conditional, and the credential theft happens inside the browser session, controls that only inspect mail, domains, or static URLs can miss the attack entirely.

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 attacker-in-the-middle attacks increase Google Workspace account risk?

A: Because they can capture a live authenticated session after the victim has completed sign-in. That means the attacker may not need to reuse the password or MFA code, which turns session theft into the real compromise boundary for Google Workspace.

Q: What are the signs that a malvertising phishing chain is hiding from analysis?

A: A common sign is a page that looks harmless when loaded directly but changes behaviour only after the correct click path or parameters are supplied. Another signal is highly scoped targeting by geography, device, or domain, which makes broad scanning and sandboxing miss the malicious branch.

Q: What should teams do when a stolen browser session is suspected?

A: Contain the session before the attacker can reuse it. Revoke or invalidate the token, review recent consent grants and browser activity, check for extension abuse, and examine whether the account was used to access administrative or data-heavy applications. The goal is to stop replay and identify what the session already touched.

Technical breakdown

Conditional redirects in malvertising chains

The campaign used an initial ad-click destination that functioned as a benign redirector, then forwarded the victim only when the expected parameters were present. That pattern frustrates scanners and analysts because the first URL may never expose the malicious payload in isolation. The real phishing page only appears after the chain is walked in the right order, which makes link reputation and isolated crawling weak signals on their own. For identity teams, the control question is no longer simply whether a URL is malicious, but whether the full browser journey can be trusted.

Practical implication: Inspect the full redirect path, not just the landing domain, when assessing search-delivered phishing risk.

Attacker-in-the-middle theft of Google Workspace sessions

Attacker-in-the-middle phishing inserts a reverse proxy between the victim and the legitimate login flow so the attacker can relay credentials in real time. That means the attacker does not need to break authentication outright. Instead, they capture the live session token after sign-in, which can bypass some MFA assumptions because the session is already authenticated. For Google Workspace environments, the exposure is not limited to the password or one-time code. The stolen session can become the real prize if browser-based controls do not detect the proxying layer.

Practical implication: Treat session theft as the primary failure mode and monitor for replayable browser sessions after authentication.

Detection evasion through conditional loading and scoped targeting

The article shows two common evasion techniques: conditional loading that hides malicious content from direct analysis, and targeting that narrows who can reach the lure based on geography, domain, or device. These methods reduce the usefulness of sandboxing, web scraping, and broad indicator lists because the malicious behaviour only appears for the intended victim profile. This is why short-lived indicators matter less than behavioural controls. Browser-side visibility, identity telemetry, and response at the moment of page load are the stronger defenses in this pattern.

Practical implication: Move detection from static indicators to browser-time behaviour and identity-session telemetry.

Threat narrative

Attacker objective: The attacker wanted Google Workspace account access and a live browser session that could be reused for follow-on abuse or resale.

1. Entry occurred through a malicious Google search ad that impersonated TradingView and led the user into the phishing chain.
2. Credential access followed when the user reached the reverse-proxy Google sign-in page and entered credentials into the attacker-in-the-middle flow.
3. Impact came from theft of the authenticated Google Workspace session, giving the attacker account access that could be reused without repeating the login flow.

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.

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 is now the real phishing boundary: This campaign did not try to defeat Google Workspace at the mail layer, it tried to win inside the browser after search discovery. That shifts the governance problem from message inspection to session assurance, because the decisive control point is where the login interaction is completed. For identity programmes, the relevant question is whether browser-time telemetry is part of the access model, not whether email security is tuned harder.

Email-first phishing models are structurally incomplete for Google Workspace: Malvertising bypasses the assumption that phishing begins in the inbox. Search-delivered lures, conditional redirects, and cloned login pages create an identity attack surface that lives outside traditional email controls. The implication is not that email security has no value, but that it is no longer the primary control plane for modern credential theft.

Ephemeral infrastructure has become an access commodity: Short-lived domains, scoped targeting, and conditional loading turn infrastructure churn into an operational defense for attackers. That means static blocklists and one-time takedowns arrive after the useful window has passed. Practitioners should read this as a shift toward infrastructure that is deliberately hard to observe, which raises the value of browser-side detection over domain-only intelligence.

TradingView impersonation is a reminder that brand trust is a delivery vector: The lure worked because the user recognised a legitimate service and followed a believable path to Google sign-in. That is a governance problem as much as a threat problem, because user trust in common SaaS brands becomes the attacker’s initial access path. Identity programmes need to assume that familiar brands can be weaponised as transport, not just as targets.

Browser-session theft should be treated as account compromise, not just phishing success: Once the live session is captured, the attacker may not need the password again. That changes incident handling, because the harmful state is the authenticated browser context, not only the credential value. Security teams should therefore think in terms of session governance, not merely password hygiene, when evaluating this attack class.

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

Search-delivered phishing is now part of the identity perimeter: Teams that still anchor phishing defence in email miss a growing class of lures that begin in search and end in a browser session. That means identity telemetry needs to extend to page-load behaviour, redirect chains, and session continuity, not just inbox filtering.

Conditional-loading pages create an observation gap: A page that looks benign to one observer and malicious to another breaks the assumptions behind static scanning. Security teams should expect attackers to optimise for analyst friction, which raises the value of live browser inspection and behavioural detection over indicators that expire quickly.

Browser session control is becoming as important as authentication strength: Once a live session is stolen, stronger passwords do not change the compromised state. Identity programmes should therefore treat session revocation, replay detection, and post-authentication monitoring as core controls for Google Workspace and other browser-first services.

For practitioners

• Harden browser-side phishing detection Use controls that inspect the full page load and login flow in the browser, not only mail gateways and static URL feeds.
• Review Google Workspace session-risk signals Correlate sign-in events, unusual browser sessions, and token reuse so live session theft is visible as a distinct compromise pattern.
• Block search-delivered lure paths Treat Google Search and other ad-delivered entry points as active phishing channels and apply monitoring to user navigation into login pages.
• Hunt for conditional redirect behaviour Look for landing pages that behave benignly in isolation but change content or forwarding logic when accessed through a specific ad click path.
• Shorten the useful life of compromised sessions Reduce exposure by tightening session governance, especially where browser sessions can persist after primary authentication succeeds.

Key takeaways

• This campaign shows that phishing controls built around email are no longer enough when attackers use search ads, redirect chains, and browser-time credential theft.
• The key failure mode is session compromise after login, which can leave Google Workspace access exposed even when the password challenge itself was completed.
• Browser-visible controls, session monitoring, and fast invalidation of stolen sessions are the practical countermeasures that matter most for this attack pattern.

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.
• Adversary-in-the-middle phishing: A phishing method that places an attacker between the user and the real identity provider so the attacker can intercept or relay the authenticated session. It often preserves the user experience, which is why it can evade awareness and some detection paths while still producing usable session tokens.
• Browser Session Theft: Browser session theft is the capture of authenticated web-session state after a user has already signed in. It is dangerous because the attacker may not need to know the password or defeat MFA again, only reuse the live session to act as the victim.
• Conditional Redirect: A conditional redirect sends different content or next steps depending on the visitor’s path, parameters, or profile. Attackers use it to hide malicious behaviour from scanners and analysts, which means the redirect logic itself becomes part of the evasive infrastructure.

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.