QR Phishing (Quishing): How to Inspect Unknown QR Codes Safely

When an attacker embeds a 300x300 PNG QR matrix inside a PDF attachment titled M365_MFA_Reauthentication_Required.pdf, text-based email link scanners inspect zero URLs. The PDF contains no clickable /URI annotation dictionary and no HTML <a href> tag—only a compressed /FlateDecode raster image stream. Seconds later, the recipient points a personal smartphone at their laptop monitor, shifting execution off a corporate EDR-protected workstation onto an unmanaged mobile browser over 5G cellular data.

Checking an unknown QR code safely requires breaking that cross-device execution loop. Scanning an untrusted matrix with a native smartphone camera truncates the preview banner to roughly 30 characters while hiding Punycode homographs, open-redirect parameters, and non-HTTP protocol triggers. Conversely, uploading a screenshot of a suspicious corporate email to a cloud-based QR decoder website leaks confidential documents to third-party servers and risks triggering server-side URL prefetchers that detonate your unique victim tracking token.

Why Quishing Bypasses Enterprise Secure Email Gateways (SEGs)

Conventional phishing controls assume a malicious hyperlink exists as parseable text inside the MIME body or PDF object tree, and that the click will originate from the managed endpoint receiving the message. Quishing (QR code phishing) breaks both assumptions at once.

Attackers embed QR lures inside workflows where cross-device scanning already feels mandatory: Microsoft Entra ID / 365 Authenticator re-authentication notices, fake DocuSign or Adobe Sign envelopes, HR payroll direct-deposit updates, and overdue vendor invoices. To evade optical character recognition and gateway image heuristics, campaigns exploit ISO/IEC 18004 Reed-Solomon error correction (which tolerates up to 30% symbol damage at Level H) by splitting QR modules across HTML table cells, inverting foreground contrast, or burying rasterized matrices inside multi-page PDF attachments.

flowchart TD
  subgraph Bypass["Cross-Device Quishing Attack Path"]
    A["Phishing PDF with Raster QR PNG"] --> B["Corporate SEG (No Text URL Found)"]
    B --> C["Managed Laptop Screen"]
    C -->|"Optical Air-Gap Pivot"| D["Personal Phone Camera on 5G"]
    D --> E["AiTM Proxy Captures Session Cookie"]
  end

  subgraph Safe["Zero-Upload Local Triage Workflow"]
    C -->|"Clipboard Screenshot (Cmd+V)"| F["Local Browser RAM Decode (0 Bytes Sent)"]
    F --> G["Raw URI & Query String Inspection"]
    G --> H["Block Malicious Host Without Detonating Token"]
  end

Once delivered, the optical pivot from laptop screen to personal phone bypasses three enterprise controls:

1. Zero Corporate DNS or SWG Visibility: A personal phone on carrier 5G bypasses the corporate Secure Web Gateway (SWG), split-horizon DNS blocklists, and TLS inspection.
2. Missing Desktop Passkeys and Password-Manager Guards: Managed desktop browsers enforce hardware-bound FIDO2 credentials, device certificates, and password-manager origin matching. On an unmanaged mobile browser, victims type passwords manually and approve MFA prompts against Adversary-in-the-Middle (AiTM) proxies like Evilginx.
3. No Time-of-Click URL Rewriting: Enterprise link wrappers (Safe Links or URL Defense) sandbox text URLs on click. Raster QR images inside PDFs are never rewritten, routing straight to attacker infrastructure.

Four Non-Obvious QR Attack Payloads Beyond Basic Phishing Links

Treating QR codes strictly as containers for https:// web links leaves major blind spots during inspection. Under ISO/IEC 18004, a Version 40-L symbol encodes up to 2,953 bytes of arbitrary 8-bit data, and mobile OS camera apps automatically dispatch system intent handlers across multiple non-HTTP URI schemes.

1. Truncated Camera Banners, IDN Punycode Homographs, and Open Redirects

Native iOS and Android camera viewfinder banners prioritize compact UI chrome over forensic visibility. Mobile overlays typically display only the domain label or truncate strings beyond 25 to 35 characters—concealing the path, port, and query string.

Attackers weaponize this narrow banner using three techniques:

• IDN Homograph Spoofing (RFC 5891): Replacing the second Latin o (U+006F) in microsoft with Cyrillic о (U+043E) yields ASCII Punycode login.xn--micrsoft-qbh.com, which renders identically to login.micrоsoft.com in Unicode overlays.
• Subdomain Padding: Encoding https://login.microsoftonline.com.sso-reauth-portal.net/oauth2/v2.0/authorize pushes the registered domain (sso-reauth-portal.net) outside the camera notification pill.
• Open Redirects and Opaque Shorteners: Attackers chain cloud redirectors or shorteners ahead of AiTM pages. Because marketing teams also print third-party tracking domains on collateral—a lock-in hazard covered in static vs. dynamic QR codes and the free-trial redirect trap—users routinely tap unfamiliar short-link hosts without seeing the final destination.

