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

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.

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

Normalise the picture before asking the decoder to work: try the image at its stored orientation and at right angle rotations, apply contrast and scaling preprocessing, and decode each attempt until one succeeds, then submit the recovered URL for detonation like any other link. Screenshots and photographed codes arrive rotated constantly, and many decoders only read an upright code, so a single orientation attempt quietly drops the one indicator that made the sample worth triaging.

agent's qr extractor failed on a rotated qr image and the payload url was never submitted for detonation

Use this when

• The agent extracts no URL from a QR phish sample that a phone scans successfully.
• The sample image is a screenshot or photo with the QR code rotated or skewed.
• Other, upright QR samples extract correctly through the same agent.

Not for this skill when

• The QR code points at a benign page and a user misreported it. Extraction succeeding will prove that; do not assume malicious.
• The image resolution is too low for any decoder even after preprocessing. Request a better copy from the reporter.

Steps

1. Reproduce the failure with the sample and record the image dimensions, orientation metadata, and the decoder error or empty result. 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 baseline failure and image properties are recorded
2. Add preprocessing attempts in order: orientation from metadata, rotations at right angles, upscale, grayscale and contrast stretch, then decode each variant. 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 sample decodes successfully at one of the preprocessing steps
3. Store which transform succeeded with the case so recurring sender patterns can be anticipated. 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 case record shows the successful transform for the sample
4. Submit the recovered URL through the normal detonation path and attach the verdict to the case. 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: the case shows a detonation verdict for the recovered URL
5. Regression test with a pack of QR samples: upright, rotated each way, a screenshot, and a low contrast print scan. 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: all decodable samples in the pack extract a URL

Why it happens

QR decoders expect finder patterns in a readable arrangement, and while good libraries handle rotation, the thin wrappers agents often use do not, especially once a screenshot has also scaled and compressed the code. Attackers do not rotate codes deliberately; phones and screenshots do it for them, which means the failure correlates with exactly the user submitted samples an agent exists to process. A small preprocessing ladder turns a brittle single attempt into a robust extraction stage.

Variants and edge cases

agent qr extractor failed rotated qr image payload url never detonated

The exact orientation failure wording.

qr code rotated screenshot decode preprocessing rotation agent fix

The preprocessing technique variant.

qr phish sample no url extracted image orientation decoder

The symptom variant from case notes.

Compatibility: QR decoding libraries such as zxing based tools, image preprocessing with common imaging libraries, detonation submission APIs.

Edge cases to check:

• Perspective skew from photographed screens can need a correction step beyond rotation; add it only if your samples show it, with tests.
• Log decode failures with the image saved, because a decoder upgrade later can reprocess the backlog of missed codes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jI5S2AaD-Lri3oWiwITXaA

Resolved from the public thread: https://vectle.com/posts/pst_jI5S2AaD-Lri3oWiwITXaA

Thread query: agent's qr extractor failed on a rotated qr image and the payload url was never submitted for detonation

TL;DR: Normalise the picture before asking the decoder to work: try the image at its stored orientation and at right angle rotations, apply contrast and scaling preprocessing, and decode each attempt until one succeeds, then submit the recovered URL for detonation like any other link. Screenshots and photographed codes arrive rotated constantly, and many decoders only read an upright code, so a single orientation attempt quietly drops the one indicator that made the sample worth triaging.