9.4 Safe Attachments Policies

Safe Attachments Policies

By the end of this subsection, you will understand sandbox detonation modes, know when to use Dynamic Delivery vs Block, configure Safe Attachments for SharePoint/OneDrive/Teams, and verify detonation results with KQL.

How Safe Attachments works

Safe Attachments opens email attachments in an isolated sandbox (a virtual machine) and observes their behavior. If the file tries to execute code, modify the registry, download additional files, or phone home to a C2 server, it is classified as malicious and blocked.

This catches zero-day malware that signature-based scanning misses — the file has never been seen before, so it has no signature, but its behavior in the sandbox reveals malicious intent.

Detonation modes

Safe Attachments for SharePoint, OneDrive, and Teams

Email attachments are not the only file vector. Attackers upload malicious files to SharePoint or share them via Teams. Safe Attachments for SPO/OD/Teams scans files uploaded to these services and blocks access to files identified as malicious.

Configuration: In Threat policies, enable “Turn on Defender for Office 365 for SharePoint, OneDrive, and Microsoft Teams.” This is a global setting — it applies to all sites and channels.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Verify Safe Attachments detections
EmailAttachmentInfo
| where TimeGenerated > ago(30d)
| where ThreatTypes has "Malware"
| summarize
    MalwareCount = count(),
    UniqueFiles = dcount(SHA256),
    FileTypes = make_set(FileType, 10)
    by bin(TimeGenerated, 1d)
| sort by TimeGenerated asc

Safe Documents for Office clients

Safe Documents extends sandbox detonation to files opened in Protected View on desktop Office apps. When a user opens a Word, Excel, or PowerPoint file from the internet or an email attachment, Office opens it in Protected View (read-only). Safe Documents scans the file while it is in Protected View. If the file is clean, the user can click “Enable Editing.” If malicious, the file is blocked.

This catches a common attack vector: a user downloads a macro-enabled document from a website (not email), opens it in Word, and the macro detonation in Safe Documents catches the malware before the user enables editing.

Detonation verdict verification

After configuring Safe Attachments, verify it is working by checking detonation results:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

EmailAttachmentInfo
| where TimeGenerated > ago(7d)
| where ThreatTypes != ""
| summarize
    Detections = count(),
    UniqueHashes = dcount(SHA256),
    FileTypes = make_set(FileType),
    Actions = make_set(DeliveryAction)
    by ThreatTypes
| sort by Detections desc

Required role and blast radius

Required role: Security Administrator.

Detonation modes — choosing the right one

Safe Attachments has four modes. The choice affects both security and user experience:

Block. Attachments are detonated in the sandbox. If malicious: the entire email is blocked (not delivered). If clean: delivered normally. Detonation takes 30-120 seconds. During this time, the email is delayed.

Replace (Dynamic Delivery — recommended). The email body is delivered immediately without the attachment. The attachment is detonated in parallel. If clean: the attachment is re-attached (the user sees it appear in the email after a short delay). If malicious: the attachment is removed and the user is notified. The user can read the email immediately and receives the attachment within minutes.

Monitor. Attachments are detonated but no action is taken. The results are logged. Use this for initial deployment to understand the detection volume before enabling blocking.

Off. No detonation. Not recommended for any production environment.

Recommended deployment path:

Week 1: Deploy in Monitor mode. Review detections daily. Assess: how many attachments are flagged, what file types, how many false positives?

Week 2: Switch to Dynamic Delivery. Users receive email bodies immediately; attachments arrive after detonation. This is the best balance of security and usability.

Week 4: Review. If false positive rate is acceptable: maintain Dynamic Delivery. If specific senders are consistently flagged (legitimate automated systems sending unusual file types): create per-sender exceptions.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Safe Attachments detection monitoring
EmailEvents
| where TimeGenerated > ago(30d)
| where ThreatTypes has "Malware"
| where DeliveryAction in ("Blocked", "Replaced")
| summarize
    MalwareBlocked = count(),
    UniqueAttachments = dcount(tostring(AdditionalFields)),
    UniqueRecipients = dcount(RecipientEmailAddress)
    by bin(TimeGenerated, 7d)

