LinkedIn phishing now chains trusted cloud services to steal sessions

At a glance

What this is: This is Push Security’s analysis of a LinkedIn-based phishing campaign that used trusted cloud redirects and an AiTM page to steal Microsoft sessions.

Why it matters: It matters because identity teams can no longer treat phishing as an email problem, and browser-level session theft affects human IAM, OAuth risk, and broader identity attack surface management.

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.

👉 Read Push Security’s analysis of LinkedIn phishing and session theft

Context

LinkedIn-based phishing succeeds when defenders still assume the inbox is the primary delivery path and the browser is a secondary concern. In practice, the lure starts in a social channel, moves through trusted Google and Microsoft services, and ends in a credential or session theft workflow that identity controls were not tuned to inspect.

For IAM and security teams, the issue is not just phishing volume. The real gap is that traditional email filtering, link scanning, and domain reputation checks do not reliably govern user sessions once the attack is living inside the browser, where MFA fatigue, AiTM interception, and trusted-service redirects can combine into one chain.

Key questions

Q: How should security teams respond to LinkedIn-based phishing that uses trusted redirects?

A: Security teams should monitor social platforms, browser sessions, and redirect behaviour together, because the attack chain begins outside email and often ends after the user has authenticated. The response should focus on suspicious multi-hop link journeys, post-login anomalies, and session protection rather than URL blocking alone.

Q: Why do legitimate Google and Microsoft redirects make phishing harder to stop?

A: Trusted redirects make phishing harder to stop because each intermediary can look legitimate to reputation-based filters, allowing the final credential page to arrive with inherited trust. That weakens controls that only inspect the destination domain and makes chain analysis more important than single-link scoring.

Q: What do security teams get wrong about MFA in AiTM phishing attacks?

A: Teams often assume MFA ends the threat once the login challenge succeeds, but AiTM attacks can capture the resulting session instead. The control gap is at the browser and token layer, so MFA must be paired with phishing-resistant methods and session-aware detection.

Q: Which controls matter most when phishing moves beyond email into the browser?

A: The controls that matter most are browser telemetry, session protection, suspicious redirect inspection, and user access monitoring across social and collaboration channels. If the enterprise only watches the inbox, it will miss the actual place where the compromise unfolds.

Technical breakdown

Social platform delivery changes the attack surface

LinkedIn direct messages create a delivery path that sits outside the controls most enterprises built for email abuse. That matters because the attack begins in a user-initiated social context, which often carries higher trust and lower filtering. The campaign described by Push used that channel to deliver a link that looked ordinary until it was passed through several trusted services. The technical shift is simple but important: the channel is not malicious by itself, yet it bypasses the enterprise visibility stack that was designed around inbox-centric phishing.

Practical implication: extend detection and governance beyond email into browser and social channels where identity lures now start.

Redirect chains and obfuscation defeat reputation-based filtering

The campaign chained Google Search, Firebase, Google Sites, and Microsoft Dynamics to obscure the final destination. Each hop made the payload look less suspicious to automated controls that rely on URL reputation or static domain rules. Cloudflare Turnstile added bot protection, while page obfuscation changed page structure and content to reduce signature matching. This is not sophistication for its own sake. It is a delivery pattern designed to exploit the fact that trust is often inferred from intermediate infrastructure, not just the final phishing page.

Practical implication: inspect redirect behaviour and browser context, not just the destination URL, when evaluating identity threats.

AiTM phishing turns MFA into a session theft problem

The final stage was an adversary-in-the-middle phishing page impersonating Microsoft. AiTM attacks proxy the victim’s login flow so the attacker can capture session material after authentication, which can sidestep MFA protections that only validate the login ceremony. Once the session is stolen, the attacker no longer needs the original prompt to succeed. The control failure is at the session layer, where token theft and reuse matter more than password quality or one-time challenge success.

Practical implication: treat browser session protection and phishing-resistant authentication as complementary controls, not interchangeable ones.

Threat narrative

Attacker objective: The attacker’s objective is to steal authenticated Microsoft session access that can be reused without the original password or MFA challenge.

1. Entry began with a LinkedIn direct message containing a benign-looking link that moved the victim into a trusted-service redirect chain.
2. Credential access occurred when the victim reached a Microsoft-branded AiTM page that captured Microsoft session material after the login flow.
3. Impact followed when stolen session access bypassed MFA assumptions and created a path to account compromise and downstream identity abuse.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

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 session trust is now part of identity governance, not just endpoint hygiene. This campaign shows that the security boundary has moved into the browser, where users authenticate, click, and complete session hand-offs. Traditional IAM programmes that stop at login success are missing the point. The practical conclusion is that identity governance must include how sessions are created, intercepted, and reused in real time.

