Unmasking QRishing: from convenience to concern

Status: presented at the 3rd ICAICCIT 2025 international conference, co-sponsored by the IEEE Delhi Section. Part of my QR-code security research line and a direct cousin of the QR-analysis module in my AI Threat Detection platform. Full venue details, DOI, and the paper PDF land here once I pull them from my vault.

Quick Response codes were designed for one thing: to make the gap between "see a thing" and "go somewhere" disappear. That convenience is also the attack surface.

The problem

A QR code hides its destination. By the time a user sees the URL it encodes, they've already pointed a camera at it and — usually — decided to trust it. That inverted trust model is what QRishing exploits:

QRishing (QR phishing) — a QR code is swapped onto a poster, menu, parking meter, or package to deliver a phishing link
Malicious encoding — QR payloads carrying malicious URLs, malware download links, or Wi-Fi/credentials payloads that execute on scan
Session/identity attacks — codes that drive users through an attacker or proxy (the QRLJacking family), hijacking an already-authenticated session or harvesting credentials in transit

The uncomfortable part is that most traditional phishing defenses never see the attack. Email gateways scan links in messages; they don't scan the paper menu in a restaurant. QR codes sit exactly in that blind spot — out-of-band, off-network, and visually indistinguishable from a legitimate one.

What the paper does

The research analyzes QRishing as a full attack chain rather than a list of symptoms:

Attack-vector analysis — where QR codes get abused (physical substitution, digital embedding, email attachments, and the print-photo-upload relay where a screenshot of a code keeps its payload)
Detection proposal — an ML-based classification approach for QR payloads: decoded content and destination metadata become the features, rather than trusting the human to pre-verify anything
Mitigation & defense — defensive measures for QR-code exploitation, spanning technical controls and user-side behavior

Why ML, not just blocklists

A blocklist of known-bad QR destinations fails the same way it always does: attackers register fresh domains faster than anyone can list them. The proposal treats each scanned code as a sample — decoded text, expanded URL, destination reputation signals, and structural features of the payload — and lets a model separate the malicious tail from the long, legitimate tail of QR usage, with a risk signal shown before the browser opens.

The companion engineering work lives in the AI Threat Detection & Security Operations platform, where QR images are decoded and validated against VirusTotal, Google Safe Browsing, and PhishTank before the LLM reasons over the context — the same "decode, score, then act" flow the paper argues for.

Defense, summarized

Decode-then-inspect: never let a QR code open a destination directly — expand shortened URLs and reputation-check the landing domain first
Detect at the scan point: ML risk scoring on the payload + destination as the code is scanned, not after the damage
Harden the medium: signed/provenance-tracked QR issuance for organizations, tamper-evident placement, and monitoring for substituted codes
User-side measures: scan with a viewer that previews the URL, and treat unsolicited codes (sticker-over-sticker, unexpected packages) as suspicious

Status & next steps

Presented at ICAICCIT 2025. Once I recover the full paper from the vault, I'll expand this with the evaluation setup, results, and the exact defensive framework — and link the published proceedings entry and DOI.