9.3 Safe Links Policies

Safe Links Policies

By the end of this subsection, you will understand URL rewriting and time-of-click scanning, know when Safe Links fails and why, configure a Safe Links policy, and track user clicks with KQL.

How Safe Links works

When a user receives an email containing a URL, Safe Links rewrites the URL to route through Microsoft’s scanning infrastructure. When the user clicks, the request goes to Microsoft first, which scans the destination in real-time, then either allows or blocks the user from reaching it.

Time-of-click protection is the key feature. A URL that was clean at email delivery may become malicious hours later (the attacker activates the phishing page after the email passes scanning). Safe Links catches this because it scans at the moment of click, not at the moment of delivery.

URL scanning modes

When Safe Links fails

Safe Links is not infallible. Understanding its limitations prevents false confidence:

Click tracking with KQL

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

UrlClickEvents
| where TimeGenerated > ago(7d)
| where ActionType == "ClickBlocked" or IsClickedThrough == true
| summarize
    TotalClicks = count(),
    Blocked = countif(ActionType == "ClickBlocked"),
    WarningShown = countif(ActionType == "ClickAllowed" and IsClickedThrough == false),
    ClickedThrough = countif(IsClickedThrough == true)
    by UrlDomain
| where TotalClicks > 3
| sort by ClickedThrough desc

URL rewriting explained

When Safe Links is active, the original URL in the email is replaced with a Microsoft URL:

Original: https://northgate-voicemail.com/auth/a3f8b2c1/login Rewritten: https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnorthgate-voicemail.com%2Fauth%2Fa3f8b2c1%2Flogin&data=...

When the user clicks, the request goes to safelinks.protection.outlook.com first. Microsoft scans the target URL in real-time, then either:

• Allows: redirects the user to the original URL
• Warns: shows a warning page (user may click through if policy allows)
• Blocks: shows a block page (user cannot proceed)

The entire process takes under 2 seconds for known-clean URLs. Unknown URLs may take 5-10 seconds while detonation runs.

Safe Links coverage scope

Policy configuration

1. Navigate to security.microsoft.com -> Policies -> Threat policies -> Safe Links
2. Create a new policy (or edit the default)
3. Settings:
   • URL and click protection settings: On (URLs rewritten and checked)
   • Track user clicks: Yes (never disable)
   • Let users click through: No (recommended) — users cannot override the block. If you set this to Yes, users can click through warnings (the Module 14 scenario).
   • Scan URLs in email: On
   • Scan URLs in Teams: On
   • Scan URLs in Office apps: On
   • Do not rewrite URLs: Off (keep rewriting)
4. Apply to all users (or specific groups)

Required role and blast radius

Required role: Security Administrator.

How Safe Links works — the scanning sequence

Understanding the scanning sequence clarifies both the protection and the limitations:

Pre-delivery scanning. When an email arrives, Defender extracts all URLs from the body and attachments. Each URL is checked against Microsoft’s real-time reputation database and detonated in a sandbox (the URL is visited by an automated browser). If the URL is malicious: the email is blocked or the URL is wrapped with a Safe Links URL that displays a block page when clicked.

Time-of-click scanning. Even if the URL was clean at delivery time, Safe Links re-scans when the user clicks. The user’s click goes to https://safelinks.protection.outlook.com/... which performs a real-time check before redirecting to the actual URL. This catches URLs that were clean at delivery but weaponised afterward (the attacker sets up the page after the email is delivered to evade pre-delivery scanning).

The critical gap: If the URL is behind a CAPTCHA, a login wall, or uses JavaScript rendering that the automated scanner cannot execute, the pre-delivery scan sees a benign page. Time-of-click scanning may also be defeated if the attacker serves different content to Microsoft’s scanning infrastructure than to human visitors (user-agent filtering, IP-based geofencing). This is exactly what the AiTM kit in Module 12 exploited.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Safe Links click tracking — what URLs are users clicking?
UrlClickEvents
| where TimeGenerated > ago(30d)
| summarize
    TotalClicks = count(),
    Allowed = countif(ActionType == "ClickAllowed"),
    Blocked = countif(ActionType == "ClickBlocked"),
    PendingDetonation = countif(ActionType == "UrlDetonation"),
    UniqueUsers = dcount(AccountUpn)
    by bin(TimeGenerated, 1d)
| order by TimeGenerated desc

The “Allowed” column is your risk metric. These are clicks that Safe Links permitted — either the URL was clean, or the URL evaded scanning. High Allowed counts on days with known phishing campaigns indicate evasion.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Find the most-clicked external URLs — prioritise investigation
UrlClickEvents
| where TimeGenerated > ago(7d)
| where ActionType == "ClickAllowed"
| where IsClickedThrough == true
| extend UrlDomain = tostring(parse_url(Url).Host)
| summarize ClickCount = count(), UniqueUsers = dcount(AccountUpn)
    by UrlDomain
| where ClickCount > 5
| order by ClickCount desc

Review this weekly. Domains with high click counts that you do not recognise warrant investigation — they may be legitimate (a shared tool) or may be a long-running phishing campaign with a URL that evades scanning.

Safe Links for internal email

By default, Safe Links scans URLs in external email only. Enable internal email scanning. Internal phishing (a compromised account sending phishing to colleagues) is a key progression in the Module 12 AiTM scenario — Wave 4 was internal phishing from compromised accounts. Without internal Safe Links, these internal phishing URLs are not scanned.