A steady baseline of 5-20 malware attachments blocked per week is typical. A spike (100+ in a day) indicates a campaign — investigate with Threat Explorer.

Safe Attachments for SharePoint, OneDrive, and Teams

Extend Safe Attachments beyond email. When a file is uploaded to SharePoint, OneDrive, or Teams, Safe Attachments scans it. If malicious: the file is blocked from download (users can see the file name but cannot open it).

Navigate to: Defender → Policies → Safe Attachments → Global settings → Turn on Defender for Office 365 for SharePoint, OneDrive, and Microsoft Teams.

Why this matters for insider threat (Module 16). If a compromised account uploads a malicious file to SharePoint, Safe Attachments blocks other users from downloading it — containing the spread without requiring manual intervention.

Blast radius: File upload delay (scanning takes seconds). False positives block legitimate files from download — rare but impactful when it happens to a shared project file.

Rollback: Disable the global setting. Blocked files become downloadable again immediately.

Verify:

1
2
3
4
5
6

// SharePoint/OneDrive Safe Attachments detections
CloudAppEvents
| where TimeGenerated > ago(30d)
| where ActionType == "FileMalwareDetected"
| project TimeGenerated, AccountDisplayName, Application,
    FileName = tostring(parse_json(RawEventData).SourceFileName)

Dynamic Delivery — the user experience

Understanding the user experience helps you set expectations during deployment:

T=0: The email arrives. The user sees the email body, but the attachment shows a placeholder: “This attachment is being scanned. It will be available shortly.”

T=30-120 seconds: The sandbox completes detonation. If clean: the placeholder is replaced with the actual attachment. The user can now open it. If malicious: the placeholder is replaced with a notification: “This attachment has been removed because it contained malware.”

What happens if the user opens the email during scanning? They see the placeholder. They cannot download or preview the attachment. Some users will be confused (“where is the attachment?”). Pre-communicate: “You may occasionally see a ‘scanning’ placeholder on attachments. This is our new malware protection — the attachment will appear within 1-2 minutes.”

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Monitor Dynamic Delivery: how many emails are experiencing delivery delays?
EmailEvents
| where TimeGenerated > ago(7d)
| where DeliveryAction == "Delivered"
| extend HasDynamicDelivery = (tostring(AdditionalFields) has "DynamicDelivery"
    or tostring(AdditionalFields) has "Replaced")
| summarize
    TotalDelivered = count(),
    DynamicDeliveryCount = countif(HasDynamicDelivery),
    DDPercent = round(100.0 * countif(HasDynamicDelivery) / count(), 1)
    by bin(TimeGenerated, 1d)

Expected: Dynamic Delivery applies to 10-30% of delivered email (emails with attachments). If the percentage is higher: check whether attachments from known-safe internal systems are being scanned unnecessarily (consider per-sender exceptions). If 0%: Safe Attachments is not in Dynamic Delivery mode or is not processing email correctly.

Attachment types that evade sandboxing

Not all file types can be detonated in the sandbox. Some bypass analysis:

Password-protected archives. A ZIP file with a password cannot be opened by the sandbox. The attacker includes the password in the email body — the user extracts the file manually, bypassing the sandbox entirely. Detection relies on: heuristic rules (email with a password-protected attachment is suspicious), the transport rule blocking dangerous file types inside the archive (if extractable), or endpoint detection when the payload executes.

Embedded macros in uncommon formats. The sandbox prioritises Office documents (Word, Excel, PowerPoint) and executables. Less common formats (.slk, .iqy, .settingcontent-ms) may receive less thorough analysis. These are niche attack vectors but worth blocking at the transport layer (subsection 9.7, Rule 3).

Files exceeding the size limit. Safe Attachments has a maximum file size for sandbox detonation. Files exceeding this limit are delivered without detonation. The limit varies by configuration — check the current Microsoft documentation for the active limit.

Safe Attachments operational metrics

Track monthly to assess sandbox effectiveness:

Detection volume: Malware attachments blocked per month. A steady baseline with occasional spikes (campaigns) is normal. A sudden drop to zero: either no malware is targeting your organisation (unlikely), or Safe Attachments is not processing email (investigate).

Detonation time: How long between email arrival and sandbox verdict. The monitoring query from this subsection provides this data indirectly (emails with Dynamic Delivery show a delay). Target: under 2 minutes for 95% of attachments. If slower: consider whether your Safe Attachments policy is scanning too broadly (all attachments vs targeted file types).

File type distribution: What types of malicious files are being caught?

1
2
3
4
5
6
7
8

// Malicious attachment analysis: what file types are attackers using?
EmailAttachmentInfo
| where TimeGenerated > ago(90d)
| where ThreatTypes has "Malware"
| extend FileExtension = tostring(split(FileName, ".")[-1])
| summarize Count = count() by FileExtension
| order by Count desc
| take 10

This shows which file types your organisation is being targeted with. If .docm (macro-enabled Word) dominates: your transport rule should block .docm unless specifically needed. If .html or .htm appears frequently: attackers are using HTML smuggling — a technique where the HTML file contains embedded JavaScript that assembles a malicious payload in the browser.

Safe Attachments and the investigation timeline

During an incident investigation (Modules 12-16), the Safe Attachments verdict appears in EmailAttachmentInfo. This tells you:

Was the attachment caught or missed? If ThreatTypes shows “Malware”: the sandbox detected the threat but the email may still have been delivered (depending on the mode — Monitor mode logs but does not block).

What was the detonation result? The sandbox analysis details provide: the file hash (for IOC matching), the observed behaviour (network connections, registry modifications, process creation), and the classification.

1
2
3
4
5

// Investigation: attachment analysis for a specific email
EmailAttachmentInfo
| where NetworkMessageId == "MESSAGE-ID-FROM-INVESTIGATION"
| project FileName, FileSize, FileType, ThreatTypes, ThreatNames,
    SHA256 = tostring(parse_json(tostring(AdditionalFields)).SHA256)

The SHA256 hash is critical for: cross-referencing with endpoint detections (did any device execute this hash?), checking against threat intelligence (VirusTotal, MITRE), and creating file-based detection rules in Defender for Endpoint.

Safe Attachments exception management

Not every attachment needs sandboxing. Some legitimate automated systems send attachments that trigger false positives or cause unnecessary processing delays.

Common exception scenarios:

Automated report systems that send PDF reports hourly (ERP, BI tools). These are high-volume, known-benign senders. Exception: create a Safe Attachments policy exception for the specific sender address (e.g., reports@erp.northgateeng.com).

Scanned document systems that send image-heavy PDFs (multifunction printers that scan-to-email). These are internal senders whose output triggers extended detonation times. Exception: bypass scanning for the printer’s sender address.

Partner data feeds that send CSV or XML files on a schedule. These fail detonation (the sandbox cannot meaningfully analyse CSV files) and add processing delay without security benefit. Exception: bypass for the specific sender and file type combination.

How to create exceptions: Defender → Policies → Safe Attachments → create a new policy (higher priority than default) with condition “The sender is [address]” and action “Off” (disable scanning for this sender). Document each exception with: the business justification, the risk assessment (what threats would be missed), the review date (quarterly), and the approver.

Exception governance: Every exception is a hole in the protection stack. Review exceptions quarterly. If the automated system changes (new sender address, new file types): update the exception. If the system is decommissioned: remove the exception. Maintain a register: sender, exception type, date created, justification, next review date.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Monitor attachment volume by sender — identify candidates for exceptions
// (high-volume, low-threat senders that generate scanning load)
EmailAttachmentInfo
| where TimeGenerated > ago(30d)
| join kind=inner (
    EmailEvents | project NetworkMessageId, SenderFromAddress
) on NetworkMessageId
| where ThreatTypes == "" or isempty(ThreatTypes)  // Clean attachments only
| summarize AttachmentCount = count() by SenderFromAddress
| where AttachmentCount > 100
| order by AttachmentCount desc

High-volume senders with zero malicious detections in 30 days are strong candidates for scanning exceptions — they generate processing load without security benefit.