Phishing detection evasion is shifting to trusted redirect chains

At a glance

What this is: This is an analysis of a phishing kit that used trusted redirect paths, ADFS, and malvertising to reach a Microsoft-impersonating login page.

Why it matters: It matters because IAM, NHI, and identity security teams need to defend the delivery chain and trust boundary, not only the final credential-harvesting page.

👉 Read Push Security's analysis of trusted redirect phishing and ADFS abuse

Context

Phishing detection is failing less at the point of page rendering and more at the point of delivery trust. When attackers can route a victim from a legitimate-looking Microsoft login path to a reverse-proxy phishing page, the security model that assumes URL reputation and email-layer filtering will catch the threat is already weakened.

For identity programmes, the issue is not just credential theft. It is the way trusted web infrastructure, single sign-on redirect logic, and malvertising can be combined to move a user from an allowed link to a hostile authentication flow without triggering the controls many organisations still depend on.

Key questions

Q: How should security teams detect phishing that uses trusted redirect chains?

A: Security teams should detect the full browsing path, not only the final domain. The best signal is an unexpected redirect from a trusted sign-in URL into a different domain, especially when it appears in browser, proxy, or identity logs as part of a multi-hop sequence. That approach catches delivery abuse before credential capture completes.

Q: Why do ADFS-based phishing attacks evade normal URL filtering?

A: They evade normal filtering because the initial link can look legitimate while the malicious hop happens later in the authentication flow. URL tools often evaluate the first destination or a simplified link reputation, but ADFS abuse turns the redirect itself into the attack path. That means the control failure is in flow visibility, not only domain blocking.

Q: What do security teams get wrong about malvertising-led phishing?

A: Teams often treat malvertising as a web-advertising issue rather than an identity threat. In reality, it can be the first step in a credential theft chain that bypasses email controls entirely and lands users on a sign-in page built to intercept authentication. Defence needs browser-side detection and ad-path awareness.

Q: Who is accountable for phishing defences when trusted redirects are abused?

A: Accountability sits across email security, browser security, identity teams, and federation owners. If trusted redirects are being abused, ownership cannot stay with one control layer, because the attack crosses delivery, navigation, and authentication boundaries. The practical response is shared logging, shared baselines, and joint escalation paths.

Technical breakdown

How trusted redirect chains bypass URL-based detection

The core technique is to place a malicious destination behind a legitimate redirect path so scanners see the trusted front door first. In this case, a Microsoft login URL was used to carry the victim into a phishing chain, with the malicious domain hidden deeper in the navigation flow. That structure reduces the effectiveness of URL intelligence, gateway inspection, and static blocklists because the initial indicator looks normal. The phishing page itself can stay generic. The innovation sits in the delivery mechanics, where the attacker controls where the browser lands next.

Practical implication: monitor redirect behaviour and not just final destination domains.

ADFS redirect abuse as a delivery primitive

Active Directory Federation Services can be used as a legitimate identity bridge between Microsoft services and a tenant-specific authentication flow. Attackers can abuse that trust relationship by configuring a tenant and redirect target that causes Microsoft to send the browser onward to an attacker-controlled domain. That makes the malicious hop look like part of standard sign-in processing rather than an external detour. The result is a phishing chain that inherits some of the trust of the identity system it imitates, which complicates both automated analysis and user suspicion.

Practical implication: inventory ADFS use and alert on unexpected federation redirects.

Malvertising plus conditional loading creates layered evasion

The lure in this case did not rely on email alone. A search ad delivered the user to the first link, adding a channel that often bypasses email security controls entirely. The kit then used conditional loading to decide whether to continue the attack flow, which frustrates crawlers and sandboxing tools that do not meet the page’s expected conditions. This layering matters because each step is weak on its own, but together they produce a chain that is harder to classify, harder to reproduce, and harder to block using one control plane.

Practical implication: combine browser telemetry, ad-blocking policy, and redirect-aware detections.

Threat narrative

Attacker objective: The attacker aimed to harvest credentials and session access while preserving the appearance of a trusted Microsoft sign-in flow.

