Correction: Google Ads–served AiTM phishing is bypassing 2FA to hijack ManageWP and Google Ads manager accounts
A sophisticated, operator-run phishing campaign is using Google Ads to position Adversary-in-the-Middle (AiTM) pages in front of ManageWP and Google Ads users — a step beyond “simple” phishing that routinely defeats 2FA and abuses ad platform trust.
What the attackers actually achieve and why a basic reading is wrong
Rather than generic mass phishing, operators are buying search ads for terms like “ManageWP” and sending clicks through ad-approved display URLs to counterfeit login flows that capture credentials and real-time 2FA codes. Guardio Labs’ investigation shows this is enabling full account takeover, not just credential harvesting: once attackers capture an active session or the 2FA OTP, they log in and control ManageWP or Google Ads Manager (MCC) accounts.
This matters because ManageWP — owned by GoDaddy and used to manage more than one million WordPress sites — is a high-value target. Compromising an MCC account lets an attacker run ads across many linked accounts and drain advertising budgets; misreading the campaign as “easy to block with standard 2FA” misses the AiTM mechanism that intercepts the second factor in real time.
The campaign’s infrastructure and operator signals
Guardio Labs gained access to parts of the attackers’ command-and-control and found a private, operator-driven phishing framework (not a commodity kit). The framework contains Russian-language disclaimers forbidding use against Russian systems and backend commands in Brazilian Portuguese, indicating multinational operator involvement. Operators use Cloudflare to hide infrastructure, embed anti-research measures (cloaking and disabled right-click), and exfiltrate stolen credentials and OTPs to attacker-controlled Telegram channels; Guardio tied at least 200 unique victim events to this cluster.
Technical tricks matter: attackers register spoofed domains that mimic orion.managewp.com with similar characters — examples seen include menagewp[.]com and orion.manaqewp[.]com — and host fake Google Ads-themed login pages on Google Sites. Google Ads’ policy allowing different display and landing URLs lets a trustworthy-looking ad text point to a malicious landing, and the campaign frequently routes victims through an initial Google Sites page before redirecting to a legitimate page to reduce user suspicion.
Concrete checks you can run now
If you or a client sees ManageWP or Google Ads login prompts reached via an ad, prioritize these verifications: confirm the exact landing domain (character-by-character), inspect the TLS certificate issuer and SANs, check the ad’s declared final URL versus its display URL, and review active sessions in Admin consoles. On Linux, quick commands include whois, curl -I to fetch headers, and openssl s_client -connect to inspect certificates; for immediate containment, revoke active sessions and rotate API keys tied to the account.
| Signal | Tool / command | Immediate action |
|---|---|---|
| Display URL differs from final click URL | Inspect ad JSON in Ads UI or click then check browser address bar | Report the ad to Google; block the landing domain; revoke sessions |
| Lookalike domain (e.g., menagewp[.]com) | whois; openssl s_client -connect <domain>:443 | Add to hosts blocklist; notify clients; check past logins for similar referrers |
| Unexpected OTP prompt or repeated OTP requests | Check sign-in logs in ManageWP/Google accounts | Rotate credentials and 2FA methods; require hardware keys where possible |
Quick Q&A
Is standard SMS or app-based 2FA still useful? Yes, but AiTM pages can capture OTPs delivered via SMS or authenticator apps in real time; moving to phishing-resistant methods (FIDO2 hardware keys) materially raises the attacker’s cost.
Why does Google Ads enable this? Google’s ad system allows different display and landing URLs to support legitimate advertisers; that policy, plus scale, creates a practical enforcement gap that attackers exploit. Google removed billions of ads and suspended millions of accounts in 2023, but the loophole for display vs landing URL misuse persists.
What immediate checks should agencies managing MCCs run? Audit linked accounts for unknown users or sudden billing changes, review recent ad creation timestamps, and rotate account-level authentication and API credentials if you detect suspicious activity.
Operational choices for defenders and the next enforcement checkpoint
For agencies and advertisers, the realistic options are tradeoffs: enforce hardware-based MFA for staff and clients (FIDO2), lock down MCC admin privileges, and implement detection rules for ad-created redirects or newly added display/landing URL mismatches. These steps impose operational friction but create higher thresholds that the private, operator-driven campaigns must overcome to succeed.
The next verification point is whether Google’s evolving ad enforcement — including tighter checks on URL mismatches and more aggressive automated detection of cloaking — can materially close this avenue. Until platform controls tighten, expect attackers to adapt (as Guardio’s 200+ victim count and multilingual framework already show), so pragmatic containment and stronger authentication policies are the effective levers available to defenders today.
