Nested QR Codes: How Quishing Is Beating Email Gateway Scanners

Most gateway QR handling today follows the same shape: an image classifier flags a likely QR symbol in the message, an optical decoder (typically a standard library such as ZXing or ZBar under the hood) attempts a single decode pass, and if it returns a URL, that URL is submitted to the same reputation and sandboxing pipeline used for text-based hyperlinks. This closed the original quishing gap, where the failure mode was simply never attempting a decode at all.

Nested and split QR codes attack the decode step itself, not the reputation step downstream.

Nested QR codes place a second, functional QR code inside or overlapping the finder patterns of a first QR code in the same image. Barracuda's research describes the outer code resolving to a malicious URL while an inner code resolves to something legitimate, such as a Google URL. A single-pass decoder scanning left to right or center-out returns whichever symbol its algorithm locks onto first. That produces one of three outcomes for the gateway: it decodes the benign code and clears the message, it decodes the malicious code and (if reputation checks the URL correctly) catches it, or it detects two overlapping/conflicting symbol patterns, fails to get a clean read, and passes the image through as undecodable rather than blocking on an inconclusive result. Attackers are optimizing for the first and third outcomes. A human eye and a phone camera app, by contrast, tend to resolve the more visually dominant or better-aligned code, which is the one the attacker controls.

Split QR codes take a different route to the same result. The Gabagool kit divides one complete QR payload across two separate image files placed side by side or stacked in the message body, styled as fake Microsoft password reset notifications. Each individual image is a partial, non-decodable QR fragment. Gateways that classify and decode images independently see two images that each fail to produce a valid QR read, so no URL is ever extracted from either one. The full code only reconstructs visually once rendered together in an actual mail client, which is precisely where the human victim, not the gateway, encounters it.

A third, closely related evasion path matters even when the decode step succeeds cleanly: the decoded URL itself can be a legitimate-looking first hop. Attackers increasingly route the QR payload through a URL shortener, a cloud storage share link, an open redirect on a trusted domain, or a CAPTCHA-gated interstitial before the actual credential-harvesting page. If your gateway's reputation check evaluates only the first-hop domain and does not follow the redirect chain, a technically correct decode still clears a malicious campaign because the string it checked was never itself flagged as bad.

Before starting the implementation procedure below, confirm the following. Skipping this check means you are debugging the wrong layer.

• An email security gateway or add-on that already performs QR decoding. This includes Microsoft Defender for Office 365 (Plan 2, Safe Links extended to QR-extracted URLs), Proofpoint Targeted Attack Protection, Mimecast URL Protect, Abnormal Security, or Perception Point. If your gateway does not decode QR images at all, fix that gap first: the techniques in this guide are meaningless against a pipeline with zero QR-decoding capability.
• Confirmed knowledge of what your current QR-scanning logic actually does. Specifically: does it attempt more than one decode pass per image, does it flag images containing multiple overlapping QR-like patterns as suspicious on their own, and does it resolve the decoded URL through any redirect hops before reputation scoring, or only check the literal string extracted from the code. Most vendors do not document this level of detail publicly; get it from your account team or a support ticket, not the marketing page.
• Log access to review what the gateway extracted from a known QR-bearing message, whether from message trace, a security event export, or a SIEM integration, so you can verify results in the validation phase rather than assuming success.
• The ability to add a secondary scanning layer (a sandbox platform, a SOAR playbook, or a secondary vendor product) if your primary gateway's vendor has not yet shipped multi-symbol or redirect-chain handling. Not every gateway can be reconfigured internally to close this gap; some require a compensating layer instead.

Work through these steps in order. Steps 1 through 3 are gateway-native configuration checks; steps 4 through 6 add the compensating detection layer that catches what native decoding still misses.

Configuration changes are worthless until you have proven they change the outcome on an actual nested or split QR sample, not just a plain single-code test message.

Constructing a safe test nested QR code: Generate two valid QR codes with any free QR generator, one encoding a known-benign internal test URL and one encoding a second known-benign URL from a different domain. Overlay them in an image editor so the two symbols visually overlap or share finder-pattern space, approximating the structure Barracuda describes (an outer and inner code in the same graphic). Do not use a live malicious sample from a public threat intel feed for this test; a safe synthetic overlap is sufficient to validate decoder behavior.

Constructing a safe test split QR code: Generate a single QR code encoding a benign test URL, then physically cut or crop the resulting image into two roughly equal fragments and place them as two separate image files in a test email, positioned adjacently as they would render in a mail client.

What to check after sending each test through your pipeline:

• Did the gateway's classifier flag either test image as QR-like content at all, even without a clean decode
• For the nested test, which of the two encoded URLs (if either) appears in the extracted-URL log, and does the log show any indicator that more than one symbol was detected in the image
• For the split test, did the message get held, quarantined, or flagged for the undecodable multi-image pattern, or did it pass through silently
• If you implemented Step 3's redirect-chain following, send a QR code encoding a URL that redirects at least twice before reaching a test landing page, and confirm the final hop, not just the first, drives the reputation verdict
• Repeat the full test set after any vendor policy change or platform update, since decoder behavior for edge cases like this is not guaranteed to be stable across releases

Closing this gap reduces exposure; it does not eliminate the underlying architectural problem, which is that a QR code is fundamentally a rendered image and the ground truth of what it decodes to can depend on decoder implementation, image resolution, and rendering context in ways that are hard to fully standardize.

• Decoder-specific blind spots persist. An attacker who tests their nested or split QR construction against the same open-source decoder libraries commonly used in gateway products (ZXing, ZBar) can iterate until they find a symbol layout that reliably favors the malicious code on that specific library, while still resolving to the malicious code on the far more permissive decoders built into iOS and Android camera apps.
• Rendering-dependent attacks persist even after compositing. If a secondary scanner composites multi-part images at a different resolution, scale, or color depth than the recipient's actual mail client will use, a split QR code tuned for a specific rendering size may still fail to reconstruct correctly in the scanner even though it reconstructs correctly for the human recipient.
• Redirect chains can be time-delayed or geofenced. A redirect chain that resolves to a benign page when crawled by a security vendor's sandbox IP range or immediately after send, but flips to the malicious landing page after a delay or only for requests from residential IP ranges and mobile user agents, defeats redirect-following detonation even when it correctly follows multiple hops. This is a known evasion pattern in broader phishing infrastructure and applies equally to QR-encoded redirect chains.
• Out-of-band delivery bypasses email scanning entirely. None of the controls in this guide apply to a nested or split QR code delivered via a channel your email gateway never touches: a physical sticker, a Teams or Slack message, an SMS image, or a QR code embedded in a PDF hosted on a legitimate but compromised or lookalike third-party site rather than attached to the email itself.
• CAPTCHA and interaction gates block automated follow-through outright. A redirect chain ending in a CAPTCHA challenge or a JavaScript-gated interstitial defeats sandboxed URL crawling regardless of how many hops the sandbox is configured to follow, since the sandbox typically cannot solve the challenge and will either see a blank page or stall before reaching the actual credential harvesting page. This is the same fake-verification pattern covered in ClickFix Detection: Stopping Fake CAPTCHA Malware Delivery, and it applies equally well as a quishing redirect endpoint as it does to malware delivery.

Every control recommended above increases the aggressiveness of image and QR analysis, and that comes with a real false positive cost that should be weighed deliberately rather than deployed blind.

Multi-symbol and overlap detection (Step 2) will flag legitimate compound graphics. Marketing emails, event materials, and vendor communications that legitimately place two QR codes in one graphic (for example, one for iOS and one for Android app store links) will trigger the same signal as a nested malicious code. Start this control in monitor/alert mode rather than automatic quarantine, and build an allowlist for known internal and vendor senders who use this pattern legitimately before enforcing a hard block.

Quarantining undecodable multi-image messages (Step 5) will catch legitimate split-image content. Newsletters, infographics, and design-heavy marketing emails routinely split a single visual across adjacent images for layout reasons unrelated to QR codes. Scope this rule narrowly to image pairs the classifier specifically identifies as partial QR-pattern fragments, not to any message containing multiple small adjacent images, or the false positive volume will overwhelm the SOC queue within days.

Full redirect-chain detonation (Step 3) increases latency and infrastructure cost. Following two to three hops per QR-extracted URL through a detonation sandbox is materially more expensive, in both processing time and licensing cost on consumption-priced sandboxing tiers, than a single reputation lookup. Message delivery delay for legitimate QR-bearing email (event tickets, boarding passes, genuine MFA setup flows) will increase measurably. Set a delivery hold SLA target (most vendors target under two minutes for full detonation) and monitor it, since a control that delays legitimate boarding passes by ten minutes will generate help desk tickets that erode trust in the security team faster than the phishing catch rate builds it.

OCR and image-structure analysis (Step 6) has the highest tuning burden of any control here. Distorted, low-resolution, or stylized QR codes in entirely legitimate contexts (scanned documents, faxed forms, print-to-PDF conversions with compression artifacts) can trigger the same visual-noise heuristics used to flag obfuscated malicious codes. Budget for an explicit tuning period with a human-reviewed sample set before this control moves from alerting to automatic action, and expect to revisit thresholds after any change to your mail client's image rendering or compression pipeline.