1. Entry began when the victim followed a search ad rather than a direct phishing email, which gave the attacker a delivery path that bypassed most email-layer controls.
2. Escalation occurred when a legitimate Microsoft redirect and custom ADFS setup carried the browser toward an attacker-controlled domain that hosted the reverse-proxy phishing page.
3. Impact was the capture of credentials and session material through an AiTM page designed to intercept the victim during sign-in and bypass MFA protections.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trusted delivery is now part of identity attack surface. This attack did not need a novel phishing page to succeed. It exploited the assumption that trusted sign-in routes, browser search results, and domain reputation are reliable indicators of safety. That assumption is weaker than many IAM programmes admit, because the user can be guided from a legitimate entry point into a hostile authentication flow before traditional controls engage. Practitioners should treat delivery trust as an identity control problem, not a messaging problem.

Open-redirect thinking now applies to identity infrastructure as well as web apps. The most useful mental model here is not a phishing site with a fake login page. It is a trusted redirect chain that functions like an identity-layer open redirect. That framing matters because it shifts attention to federation paths, tenant configuration, and browser-mediated identity hops rather than only malicious domains. Teams that only measure block rates at the final page are looking too late in the sequence.

Phishing defence must move from URL reputation to flow integrity. URL filtering still has value, but this attack shows that control efficacy now depends on understanding the full path a user takes, including ads, redirects, federation hops, and conditional page logic. The category is moving toward runtime inspection of the browsing path and identity handoff, not static classification of the destination. That makes browser-level telemetry and redirect analysis more important for practitioners than isolated email gateway outcomes.

ADFSjacking is a useful named concept for this pattern. The article shows a sign-in abuse chain where ADFS is used to steer users through a trusted Microsoft authentication path into attacker infrastructure. That is not the same thing as ordinary phishing, because the identity bridge itself becomes the delivery mechanism. Security teams should recognise that federation components can be abused as trust amplifiers, not just authentication services.

From our research:

• 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.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and a further 47% having only partial visibility.
• For related identity governance context, review NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding controls reduce trust-chain exposure.

What this signals

Trusted redirect abuse will force teams to widen their detection boundary. The control problem is no longer limited to where a link points. It now includes how the browser got there, which federation layer handled the hop, and whether the path is consistent with legitimate identity flow. That is why teams should pair browser telemetry with identity logging and federation baselines.

Identity security programmes need a better model for delivery trust. When malvertising, redirect chains, and ADFS are combined, the attacker is exploiting assumptions that sit between security domains. Teams that still optimise only for email filtering or final-domain blocking will miss the attack class entirely. The better posture is to treat redirect integrity as part of sign-in assurance.

Adversaries are turning trusted infrastructure into camouflage. That means defenders need to assume the lure may arrive through a channel they do not traditionally own, then mutate before it reaches the credential prompt. For deeper lifecycle context, see the NHI Lifecycle Management Guide and the 52 NHI breaches Report for how unmanaged trust paths accumulate operational risk.

For practitioners

• Monitor redirect chains, not just destination domains Look for legitimate Microsoft or SSO URLs that resolve into unexpected domains, especially when the path includes federation markers or unusual hop sequences. Prioritise browser and proxy logs that preserve the full redirect chain so analysts can see how the user reached the final page.
• Inventory and baseline federation redirects Document which applications and tenants legitimately use ADFS or similar federation flows, then alert on sign-in paths that do not match that baseline. This makes it easier to distinguish normal tenant routing from attacker-controlled redirect infrastructure.
• Expand detections beyond email delivery Treat malvertising, third-party links, social media, and messaging platforms as first-class phishing delivery channels. Defensive policy should assume the lure may arrive outside the email stack and still require browser-side inspection.
• Correlate browser telemetry with identity events Join page-load activity, login redirects, and authentication events so analysts can see whether a credential prompt was reached through a trusted path or an obfuscated detour. That correlation is essential when conditional loading prevents reproduction in a sandbox.

Key takeaways

• The central failure is not the phishing page alone, but the trusted redirect path that delivered victims to it.
• ADFS, malvertising, and conditional loading together create an attack chain that weakens URL filtering and analysis tooling.
• Defenders need flow-level visibility, federation baselines, and browser telemetry if they want to catch this class before credentials are captured.

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.
• Malvertising: The use of malicious or abused online advertising to deliver a lure that leads to fraud, phishing, or malware. In identity attacks, malvertising is valuable because it bypasses email defenses and places the user directly into a browser-based attack chain.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 governance in your organisation, it is worth exploring.

This post draws on content published by Push Security: a phishing attack using legitimate Microsoft login redirects, ADFS, and malvertising. Read the original.