Quishing (T1660)

Quishing is phishing that arrives as a QR code instead of a link. The code is an image, so the software that checks messages for dangerous links has nothing to read, and the destination only appears once a camera decodes it. MITRE ATT&CK tracks it in its mobile matrix as `T1660`.

It is pronounced KWISH-ing, rhyming with fishing, and the Cambridge Dictionary added it to its new-words list in 2024. Enough people ask that search engines now answer the pronunciation before they answer the definition, sourcing it from dictionaries rather than from any security page.

Here is the odd thing about the advice attached to quishing. The most repeated tip, on both major search engines, is to check the web address before you open it. The same answers also tell you that the address cannot be seen before you scan. Both statements are true, and the sequence between them is the entire mechanism, which nothing on either results page explains.

This page explains it, and then covers what a government advisory published in January says about the same attack.

Explain it like I'm 10

A QR code is a picture of a web address. That is all it is.

A person cannot read a picture of an address, and neither can most of the software that checks your messages for dangerous links. A camera can. So the check that would normally happen before a message reaches you does not happen at all, and the first thing that reads the address is the phone in your hand.

Which means the last line of defence is a person holding a phone, looking at a small piece of text, deciding whether to tap it.

That is not a criticism of anyone. It is a description of where the decision ended up.

Why quishing gets past the filters

The mechanism is not complicated and the whole field describes it the same way. A filter that looks for dangerous links needs a link to look at. A QR code has none. The destination is encoded in a pattern of squares, and nothing resolves it into an address until a camera does.

That is why a message carrying a code can pass through checks that would have stopped the same message carrying the same address as text. The content is identical. Only the format changed.

It helps to know how these codes actually arrive, because the answer is less exotic than the public examples suggest. Microsoft's reporting for the first quarter of 2026 found that PDF attachments were the dominant delivery method throughout the quarter. The image is not usually pasted into the message itself; it is inside a document attached to it, which is a second layer between the code and anything designed to inspect it.

The message is checked on one device and acted on by another

There is a second consequence, and it is the more important one. Reading this is a derived point rather than something any single source states outright, but it follows directly from where the pieces sit.

The email arrives on a work computer, which is usually managed, patched and monitored. The code is scanned with a phone, which usually is not. The attack moves you from a supervised device to an unsupervised one, and it does so using a motion so ordinary that nobody experiences it as a decision.

What your phone actually does when you scan

This is the question most people actually have, and it has a documented answer.

Take the contradiction first. Google's summary for this term states that "you cannot see the real website address before you scan the code". Four bullets later it advises: "If your phone shows you the web address after scanning, read it carefully before tapping to open it." The other major engine goes further and suggests using a QR scanner that shows the URL, which implies the one already on your phone does not.

What the camera actually does

Apple's instructions for its own camera describe a different sequence. You open the Camera app, hold the device so the code appears, and a notification banner appears at the top of the screen. You then tap that banner to open the content. There is also a Scan Code button in Control Center that behaves the same way.

Australia's cyber security centre describes the same category of attack as "a social engineering technique that tricks you into scanning malicious QR codes", which is a more accurate framing than most: the technical part is trivial, and the part that has to work is the persuasion.

So the destination is surfaced, and a tap is required. The address is not visible before you scan, and it is visible after. Both halves of the advice were describing the same two seconds from different sides.

What that does not mean

Three limits, because this is the part where it would be easy to overclaim.

This is one company's documented behaviour for its own camera app. It is not a statement about every scanner application, every Android build, or every version of anything. Check what your own device does.

More importantly, nothing here shows that people read what they are shown. The banner is small, it appears while you are still holding the phone up at an awkward angle, and tapping it is the natural continuation of the motion you already started. Being shown something and reading it are different events.

Which is the reframe worth taking away. The standard advice is not asking you to acquire a capability you lack. It is asking for two seconds of attention at a moment that has been designed to feel like nothing is happening.

Is the sticker thing real?

Every explainer on this subject mentions someone sticking a fake QR code over a real one, on a parking meter or a restaurant menu or a public sign. When twenty vendor pages repeat the same colourful example, the reasonable instinct is to ask who actually documented it.

The research for this article began from that suspicion, and the suspicion was wrong. That deserves saying directly rather than quietly dropping it, because a page that only reports the expectations it managed to confirm is less useful than one that reports the ones it had to abandon. The claim is better sourced than the vendor pool makes it look.

Who has actually documented it

MITRE's own technique description carries the scenario in the framework's words: an adversary "could replace a legitimate public QR Code with one that leads to a different destination, such as a phishing website". The United States Federal Trade Commission published a consumer alert about scammers covering QR codes with their own in December 2023. Municipal transport authorities have issued their own warnings about parking-meter overlays, Honolulu's in April 2023 and New York City's subsequently. The United States Postal Inspection Service maintains a page on the subject.

That is a framework, a federal consumer regulator, at least two city transport departments and a federal law-enforcement service. The example is repetitive because it is documented, not because it is invented.

But it is not the common case

Documented is not the same as typical. The measurement further down this page counts codes arriving in email, mostly inside PDF attachments, in volumes that run to millions a month. The parking meter is the memorable example because it is physical and easy to picture. The ordinary one is a document attached to a message, and it is the one most people will actually meet.

What the framework calls it

MITRE ATT&CK tracks this as `T1660`, Phishing - and the interesting detail is which matrix it sits in.

It is not in ATT&CK's Enterprise matrix. It is in the Mobile matrix, filed under Initial Access, with platforms listed as Android and iOS. The technique is at version 1.2 and was last modified on 12 May 2026. It has no sub-techniques, which for a technique this widely discussed is itself informative: the framework treats quishing as one delivery variation among several rather than as a family of its own.

