QR phishing and OAuth abuse: what we see in campaigns right now

Quishing is phishing where the malicious link sits inside a QR code instead of in the text. Many mail gateways see only an image, never read the URL out of it, and the message goes through without a warning. The victim then scans the code with a phone, outside the company’s proxy, its endpoint detection and response (EDR), and its device management.

Link filters work with text: they take the URL apart, compare the domain against reputation lists, and sometimes open it in a sandbox. A QR code is a bitmap image to them, or a piece of a PDF that no link can be pulled out of. The same link that would land in quarantine inside the body of an email gets through as a little square.

Moving the victim to a personal phone is the other half of the trick. A phone has no company protection on its traffic and a shorter address bar, so a spoofed domain is easier to miss. The QR code can be passed off as an MFA reset, a secured document, or an invoice to scan.

The most common form is a PDF attachment with a single QR code and a line like “scan to view the secured document.” The attachment looks harmless because it carries no clickable link, only an image. The QR code doesn’t have to arrive by mail, though: a QR poster in the building and other on-site scenarios work on the same principle.

Once scanned, it opens a login page indistinguishable from Microsoft or from a company portal, on a domain that comes close to the real name. More advanced campaigns put a reverse proxy behind that page (AiTM, adversary in the middle), which forwards passwords and the session cookie on to the real Microsoft. That gets past ordinary MFA with a one-time code or a push, and the stolen account opens the way to what comes after that first access.

Consent phishing abuses OAuth: the victim sends no password, only clicks through a consent that gives the attacker’s application access to the mailbox, files, or contacts. MFA doesn’t stop it, because the user signed in legitimately, and a token issued to such an application survives even the user changing their own password.

The attack starts with a link to the genuine Microsoft sign-in page (login.microsoftonline.com). After the sign-in, the standard consent screen appears: an application with a name that resembles Microsoft asks for permissions such as Mail.Read and offline_access. Whoever clicks through the consent hands the attacker a refresh token with permanent access.

From there the attacker reads mail, downloads files from OneDrive, or sends further phishing from a trusted address, including fraudulent payments and invoices with no malware involved, without a single extra sign-in. Because the attacker never had the password, changing it solves nothing. Microsoft says as much in its remediation documentation: neither a password reset nor enforced MFA helps against this attack. The access stays until someone revokes the consent or the issued tokens.

Each of the two techniques aims at a different blind spot. Quishing gets around link checking by sending no text link at all. Consent phishing gets around the password and MFA by not needing either. A defense built on those two layers alone will not catch them.

The AiTM proxy also shows that MFA is no cure by itself. A code from an app and a push confirmation can be forwarded just like a password, because the attacker sits between the victim and the server and steals the finished session cookie outright. What holds up is a sign-in bound to the domain.

Against quishing, analysis of QR codes in the mail gateway and phishing-resistant MFA help; against consent phishing, restricting user consent in Microsoft Entra ID and auditing the permissions already granted. Both are configuration, not awareness.

For quishing, deploy a gateway that can decode QR codes and evaluate the hidden link, and quarantine PDFs with a QR code from external senders. The decisive step, though, is swapping the second factor for FIDO2 or a passkey. That one is bound to the domain, so it doesn’t work on a spoofed page, not even through an AiTM proxy.

Close consent phishing on the tenant side like this:

• In Microsoft Entra ID, turn off unrestricted user consent and turn on the admin consent workflow, so an administrator approves each request for permissions.
• Go through the consents already granted and the registered OAuth applications, and revoke the risky and the unused ones.
• Turn on publisher verification and block unverified applications that reach for data.
• Set up Conditional Access and watch newly granted consents in the audit logs.

Anyone unsure about this configuration can go through it with us as part of a security consultation. Whether your own people fall for a QR code and a fake consent is what a phishing simulation built for your sector shows.

A report button in the email client and a rehearsed procedure for whom to report an incident to shorten the time the attacker keeps access. With consent phishing, it comes down to how fast the consent is revoked, not whether the email is spotted.