Navigate to: Defender → Policies → Safe Links → default policy → Settings → “Safe Links checks a list of known, malicious links when users click links in email” → ensure it applies to “Messages sent within the organization.”

Blast radius: Minor email delivery latency for internal email (URL scanning adds milliseconds). No user-facing impact.

Rollback: Disable internal email scanning in the policy. Previously scanned URLs are not affected.

Safe Links for Teams and Office applications

Extend Safe Links protection beyond email:

Microsoft Teams: Enable Safe Links for Teams. URLs shared in Teams chats and channels are scanned at click time. This catches phishing URLs shared via Teams by compromised accounts or external guests.

Office applications: Enable Safe Links for Office apps (Word, Excel, PowerPoint). URLs in documents are scanned when clicked. This catches malicious URLs in attachments that the user opened and then clicked a link within.

Navigate to: Defender → Policies → Safe Links → “Settings that apply to content across Office 365 applications.” Enable: Safe Links for Teams, Safe Links for Office applications.

URL wrapping and user experience

Safe Links replaces every URL in email with a wrapped URL: https://safelinks.protection.outlook.com/?url=...&data=.... When the user clicks, the request goes to Microsoft first, which scans the URL in real time, then redirects to the original URL if clean.

User impact: Wrapped URLs look different — long, unfamiliar strings instead of the original URL. Some users find this confusing or suspicious (“why does this link look weird?”). Pre-communicate: “All links in email are now scanned by our security system. The wrapped URL starting with safelinks.protection.outlook.com is normal — it means the link has been checked.”

Do not unwrap URLs. Some organisations configure Safe Links to rewrite URLs to their original form after scanning. This removes the time-of-click protection — if the URL becomes malicious after delivery, the user clicks the unwrapped (unprotected) URL. Keep URL wrapping enabled.

Safe Links configuration for maximum protection

Navigate to: Defender → Policies → Safe Links → default policy.

Settings to enable:

1. On: Safe Links checks a list of known, malicious links when users click links in email. This is the core feature.
2. On: Safe Links checks a list of known, malicious links when users click links in Microsoft Teams.
3. On: Apply Safe Links to email messages sent within the organization. Critical for internal phishing detection (Module 12 Wave 4).
4. On: Apply real-time URL scanning for suspicious links and links that point to files. Enables detonation of URLs that redirect to file downloads.
5. On: Wait for URL scanning to complete before delivering the message. Prevents the email from being delivered before the URL scan completes — closing the pre-delivery gap.
6. Do NOT allow users to click through to the original URL. When Safe Links blocks a URL, the user sees a block page. Some configurations allow the user to click through anyway (“I know this is safe”). Disable click-through — if Safe Links blocked it, the user should not override.

Blast radius of “Wait for URL scanning”: Email delivery delay of 5-30 seconds for emails containing URLs (while the URL is scanned). For most organisations: unnoticeable. For high-volume email environments (customer support, sales): may cause slight delays in email-dependent workflows.

Rollback: Disable individual settings. Previously scanned URLs retain their verdicts.

Safe Links URL detonation bypass techniques

Attackers actively develop techniques to bypass Safe Links scanning. Understanding these informs your defensive layering:

CAPTCHA gates. The phishing page is behind a CAPTCHA. Safe Links’ automated scanner sees the CAPTCHA page (benign), not the phishing page behind it. Module 12 used this technique.

Conditional redirects. The URL serves different content based on: user agent (human browser vs Microsoft scanner), IP address (Microsoft’s scanning infrastructure IP ranges), geographic location, or referrer header. The scanner sees a benign page; the user sees the phishing page.

URL shorteners with time delays. The shortened URL redirects to a benign page for the first hour (during scanning), then redirects to the phishing page after the scan completes.

Base URL mutation. The attacker changes the URL’s subdomain or path every few hours. Safe Links scans the URL at delivery time and blocks it. The attacker rotates to a new URL and sends the next wave. Each URL is new — Safe Links must scan each independently.

Defence against bypass techniques: No single layer catches everything. Layer Safe Links (URL scanning) with anti-phishing (impersonation detection), transport rules (domain blocking), ZAP (post-delivery cleanup), and user reporting (human sensor network). The attacker must bypass ALL layers simultaneously — which is significantly harder than bypassing one.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// Identify URLs that Safe Links allowed but that were later reclassified
// (evidence of bypass that was subsequently detected)
let AllowedClicks = UrlClickEvents
| where TimeGenerated > ago(30d)
| where ActionType == "ClickAllowed"
| project ClickTime = TimeGenerated, AccountUpn, Url, NetworkMessageId;
let LaterBlocked = EmailPostDeliveryEvents
| where TimeGenerated > ago(30d)
| where ActionType == "ZAP"
| project ZapTime = TimeGenerated, NetworkMessageId;
AllowedClicks
| join kind=inner LaterBlocked on NetworkMessageId
| where ZapTime > ClickTime
| project AccountUpn, Url, ClickTime, ZapTime,
    GapMinutes = datetime_diff('minute', ZapTime, ClickTime)
| order by GapMinutes asc

This query finds the worst case: URLs that Safe Links allowed (the user clicked and reached the page) but that were later identified as malicious (ZAP removed the email). The GapMinutes column shows how long the user was exposed. If this query returns results: those users need investigation for potential credential compromise.