safe links failed to rewrite data-uri redirect inside pdf attachment
Covers Safe Links failing to rewrite a data-URI style redirect hidden in a PDF attachment, treating in-document links as attachments to detonate rather than body links to rewrite. Use when a PDF carries an embedded redirect the mail rewriter missed. Not for normal web links in a PDF that your sandbox already extracts.
TL;DR
Rewriters process message body links. A link buried in a PDF, especially one built through a data URI or script action, belongs to the attachment pipeline, and if the sandbox does not extract and follow document links, it passes silently. The control point is Safe Attachments detonation with document link extraction, plus policy that treats external PDFs with embedded actions as scannable content.
safe links failed to rewrite data-uri redirect inside pdf attachmentUse this when
- A phishing PDF was delivered and its internal link or action never appears in mail scanning logs.
- The sandbox report on the PDF lists no extracted URLs.
Not for this skill when
- The PDF link is a plain annotation link your sandbox already extracts and scores. Then the issue is the verdict, not extraction.
- The redirect is in the HTML body disguised as text. That is a body rewriting case.
Steps
- Open the sample in a document analysis tool and extract all links, actions and embedded URIs without executing them. Verify: the hidden redirect target is recovered.
- Submit the PDF to the sandbox and read whether its engine extracts document URLs at all. Verify: extraction capability for PDFs is proven by test.
- Enable document link extraction and detonation for attachments if your platform offers it, and include PDFs in the detonate file types. Verify: PDFs are in scope for the affected users.
- Block the extracted target URL in the tenant list and purge other copies of the message. Verify: the campaign URL is blocked and copies removed.
- Re-send the sample through mail flow in a test mailbox. Verify: the PDF is detonated and its link is reported or the message is quarantined.
Variant phrasings
pdf attachment embedded link not scanned phishing
The embedded link variant.
data uri redirect inside pdf safe attachments extraction
The technique variant.
Compatibility: Safe Attachments document analysis, gateway PDF link extraction features. Note: avoid writing the data URI scheme literally in tickets shared externally.
Why it happens
A PDF is a container of actions, not a static page. Rewriters that scan message text never see inside it, and attackers moved lures into documents precisely because that seam between body scanning and attachment scanning exists in many tenants.
Edge cases / pitfalls
- JavaScript actions in PDFs are rare in legitimate business documents. Flagging them is low-noise.
- Flattening or stripping active content from inbound PDFs is a strong compensating control some tenants adopt.
- Keep the analysis copy of the PDF; its internal indicators age better than the sending domain.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst6Ihwq9qaxabMqbF73qO0Q