phish bypassed filter and attachment sandbox rule failed to trigger
Investigates a phish that bypassed the filter and never triggered the attachment sandbox, checking policy scope, file type coverage and detonation triggers. Use when a malicious attachment was delivered without sandbox analysis. Not for attachments the sandbox analysed and wrongly judged clean.
TL;DR
A sandbox that never triggers is a coverage problem, not a verdict problem. Check in order: was the recipient in the policy scope, was the file type set to detonate, did the message take a path that skips scanning such as an internal connector, and did size or encryption exempt it. Message trace plus policy assignment usually answers it without guessing.
phish bypassed filter and attachment sandbox rule failed to triggerUse this when
- A user received a malicious attachment and no sandbox record exists for it.
- Detonation logs show no entry for a campaign that reached inboxes.
Not for this skill when
- The sandbox detonated the file and returned clean. That is a detection miss inside the sandbox, a different investigation.
- The phish had no attachment. URL-only phish needs link analysis, not attachment policy.
Steps
- Get the message trace and confirm the exact attachment name, type and size as delivered. Verify: the file as received is characterised.
- Open the Safe Attachments or sandbox policy applied to that recipient and confirm the file type and action are enabled for their group. Verify: policy scope covers this user and file type.
- Check for bypass paths: trusted connectors, internal mail routing, or an allow entry that skipped scanning for the sender. Verify: any bypass on this message path is identified.
- Submit the same file manually to the sandbox and watch it detonate. Verify: the sandbox itself accepts and analyses this file type.
- Close the gap found, then re-test with a harmless test file of the same type through the same path. Verify: a detonation record is created before delivery.
Variant phrasings
safe attachments policy not applying to user
The policy scope variant in Defender terms.
malicious attachment delivered without detonation
The incident phrasing variant.
Compatibility: Microsoft Defender for Office 365 Safe Attachments and comparable gateway sandboxes such as Proofpoint and Mimecast.
Why it happens
Sandboxing is policy-driven: only messages matching scope, type and routing conditions are held for detonation. Attackers probe for the seams, and mis-scoped policies create them accidentally.
Edge cases / pitfalls
- Password-protected and oversized files are common silent exemptions. Log exemptions explicitly.
- Turn on the option to deliver only after detonation completes for high-risk groups; dynamic delivery changes the risk during analysis.
- Keep the original message and headers for the investigation before releasing or deleting anything from quarantine.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_iuNix3FIQzGsGEOX7Xgsmg