QR Code Phishing: How Quishing Works and Why It's Getting Past Email Filters

The quishing problem

Been seeing a consistent uptick in QR code phishing in ThreatWatch feed data over the past few months. Decided to spend this week understanding the evasion mechanics properly rather than just treating it as a volume trend.

The basic attack isn’t new, embed a QR code in an email that links to a credential harvesting page. But the evasion has become much more sophisticated. Barracuda’s threat research team flagged 500,000+ phishing emails with QR codes in PDF attachments in 2024. The PDF wrapper is the first evasion layer: email scanners that would inspect a direct URL in an email body can’t easily extract and analyse a URL encoded in an image embedded in an attached PDF.

How the evasion stack works

Working through the documented techniques:

Layer 1, PDF attachment wrapper. Instead of a QR code directly in the email body (which some scanners now handle), the QR is in a PDF. The PDF appears clean to basic attachment scanners. The user opens it and scans the code with their phone, now they’re on a personal device that’s outside the organisation’s security controls.

Layer 2, QR code obfuscation. By late 2024, several variants emerged:

• Split QR codes: The code is divided across multiple images. Each fragment is individually benign; a human visually assembles them. Automated tools can’t combine and decode them.
• ASCII-based QR codes: Rendered as text characters rather than an image. OCR-based scanning identifies it as text, not a QR code. A phone camera reads it fine.
• Colour-modified QR: Standard QR parsers expect black-on-white patterns. Modified colour schemes defeat some scanners without affecting phone camera decoders.
• Content stream embedding: Drawing the QR code directly in the PDF’s content stream rather than as an embedded image object. Image-based extractors find nothing; a rendering engine displays it normally.

Layer 3, URL obfuscation. Even if the QR is decoded, the URL itself may redirect through legitimate infrastructure:

• Legitimate redirect services (Google, Microsoft, bit.ly) as intermediary hops
• Cloudflare Turnstile or similar CAPTCHAs to block automated crawlers
• Device-conditional redirects: serves benign content to headless browsers, malicious content to mobile user agents

The Sophos team documented this in detail after one of their employees was targeted in June 2024: fake benefits email, PDF attachment, QR code linking through a legitimate Microsoft redirect to a credential harvesting page. The email itself cleared every filter.

Why this is a problem for awareness training

Most phishing simulation platforms, including PhishRig in its current form, test email-based lure detection. You send a simulated phishing email and see who clicks. That doesn’t test the cross-device attack vector at all.

With quishing, the attack happens on the user’s phone after the email has already bypassed filters. The failure mode is different: it’s not “user clicked a suspicious link in email”, it’s “user scanned a QR code in a PDF and didn’t question why a PDF needed them to scan a QR code with their phone.”

I want to add a quishing simulation module to PhishRig. The lure would include a QR code linking to a controlled landing page, and the simulation would track whether users:

1. Open the PDF attachment
2. Scan the QR code
3. Enter credentials on the landing page

Step 3 is what we really care about, and it requires a mobile-accessible landing page with a plausible scenario. I’m going to build this out over the next few weeks alongside the Evilginx integration work.

Notes on CVE-2024-21762

Unrelated to phishing but worth documenting: CVE-2024-21762, the Fortinet FortiOS SSL VPN out-of-bounds write (CVSS 9.8). Unauthenticated RCE, actively exploited since February 2024, Volt Typhoon (Chinese state-sponsored) was in the attribution. The sslvpnd process runs as root, so successful exploitation gives immediate full system access.

I note this because it keeps appearing in ThreatWatch APT feed data as an active initial access vector, months after patches were available. The patch-to-exploitation gap on critical SSL VPN vulns is consistently short (days), but the patch-to-remediation gap is long (months). Network edge appliances are a persistent blind spot in enterprise patching cycles.

---

Next week: getting Evilginx3 running and understanding AiTM mechanics in detail. The quishing module needs a good credential capture backend, and Evilginx is the right tool for that.