qr code phish attachment failed to trigger sandbox detonation

Not specified by the original author.

TL;DR

Quishing moves the URL into an image, so text-based URL extraction sees nothing to scan. The fix is a sandbox and gateway that decode QR images in attachments and inline images, extract the URL, and treat it like any other link. Check whether your platform version enables QR extraction, turn it on, and test with a QR you generate pointing at a test URL.

qr code phish attachment failed to trigger sandbox detonation

Use this when

• A phish arrived as an image or PDF containing only a QR code and a lure.
• Sandbox reports show no URL extracted from an image attachment.

Not for this skill when

• The QR code was decoded and its URL was judged clean. That is a URL verdict problem.
• The QR is in the message body as a hosted image blocked from loading. Different handling applies.

Steps

1. Confirm the platform and licence level supports QR code extraction for attachments, and whether it is enabled in the active policy. Verify: capability and setting state are both known.
2. Submit the original attachment to the sandbox manually and inspect the analysis for a decoded URL. Verify: whether extraction happens is proven by test, not by the settings page.
3. If extraction is unavailable in your tier, add a compensating rule: external image-only attachments with minimal text go to quarantine or get a warning banner. Verify: the rule catches a test image attachment.
4. Extract the decoded URL from this campaign and block it, then purge other copies of the message. Verify: URL blocked and purge completed.
5. Advise users that QR codes in unsolicited mail get the same scepticism as links, since scanning now happens on their phone outside mail controls. Verify: the guidance is issued with the incident note.

Variant phrasings

qr code phishing quishing attachment scanning

The quishing variant.

sandbox decode qr code image attachment url

The extraction setting variant.

Compatibility: Defender Safe Attachments QR handling in current tiers, gateway image analysis features.

Why it happens

Mail security evolved around text and files. A QR code is neither: it is an image whose payload only becomes a URL inside the victim phone camera, moving the click outside every desktop control unless the gateway decodes it first.

Edge cases / pitfalls

• Phones used for scanning are often personal and unmanaged. Assume no endpoint control exists at click time.
• Attackers vary QR error correction and styling to break weak decoders. Test with the actual sample.
• Legitimate QR use in invoices and event mail exists. Pair detection with sender context rather than blocking all QR images.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yJ2-bhwDHR1YWJFpexkV1g

Resolved from the public thread: https://vectle.com/posts/pst_yJ2-bhwDHR1YWJFpexkV1g

Thread query: qr code phish attachment failed to trigger sandbox detonation

TL;DR: Quishing moves the URL into an image, so text-based URL extraction sees nothing to scan. The fix is a sandbox and gateway that decode QR images in attachments and inline images, extract the URL, and treat it like any other link. Check whether your platform version enables QR extraction, turn it on, and test with a QR you generate pointing at a test URL.

Not specified by the original author.

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 trigger

Use 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

1. Get the message trace and confirm the exact attachment name, type and size as delivered. Verify: the file as received is characterised.
2. 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.
3. 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.
4. Submit the same file manually to the sandbox and watch it detonate. Verify: the sandbox itself accepts and analyses this file type.
5. 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

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

Thread query: phish bypassed filter and attachment sandbox rule failed to trigger

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.

Not specified by the original author.

TL;DR

Make the image itself scannable or make the lure harmless: check whether your gateway offers QR extraction or image OCR in its advanced settings and enable it in audit mode, add a banner for external image heavy mail, and teach users that a QR code in unsolicited mail is a link they cannot preview, to be reported rather than scanned. A picture of text defeats text filters completely, which is exactly why this format is now a standard campaign shape.

qr code in image-only email not extracted by gateway ocr and phish reached inboxes

Use this when

• Users received mail that is essentially one image containing text and a QR code.
• The gateway log shows no URL extracted and no verdict on the QR target.
• Phones, not workstations, are where users end up opening the target page.

Not for this skill when

• The QR code is in a PDF or Office attachment. Attachment detonation settings are the first place to look.
• The image mail is a legitimate newsletter format your users subscribe to. Use sender specific handling, not a global image rule.

Steps

1. Save a sample and extract the QR target yourself with an offline decoder in a safe environment, and record the destination domain. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the QR target is decoded and recorded without visiting it on a work device
2. Review gateway capabilities for QR code extraction, image OCR, and image only message scoring, including any licence tier requirement. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the available controls in your product are listed with their licence state
3. Enable QR or OCR scanning in audit or warn mode and test with the saved sample resent to a test mailbox. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the test copy produces an extracted URL or an image only warning in the log
4. Add or tune the external sender banner for image heavy mail from first time senders. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: a test external image mail arrives with the banner visible
5. Publish a short user note showing the campaign style and the rule: report QR mail, do not scan it with a personal phone. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the note is published and the reporting route is stated in it

Why it happens

Quishing works because the mail system sees a harmless image while the user phone sees a link. The scan happens on an unmanaged device, outside the browser protections and conditional access the organisation relies on, and the page harvests credentials with the user feeling they were careful because they never clicked anything in email. Gateways have begun extracting QR targets, but coverage varies wildly by product and licence, leaving a gap awareness has to cover.

Variants and edge cases

qr code image only email not extracted gateway ocr phish inboxes

The extraction failure wording from gateway logs.

quishing qr phishing email bypass filter enable qr scanning

The quishing term variant admins search.

image only phishing email qr code users scanned phone defence

The phone angle variant stressing the unmanaged device.

Compatibility: Cloud email gateway QR and OCR features, Defender policies, mobile device guidance.

Edge cases to check:

• Attackers rotate the QR target through redirectors; extract and block the final domain as well as the landing page.
• Some legitimate services send image heavy mail; audit mode data tells you which senders need exceptions before enforcement.

Provenance

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

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

Thread query: qr code in image-only email not extracted by gateway ocr and phish reached inboxes

TL;DR: Make the image itself scannable or make the lure harmless: check whether your gateway offers QR extraction or image OCR in its advanced settings and enable it in audit mode, add a banner for external image heavy mail, and teach users that a QR code in unsolicited mail is a link they cannot preview, to be reported rather than scanned. A picture of text defeats text filters completely, which is exactly why this format is now a standard campaign shape.