TL;DR: A malvertising campaign impersonating TradingView used conditional redirects and attacker-in-the-middle phishing to steal Google Workspace credentials and live sessions, while also bypassing email-based phishing controls and many static detections, according to Push Security. The pattern shows browser-based identity controls matter when search-delivered lures, session theft, and rapid infrastructure rotation converge.
At a glance
What this is: This is an analysis of a malvertising phishing chain that impersonated TradingView and used attacker-in-the-middle infrastructure to hijack Google Workspace sessions.
Why it matters: It matters because search-delivered phishing now targets identity at the browser layer, where email controls, domain reputation, and static indicators miss the session-theft path that IAM teams must govern.
By the numbers:
- 4 in 5 ClickFix attacks intercepted by Push were delivered via Google Search.
👉 Read Push Security's analysis of malvertising-driven AiTM phishing against Google Workspace
Context
Malvertising is paid advertising abused to deliver phishing or malware instead of legitimate traffic. In this case, the lure began with a Google search for TradingView, then moved through a chain of redirects into a cloned login flow that targeted Google Workspace credentials and live sessions.
The governance gap is not just phishing detection. It is browser-level identity protection for workloads and SaaS access, because session hijacking, malicious OAuth grants, and credential replay can all happen after a user has already passed the first line of defence.
For IAM and identity security teams, this is a reminder that attacker-in-the-middle phishing now lives beside SSO, MFA, and browser session controls, not outside them. The attack pattern is typical of modern identity-led intrusion rather than an edge-case tactic.
Key questions
Q: How should security teams defend against malvertising that leads to AiTM phishing?
A: Security teams should combine browser-side detection, search-lure monitoring, and session-aware identity controls. AiTM phishing often bypasses email gateways entirely, so defence has to cover the full click path, the login proxy, and post-authentication session abuse. The practical goal is to interrupt stolen session creation, not just flag suspicious links after the fact.
Q: Why do AiTM phishing attacks remain effective against MFA?
A: AiTM attacks remain effective because they proxy the real login in real time and capture the authenticated session after MFA succeeds. MFA can still verify the user, but it does not stop the attacker from inheriting the resulting session token. That is why session protection and browser-level detection matter alongside authentication policy.
Q: What do security teams get wrong about search-based phishing?
A: Teams often treat phishing as an email problem and underestimate search results, paid ads, and brand impersonation. Search-based delivery can be tightly targeted, rotated quickly, and hidden behind conditional redirects. If controls only watch the inbox, the attacker can still reach the browser and the identity provider through a different route.
Q: Who is accountable when a stolen SaaS session is reused after phishing?
A: Accountability usually spans identity, endpoint, and security operations teams because the compromise crosses authentication, browser session handling, and threat response. The identity team owns session and access policy, while security operations must detect unusual browser behaviour and revoke risky sessions quickly. The question is not who caused it, but who can terminate reuse fastest.
Technical breakdown
How malvertising becomes an initial access path
Malvertising turns search intent into a delivery channel. The attacker pays to place a malicious ad near a legitimate brand search, then routes the user through a short-lived chain that looks normal enough to avoid suspicion. In this case, the victim searched for TradingView, clicked the ad, and was sent to a redirect site before reaching a convincing clone. The key technical advantage is that the lure is not sent through email, so traditional phishing controls never see the message. The landing pages can also be geographically scoped or device-scoped, which limits exposure to scanners and analysts.
Practical implication: extend monitoring to browser-delivered lures and search-based entry, not just email.
Why conditional redirects defeat static analysis
Conditional loading means the attacker serves different content depending on how the page is reached. If a scanner opens the URL directly, it may see a harmless page or a blocked request. If the victim arrives through the expected ad parameters, the chain continues into the cloned site. This breaks simple reputation checks, URL scanning, and isolated manual review because the malicious stage is hidden behind a valid-looking navigation path. The technique also supports rapid rotation, so the infrastructure can change before blocklists catch up.
Practical implication: inspect the full click path and parameter context, not just the final landing URL.
How attacker-in-the-middle phishing steals the session
Attacker-in-the-middle, or AiTM, phishing sits between the user and the real identity provider. The user submits credentials into a proxy page that forwards the login to Google, then the attacker captures the authenticated session cookie or token after MFA completes. That means the attacker does not need to crack the password or defeat MFA directly. They inherit the session already accepted by the identity system. For Google Workspace and other SaaS environments, this shifts the problem from authentication failure to session theft and reuse.
Practical implication: pair MFA with session controls and browser-side detection that can interrupt token theft in real time.
Threat narrative
Attacker objective: The attacker aims to steal valid Google Workspace access and session state that can be resold, reused, or leveraged for follow-on intrusion.
- Entry begins with a paid search ad impersonating TradingView, which routes the victim away from the legitimate brand and into attacker-controlled infrastructure.
- Credential access occurs when the victim reaches a reverse-proxy AiTM page and submits Google credentials, allowing the attacker to capture the live authenticated session.
- Impact follows when the stolen session can be reused to access Google Workspace and related SaaS accounts without triggering a fresh login challenge.
Breaches seen in the wild
- MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Browser-delivered phishing has become an identity governance problem, not just a detection problem. When search ads, cloned sites, and AiTM proxies are used together, the compromise path happens inside the same browser where users authenticate to SaaS. That collapses the old separation between phishing prevention and access governance. Practitioners need to treat browser session protection as part of identity control rather than a separate endpoint concern.
Malvertising creates identity attack surface outside the email stack. The attacker bypassed the most mature phishing control surface by using Google Search instead of inbox delivery. That means the highest-risk path may now start in public web navigation and end in federated identity compromise. Security teams should assume the first malicious touchpoint can be search, not mail, and should calibrate control coverage accordingly.
Conditional loading is a detection-evasion pattern that breaks scanner confidence. The page that analysts or bots see is not necessarily the page the victim sees. That undermines URL reputation, isolated sandboxing, and manual triage when the malicious branch is gated behind the correct navigation context. The implication is that identity-adjacent threat validation must examine user journey state, not single URLs in isolation.
Session theft has become the real prize in Google Workspace phishing. The objective is no longer only password capture. It is authenticated access that survives MFA and can be used without repeating the original sign-in path. That makes live-session protection, browser telemetry, and rapid containment of suspicious web-authenticated sessions central to enterprise identity defence.
Identity credentials are now a reusable criminal commodity. The article's reference to broader criminal ecosystems shows why stolen access is monetised quickly after capture. In NHI and human IAM alike, access has economic value only when it can be transferred reliably. Practitioners should therefore focus on shortening the utility window of stolen sessions, not just on blocking the first click.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
- For a broader view of identity exposure patterns, see The 52 NHI breaches Report, which shows how quickly exposed access can turn into operational compromise.
What this signals
Search-delivered phishing is now an identity front door. The control gap is no longer limited to inbox security, because attackers can start in public search and end inside a federated SaaS session. Teams that own SSO, browser security, and incident response need a shared playbook for session theft, not separate policies that stop at authentication.
With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the broader identity lesson is clear: delegated access paths remain poorly understood. That same visibility gap makes it harder to tell whether a compromised browser session, a malicious grant, or a reused token is the real entry point.
This is where browser-centred identity monitoring becomes a practical programme requirement. If your team can see only login success and not the surrounding page behavior, you are blind to the attack stage where AiTM phishing actually wins.
For practitioners
- Extend phishing detection into the browser Instrument browser-side telemetry so search-delivered phishing, redirection chains, and session theft can be blocked at the point of page load, not only at email ingress.
- Inspect the full navigation chain Review URL parameters, redirect hops, and conditional loading behavior together, because the final landing page may look benign when opened out of context.
- Harden Google Workspace session controls Use session risk policies, suspicious-login review, and rapid token revocation so a captured cookie or proxy-authenticated session cannot persist after the original compromise.
- Reduce exposure to search-based lure delivery Monitor for brand impersonation in search results, high-risk ad traffic, and geographically scoped lure campaigns that target the organization through public search rather than email.
Key takeaways
- Malvertising can bypass email controls and still reach the same identity assets that classic phishing targets.
- AiTM phishing succeeds because it captures the live session after authentication, which makes MFA alone insufficient.
- Browser-level detection and session revocation are the controls that change the outcome when the attack begins in search and ends in SaaS.
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 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers compromised credentials and session abuse used in this phishing chain. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Continuous verification matters when a stolen session can persist after MFA. |
| NIST CSF 2.0 | DE.CM-1 | Detecting malicious browser behavior requires continuous monitoring of identity events. |
Instrument browser and identity telemetry so suspicious sessions can be detected and revoked quickly.
Key terms
- Attacker-in-the-middle phishing: A phishing technique where the attacker proxies the victim's login flow to a real identity provider and captures the authenticated session. The victim may complete MFA successfully, but the attacker still inherits the live session token or cookie and can reuse it for access.
- Malvertising: The use of online advertising to deliver malicious links, phishing pages, or malware instead of legitimate content. It shifts initial access away from email and into search or ad networks, which makes browser-level inspection and brand monitoring more important.
- Session hijacking: The takeover of an authenticated web or SaaS session after the user has already signed in. In identity governance terms, this is dangerous because the attacker acts as an already-approved user, bypassing the normal value of passwords and MFA at the point of entry.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by Push Security: malvertising phishing impersonating TradingView and targeting Google Workspace. Read the original.
Published by the NHIMG editorial team on 2025-12-08.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org