suspicious url rewrite failed on blob storage link

Not specified by the original author.

TL;DR

Blob storage links look like ordinary HTTPS links, but some rewrite policies exclude cloud storage domains, or the URL is wrapped in a sharing format the rewriter does not parse. The result is an unscanned path straight to hosted phish or malware. Find the exclusion or parsing gap, remove broad cloud storage exemptions, and rely on detonation of the target file instead of trust in the hosting brand.

suspicious url rewrite failed on blob storage link

Use this when

• Mail links to public blob storage arrive unrewritten and unscanned.
• A phish hosted on a major cloud storage service was delivered clean.

Not for this skill when

• The storage link is your own tenant storage with access controls. Internal sharing policy differs.
• The rewriter fails on all links, not just storage. That is a global Safe Links fault.

Steps

1. Take a delivered storage link and check the raw message to see whether rewriting was applied or skipped. Verify: skipped rewriting is confirmed in the raw HTML.
2. Review the rewrite policy exclusions and do-not-rewrite lists for storage domains added for convenience. Verify: any storage exclusion is named with its reason.
3. Check whether the sharing URL format, such as a pre-signed or tokenised link, is one your rewriter supports, using vendor documentation and a test send. Verify: format support is established by test.
4. Remove broad storage domain exclusions and instead exclude only specific trusted internal storage accounts. Verify: external storage links are now rewritten.
5. Send a test storage link to a harmless hosted file and click through. Verify: the link is rewritten and the target is scanned at click time.

Variant phrasings

safe links do not rewrite cloud storage urls

The exclusion variant.

phishing hosted on blob storage bypass mail scanning

The abuse variant.

Compatibility: Defender Safe Links policies and do-not-rewrite lists, comparable gateway rewrite exclusions.

Why it happens

Attackers host on reputable cloud storage precisely because tenants exempt it to make internal sharing work smoothly. The exemption generalises from our storage to all storage, and the brand of the host says nothing about the tenant who uploaded the file.

Edge cases / pitfalls

• Pre-signed storage URLs expire, which also defeats later investigation. Capture the target file at triage time.
• Detonation of linked files depends on size and type limits. Know your platform caps for storage links.
• Prefer rewriting with detonation over blocking storage domains, which breaks legitimate vendor sharing.

Provenance

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

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

Thread query: suspicious url rewrite failed on blob storage link

TL;DR: Blob storage links look like ordinary HTTPS links, but some rewrite policies exclude cloud storage domains, or the URL is wrapped in a sharing format the rewriter does not parse. The result is an unscanned path straight to hosted phish or malware. Find the exclusion or parsing gap, remove broad cloud storage exemptions, and rely on detonation of the target file instead of trust in the hosting brand.