Phishing detection evasion is shifting to trusted redirect chains

At a glance

What this is: This is an analysis of phishing delivery that uses trusted redirect chains to move victims from legitimate Microsoft and Google entry points to AiTM credential theft pages.

Why it matters: IAM, SSO and security teams need to detect when trusted identity and web infrastructure is being used as the delivery path, because URL reputation alone no longer explains phishing risk.

Context

Phishing detection often assumes the suspicious part of the attack is the final destination URL. This article shows that assumption breaking down when attackers use legitimate redirect paths, ADFS configuration and ad-supported links to move a user into a phishing flow before traditional URL filters can intervene.

For identity programmes, the key issue is not just whether a phishing page looks convincing. It is whether trusted login infrastructure, federation redirects and browsing context are being abused to deliver attacker-controlled authentication prompts through apparently valid paths.

Key questions

Q: What breaks when phishing delivery uses trusted redirect chains instead of obvious malicious URLs?

A: URL reputation and destination filtering break first, because the attacker can hide behind legitimate services until the final redirect. Security teams need to evaluate the full user journey, including federation hops, ad clicks and intermediary domains, because each step can appear harmless even when the chain ends in credential theft.

Q: Why do ADFS and SSO redirects make phishing harder to detect?

A: They borrow legitimacy from identity infrastructure that users and security tools already expect to see during sign-in. When an attacker can steer a valid login flow into a malicious domain, the redirect looks like normal authentication behaviour unless defenders have baseline knowledge of approved tenants and redirect endpoints.

Q: How can security teams reduce risk from malvertising-led phishing campaigns?

A: They should extend monitoring beyond email and into search, ad traffic and browser telemetry, because many lures now begin outside the inbox. The practical control is to identify high-risk click paths that chain a sponsored result into identity prompts or federation redirects.

Q: How should IAM teams decide whether a redirect chain is suspicious or legitimate?

A: They should compare the observed redirect path against known-good identity flows, approved domains and expected federation behaviour. Any transition that moves from a trusted sign-in service into an unapproved tenant, path or domain should be treated as an authentication risk until proven otherwise.

Technical breakdown

Trusted redirects as a delivery layer for phishing

A trusted redirect chain is a sequence that begins in a legitimate service and ends at an attacker-controlled page. In this case, Microsoft login infrastructure, an ADFS setup and Google ad traffic were combined to make the phishing path look ordinary until the final handoff. That matters because many controls inspect the destination URL in isolation, while the real risk lives in the route taken to reach it. If the chain appears benign at each hop, email security, proxy scanning and URL intelligence can all be bypassed before the user reaches the AiTM page.

Practical implication: detect phishing by tracing redirect provenance, not just by classifying the final URL.

Why ADFS and SSO redirect abuse is effective

ADFS is commonly used to federate on-premises identity with cloud applications, so redirects from Microsoft login flows are expected in many environments. Attackers exploit that expectation by creating a tenant and configuring federation in a way that causes a legitimate login URL to forward into a malicious domain. The abuse is less about a broken protocol and more about trust in identity plumbing: if a redirect appears to belong to the sign-in journey, it inherits legitimacy. That makes federation-aware inspection more useful than static domain lists.

Practical implication: baseline normal federation redirects and alert on tenant or domain transitions that do not match your approved identity estate.

Malvertising and invisible redirect infrastructure

Malvertising widens the attack surface because the lure begins outside email, often in search results or sponsored links. In the article, the user clicked a Google ad and then moved through a legitimate-looking path before landing on the phishing site, while a fabricated intermediary domain helped mask the chain from automated tools. This technique matters because it defeats assumptions that phishing is primarily an inbox problem. Once delivery moves through search, ads or third-party links, controls need to understand user journey context as well as URL reputation.

Practical implication: extend phishing monitoring to search traffic, ad clicks and redirect telemetry, not only to email gateways.

Threat narrative

Attacker objective: The attacker wants to steal authenticated access by blending trusted redirects with AiTM session capture so the victim reaches the phishing page without obvious warning signs.

1. Entry began with a malvertising click from Google search that delivered the victim to a legitimate-looking Microsoft login flow.
2. Credential harvesting followed through an AiTM reverse-proxy page designed to capture the user's session while bypassing MFA.
3. Impact would be stolen credentials and session tokens that can be reused to impersonate the victim inside cloud identity services.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.

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

