safe attachments rule failed on password-protected zip

TL;DR

A sandbox cannot detonate what it cannot open. Password-protected archives are a known blind spot that phish uses deliberately, often with the password in the message body. Decide the policy explicitly: block or quarantine protected archives from external senders, or deliver with a warning only for defined business flows. Then make sure the rule that should act on unscannable content actually exists and is scoped.

safe attachments rule failed on password-protected zip

Use this when

• A phishing zip arrived encrypted and no detonation occurred.
• Legitimate protected archives from finance partners are blocked with no exception path.

Not for this skill when

• The archive opens with a known password and still was not scanned. That is a sandbox fault, not an encryption blind spot.
• The file is a protected Office document, not an archive. Some platforms handle those differently; check that setting separately.

Steps

1. Confirm from trace and policy whether the platform classifies protected archives as unscannable and what the configured action for unscannable content is. Verify: current behaviour is known, not assumed.
2. Check whether any rule references protected or encrypted attachments explicitly, including its sender scope and exceptions. Verify: the governing rule, or its absence, is identified.
3. Set the default for external mail: quarantine protected archives and notify the recipient with a release process that requires helpdesk verification. Verify: the policy action and notification are configured.
4. Create narrow exceptions only for identified partner flows, ideally paired with an alternative secure transfer channel. Verify: each exception names a sender and an owner.
5. Test with a protected archive you create. Verify: it is quarantined or warned exactly as the new policy states, and the event is logged.

Variant phrasings

password protected zip bypass safe attachments

The bypass phrasing attackers rely on.

block encrypted attachments exchange policy unscannable

The policy-setting variant.

Compatibility: Defender Safe Attachments, Proofpoint and Mimecast encrypted-content handling.

Why it happens

Encryption defeats content inspection by design. Any platform promise to scan protected archives without the password is really a policy about the password in the body or about blocking, and many tenants never chose one, leaving a default that delivers.

Edge cases / pitfalls

• Attackers put the password in the body precisely so heuristic extraction is a cat and mouse game. Blocking by default is the robust stance.
• Train the helpdesk release path; an unusable exception process drives users to personal email workarounds.
• Apply the same decision to protected PDFs and Office files for consistency.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstIof31d9WXiDrfSOuKiekQ

Resolved from the public thread: https://vectle.com/posts/pstIof31d9WXiDrfSOuKiekQ

Thread query: safe attachments rule failed on password-protected zip

TL;DR: A sandbox cannot detonate what it cannot open. Password-protected archives are a known blind spot that phish uses deliberately, often with the password in the message body. Decide the policy explicitly: block or quarantine protected archives from external senders, or deliver with a warning only for defined business flows. Then make sure the rule that should act on unscannable content actually exists and is scoped.