2. Malicious WIFI: Evil-Twin Auto-Join Payloads

Both iOS and Android natively parse the ZXing WIFI: URI specification from the camera app, presenting a one-tap system prompt to join the encoded wireless network:

WIFI:S:Airport_Free_5G;T:WPA;P:GuestAccess2026;H:false;;

In lounges, hotels, conferences, and cafés, attackers place rogue WIFI: QR placards advertising a “5G Guest” SSID backed by an evil-twin access point. Because the WPA pre-shared key (P:) and hidden-network flag (H:) are embedded directly in the matrix, tapping Join associates the phone immediately—exposing the device to captive-portal credential harvesting and rogue DHCP/DNS spoofing.

3. Pre-Filled SMSTO:, mailto:, and tel: Social-Engineering Triggers

Non-HTTP messaging and telephony schemes abuse the victim’s own authenticated phone number or mail client by pre-populating recipients and command text:

SMSTO:+18005550199:CONFIRM WIRE BATCH 8841 AUTH-OK
mailto:helpdesk-reset@corp-verify-sso.example?subject=MFA%20Reset&body=Approve%20enrollment%20ID%3A%2099412
tel:+18885550142,,4019#

• SMSTO: / sms: Payloads: Open the native SMS app addressed to attacker-controlled numbers, SIM-swap social engineering lines, or automated SMS reply workflows requiring only a tap on Send.
• mailto: Payloads (RFC 6068): Draft pre-filled emails from the victim’s real SPF/DKIM-authenticated address to trigger helpdesk resets or fraudulent vendor approvals.
• tel: Payloads with DTMF Pauses (RFC 3966): Dial fake bank fraud desks while appending , (2-second pause) DTMF tones to dial extensions automatically upon connection.

4. Physical Sticker-Overlay Attacks on Public Payment Infrastructure

On municipal parking meters, Level 2 and DC fast EV chargers, and restaurant table tents, attackers stick weatherproof vinyl QR decals (25 mm x 25 mm to 40 mm x 40 mm at 300 DPI) directly over legitimate operator codes. Because drivers standing in outdoor glare expect to enter payment card details on an unfamiliar municipal billing portal, unverified physical QR overlays routinely capture full card numbers, CVVs, and recurring authorization charges of $35 to $250 before the driver notices the meter session never activated.

The Privacy Paradox of Cloud-Based Online QR Decoders

When employees suspect a PDF invoice or MFA notice hides a quishing lure, many screenshot the document on their laptop and upload it to a free “online QR decoder” website to avoid scanning it with their phone.

If that decoder uploads files to a remote backend server, triage creates two new security liabilities:

1. Confidential Document Leakage: Cropped email screenshots frequently capture invoice totals, contract terms, or wire instructions. Sending that image via multipart/form-data POST to an unvetted server creates the third-party storage, log retention, and GDPR Article 28 / NDA risks detailed in why uploading contracts to free online PDF editors is a security risk.
2. Server-Side Prefetching & Victim Token Detonation: Cloud QR sites often fetch decoded URLs from backend servers to scrape <title> previews. Targeted quishing URLs embed per-recipient tokens like ?state=c2FsZXNAdXRpbGlvbWUuY29t (Base64 for sales@utiliome.com). Any server-side GET request detonates that token, confirming to the attacker that your mailbox is active.

A Safe 3-Step Local QR Inspection Workflow

Keep the entire QR decode and URI parsing pipeline inside local workstation memory so zero image bytes leave your machine and zero network requests touch the attacker’s server.

Step 1: Decode the Screenshot Locally via Clipboard Paste (0 Bytes Uploaded)

Capture a region screenshot directly to your system clipboard (Ctrl+Cmd+Shift+4 on macOS, Win+Shift+S on Windows, or PrtScn on Linux) without even writing a temporary file to disk. Open Utiliome’s Private In-Browser QR Scanner and press Cmd+V (Ctrl+V) or drag-and-drop the screenshot onto the dropzone.

The widget decodes the clipboard Blob locally via Html5Qrcode.scanFile() inside an offscreen HTML5 <canvas> in browser RAM, then classifies the payload with detectQrPayload. Zero bytes are uploaded—which you can confirm by checking your browser DevTools Network tab (F12) for zero outbound Fetch/XHR traffic. Rather than auto-navigating, the scanner displays the detected protocol badge (url, wifi, sms, email, phone, vcard, event, whatsapp, geo, or crypto) alongside the full, unedited Raw Decoded Content string.

