QR Code Phishing (Quishing) Guide

A QR code hides its destination inside an image, so a phishing link that would be caught as text can pass the email filter, land on an unmanaged phone and capture a corporate login out of sight of most enterprise controls. Quishing (QR code phishing) now turns up in three places: email bodies and attachments aimed at staff, physical stickers on parking meters and payment points aimed at the public, and texts or letters that push people to "scan to pay" or "scan to verify". This guide explains how the attacks work at a high level, why they evade email security and users, the evasion techniques defenders now see, and the layered controls that work: QR decoding at the mail layer, mobile and identity controls, user guidance and reporting. It is written for email security, SOC, identity and awareness teams and anyone who publishes QR codes to customers, and contains no lure examples.

Key takeaways

• The real target is usually a login. Enterprise quishing lures commonly lead to a fake sign-in page, and kits such as Tycoon 2FA work as an adversary-in-the-middle (AiTM) proxy that captures the password, the MFA code and the session, so phishing-resistant authentication matters more than any QR-specific tool.
• The device switch is the attack. Scanning moves the victim from a managed laptop with link rewriting and web filtering to a phone that may have none, which is why the NCSC lists personal phones lacking employer protections as a reason criminals favour QR codes.
• Your email layer must decode images. Check that the product renders images, PDFs and documents, decodes QR codes, and treats the extracted URL like any other link, including detonation and post-delivery removal.
• Attackers already evade naive decoders. Split codes, nested codes and QR codes drawn with text characters are documented in the wild; test your controls with them rather than trusting a datasheet.
• Physical quishing is a fraud and brand problem. If you publish QR codes for payment or parking, design them to be hard to overlay, inspect them, and give people a typed URL or app as the official alternative.

How QR code phishing works

A QR code encodes a short string, usually a URL, that the victim cannot read, so the cues training teaches (a misspelt domain, a mismatched link) are unavailable until after scanning. MITRE ATT&CK for Mobile describes it plainly under T1660 Phishing: "Adversaries may use QR codes (known as "quishing") to redirect users to a phishing website", either by replacing legitimate public codes or by sending codes through SMS or email. In the enterprise matrix the email delivery falls under T1566.001 Spearphishing Attachment or T1566.002 Spearphishing Link, depending on whether the code sits in an attachment or the body.

The FBI warned in January 2022 that criminals tamper with both digital and physical codes to send victims to sites that harvest login and financial details, that a code can lead to malware, and that payment codes can be swapped so funds go to the criminal. The FTC's December 2023 alert describes codes stuck over legitimate ones on parking meters and codes sent by text or email with pretexts such as a failed delivery, an account problem or "suspicious activity" that needs a password change. The NCSC's February 2024 assessment adds balance: QR code fraud is a small share of cyber fraud and mostly happens in open spaces such as stations and car parks, while use in phishing email is growing. Vendor figures give a sense of scale: Microsoft says Defender for Office 365 blocked up to 3 million QR phishing attempts a day at the peak, now about 200,000 a day, and Barracuda reported that about 1 in 20 mailboxes were targeted with QR attacks in the last quarter of 2023. See the Phishing Guide.

Why email filters and users miss it

• No link to inspect: classic email security was built to parse text links. Microsoft's own account of the QR surge says analysing every image in every message was not standard practice, and a message containing little more than an image gives content classifiers few signals.
• No link to rewrite: time-of-click protection works by rewriting URLs or checking them when a supported mail client opens them. Microsoft's Safe Links documentation describes rewriting to a safelinks.protection.outlook.com prefix and client-side checks in Outlook. A URL encoded in pixels is not rewritten, and a phone camera opens it directly, so click-time checks on the corporate client never see it. Only pre-delivery extraction, or protection on the phone itself, can act.
• The click happens elsewhere: the scan happens on a phone, often personal and unenrolled, outside the secure web gateway, browser isolation and endpoint telemetry. The NCSC names this as one of three reasons criminals use QR codes, alongside wariness of links and filters that do not scan images.
• Small screens hide cues: Microsoft notes that "The normal warning signs users might notice on larger screens can often go unnoticed on mobile devices."
• Redirect chains and short-lived pages: the encoded URL is often a redirector or a trusted service, with the phishing page several hops later. Barracuda's 2024 research reported phishing pages built with blob URIs, which are generated in the browser and expire quickly, so URL scanners may not flag them at first.

Evasion techniques defenders now see

Once email products began decoding QR images, kit authors changed how codes are drawn. These techniques come from published vendor research.

Where identity fits: quishing, AiTM and the device switch

