We Have Microsoft Safe Links. Why Are We Still Getting Phished?
Back to all blogsMicrosoft Safe Links is enabled, configured, and running. Yet phishing attacks are still getting through. This is not a configuration problem. It is a structural limitation that every CISO running Microsoft 365 needs to understand before the next incident lands on their desk.
The Question Nobody Wants to Ask Out Loud
You have Microsoft Defender for Office 365. Safe Links is configured. Your team runs security awareness training. MFA is enforced across the organisation.
And yet someone clicked a phishing link last quarter. Or the quarter before that. Or you are sitting in a board meeting being asked to explain how it happened when you clearly had controls in place.
This is not a hypothetical scenario. It is the reality for thousands of security teams running Microsoft 365 right now.
The uncomfortable answer is not that Safe Links failed to do what it was designed to do. It is that Safe Links was never designed to catch the class of threats that are responsible for most successful phishing attacks in 2026. Understanding that distinction is the starting point for building a defence posture that actually holds.
What Microsoft Safe Links Actually Does
Before examining the gaps, it is important to be precise about what Safe Links is designed to do. Precision matters here because conflating what Safe Links does with what comprehensive click-time protection looks like is exactly how security teams end up exposed.
Safe Links rewrites every URL in an inbound email during mail flow, replacing the original link with a Microsoft-controlled proxy URL. When a user clicks the rewritten link, the request routes through Microsoft's scanning infrastructure where a time-of-click reputation check runs against their threat intelligence database. If the URL matches a known malicious indicator, access is blocked. If it does not, the user is forwarded to the destination in their local browser.
This is a meaningful and genuine security control. For high-volume, known-threat phishing campaigns using infrastructure that Microsoft has already catalogued, Safe Links provides effective protection. It is not useless. It is incomplete.
The distinction between those two things is the entire problem.
Why Safe Links Is Not Enough: The Structural Gaps
Gap 1: Safe Links Relies on Reputation. Attackers Have Learned to Start Clean.
The core mechanism of Safe Links is reputation-based detection. A URL is evaluated against Microsoft's threat intelligence database at the time of click. If the domain or URL has been flagged, it is blocked.
Tycoon2FA generated large numbers of subdomains for individual phishing campaigns, used them briefly, then dropped them and spun up new ones. Parent root domains might remain registered for weeks or months, but nearly all campaign-specific FQDNs were temporary. The rapid turnover complicated detection efforts such as building reliable blocklists or relying on reputation-based defences.
This is not an edge case. In mid-2025, Tycoon2FA was responsible for 62% of all phishing attempts blocked by Microsoft, generating more than 30 million malicious emails in a single month. The infrastructure powering the majority of Microsoft 365 phishing attacks is specifically engineered to rotate faster than reputation databases can catalogue it.
When a freshly registered domain with no threat history is used in a campaign, Safe Links has no basis for blocking it. The reputation check returns clean. The user reaches the phishing page.
Gap 2: Conditional Redirects Serve Different Content to Scanners and Real Users
This is one of the most technically sophisticated and widely used bypass techniques in active deployment today.
Conditional redirects tied to user agent or region keep scanners on a clean path while real users see the final payload, a pattern that shows up often in phishing attacks.
The mechanism works because Safe Links scans from Microsoft's infrastructure using known scanning signatures. Attackers detect these signatures and serve benign content to the scanner while routing real users to the malicious destination. The reputation check sees a clean page. The employee sees a credential harvesting form.
To evade detection, Tycoon2FA used techniques like anti-bot screening, browser fingerprinting, heavy code obfuscation, self-hosted CAPTCHAs, custom JavaScript, and dynamic decoy pages.
Safe Links has no mechanism to account for the fact that what it scanned is not what your user sees.
Gap 3: Adversary-in-the-Middle Attacks Operate After Authentication - Outside Safe Links' Scope
This is the gap that is causing the most significant damage to Microsoft 365 environments in 2026.
AiTM phishing does not rely on getting malware onto the endpoint. It intercepts the authenticated session after the user has already completed MFA. The phishing link looks clean. It routes to what appears to be a legitimate login page. The user authenticates. MFA completes successfully. But a reverse proxy positioned between the user and Microsoft's identity provider captures the session cookie in real time.
Tycoon 2FA is responsible for an estimated 44.5% of all credential theft attacks globally in 2025, commanding an 89% share of the AiTM PhaaS market. Its singular innovation: it does not just steal passwords. It intercepts fully authenticated sessions after MFA has been completed, making multi-factor authentication irrelevant.
Safe Links scans the URL that initiates this chain. If that URL is clean, which it often is because it routes through legitimate infrastructure before the proxy intercepts the session, the user is forwarded through without challenge.
The Tycoon2FA platform accounted for 62% of phishing attempts Microsoft blocked by mid-2025, linking to 96,000 victims, including 55,000 Microsoft customers.
Read that carefully. These were Microsoft customers with Microsoft's own security stack deployed. Safe Links was running. The attacks succeeded regardless.
Gap 4: Legitimate Platform Abuse Is Structurally Unblockable by Safe Links
Key trends observed include abuse of legitimate services, such as URLs hosted on the Microsoft Dynamics 365 marketing platform or protected by Cloudflare Turnstile CAPTCHAs.
A URL pointing to Microsoft Dynamics 365, SharePoint, OneDrive, Google Drive, or Dropbox will almost never be blocked by Safe Links regardless of what content sits behind it. Blocking these domains entirely would break legitimate business operations. Safe Links cannot selectively evaluate content hosted on trusted platforms in real time.
Attackers know this. Hosting malicious content behind trusted platform URLs is now standard tradecraft, not an advanced technique.
Gap 5: QR Code Phishing Bypasses URL Scanning Entirely
Quishing uses QR codes to direct victims to malicious sites. This technique bypasses traditional email security filters because the malicious link is encoded in an image, not in text. Quishing attacks surged 400% between 2023 and 2025.
Safe Links rewrites text-based URLs. It does not decode URLs embedded in QR code images. A phishing campaign that delivers its malicious URL inside a QR code image is completely invisible to Safe Links' URL scanning engine.
Gap 6: Safe Links Has Documented Coverage Limitations
Microsoft's own documentation confirms structural coverage gaps. Safe Links does not work on mail-enabled public folders. Safe Links supports only HTTP, HTTPS, and FTP link formats. Safe Links does not provide protection for URLs in rich text format email messages. If a system failure occurs when reading the Safe Links policy configuration from certain applications, the user does not receive Safe Links protection and is redirected to the clicked link.
These are not configuration failures. They are documented product limitations that create predictable blind spots in coverage.
The Deeper Problem: Safe Links Was Built for a Different Threat Era
Because Microsoft Defender is a known quantity to attackers, sophisticated threats are often designed specifically to bypass its defences. Many technical leaders find that while Defender is a good first layer, they require a specialised solution to catch the advanced attacks that slip through.
This is the core issue. Safe Links was designed to protect against the phishing techniques that were dominant when it was built high-volume campaigns using known malicious domains delivered through email. It does that well.
The threat landscape has moved to a different model entirely. Phishing is now as much of an infrastructure problem as a content problem. Attackers are using Telegram bots, link forwarding services, and front-end hosting to scale up phishing campaigns.
Modern phishing infrastructure is built to be disposable, adaptive, and specifically tuned to evade the controls that defenders have deployed. Safe Links leans on real-time reputation checks and detonation results, which work until a redirect chain shifts faster than the scanner can follow.
What Happens After Safe Links Clears a Link
This is the question that defines your actual risk exposure.
When Safe Links performs its reputation check and the URL returns clean, the user is forwarded to the destination in their local browser on their own device, connected to your corporate network. From that point forward, Safe Links has no further involvement in what happens. Whatever the destination does redirect to a credential harvesting page, present a fake login form, initiate an OAuth consent flow, intercept a session cookie happens entirely within the user's local browser environment.
The security envelope around that session disappears the moment Safe Links forwards the user through.
This is the gap that a post-delivery, click-time isolation approach addresses. Rather than checking a link against a reputation database and releasing the user to the destination, an isolation model opens the destination in a secure containerised environment completely outside the user's device and network. The user can interact with the page normally. But the execution happens in a contained environment where credential harvesting forms, session interception, malicious scripts, and exploit attempts cannot reach the endpoint.
When a URL cannot be verified with high confidence as genuinely safe, it should not be opened in the user's local browser at all. That principle is what separates reputation-based URL checking from genuine click-time protection.
What CyberCheck360 Does Differently
CyberCheck360 is not a replacement for Microsoft Defender or Safe Links. It is the layer that closes the gap that Safe Links was not built to cover.
When a user clicks a link that has passed Safe Links' reputation check, CyberCheck360 opens that link inside an isolated browsing session that runs entirely outside the user's device and network. The page loads, scripts execute, and any redirect chain is followed all within the contained environment. If the destination attempts to harvest credentials, intercept a session, or deploy malicious content, none of it can reach the endpoint because the session never touches the local browser.
Trusted links with a clean, verified history open normally. Everything else opens in the isolated container.
This is the distinction that matters for CISOs evaluating their Microsoft 365 security posture. Safe Links answers the question "have we seen this URL before and do we know it is bad?" CyberCheck360 answers the question "what is this URL actually doing right now, and is our user protected regardless of the answer?"
Both questions need an answer. Safe Links only covers one of them.
See how CyberCheck360 closes the gap that Microsoft Defender was not built to cover.
Building the Right Architecture Around Microsoft 365
The goal is not to replace Microsoft's security stack. It is to deploy it accurately. That means understanding what each layer covers and where each layer stops.
A realistic architecture for Microsoft 365 email security in 2026 looks like this:
Layer 1: Microsoft Defender for Office 365 with Safe Links and Safe Attachments Handles high-volume known threats, spam filtering, and reputation-based URL checking. This layer should be properly configured and not treated as optional.
Layer 2: Email Authentication (SPF, DKIM, DMARC) Prevents domain spoofing and impersonation at the protocol level. Should be enforced with a DMARC policy of reject, not just monitoring.
Layer 3: Click-Time URL Isolation Covers the gap that reputation-based checking leaves open. Operates at the moment of user intent rather than at delivery, and keeps the browsing session isolated from the endpoint regardless of what the destination contains.
Layer 4: Phishing-Resistant MFA (FIDO2) Addresses AiTM attacks that bypass software-based MFA. Session cookie theft is irrelevant if the authentication cannot be proxied.
Layer 5: User Reporting and SOC Feedback Loop User-reported phishing that Safe Links did not catch is your most valuable signal for understanding what is getting through. This data should feed directly into your threat intelligence and detection tuning.
None of these layers are sufficient in isolation. Each one compensates for the limitations of the others. The CISO conversation should not be "do we have Safe Links enabled?" It should be "what is our protection model for the threats that Safe Links does not catch?"
Frequently Asked Questions
Is Microsoft Safe Links effective?
Yes, for the threats it was designed to detect. Safe Links is effective against high-volume phishing campaigns using known malicious infrastructure, known bad domains, and links that have been catalogued in Microsoft's threat intelligence database. It is not effective against newly registered domains with no reputation history, conditional redirect attacks that serve different content to scanners and real users, QR code phishing, or AiTM attacks that intercept sessions after Safe Links has already cleared the link.
Why are phishing attacks still succeeding in Microsoft 365 environments?
The primary reason is that modern phishing infrastructure is specifically engineered to bypass reputation-based controls. The Tycoon2FA phishing-as-a-service platform alone was responsible for 62% of phishing attempts blocked by Microsoft in mid-2025, and still compromised 55,000 Microsoft customers despite Safe Links being deployed. Attackers use disposable subdomains, conditional redirects, and AiTM proxies specifically because they know how Microsoft's scanning infrastructure works and how to evade it.
What is the difference between Safe Links and URL isolation?
Safe Links checks a URL against a reputation database at the time of click and either blocks or forwards the user based on that check. URL isolation opens the destination in a containerised environment outside the user's device, so whatever the page does cannot reach the endpoint regardless of whether the URL was flagged. Safe Links is a gate check. URL isolation is a protective envelope around the entire browsing session.
Does adding a third-party URL isolation solution require removing Microsoft Defender?
No. Solutions like CyberCheck360 are designed to operate alongside Microsoft Defender, not replace it. They cover the click-time gap that Defender leaves open without disrupting the email filtering, threat intelligence, and incident response capabilities that Defender provides.
What is an AiTM phishing attack and why does Safe Links not stop it?
An adversary-in-the-middle phishing attack positions a reverse proxy between the user and a legitimate identity provider. The user clicks a link, reaches what appears to be a legitimate login page, authenticates, and completes MFA. The proxy intercepts the session cookie in real time after authentication completes. Safe Links scans the URL that initiates this chain. If that URL is clean, which it often is because it routes through legitimate or newly registered infrastructure, Safe Links forwards the user through without challenge. The session interception happens after Safe Links has already made its decision.
How do attackers bypass Safe Links using QR codes?
Safe Links scans text-based URLs embedded in email messages. A QR code is an image. Safe Links does not decode the URL encoded inside a QR code image, so the malicious destination is invisible to Safe Links' URL scanning engine entirely. The user scans the code with their phone, typically a device outside the corporate security perimeter, and the malicious page loads on a device with no Safe Links protection at all.
What should a CISO do if Safe Links is already deployed but incidents are still occurring?
First, audit your Safe Links configuration against Microsoft's Strict preset to ensure it is fully configured rather than partially deployed. Second, review your DMARC policy and ensure it is set to reject rather than monitoring only. Third, evaluate whether you have click-time isolation covering the gap between what Safe Links checks and what happens after a clean link is forwarded to the user's browser. Fourth, implement FIDO2 phishing-resistant MFA to address AiTM session interception. Fifth, establish a user reporting mechanism and use reported phishing that bypassed Safe Links as active intelligence for tuning your detection posture.
The Bottom Line
Microsoft Safe Links is a necessary and valuable component of a Microsoft 365 security architecture. It is not a complete email security strategy.
The phishing attacks that are succeeding in Microsoft 365 environments in 2026 are not succeeding because Safe Links is broken. They are succeeding because they are specifically engineered to operate in the space that Safe Links was never designed to cover: disposable infrastructure with no reputation history, conditional redirects that serve different content to scanners and users, QR code delivery, and AiTM session interception after the user has already authenticated.
Closing that gap requires a different kind of control. One that does not ask what a URL is known to be but instead isolates what it actually does, at the moment the user clicks it, in an environment that cannot reach your endpoints regardless of the outcome.
That is the question every CISO running Microsoft 365 should be asking right now.
Published by CyberCheck360 | Post-Delivery Email Security cybercheck360.com