Your Users Clicked Through Safe Links and Got Compromised. Here Is Why That Happens.
Back to all blogsSafe Links ran. The check passed. The user clicked. And somehow, your organisation still got compromised. This is not a mystery. It is a pattern — and it has a specific, fixable cause.
It Passed Every Check. And It Still Got Through.
You have been here before. Or you are about to be.
An email lands. Safe Links rewrites the URL. The user clicks. Microsoft runs its reputation check. Green light. The user reaches the destination.
And then the incident report lands on your desk.
This is not a fluke. It is not a configuration error. It is a structural gap that exists in every Microsoft 365 environment running Safe Links as its only click-time protection. Understanding it is the difference between fixing the symptom and fixing the problem.
What Safe Links Actually Checks
Before we get into why it fails, let us be precise about what Safe Links does.
When a user clicks a rewritten link, Safe Links checks:
Whether the domain has been flagged as malicious in Microsoft's threat intelligence database
Whether the URL matches known phishing signatures or patterns
Whether the destination has been detonated and found to be clean in a prior scan
What the page actually does to your user after they arrive
Whether the destination changed after the check was completed
Whether the session is being intercepted in real time after authentication
It cannot answer the question that matters most after the check: what is happening to your user right now?
The Three Moments Safe Links Cannot See
Moment 1
After the Check, the Page Changes
Safe Links scans the URL and finds a clean page. Minutes later, the attacker switches the destination to a credential harvesting form. Your user clicks the link two hours after delivery. Safe Links already cleared it. Nobody is watching anymore.
Moment 2
The Page Detects It Is Being Scanned
Advanced phishing kits detect Microsoft's scanning IP ranges and serve clean content to the scanner. Your user gets the real malicious page. Safe Links saw something completely different and passed it through with confidence.
Moment 3
The Session Gets Hijacked After Login
The URL is clean. The page looks like Microsoft. Your user logs in and completes MFA. A reverse proxy positioned between them and Microsoft's servers captures the authenticated session cookie. Safe Links forwarded the user through and stopped watching. The attacker now has full account access.
This Is Not Theoretical. This Happened Last Quarter.
In April 2026, Microsoft documented a phishing campaign that ran across two days and compromised users across 26 countries.
Real Campaign - April 2026
The emails even claimed that all links and attachments had been securely reviewed.
They had not been. But the users believed they had. And Safe Links, checking the initial link, found nothing to dispute that claim.
The Stat That Should Be on Every CISO Dashboard
91%
of cyberattacks still begin with email
Source: Microsoft Digital Defense Report 2025
28%
of breaches investigated by Microsoft started with phishing or social engineering
23%
of all tracked brand impersonation attacks in Q2 2026 used Microsoft branding
7.6B
email-based phishing threats detected by Microsoft in Q2 2026 alone
Where Safe Links Ends and the Risk Begins
Here is the moment that matters most and that almost no one talks about clearly.
Safe Links Zone
Email arrives. URL is rewritten. User clicks. Reputation check runs. Result: clean. User forwarded.
✓ Protected
After Safe Links
User lands in local browser. Page executes. Credentials can be harvested. Session can be intercepted. Downloads can trigger.
✗ Exposed
That is the gap. It is not subtle. It is just rarely described this directly.
What Actually Closes the Gap
The fix is not better Safe Links configuration. The fix is a layer that continues protecting the user after Safe Links has done its job.
Click-time URL isolation opens the destination inside a containerised browsing session that runs entirely outside the user's device and network. Trusted links open normally. Everything else opens in the container.
What happens inside the container stays inside the container:
- Credential harvesting forms cannot capture credentials from the user's local browser
- Session interception proxies cannot intercept a session that never touches the local device
- Malicious scripts cannot execute against the user's endpoint
- File downloads cannot reach the user's file system The user sees the page. Interacts with it normally. But the execution is isolated. Whatever the attacker has prepared cannot reach the endpoint.
This is not a replacement for Safe Links. It is the layer that makes Safe Links complete.
See how CyberCheck360 isolates every unverified link at click time independently of Safe Links.
Frequently Asked Questions
Why do users get compromised even with Safe Links enabled?
Safe Links checks URLs against a reputation database at click time. It cannot detect destinations that change after the check, pages that serve different content to scanners than to real users, session interception attacks that occur after authentication, or URLs embedded in images like QR codes. When a link passes these checks and the user is forwarded to the destination, Safe Links has no further role in protecting what happens next.
What is the difference between Safe Links and click-time URL isolation?
Safe Links checks a URL and makes a block or forward decision based on reputation. Once it forwards the user, protection ends. Click-time URL isolation opens the destination in a containerised environment outside the user's device, so whatever the page does cannot affect the endpoint regardless of whether the URL was flagged.
Can attackers really detect when Safe Links is scanning?
Yes. Advanced phishing kits fingerprint Microsoft's scanning infrastructure using IP ranges, user agent strings, and request timing. When scanner signatures are detected, the kit serves benign content. When a real user visits the same URL, the malicious page loads. Safe Links sees a clean result. The user sees the phishing page.
Does fixing Safe Links configuration solve this problem?
Partially. Ensuring Safe Links is configured to Strict preset and applied to all mailboxes reduces exposure from misconfiguration gaps. But configuration improvements cannot address structural limitations like post-click session interception, bait-and-switch destination switching, or scanner detection evasion. Those require a different kind of control at a different point in the attack chain.
Published by CyberCheck360 | Post-Delivery Email Security cybercheck360.com