Case Library / Quishing (QR Code Phishing) / QR phishing attack on a US MSP: the fake MFA-reactivation email (2023)
Quishing (QR Code Phishing) Documented incident

QR phishing attack on a US MSP: the fake MFA-reactivation email (2023)

A fake 'reactivate your MFA' email with a QR code targeted a US MSP employee in 2023, routing through a fake security scan to a Microsoft 365 login copy.

Share:

Social Engineering Examples·2 sources

In May 2023, email security firm Hornetsecurity published its analysis of a QR-code phishing email sent to one employee at a US managed service provider. Dressed as a support ticket and branded with Microsoft logos, it said the employee's multi-factor authentication had been switched off and needed "reactivating" by scanning a QR code. Hornetsecurity traced the code through a fake "security scan" page to a freshly registered Microsoft 365 login copy. It doesn't say whether the employee scanned it. Status: Vendor analysis, outcome unknown.

Key takeaways

  • The email got past Microsoft 365's built-in filtering, according to Hornetsecurity.
  • A fake security-scan page showing a green "Success" tick was there to calm the victim before the real trap.
  • The attackers hid behind Cloudflare's bot protection to make it harder for security tools to inspect the pages.
  • No compromise, loss or attacker was confirmed. This is a description of the trap, not of a victim falling into it.

The email

The sender name was spoofed to show the MSP's own name, and the message looked like a support ticket. It carried Microsoft and Microsoft Authenticator logos and said, in substance, that MFA was no longer active on the account and the recipient should reactivate it by following instructions on their device. The call to action was a Microsoft-branded QR code to scan with a phone.

Tip: an email saying your security has been switched off is designed to make you hurry. Check in your account settings directly, not through the email.

Where the QR code led

Stage What Hornetsecurity found
1. Email Spoofed support ticket with a QR code instead of a link
2. Phone Scanning moves the click off the monitored work computer
3. Fake scan A page on a .ru domain played a security-scan animation, then showed a green tick and "Success". Hornetsecurity had seen the same page style in an earlier campaign
4. Login copy A newly registered Microsoft 365 login page, "likely" built to capture credentials

Hosting the fake scan page behind Cloudflare let the attackers use Cloudflare's anti-bot checks against security vendors trying to analyse the page automatically. That's a common trick in quishing and credential harvesting.

What's known and what isn't

Known Not known
One employee at a US MSP was targeted Whether they scanned the code
The email beat Microsoft 365's native filtering Whether any account was taken over
The full chain from QR code to fake login Who was behind it
Published 19 May 2023 The exact date of the attack

Targeting an MSP is worth noting. MSPs manage IT for other companies, so one stolen login can open doors to many customers. See supply-chain social engineering.

What stops it

  • Filtering that reads QR codes in emails, not just text links.
  • Phishing-resistant MFA for admin and MSP staff.
  • A clear rule: MFA changes happen in the official app or portal, never from an email.
  • Treat "your security is off" emails as suspect, especially ones spoofing your own company name.
  • Report and check. If you scanned, tell IT and change your password from a trusted device.

See also a similar MFA-setup QR attack where credentials were captured.

Common questions

What is QRishing?

Another name for quishing: phishing that uses a QR code to send victims to a fake website.

Why did the attackers use Cloudflare?

Cloudflare's bot protection made it harder for automated security tools to inspect the fake pages.

Was the MSP employee hacked?

Hornetsecurity doesn't say. Its write-up describes where the QR code led, not what the employee did.

Why target an MSP?

MSPs run IT for other companies, so access to one can lead to many others.

Sources
  • Recent QRishing Attack Exploits Cloudflare and Microsoft. Hornetsecurity (primary). Primary vendor incident write-up, published 2023-05-19; source of all technical details (MFA-reactivation lure text, QR-to-.ru-to-Cloudflare-to-M365-phish chain, single-employee targeting, no confirmed compromise, no financial figures). Re-confirmed via direct fetch 2026-07-29 (previously confirmed 2026-07-22): the write-up narrates the technical mechanism/destination of the QR code and never states the employee scanned it, reached the interstitial, or reached the final phishing page; scanning device is described only as 'their smartphone,' not confirmed as personally owned. Exact attack date is not disclosed; 2023-05-19 is the publication date.
  • QRishing: How Businesses Can Counter The Emerging Cyber Threat. Group 8 (secondary). Secondary write-up summarizing/citing the same Hornetsecurity US-MSP case (MFA-reactivation lure, fake M365 login). Confirmed via direct fetch 2026-07-29: the article (dated 21 Feb 2024) independently describes the same single-employee, US-based MSP, MFA-reactivation-themed M365 QRishing case, consistent with the primary source.
Cite this case

Social Engineering Examples. “QR phishing attack on a US MSP: the fake MFA-reactivation email (2023)”. Accessed 3 November 2026. https://socialengineeringexamples.com/hornetsecurity-qrishing-us-msp-2023

