Ahrefs impersonation attacks expose ad-manager identity risk

At a glance

What this is: This is a security analysis of malvertising that impersonates Ahrefs to steal Google account sessions through browser-based AITM phishing.

Why it matters: It matters because ad manager accounts often sit on top of broader SaaS access, so compromise can affect both NHI-adjacent workflows and human identity estates.

By the numbers:

• 3 in 5 apps also allow you to access an account using a new login method without doing any further verification checks.
• 4 in 5 ClickFix attacks intercepted by Push were delivered via Google Search.
• Ad fraud cost advertisers tens of billions, potentially nearing $100 billion or more, with projections reaching $172 billion by 2028.

👉 Read Push Security's analysis of Ahrefs impersonation and Google Ads hijacking

Context

Malvertising is paid search abuse that uses sponsored results to push users into fake login flows, and the primary keyword here is ad manager account hijacking. In this case, the attack chain starts with a search query, but the security failure is identity-related: a browser-trusted path is used to capture Google credentials and sessions.

The governance gap is that many organisations still treat ad platform access as a marketing concern rather than a high-value identity surface. When a Google account is also an access path into Google Workspace or connected SaaS apps, a single compromised browser session can become broad enterprise access without touching email security controls.

Key questions

Q: What breaks when ad manager accounts are treated as low-risk marketing access?

A: What breaks is the assumption that compromise stays inside the ad platform. Ad manager identities can also unlock Workspace, billing, and connected SaaS access, so a single stolen session can create enterprise-wide exposure. Treat these accounts as privileged identities and map every downstream system they can reach before the next phishing campaign lands.

Q: Why do search-delivered phishing attacks bypass so many controls?

A: They bypass controls because the user is redirected in the browser, not through email. That means mail filters, link rewriting, and many secure gateway rules never see the attack path. Effective defence needs runtime inspection in the browser, plus account-level controls that detect suspicious session creation and suspicious login context.

Q: How do security teams know if account linking is creating hidden identity risk?

A: Look for login flows where one email address can recover or re-open access across multiple identity providers without a fresh assurance step. That behaviour creates cross-IdP impersonation risk because a compromise in one system can be reused elsewhere. The signal is account reuse with weak re-verification, especially for SaaS applications tied to the same email identity.

Q: Should organisations rely on MFA alone against AITM phishing?

A: No. MFA can be completed inside an AITM phishing page, which means the attacker may still capture a valid session after the user authenticates. Organisations need controls that stop session theft at the browser, validate abnormal login context, and limit what a newly minted session can access.

Technical breakdown

Malvertising as the entry vector for account takeover

The campaign uses sponsored search results to route victims away from the legitimate brand and onto attacker-controlled pages. Because the lure appears in Google Search, it bypasses the normal email-based warning layer and exploits trust in the browser’s first-click experience. The fake landing page is often hosted on legitimate infrastructure, which reduces obvious signals at the network edge. This is not simple redirect abuse. It is identity deception delivered through a familiar discovery path, with the browser as the primary execution environment.

Practical implication: monitor brand impersonation in search and block suspicious web sessions before credentials reach the fake login page.

AITM phishing and session theft in the browser

An attacker-in-the-middle phishing page proxies the victim’s authentication flow so credentials and MFA completion look legitimate to the user while the attacker captures the resulting session artefact. That matters because the goal is not only password theft. The attacker wants a live session token or equivalent app session that survives initial login checks. In browser-based identity attacks, the session becomes the prize, and the phishing page is merely the mechanism for brokering that session.

Practical implication: enforce browser-side controls that inspect the page at runtime, not just email or gateway detections.

Why ad manager accounts create broader identity blast radius

Ad manager access is often tied to enterprise Google identities, shared billing workflows, and connected SaaS applications. That means compromise can extend beyond ad spend abuse into Workspace access and SSO-enabled downstream apps, especially where email remains the account identifier. The technical risk is not just privilege within one platform. It is identity reuse across platforms, where one successful session theft can unlock multiple business systems through account linking and federated access paths.

Practical implication: classify ad manager accounts as high-risk identities and map every connected application before a campaign lands.

Threat narrative

Attacker objective: The attacker aims to steal a usable Google session and convert it into broader enterprise access, ad fraud, or account abuse.

1. Entry occurs when a user searching for Ahrefs clicks a sponsored result that leads to a fake brand page under attacker control.
2. Credential access follows when the victim is pushed into a cloned Google sign-in flow and completes the login plus MFA challenge inside the phishing page.
3. Impact occurs when the attacker steals the app session and takes over the Google account, creating downstream access to linked SaaS and Workspace services.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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-mediated identity attacks have become an enterprise access problem, not a phishing problem. The campaign works because the browser is now the execution point where identity is resolved, sessions are minted, and downstream access is inherited. Email controls do not see the path, and network controls often see only legitimate hosting or search traffic. Practitioners should treat browser session control as part of identity governance, not a separate security layer.