Trusted delivery paths have become part of the phishing attack surface: Security teams still treat the final destination URL as the primary signal, but this attack shows that the delivery chain itself can be weaponised. When Microsoft login redirects, ad-click paths and federation hops look legitimate in isolation, URL-based defenses lose their most reliable assumption. The practitioner takeaway is that phishing detection now has to inspect the journey, not just the landing page.

Federation trust is being abused as a camouflage layer: ADFS and similar sign-in flows are supposed to make authentication seamless, but that same legitimacy can be redirected into attacker infrastructure. This is not just a web filtering problem. It is a trust-boundary problem where identity infrastructure can confer credibility on a malicious destination before the user has any reason to doubt it. Practitioners should treat unexpected federation transitions as security events, not merely navigation events.

Identity security programmes need redirect intelligence, not only domain intelligence: A domain reputation feed cannot explain why a user reached a phishing page through a valid Microsoft path, and it cannot reconstruct the invisible hops that made the lure succeed. The named concept here is redirect-chain trust debt: each trusted hop accumulates legitimacy that defenders may not be monitoring. Teams should assume that attack delivery will continue moving upstream into legitimate services, not back toward obvious phishing domains.

URL-based detection is no longer sufficient when the lure starts in trusted channels: The article shows how search ads and third-party redirects can bypass email-centric controls and push the real risk into browser-time analysis. That widens the governance problem across IAM, web security and endpoint telemetry. The practical conclusion is that phishing governance now spans the full user journey, from lure acquisition to sign-in interception.

Attacker innovation is shifting from page design to delivery path engineering: The phishing page itself was ordinary, which is the point. The real differentiation came from how the page was delivered and obscured. That changes how practitioners should read modern phishing: the page may be generic, but the access path is increasingly engineered to evade automated scrutiny. Detection strategy must therefore prioritise chain reconstruction and federation context over surface-level page inspection.

What this signals

Redirect-chain trust debt: Each legitimate hop in a phishing delivery chain adds a layer of apparent credibility that defenders may not be monitoring. That means phishing governance has to shift from single-URL judgement to path-based analysis across identity, browser and proxy telemetry.

Identity teams should expect more attacks to begin in trusted contexts such as search, federation and third-party services rather than in obvious phishing domains. That shifts the detection problem from “is this site bad?” to “how did the user arrive here?” and makes redirect provenance a first-class control signal.

For practitioners

• Monitor federation redirects for unexpected domain hops Alert when Microsoft sign-in URLs redirect into non-approved domains, especially when the path includes ADFS-style patterns that do not match your legitimate tenant footprint.
• Trace phishing incidents through browsing chains Use browser and proxy telemetry to reconstruct the full redirect chain from lure source to landing page so analysts can see the invisible hops that URL filters miss.
• Block or scrutinise ad-supported lure paths Treat search ads and sponsored links as phishing delivery vectors, not just email alternatives, and monitor for clicks that lead to identity prompts through redirect services.
• Baseline approved federation behaviour Document which identity providers, tenant names and redirect endpoints are expected in your environment, then flag anything outside that baseline for review.

Key takeaways

• Trusted redirect chains let phishing campaigns inherit legitimacy from Microsoft login flows, ADFS and search-ad entry points before the final malicious handoff.
• The article shows that the weak point is delivery trust, not simply the quality of the phishing page or the presence of a suspicious final URL.
• Practitioners need redirect-aware monitoring, federation baselines and browser-level telemetry to catch attacks that URL reputation alone will miss.

Key terms

• Trusted Redirect Chain: A sequence of web redirects that begins with a legitimate-looking URL and ends at an attacker-controlled destination. In identity attacks, the chain is used to inherit trust from a known service while hiding the malicious hop deeper in the browsing flow.
• ADFSjacking: Abuse of Active Directory Federation Services to steer a user through a trusted authentication flow into attacker infrastructure. The identity system itself becomes part of the lure, which makes the attack harder to spot with simple domain blocking or page reputation checks.
• 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.
• Malvertising: The use of online ads to distribute malicious links or payloads. In this context it places cloned developer tool pages ahead of legitimate results, giving the attacker a trusted-looking entry point without needing an email campaign or direct social contact.

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.