Attack Chain & Defense
1Reconnaissance and target selection
What happened

Hornetsecurity's write-up does not describe specific recon tradecraft used against this MSP, but campaigns of this type typically involve identifying a target organization and picking a specific employee, likely favoring an MSP because a single compromised account can offer a plausible pivot point into every downstream client tenant the MSP manages.

The control that would have stopped it

which organizations and employees an attacker chooses to target is largely invisible to defenders in advance, so the realistic control sits downstream, at the email and account-access layers where campaigns like this one actually land, rather than at the target-selection stage itself.

2Infrastructure staging
What happened

the attackers registered a domain Hornetsecurity verified was very recently created to host the final Microsoft 365 spoof, staged a separate .ru-hosted fake 'security scan' interstitial that reused attributes and behaviors from a prior campaign Hornetsecurity had already reported, and fronted that interstitial with Cloudflare specifically to gain its antibot protections and slow down vendor or analyst investigation.

The control that would have stopped it

domain-age and reputation-based filtering, plus cross-vendor threat-intel sharing that flags reused phishing-kit attributes across campaigns (the same correlation Hornetsecurity itself made against a prior incident), helps surface freshly registered spoofing domains and known abusive hosting patterns before an email is even delivered.

3Lure crafting
What happened

the attackers built a support-ticket-styled email using genuine Microsoft and Microsoft Authenticator branding, an MFA-deactivation urgency message, a sender display name spoofed to the target MSP's own name, and a QR code (rather than a text link) as the only call-to-action, a combination designed to look official and to evade filters that scan URLs or text rather than images.

The control that would have stopped it

email security tooling that uses computer vision and logo/brand-impersonation detection can catch lures built around official-looking branding and urgency framing even when the payload link is hidden inside an image rather than in text.

4Delivery
What happened

the email was sent to a single employee at the target MSP and bypassed Microsoft 365's native security filtering, per Hornetsecurity's detection of the campaign.

The control that would have stopped it

layering third-party email security on top of Microsoft 365's native filtering catches campaigns like this one that bypass Microsoft's own detection, per Hornetsecurity's stated recommendation.

5QR scan and channel switch
What happened

the email instructed the recipient to scan the embedded QR code with a smartphone; Hornetsecurity's write-up traces where the code leads but does not confirm the employee actually scanned it, so this step describes the intended, not confirmed, victim action.

The control that would have stopped it

security-awareness training that specifically covers QR-code risks, teaching users not to scan unsolicited QR codes or treat MFA-themed urgency prompts arriving by email as legitimate without verifying through a known channel, targets this exact step.

6Fake security-scan interstitial
What happened

if scanned and tapped through, the code would lead to the .ru-hosted page simulating an antivirus/security scan and then showing a green 'Success' checkmark, a fabricated trust signal meant to lower suspicion before the real payload page loads.

The control that would have stopped it

treating any 'security scan passed' or CAPTCHA-style success indicator encountered mid-flow as a manipulation cue rather than a trust signal, reinforced through the same awareness training, undercuts the false reassurance this interstitial is built to create.

7Credential harvesting page
What happened

the chain's final destination was the spoofed, freshly registered Microsoft 365 login page, designed to capture a username and password; Hornetsecurity describes this only as the page's 'likely' purpose and does not confirm the employee ever reached or interacted with it.

The control that would have stopped it

extending inspection and protection from mailbox to browser and mobile devices closes the gap QR codes exploit, since the click chain moves onto a smartphone and outside traditional corporate endpoint and network perimeter tools at exactly this step.

8Objective completion
What happened

captured M365 credentials would, if the chain were completed, grant initial access to the employee's account and, per Hornetsecurity, could enable data exfiltration, malware spread, or vendor email compromise reaching downstream MSP clients, though the write-up stops short of confirming any of this occurred.

The control that would have stopped it

phishing-resistant, passwordless authentication (for example FIDO2 hardware keys) and conditional-access policies that restrict logins from new devices or locations reduce what a harvested password and username can actually unlock, and for MSPs specifically, segmenting and monitoring downstream client-tenant access from MSP accounts limits how far a single compromised credential can cascade.

Quick Facts
Victim
Unnamed US-based Managed Service Provider (MSP); single employee targeted
Location
United States (specific state/city not disclosed; victim MSP not named)
Date
2023-05-19
Impact
None disclosed.
Basisnot-a-lossThe vendor does not confirm the account was ever compromised
Hornetsecurity's report contains no dollar figure, quantified loss, incident-response cost, or ransom/extortion amount. The vendor also does not confirm that the M365 account was actually compromised; its language describes the credential-harvesting login page as "likely" intended to capture credentials, not a confirmed successful takeover.
Status
Documented incident
Case Type
Real-World Incident
Sector
Technology & Software
Threat Actor
unknown
Explore more

Related Cases

Browse by what this case has in common with others in the library.