Ad manager accounts create identity blast radius that most governance models underestimate. A marketing-facing account can also be a Google Workspace identity, a billing identity, and a federated access path into other SaaS applications. That means the compromise boundary is not the ad platform alone, but the account’s full login graph. Practitioners should map each ad platform identity to every downstream application it can unlock.

Session theft is the failure mode, not password theft. AITM phishing is designed to capture the authenticated session after the user passes through MFA, which means conventional credential hygiene is insufficient on its own. The control gap is the absence of browser-time interception and contextual session validation. Practitioners should reassess whether their identity programme is still built around stolen passwords when the real prize is a live session.

Cross-IdP identity reuse turns one compromised browser flow into multiple identity exposures. When email is the shared identifier across identity providers, attackers can exploit account linking and weak re-verification behaviour to pivot across systems. This is a governance gap in account lifecycle and identity assurance, not just a phishing trend. Practitioners should treat identity matching rules as an attack surface.

Malvertising creates a named concept we can call search-delivered identity deception. The lure is not merely malicious advertising. It is a delivery model that uses sponsored search to place identity fraud in the user’s path before standard controls engage. That framing helps teams build policy around where identity compromise begins, which is in the browser session and not at the inbox.

From our research:

• 3 in 5 apps also allow you to access an account using a new login method without doing any further verification checks, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how fast access paths can outgrow oversight.
• For a broader lifecycle view, NHI Lifecycle Management Guide helps teams map where identity reuse and offboarding gaps leave residual access behind.

What this signals

Search-delivered identity deception is becoming a practical governance problem because the attack surface now sits inside the browser session, not just in mail or endpoint tooling. As more SaaS applications accept reused email identities and alternate login methods, identity assurance weakens unless the programme explicitly checks for session origin, account-linking behaviour, and post-authentication access scope.

The policy question is no longer whether users can spot a fake page. It is whether the organisation can observe and interrupt a malicious login sequence before session handoff, especially when legitimate hosting and branded search results make the lure look ordinary. Teams that still anchor phishing defence to inbox controls are leaving the most important control point ungoverned.

For practitioners, the next phase is tighter linkage between browser defence, identity telemetry, and lifecycle control. If an account can be recovered, linked, or re-used across systems without fresh verification, the programme has already created the conditions for cross-app takeover.

For practitioners

• Classify ad manager accounts as privileged identities Inventory Google Ads, Ad Manager, and MCC accounts as high-risk identities, then map every connected Workspace and SSO-enabled application those accounts can reach.
• Deploy browser-time phishing interception Use controls that inspect the rendered page and user action in real time, because search-delivered phishing often bypasses email filters and gateway inspection.
• Reduce account-linking exposure Review whether email-based account matching or new-login-method recovery paths allow a compromised Google identity to reach other applications without fresh verification.
• Track sponsor-search impersonation patterns Monitor for brand impersonation in search results, especially campaigns that reuse legitimate hosting services such as Squarespace or similar infrastructure to hide fake login pages.

Key takeaways

• Ad manager account abuse is an identity governance issue because those accounts often unlock far more than advertising workflows.
• The evidence points to browser-based session theft, which means password hygiene alone cannot close the exposure.
• Teams should treat search-delivered phishing as a session-control problem and map every downstream app reachable from ad platform identities.

Key terms

• Attacker-in-the-middle phishing: A phishing technique where the attacker sits between the user and the real service, relaying the login flow in real time. The aim is not only to steal credentials but to capture a live authenticated session that can be reused after MFA completes.
• Session hijacking: Unauthorized takeover of an authenticated session token or equivalent browser session artefact. In modern identity attacks, this is often more valuable than the password because it bypasses the need to re-authenticate and can unlock connected applications.
• Malvertising: The abuse of paid advertising channels to deliver malicious content or phishing lures. For identity teams, the key issue is that the attack begins in a trusted discovery path and can reach the user before email or gateway controls are involved.
• Cross-IdP impersonation: A situation where one identity provider account can be reused or matched against another application or identity system without a fresh assurance step. This creates a pivot path for attackers who compromise a shared email identity and then move into other services.

Deepen your knowledge

Search-delivered account takeover, AITM phishing, and browser-time identity controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment uses shared SaaS identities or ad platform access, the governance lessons apply directly.

This post draws on content published by Push Security: Ahrefs impersonation attacks and Google Ads hijacking analysis. Read the original.