Phishing-resistant MFA does not solve AiTM if the session layer is unmanaged. The attacker did not need to defeat password policy or basic second factors directly. They needed the authenticated browser session. That means the failure mode is not simply weak authentication, but an incomplete control model that assumes MFA ends the risk. Practitioners should treat session theft as a first-class identity threat, not a niche web attack.

Redirect trust debt is a useful named concept for this campaign. The attack works by accumulating trust across legitimate intermediaries until the final page appears harmless to reputation-based tools. Each trusted hop adds implicit credibility that defenders are unlikely to scrutinise at scale. The practitioner takeaway is to evaluate whether your controls are checking the full chain of trust or only the last link.

Human identity programmes now have to account for social delivery paths that were never built into classic email security models. LinkedIn, collaboration apps, and browser-native workflows are all part of the modern access surface. A governance model that assumes user contact begins in email is already outdated. The implication is that identity teams must align human access governance with where social engineering actually happens.

Session theft is becoming the preferred endpoint of modern phishing because it is operationally cleaner for attackers than password reuse. Once a valid session exists, access can be quieter and more durable than a stolen password alone. That alters the economics of identity attack detection. Practitioners need to shift from credential protection only to session assurance, browser telemetry, and suspicious redirect analysis.

From our research:

• 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, according to The State of Non-Human Identity Security.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• As session theft and trusted redirects blur identity boundaries, the NHI Lifecycle Management Guide helps teams reframe access review, rotation, and offboarding for modern identity attack paths.

What this signals

Redirect-chain phishing is forcing identity teams to think beyond mailbox security and toward browser-governed access. The practical shift is that user trust now gets mediated by social platforms, cloud services, and session cookies before a single alert fires. Teams that already map identity risk to the browser should pair that work with the OWASP NHI Top 10 and browser telemetry review.

Session theft will keep outpacing controls that only measure login success. In our research, 1 in 4 organisations are already investing in dedicated NHI security capabilities, and that investment pattern is a clue: access governance is moving toward runtime observation, not just provisioning checks. Practitioners should expect AiTM-style attacks to remain attractive wherever session reuse is easier than password capture.

Redirect trust debt: this campaign shows how much implicit trust enterprises still grant to legitimate services when they are used as transit, not destination. If your programme does not validate the full path to authentication, the attacker can borrow credibility from each hop and arrive at the login page looking normal. That is a governance problem, not only a detection problem.

For practitioners

• Instrument browser-session telemetry Collect and review browser-level signals for redirect chains, credential entry points, and unusual post-authentication behaviour so identity attacks can be detected where they execute.
• Treat social platforms as phishing ingress paths Add LinkedIn and other collaboration channels to phishing monitoring, awareness, and response playbooks instead of relying only on email gateway coverage.
• Harden against AiTM session theft Prioritise phishing-resistant authentication where possible, then pair it with session binding, token protection, and controls that reduce reuse of captured sessions.
• Review redirect-chain risk in identity workflows Test how your controls behave when a user reaches a login page through multiple trusted services, because reputation checks alone may not catch that path.

Key takeaways

• This campaign shows that phishing now succeeds by abusing social channels, trusted cloud services, and browser sessions in one chain.
• The evidence points to a control gap beyond email security: MFA can be bypassed at the session layer even when the login ceremony itself looks legitimate.
• Practitioners should shift toward browser telemetry, redirect-chain inspection, and session-aware authentication controls to reduce identity theft risk.

Key terms

• AiTM phishing: Adversary-in-the-middle phishing proxies a victim’s login flow so the attacker can observe or capture authentication material in transit. In identity terms, the compromise is not just a stolen password but a usable session or token that may outlive the original login ceremony.
• Browser session: A browser session is the authenticated state created after a successful sign-in, usually represented by cookies or tokens that let the user stay logged in. For defenders, it is often the real target of modern phishing because possession of the session can be enough to continue access without re-authentication.
• Redirect chain: A redirect chain is a sequence of intermediate web hops that forwards a user from one page to another. Attackers use it to hide the final destination, inherit trust from legitimate services, and make reputation-based detection less effective than analysing the full path.
• Identity attack surface: Identity attack surface is the full set of places where an attacker can attempt to capture, hijack, or abuse identity. It includes passwords, tokens, sessions, login pages, social channels, and connected applications, not just the formal IAM stack.

What's in the full analysis

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

• The exact redirect sequence across Google Search, Firebase, Google Sites, and Microsoft Dynamics.
• The browser-native detection logic used to spot the campaign in real time.
• The examples of page obfuscation and bot protection that helped the attackers evade analysis.
• The additional identity attack surface findings around unmanaged logins, weak MFA coverage, and risky OAuth integrations.

👉 The full Push Security post covers the redirect chain, browser detection, and session-stealing flow in detail.

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 responsible for identity security strategy or programme maturity, it is worth exploring.