LinkedIn phishing via AiTM pages: what IAM teams need to know

TL;DR: A targeted LinkedIn phishing campaign chained trusted web properties, layered redirects, and CAPTCHA-based evasion to reach an attacker-in-the-middle login page aimed at an executive’s Google Workspace account, according to Push Security. The incident shows how one compromised SSO-linked account can widen blast radius across downstream applications and turn browser-level phishing into an identity governance problem.

NHIMG editorial — based on content published by Push Security: How Push blocked a LinkedIn-delivered AiTM phishing attack targeting an executive

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

Questions worth separating out

Q: How should security teams reduce the impact of LinkedIn-delivered phishing attacks?

A: Security teams should treat LinkedIn as part of the identity attack surface, not only as a communications channel.

Q: Why do AiTM phishing attacks create more risk than ordinary credential theft?

A: AiTM phishing can capture the live session as well as the password, which lets attackers bypass some downstream authentication checks.

Q: What do security teams get wrong about phishing detection in modern browser flows?

A: Many teams still expect a malicious URL to be visible early and stable enough for static filtering or sandboxing.

Practitioner guidance

• Map executive identity blast radius Inventory every downstream application, API, and SSO-linked service reachable from executive accounts, then remove non-essential access paths and stale integrations.
• Add browser-side phishing interception Use controls that evaluate the live browser session and block attacker-in-the-middle pages before credentials or session tokens are submitted.
• Hunt for multi-step redirect patterns Search telemetry for short bursts of access across sites.google.com, Microsoft Dynamics domains, and suspicious .sa.com destinations within the same user session.

What's in the full article

Push Security's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact redirect sequence used to move victims from LinkedIn to Google Sites, then Microsoft Dynamics, and finally the AiTM login page.
• The browser-detection and block-mode behaviour that stopped the phishing flow in real time.
• The indicator patterns the vendor recommends for hunting executive-level users across the campaign.
• The timeline visibility used to reconstruct the attack chain and support incident response.

👉 Read Push Security's analysis of the LinkedIn AiTM phishing campaign →

LinkedIn phishing via AiTM pages: what IAM teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →