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.
Why This Matters for Security Teams
Phishing that relies on legitimate Google and Microsoft redirects is harder to stop because the attacker is not always presenting a suspicious destination first. Instead, the message often passes through infrastructure that reputation filters already trust, which can defeat controls that score only the final URL. That matters for identity teams, mail security teams, and incident responders because the attack path now includes a trusted chain rather than a single bad link. NIST Cybersecurity Framework 2.0 emphasizes continuous detection and response, which is more realistic than assuming a one-time block will catch every stage of the chain.
This pattern also overlaps with broader identity abuse seen in cases such as the Microsoft Midnight Blizzard breach and the Google Firebase misconfiguration breach, where trust boundaries and identity assumptions became part of the attack surface. The operational lesson is simple: redirect reputation is not the same as link safety, and chain visibility matters more than isolated scoring. In practice, many security teams encounter this only after users have already authenticated into the final page, rather than through intentional chain-aware inspection.
How It Works in Practice
Redirect-based phishing usually works by placing one or more trusted intermediary hops between the email or message and the final credential harvest page. A security gateway may see a Microsoft or Google domain at the first hop and assign the message a lower-risk score, even though the last hop resolves to an attacker-controlled site. Because each step is individually plausible, defenders need to evaluate the full redirect chain, the HTTP response pattern, and the final landing context rather than relying on the first or last domain alone.
Practically, that means combining URL rewriting, sandbox detonation, browser-level inspection, and identity telemetry. Security teams should look for unusual redirect depth, mismatched domains across hops, token leakage in query strings, and login prompts that appear after a trusted transition. This is especially important for phishing kits that abuse cloud services, short-lived signed URLs, or compromised tenant resources. The Microsoft Azure OpenAI service breach and the CI/CD pipeline exploitation case study show how trusted automation paths and inherited access can expand exposure when workflows are not validated end to end.
- Inspect the full chain, not just the first URL or the destination domain.
- Correlate message telemetry with browser and identity logs to spot suspicious handoffs.
- Flag redirects that move from trusted brands into fresh domains or credential prompts.
- Use conditional access and phishing-resistant MFA so a clicked link does not equal account compromise.
Current guidance suggests that chain-aware analysis works best when URL inspection is paired with identity-aware controls, because redirect abuse often ends at an authentic login page that looks harmless until the session is abused. These controls tend to break down in single-page webmail flows and mobile clients, where full redirect context is harder to preserve because security tooling cannot always reconstruct every hop.
Common Variations and Edge Cases
Tighter redirect inspection often increases false positives and user friction, requiring organisations to balance attack prevention against access delays. That tradeoff becomes sharper when legitimate business links use multiple hops for tracking, regional routing, or authentication handoff. There is no universal standard for classifying every redirect sequence yet, so current guidance suggests treating the chain as risk evidence rather than as automatic proof of malicious intent.
One common edge case is compromise of a trusted tenant or marketing domain, where the redirect is technically legitimate but operationally unsafe. Another is a short-lived URL that is benign at reputation-check time and malicious minutes later. The NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which matters because hidden or overly permissive identities can enable the infrastructure abuse that makes these redirects credible. Security teams should also distinguish between user-facing trust and machine trust: a branded hop may look safe to a person, yet still be part of a credential theft chain. The right response is layered verification, not blanket blocking of all redirects.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Redirect abuse needs continuous monitoring across the full chain. |
| OWASP Non-Human Identity Top 10 | NHI-06 | Trusted redirects often abuse secrets and session-bearing identities. |
| NIST AI RMF | Risk management should cover dynamic, deceptive phishing paths. |
Reduce exposure by limiting token reuse and validating credential handling across redirect hops.
