Notifications
Clear all
Topic starter
12/06/2026 12:16 am
TL;DR: A phishing campaign used legitimate Microsoft login redirects, ADFS configuration, and malvertising to send victims to an AiTM phishing page while bypassing common URL-based defenses, according to Push Security. The pattern shows that delivery trust assumptions, not just phishing page quality, are now the weak point in identity attack detection.
NHIMG editorial — based on content published by Push Security: a phishing attack using legitimate Microsoft login redirects, ADFS, and malvertising
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Expand detections beyond email delivery Treat malvertising, third-party links, social media, and messaging platforms as first-class phishing delivery channels.
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 observed in the browser timeline, including how the legitimate login path was chained into the phishing destination.
- The detection and investigation workflow used to trace tabs, popups, and form submissions back to the initial lure.
- The specific log patterns security teams can hunt for when ADFS redirects are being abused in the wild.
- The control recommendations for reducing exposure to malvertising-led phishing and trusted redirect abuse.
👉 Read Push Security's analysis of trusted redirect phishing and ADFS abuse →
Trusted redirect chains in phishing: what should IAM teams watch?
Explore further
12/06/2026 9:25 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Phishing detection evasion is shifting to trusted redirect chains