The object lives where the attack lands. That is a small piece of framework housekeeping that happens to describe the problem better than most paragraphs written about it: the thing being attacked is a phone, which is why the controls that protect a work computer are not in the picture.

Two mitigations, and one of them is you

Its mitigations are short enough to state in full. There are two. One is antivirus and antimalware tooling capable of blocking known phishing domains. The other is user guidance. Among the technique's procedure examples is a group MITRE tracks as Kimsuky, recorded as having deployed malicious QR codes in phishing emails aimed at US entities - which is where the next section starts.

What the FBI published in January

In January 2026 the FBI issued a FLASH advisory, marked TLP:CLEAR and coordinated with the Department of Homeland Security and CISA. It states that "the FBI identified Kimsuky actors deploying malicious QR codes as a part of targeted spearphishing campaigns", and it lists four incidents with dates.

In May 2025, actors impersonating a foreign advisor emailed the leader of a think tank asking for insight on developments on the Korean Peninsula, and provided "a QR code to scan for access to a questionnaire". Later the same month, actors impersonating an embassy employee emailed a senior fellow about North Korean human rights issues, with a code that "purported to provide access to a secure drive". Also in May, a code led directly to "Kimsuky infrastructure designed to conduct malicious activity".

Then, in June 2025, a strategic advisory firm received an invitation to a conference that did not exist. The code led to a registration page with a button on it. The button led to a fake Google account login page.

The lifecycle mapping nobody quotes

The same advisory publishes something no page on either search engine mentions: a table mapping the whole attack to framework techniques.

Two of those rows deserve a note rather than an explanation. Session token theft and MFA bypass share an identifier because they are the same move, and that move is the subject of this site's article on adversary-in-the-middle phishing. The point here is only that a government advisory considers them part of the same lifecycle as the code you scanned.

What it tells organisations to do

The advisory's recommendations run to a dozen items, and most are familiar: educate staff about unsolicited codes "regardless of their source (email, letter, flyer, packaging)", verify sources "through secondary means (such as contacting the sender directly)", require phishing-resistant multi-factor authentication, and audit access privileges. Two of them are unusual enough to name separately here. It tells organisations to deploy tooling "capable of analyzing QR-linked URLs before permitting access to web resources", and to log and monitor "all credential entry and network activity following QR code scans". That second instruction is the only detection-side advice found anywhere in the research for this article. Everything else on both search pages is prevention.

Is it actually getting worse?

There is one measurement from an organisation with the vantage point to take it. Microsoft's threat intelligence and Defender research teams published email-threat reporting for the first quarter of 2026 on 30 April.

Their figures show QR-code attack volumes rising from 7.6 million in January to 18.7 million in March, a 146% increase, with month-on-month growth of 59% in February and 55% in March.

What that number is and is not

It is one company's detections, across its own email security systems, over one quarter. It is a volume trend, and a steep one. It is not a prevalence figure, not an industry total, and not a count of anyone who lost money or had an account taken.

The same reporting adds a detail about delivery that is more useful than the headline. PDF attachments were the dominant way these codes arrived throughout the quarter. Codes embedded directly in the body of an email surged 336% in March - while still accounting for 5% of total volume. Those two numbers belong together. The percentage change is large because the base is small.

And there is a gap underneath all of it. No victim count was located for this article. Detection volume counts messages that were caught. It does not count people who lost something, and the two are not interchangeable.

The one thing to change

Most pages on this subject end with ten or fourteen tips. Here is one.

Read the banner before you tap it. That is the whole ask. Your phone puts the destination in front of you and waits; the change is to spend two seconds on it rather than completing the motion automatically.

It is fair to ask why something that small is enough to matter. The clearest of the documented cases above ends the way most of these do: a person arrives at a page pretending to be a service they use, and types something into it. The banner is the last moment before that page loads, and it is the only moment where the address is visible and nothing has happened yet.

Why not a longer list

The field's own advice is not wrong. Both search engines recommend inspecting physical codes for stickers, previewing the address, navigating to the official site manually, and never entering credentials on a page reached from a scan. One vendor page runs to fourteen tips.

The problem with fourteen tips is that nobody adopts fourteen habits. The banner check is the one that sits at the decision point, applies to every case above, and costs two seconds.

Three supporting habits, and then this section stops. When a code arrives unexpectedly asking for a payment or a login, type the address yourself instead. Treat a code in an unexpected message exactly as you would treat a link in one. And if you run an organisation's security, the FBI's own list is the better starting point than any vendor's, particularly the instruction to monitor what happens after a scan.

There is no app to install here, and no setting to change. The phone already does the showing. What it cannot do is the looking.

What this page cannot tell you

• Nobody publishes a victim count. The available numbers are detections, and this article says so where it uses them.
• The scanning behaviour described is Apple's, documented for its own camera app. It is not a statement about every device, and it does not show that anyone reads the banner. That distinction is the article's own limit as much as the platform's.
• One widely-read page says elderly people are the most common targets of quishing. No evidence for that was located, and it is not repeated here. A claim about which people get caught needs data behind it, and without data it is a stereotype rather than a finding.
• Two sources could not be read. The Australian government's quishing page timed out on two attempts, and the FTC's consumer alert returned an error. Both are named above because their existence and dates are established, and neither is quoted directly or linked.

The short version

Quishing is phishing delivered as a picture. The picture defeats the filters that read links, and the first thing capable of reading the address is the phone in your hand.

Which is also the good news, and the part the advice keeps almost saying. Your phone shows you where the code goes, and waits for you to tap. The address is not hidden after scanning. It is simply shown at a moment when you are mid-motion and not expecting to make a decision.

The attack is real, documented by a framework, a federal regulator, city transport departments and an FBI advisory that traces four dated incidents ending in a fake login page. None of that is a reason to stop scanning QR codes. It is a reason to look at the banner.