TL;DR: A long-running phishing campaign used Calendly-themed lures, AiTM tooling, browser-in-the-browser pop-ups, and targeted anti-analysis checks to steal Google Workspace and Facebook Business access, according to Push Security. The pattern shows how identity front doors, not just inbox filters, now determine whether business ad management accounts can be taken over and reused.
At a glance
What this is: This is a Push Security analysis of a long-running AiTM phishing campaign that used convincing job-lure pages and browser deception to target Google Workspace and Facebook Business accounts.
Why it matters: It matters because compromise of a primary IdP account can expose downstream apps, ads tooling, and SSO paths, so IAM teams need to treat front-door identity controls as part of ad account governance.
By the numbers:
- Push Security identified 31 unique URLs associated with the same campaign.
Context
Google Workspace is acting here as the primary enterprise identity front door, not just a mailbox. In the article, that account also serves as SSO into downstream applications, which means a successful AiTM phish can convert a single credential event into broad business access.
The security gap is not limited to email filtering because the attacker used staged lures, CAPTCHA gating, browser-in-the-browser tricks, and domain checks to delay analysis. For IAM and IGA teams, the important issue is how identity entry points, not just message delivery, are being engineered into takeover paths.
The article also shows why ad-management accounts deserve governance attention. Once identity access is reused across Google Workspace, Facebook Business, and related business tooling, the account boundary becomes a business-risk boundary rather than a simple authentication event.
Key questions
Q: What breaks when AiTM phishing reaches the primary enterprise IdP?
A: The main failure is that one successful login can become a bridge into native apps, downstream SSO services, and business systems that were never meant to be controlled by a single stolen session. In practice, the compromise outlives the original email and turns identity infrastructure into an access multiplier.
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 signals indicate a phishing page is designed to evade analysis?
A: Signals include long redirect chains, trusted-host relays, human verification gates such as CAPTCHA or Turnstile, and page elements that change at runtime. When a phishing page only reveals itself after a user passes a challenge, automated scanners are less likely to capture the true malicious content.
Q: How should teams govern accounts that manage digital ads?
A: Treat them as business-critical identities, not ordinary user accounts. Put ad-management access under tighter approval, review, and monitoring than standard collaboration access, and make sure the identity that reaches the ad platform is not the same one that unlocks broad enterprise SSO by default.
Technical breakdown
How AiTM phishing steals workspace sessions
Attacker-in-the-Middle phishing works by relaying a victim through a fake sign-in flow so the attacker can capture credentials and, often, session material in real time. In this campaign, the lure started with a job-opportunity email and only later delivered the phishing link, which reduced the chance of email scanners flagging it early. The victim then passed through a CAPTCHA and a Google-branded handoff before reaching the credential capture page. That design matters because it combines social engineering, conditional rendering, and identity-specific branding to defeat both human suspicion and automated analysis.
Practical implication: Treat staged lures and real-time relay pages as identity-layer attacks, not just phishing emails.
Why browser-in-the-browser and anti-analysis checks matter
Browser-in-the-browser pop-ups are a visual deception pattern that places a fake login window inside the page so the URL looks legitimate to the victim. The campaign also used domain checks, blocked non-targeted email domains, and triggered anti-analysis controls when security tools or proxies were detected. Those techniques reduce the chance that analysts, crawlers, or sandboxed browsers can fully render the malicious flow. The technical point is that the attacker is shaping both the victim journey and the defender’s visibility, which raises the bar for static detection and simple URL reputation checks.
Practical implication: Assume phishing infrastructure may hide until a target-specific condition is met, and test controls against that behaviour.
Why primary IdP compromise expands ad account exposure
When Google Workspace is the primary enterprise IdP, compromise of that account can open access to native collaboration apps and downstream SSO applications. The article ties that to business ad-management risk because the attacker was specifically pursuing accounts used to manage digital ads. That creates a governance problem: the same identity used for everyday productivity can also control revenue-facing platforms and advertising infrastructure. The exposure is wider when organisations allow multiple IdPs or permissive cross-IdP behaviour, because the attacker can pivot from one login path to another.
Practical implication: Map which downstream business systems inherit trust from the same identity front door and tighten that trust chain.
Threat narrative
Attacker objective: The attacker wanted to steal identity access that could be used to control business ad accounts and expand into broader enterprise access.
- Entry began with a highly targeted email lure framed as a job opportunity, then delivered a Calendly-themed phishing link after the victim engaged.
- Credential theft occurred through an AiTM phishing page that relayed the sign-in flow and captured Google Workspace access in a controlled handoff.
- Escalation happened when the stolen enterprise IdP account could be reused for native apps and downstream SSO access, extending the attacker’s reach beyond the initial login.
- Impact centered on access to business ad-management accounts and broader business IT access that could be leveraged, resold, or handed off to other criminal operators.
Breaches seen in the wild
- Mailchimp breach 2022: Attackers socially engineered Mailchimp staff, used a support tool to export 102 customer lists and exposed customer API keys for phishing.
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
Identity front doors, not inboxes, are now the control plane for ad-account risk. This campaign shows that the real attack surface is the account that brokers access into collaboration tools, SSO, and business platforms. When Google Workspace is the primary IdP, compromise of that identity is not a single-login event, but a route into the wider business stack. Practitioners should treat IdP governance and ad-account governance as linked controls, not separate queues.
Staged phishing now works by defeating analysis before it defeats users. The combination of delayed link delivery, CAPTCHA gating, browser-in-the-browser deception, and target-domain checks is designed to fragment defender visibility. That means URL reputation alone is no longer an adequate control boundary for identity compromise. Security teams need detection logic that watches the full sign-in path, not just message content.
Cross-IdP impersonation widens the trust boundary beyond the primary account. The article notes that overly permissive SSO setups can let attackers abuse more than one identity provider in the same organisation. This creates a policy problem, not just an authentication problem, because trust is being inherited across identity systems without enough governance over which business functions each IdP may reach. The implication is that cross-IdP trust should be reviewed wherever productivity identity also touches revenue systems.
Ad-management credentials have become reusable criminal infrastructure. The campaign’s long-running nature and repeated page recycling indicate that stolen access is treated as a commodity, not a one-off breach outcome. That changes the governance question from “Did the account get compromised?” to “How quickly does compromised advertising access become operationally useful to an attacker?” Practitioners should respond by narrowing the business function each identity can reach and by separating ad operations from general enterprise login paths.
AI-assisted social engineering is lowering the cost of high-conviction impersonation. The article does not prove an AI operator, but it does show victim-specific, polished, multi-stage lures that read like tailored human outreach. That matters because governance models built around obvious phishing cues will miss higher-quality impersonation. The practical conclusion is that identity verification and step-up controls must assume convincing pretext, not amateurish spam.
From our research library:
- The IBM/Ponemon 2025 Cost of a Data Breach Report found that phishing-initiated breaches cost an average of $4.8M each.
What this signals
Identity governance for ad platforms now depends on who can inherit trust from the primary IdP. If Google Workspace or another enterprise login can reach revenue systems without a separate control layer, then the phishing problem has already become a business-access problem. Teams should review where ad-management rights are inherited through SSO rather than assigned explicitly.
Target-specific phishing is now engineered to make defenders arrive late. The campaign used multi-stage lures and anti-analysis checks to ensure malicious content only appeared after a user looked legitimate to the attacker. That means detection has to move earlier in the journey, before the sign-in flow completes and before trust is granted.
Cross-IdP trust assumptions deserve a specific review in organisations that blend cloud collaboration and advertising operations. Where more than one identity provider can reach the same downstream application, a compromised login may have more reach than teams realise. The governance question is not whether the app is accessible, but which identity path should be allowed to reach it.
For practitioners
- Map IdP reach into ad platforms Inventory which Google Workspace or other primary identity accounts can reach ad-management systems, business apps, and SSO-connected tools. Remove unnecessary inheritance so a single enterprise login does not become a broad business-control path.
- Harden sign-in journeys against AiTM relay Require phishing-resistant authentication where possible and look for anomalous handoff patterns such as CAPTCHA gating, repeated login prompts, and browser-in-the-browser behaviour during authentication.
- Separate revenue-adjacent access from general productivity access Treat ad-management accounts as a distinct governance class with tighter approval, recertification, and monitoring than ordinary collaboration accounts.
- Review cross-IdP trust assumptions Identify cases where a user’s Google and Microsoft or other identity paths can both reach the same downstream business system, then remove permissive overlap where it is not required.
- Expand phishing detection beyond email-only controls Tune controls for multi-stage delivery, delayed-link lures, and fake sign-in pages that only render malicious content after a target-specific check passes.
Key takeaways
- A single compromised enterprise identity can become a route into collaboration tools, downstream SSO applications, and ad-management systems.
- The campaign combined staged lures, browser deception, and anti-analysis checks, which makes identity-path monitoring more important than email-only filtering.
- Teams should narrow identity inheritance into revenue-facing systems and treat ad-account governance as part of the enterprise identity boundary.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | AiTM phishing targets the authentication flow itself, not just the inbox. |
| NHI-10 — Human Use of NHI | Human-operated business accounts are being used as gateways into non-human business access. | |
| NHI-05 — Overprivileged NHI | Enterprise IdP reach into downstream apps shows how excess access widens blast radius after compromise. | |
| Recommendation — Strengthen authentication against relay attacks and require phishing-resistant sign-in for high-risk identity paths. Separate human account governance from the non-human business systems those identities can reach. Reduce inherited access paths so one compromised identity cannot control multiple business systems. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on whether the right identity path is authorised to reach ad-management systems. |
| Recommendation — Review and limit entitlements that let a primary IdP reach revenue-facing applications. | ||
| MITRE ATT&CK | TA0001;TA0006 — Initial Access; Credential Access | The campaign used phishing delivery to obtain credentials and session access. |
| Recommendation — Map the campaign to Initial Access and Credential Access to tune detections for staged phishing and AiTM relay. | ||
Key terms
- AiTM Phishing: Adversary-in-the-middle phishing inserts attacker infrastructure between the victim and the real login service. The attacker relays the login in real time, captures the issued token, and bypasses MFA by stealing the authenticated session rather than guessing the password.
- Browser-in-the-Browser: A phishing technique that renders a fake authentication window inside a webpage so it looks like a normal browser pop-up. The goal is to trick users into entering credentials or completing sign-in in a context that appears trustworthy while the attacker controls the underlying content.
- Cross-IdP Impersonation: A condition where one identity, often tied to an email address, is accepted across different identity providers or login methods without fresh verification. The risk is that a compromised account in one domain can be reused to reach unrelated applications in another, expanding the blast radius of a single takeover.
- Ad-Management Identity: Ad-management identity is the account or role used to administer business advertising platforms and related controls. Because these accounts influence revenue, campaigns, and billing, they should be governed as high-value business identities with tighter access boundaries than ordinary user accounts.
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.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org