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.
NHIMG editorial — based on content published by Push Security: malvertising phishing impersonating TradingView and targeting Google Workspace
By the numbers:
- 4 in 5 ClickFix attacks intercepted by Push were delivered via Google Search.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Push Security's full analysis covers the operational detail this post intentionally leaves for the source:
- A narrated clickthrough of the full attack chain, including the redirect path and cloned login sequence.
- Examples of the conditional loading and geofencing tricks used to evade bots and manual triage.
- Push's browser-based detection approach for AiTM phishing, ClickFix, malicious OAuth grants, and session hijacking.
- Practical examples of how the platform surfaces ghost logins, SSO coverage gaps, MFA gaps, and vulnerable passwords.
👉 Read Push Security's analysis of malvertising-driven AiTM phishing against Google Workspace →
Malvertising AiTM phishing for Google Workspace: what teams need to know?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Malvertising AiTM phishing is bypassing Google Workspace defences