Step 2: Deconstruct Redirect Chains, Homographs, and Tracking Tokens

Whenever the decoded payload is an HTTP/HTTPS URL, copy the raw text into Utiliome’s client-side URL Parser to split the RFC 3986 components without visiting the site:

• Hostname: Isolate the true registered domain immediately before the first / path separator, checking for xn-- Punycode prefixes and deceptive subdomain padding.
• Pathname & Port: Spot non-standard ports (:8443, :2096) and brand names stuffed into path segments (/microsoft.com/oauth2/).
• Query Parameters: Audit every parsed parameter row for open-redirect targets (redirect_uri, url, next, returnTo) and Base64-encoded victim identifiers (state, uid, token). For programmatic decoding techniques and RFC 3986 edge cases, see our guide on how to read URL query strings and parameters programmatically.

Step 3: Air-Gapped Terminal Triage for SOC Analysts (zbarimg + Python)

For command-line triage inside an isolated VM or macOS/Linux terminal, install zbar (brew install zbar or apt install zbar-tools) and pipe zbarimg --quiet --raw directly into Python’s built-in urllib.parse and idna codecs. This extracts the raw matrix, exposes IDN homographs, and decodes Base64 victim tokens offline with zero external sockets:

zbarimg --quiet --raw suspicious-invoice-qr.png | python3 -c '
import sys, base64
from urllib.parse import urlsplit, parse_qsl

raw = sys.stdin.read().strip()
parts = urlsplit(raw)
host = parts.hostname or ""
puny_host = host.encode("idna").decode("ascii") if host else ""
unicode_host = puny_host.encode("ascii").decode("idna") if puny_host else ""

print(f"Scheme       : {parts.scheme}")
print(f"ASCII Host   : {puny_host}")
print(f"Unicode Host : {unicode_host} (IDN Homograph: {puny_host != unicode_host})")
print(f"Path         : {parts.path}")

for key, val in parse_qsl(parts.query, keep_blank_values=True):
    print(f"Param [{key}] : {val}")
    if key in ("state", "uid", "token"):
        try:
            decoded = base64.b64decode(val, validate=True).decode("utf-8")
            print(f"  -> Base64  : {decoded}")
        except Exception:
            pass
'

Executing this one-liner against a homograph quishing PNG exposes both the spoofed domain and targeted recipient immediately:

Scheme       : https
ASCII Host   : login.xn--micrsoft-qbh.com
Unicode Host : login.micrоsoft.com (IDN Homograph: True)
Path         : /oauth2/v2.0/authorize
Param [redirect_uri] : https://auth-m365-verify.example/session
Param [state] : c2FsZXNAdXRpbGlvbWUuY29t
  -> Base64  : sales@utiliome.com

In Python environments where zbarimg is absent but opencv-python is available, cv2.QRCodeDetector().detectAndDecode(cv2.imread("suspicious-invoice-qr.png"))[0] performs the same local matrix extraction in pure Python.

Distributing Official Dynamic QR Campaigns Transparently

When your own organization needs to publish legitimate dynamic QR codes with scan analytics and post-print destination control—without relying on opaque ad-network URL shorteners that train users into risky habits—manage them through a dedicated platform like QR Build (qr-build.com) (from the creators of Utiliome) or route static codes through your own first-party domain.

Pre-Flight Verification Checklist Before Trusting Any QR Code

Run through this 6-point verification checklist before acting on any QR code in an attachment, email, or public terminal:

1. Reject Unsolicited MFA Enrollment PDFs: Enterprise identity providers (Microsoft Entra ID, Okta, Google Workspace) only generate authenticator QR codes inside an active, user-initiated security settings session—never inside an emailed PDF attachment demanding an “MFA re-sync.”
2. Decode Locally via Clipboard First: Screenshot digital QR codes and paste them into the Private In-Browser QR Scanner or zbarimg --quiet --raw instead of scanning your monitor with a personal phone on 5G.
3. Check the Leading URI Scheme: Verify that the raw payload begins with https:// rather than action-triggering schemes like WIFI:, SMSTO:, sms:, mailto:, or tel:.
4. Isolate the Registered Domain and Punycode Form: Paste URLs into a URL Parser to separate the real Hostname from subdomain padding and reveal xn-- homograph labels.
5. Audit Query Strings Without Detonating Tokens: Inspect redirect_uri, next, and url parameters for secondary phishing hosts, and never submit personalized Base64 tracking tokens to cloud link expanders.
6. Check Physical Signage for Raised Sticker Edges: On parking meters, EV chargers, and table tents, run a fingernail across the QR border to detect vinyl overlay decals and verify that the decoded hostname matches the permanent signage.