Enterprise quishing is mostly credential and session theft with a different delivery wrapper. Microsoft reports lures that impersonate password resets and two-factor verification, and Barracuda links nested codes to Tycoon 2FA, a reverse-proxy kit that relays the real sign-in page and captures the session cookie. See the AiTM Phishing Guide.

• Phishing-resistant authentication: passkeys, FIDO2 security keys and certificate-based authentication bind the credential to the genuine site's origin, so a proxied page cannot obtain a usable assertion. This is the control that makes a successful scan harmless. Note that cross-device passkey sign-in also uses a QR code, but the FIDO hybrid flow requires Bluetooth proximity between phone and computer, which a remote attacker cannot satisfy. See the Passwordless and Passkeys Guide.
• Device-based access policy: require a compliant or managed device (or an app protection policy) for access to mail, files and admin portals, so credentials captured on a personal phone cannot simply be replayed from the attacker's browser. See the Conditional Access Guide.
• Session controls: short sessions for sensitive apps, token protection where available, and fast revocation reduce the value of a stolen cookie. See the Token and Session Security Guide.
• MFA registration as a target: "re-register your authenticator" is a common pretext. Restrict who can register new methods and from where, and alert on new method registrations shortly after a QR email is delivered.

Controls that work, layer by layer

Email layer

• QR extraction everywhere: confirm the product decodes codes in inline images, attached images, PDFs and Office documents, and logs the extracted URL. In Microsoft Defender for Office 365, URLs extracted from QR codes appear in the advanced hunting EmailUrlInfo table with UrlLocation set to "QRCode"; other products expose similar fields.
• Same treatment as any link: extracted URLs should go through reputation, detonation and redirect following, and be covered by post-delivery removal when a verdict changes.
• Short-message heuristics: an external message built around one image or attachment and an MFA, password, payroll or signing pretext deserves a higher score or a warning banner.
• File type policy: block attachment types you do not need, so fewer containers can carry a code. See the Email Security Guide.

Mobile layer

• Protection on the phone: mobile threat defence or a managed browser with web protection gives a second chance after the scan, but only on enrolled devices. ATT&CK lists M1058 Antivirus/Antimalware and M1011 User Guidance as the T1660 mitigations.
• Built-in scanners only: the FBI and NCSC both advise using the phone's built-in camera scanner rather than third-party scanner apps, and never installing an app from a QR code; use the official app store.
• BYOD reality: where personal phones cannot be enrolled, rely on the identity layer instead. See the Mobile Device Security Guide.

Physical and customer-facing codes

• Design against overlays: print codes into the signage or terminal surface rather than on stickers, use a recognisable domain you own, and print the same URL in text beside the code.
• Inspect and respond: add QR checks to routine site inspections, give staff and the public a way to report tampering, and remove overlays quickly.
• Offer an alternative: the FBI advises typing a known URL for payments; make that easy by publishing a short official address and app.
• Monitor lookalike domains registered against your brand, and see the Payment Fraud Guide for payment redirection.

Choosing controls for your organisation

How to implement

1. Baseline: send a set of harmless test messages from an external test domain you control: a QR code in the body, in a PDF, in an Office file, a split code, a nested code and a text-drawn code, each pointing to a benign page you log. Record which were decoded, delivered and logged.
2. Close extraction gaps: enable QR and attachment scanning in each layer, adjust policies for the formats that slipped through, and rerun the test. Start new blocking rules in report-only or quarantine-to-admin mode for two weeks to measure false positives (legitimate QR codes in invoices, event tickets and MFA set-up emails).
3. Harden identity: enforce phishing-resistant MFA for administrators and high-risk roles first, restrict MFA method registration, and add device-based access policy for sensitive apps. Pilot with a small ring, then expand.
4. Enable reporting: make sure the report button works on mobile mail clients, and tell users they can report a QR email without scanning it.
5. Train with realistic simulations: include QR payloads in phishing simulations, as Microsoft recommends, and measure reports as well as scans. See the Security Awareness and Human Risk Management Guide.
6. Build detection: add the hunting queries and alerts in the next section, and link them to your phishing response runbook.
7. Roll back safely: if a new rule quarantines legitimate traffic, release and allow by specific sender and authenticated domain, not by broad allow lists, and record the exception with an expiry.

User guidance and reporting

Keep guidance short and specific. From the FBI, FTC and NCSC advice:

• Treat an unexpected QR code in email as a link you cannot see: do not scan it, especially if it asks you to act urgently or to reset a password or MFA. Report it instead.
• Check the address before opening: the FTC advises "inspect the URL before you open it"; built-in scanners show the destination first.
• Do not sign in or pay from a scanned page: use a bookmark, the official app or a typed address, and check physical codes for a sticker over the original.
• Verify independently: if a message claims to be from a known company or colleague, contact them using details you already hold.

In the UK, suspicious emails can be forwarded to the NCSC's Suspicious Email Reporting Service at [email protected], scam texts to 7726, and fraud reported to Report Fraud (reportfraud.police.uk). In the US, report to the FBI's IC3 at ic3.gov. Internally, a reported QR email should trigger a tenant-wide search and removal. See the Vishing and Smishing Guide for text and phone lures.

Detection and measurement

Signals worth monitoring:

• QR-bearing mail: extracted QR URLs by sender, domain age and redirect depth; spikes in short external messages with a single image or PDF.
• Follow-on sign-ins: for recipients of a QR email, sign-ins in the following hours from a new device, an unfamiliar IP or hosting provider, or a mobile browser the user does not normally use.
• Authentication changes: new MFA method registrations, password resets and new inbox rules shortly after delivery.
• User reports: reports that mention QR codes, and reports from the same campaign across departments.

An illustrative Microsoft Defender XDR hunting query that lists recent QR-extracted URLs with their recipients:

EmailUrlInfo
| where Timestamp > ago(7d) and UrlLocation == "QRCode"
| join kind=inner (EmailEvents | project NetworkMessageId, RecipientEmailAddress, SenderFromAddress, Subject, DeliveryAction) on NetworkMessageId
| summarize Recipients = dcount(RecipientEmailAddress), Senders = make_set(SenderFromAddress, 10) by UrlDomain, DeliveryAction
| order by Recipients desc

Framework mapping

In NIST CSF 2.0, the email and mobile controls sit under Protect (PR.PS, PR.AA, PR.AT) and hunting and removal under Detect (DE.CM) and Respond (RS.MA).

Common failure patterns

• Assuming the gateway decodes QR codes: many deployments never tested it, or it covers inline images but not PDFs. Test every format, including split and text-drawn codes.
• Counting on link rewriting: time-of-click protection does nothing for a URL inside an image that is opened on a phone. Pre-delivery extraction and identity controls carry the load.
• Push or OTP MFA treated as enough: an AiTM kit relays the code or approval from the phone exactly as it would from a laptop. Where high-value accounts still use them, quishing is a direct path to session theft.
• Broad allow lists for QR-heavy senders: allow entries for e-signature, ticketing or delivery services are exactly what attackers imitate. Allow by authenticated domain and keep scanning.
• Training that says "never scan a QR code": people scan menus and tickets anyway. Teach the danger signs (unexpected email, credential or payment request, sticker overlay) and make reporting easy.
• Uninspected public codes: an overlay on a meter or terminal can collect payments for weeks before anyone notices.

Practitioner checklist

• Test QR codes in email bodies, PDFs, Office files, split, nested and text-drawn forms against every email layer, and retest quarterly.
• Confirm extracted QR URLs are detonated, logged and covered by post-delivery removal.
• Score short external messages built around one image or attachment and an MFA, password or payroll pretext.
• Enforce phishing-resistant MFA for administrators, finance, HR and executives first, and restrict MFA method registration.
• Require a compliant or managed device for sensitive apps so phone-captured credentials cannot be replayed freely.
• Deploy mobile web protection on enrolled phones and tell staff to use only the built-in camera scanner.
• Add QR payloads to phishing simulations and measure reports as well as scans.
• Build a hunting query joining QR-extracted URLs to recipients and follow-on sign-ins, and alert on new MFA registrations after delivery.
• For public-facing codes, print into signage, publish the typed URL alongside, inspect regularly and offer a tampering report route.

Standards and references

• MITRE ATT&CK: T1660 Phishing (Mobile)
• MITRE ATT&CK: T1566.002 Phishing: Spearphishing Link
• FBI IC3: Cybercriminals Tampering with QR Codes to Steal Victim Funds
• FTC: Scammers hide harmful links in QR codes to steal your information
• NCSC: QR codes, what's the real risk?
• NCSC: Report a scam email
• Microsoft Learn: EmailUrlInfo table in the advanced hunting schema
• Barracuda: Split and nested QR codes fuel new generation of quishing attacks

Related NHI Mgmt Group resources: Phishing Guide · AiTM Phishing Guide · Email Security Guide · Vishing and Smishing Guide · Passwordless and Passkeys Guide