Case Library / Quishing (QR Code Phishing) / Hornetsecurity QRishing Attack on US-Based MSP (2023)

Hornetsecurity QRishing Attack on US-Based MSP (2023)

Hornetsecurity documented a QR-phishing (quishing) email sent to a single employee at a US-based MSP that spoofed an MFA-reactivation notice with a QR code leading, via a .ru-hosted fake "security scan" page behind Cloudflare, to a freshly registered Microsoft 365 credential-harvesting login page; Hornetsecurity's write-up documents this technical chain but does not confirm the employee scanned the code or that any downstream step actually occurred.

Share:

Reviewed by the Social Engineering Examples team.

What Happened

In a post published 19 May 2023, email-security vendor Hornetsecurity disclosed that it had detected and analyzed a QR-code phishing ("QRishing") attack targeting a single employee at an unnamed US-based managed service provider; the exact date of the underlying attack is not disclosed. The phishing email was disguised as a support-ticket notification, spoofed to display the targeted MSP's own name as sender, and used Microsoft and Microsoft Authenticator branding to claim the recipient's multi-factor authentication had been deactivated and needed to be "reactivated" by scanning an embedded, Microsoft-logo-branded QR code with a smartphone. Hornetsecurity noted the email had bypassed Microsoft 365's native security filtering. Hornetsecurity's write-up traces where the QR code leads rather than confirming what the employee did: scanning and tapping through would lead to a .ru-domain page staging a fake antivirus/security-scan animation (CAPTCHA-style verification theater) that resolves to a green "Success" checkmark, hosted behind Cloudflare so the attackers could exploit Cloudflare's antibot protections to hinder automated security analysis, and from there to a spoofed, recently registered Microsoft 365 login page designed to harvest credentials. Hornetsecurity's report frames the credential theft as the page's "likely" purpose rather than a confirmed compromise, and does not state whether the employee scanned the code, reached the interstitial page, or reached the final phishing page; it discloses no financial loss and no named threat actor.

How the Attack Worked

The write-up describes a four-stage attack chain engineered to evade email-security filters and antibot/analysis tools; Hornetsecurity does not confirm the targeted employee completed any step beyond receiving the email, so stages (2)-(4) below describe where the chain leads rather than confirmed victim actions: (1) Lure email: a spoofed "support ticket" style message with the display name forged to show the targeted MSP's own name, carrying Microsoft and Microsoft Authenticator logos, telling the recipient "Multi-Factor Authentication (MFA) is no longer active on your organization account. To help keep your account safe and secure. Please reactivate your authentication by following the instructions on your device," with a call-to-action to scan an embedded QR code (also Microsoft-logo-branded) with a smartphone rather than click a text link. (2) QR code as evasion layer: because the phishing link lived only inside a scannable image, filters relying on URL/text analysis rather than computer vision or QR decoding would not flag it, and scanning with a smartphone camera, as the email instructed, would move the click chain outside the monitored corporate email/endpoint environment; the source does not confirm whether the code was actually scanned or whether the device would have been personally owned or corporate-issued. (3) Fake "security scan" interstitial: the QR code, if scanned and tapped through, led to a page on a .ru top-level-domain that simulated a security/antivirus scan animation (CAPTCHA-style verification theater) and then refreshed to show a green checkmark and the word "Success," a design meant to manufacture false reassurance before the real payload page loaded; this interstitial reused attributes/behaviors Hornetsecurity had seen in a separate campaign it had previously reported, and it was hosted behind Cloudflare specifically so the attackers could piggyback on Cloudflare's antibot protections to frustrate automated security-vendor analysis. (4) Credential harvester: the chain's final destination was a spoofed Microsoft 365 login page on a domain Hornetsecurity verified had been very recently registered, designed to capture an M365 username and password; Hornetsecurity describes credential harvesting only as the page's "likely" purpose, not a confirmed outcome, and does not state whether the employee ever reached or interacted with this page.

The Lure & the Tell

Lure: an email disguised as a support-ticket / IT-helpdesk notice, with the sender display name spoofed to the targeted MSP's own name, and Microsoft plus Microsoft Authenticator logos embedded to look like an official Microsoft security notice. The body read, in substance: "Multi-Factor Authentication (MFA) is no longer active on your organization account. To help keep your account safe and secure. Please reactivate your authentication by following the instructions on your device," an urgency/loss-of-access trigger paired with a QR code (itself carrying a Microsoft logo) as the only call-to-action, rather than a clickable hyperlink. Tells that would have been visible to a trained eye: MFA "deactivation" notices are not something Microsoft delivers by asking a user to scan a QR code; legitimate Microsoft security/authenticator prompts happen in-app or via admin center, never via a support-ticket-styled email urging a phone-camera scan; the instruction to leave the desktop email client and use a smartphone to "resolve" an urgent account-security issue is itself atypical; and the subsequent "security scan" animation culminating in a green "Success" badge is a fabricated trust signal with no relationship to any real security product.

Outcome

Hornetsecurity's own filtering/detection identified and documented the campaign after it slipped past Microsoft 365's native email-security defenses; the vendor does not report whether the single targeted employee actually scanned the code or entered credentials into the final M365 phishing page, and its write-up explicitly stops short of confirming an account compromise, describing the credential capture only as the "likely" purpose of the fake login form. No breach notification, ransom, data-exfiltration claim, or follow-on incident (e.g., a reported downstream MSP client compromise) has been publicly tied to this specific case. The lasting outcome is the vendor's published technical dissection, used as an awareness/training case study rather than a confirmed-breach disclosure.

Why It Matters

The case is a compact, real-world demonstration of why QR-code phishing defeats conventional email-security controls: the malicious link exists only as an image, so filters that scan URLs/text (rather than using computer vision or QR decoding) miss it outright, and the intended click/scan step happens on a smartphone camera, stepping outside the monitored corporate email and endpoint perimeter entirely if it occurs. It also shows a layered anti-analysis design that security teams increasingly encounter: a throwaway .ru redirect, a fabricated "security scan passed" trust signal to lower victim suspicion, and a Cloudflare-fronted interstitial page used defensively by the attackers themselves to slow down vendor/analyst investigation before the real Microsoft 365 credential-harvesting page is ever reached. Because the victim was an MSP, a successful compromise here would carry outsized downstream risk: MSP credentials are a well-known pivot point into every downstream client tenant the MSP manages, making this a supply-chain-relevant target even though only one employee and one organization were directly hit, and even though Hornetsecurity never confirms the compromise progressed past the initial email.

Defenses

Hornetsecurity's recommendations: (1) security-awareness training that specifically covers QR-code risks, teaching users not to scan QR codes from unknown/unsolicited sources or tap resulting links without verifying legitimacy; (2) layered third-party email security on top of Microsoft 365's native filtering, since the malicious email bypassed Microsoft's native detection; (3) email security tooling that uses Computer Vision to detect phishing links embedded inside QR-code images (image-based threats that text/URL-only filters miss); (4) protection extended from mailbox to browser and to mobile devices, since QR codes are scanned on smartphones outside the corporate email/endpoint perimeter where traditional controls apply; (5) awareness that "security-scan" or "CAPTCHA-style" interstitial pages showing a green success indicator are a manipulation technique, not proof of safety.

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.
Attack Chain & Defense
The sequence the attacker ran
How it could have been stopped
1
Reconnaissance and target selection: 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.
Countering Stage 1: 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.
2
Infrastructure staging: 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.
Countering Stage 2: 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.
3
Lure crafting: 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.
Countering Stage 3: 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.
4
Delivery: 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.
Countering Stage 4: 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.
5
QR scan and channel switch: 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.
Countering Stage 5: 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.
6
Fake security-scan interstitial: 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.
Countering Stage 6: 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.
7
Credential harvesting page: 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.
Countering Stage 7: 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.
8
Objective completion: 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.
Countering Stage 8: 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. 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
Confirmed
Case Type
Real-World Incident
Sector
Technology & Software
Related

Related Cases

LevelBlue MTDR SOC "Quishing" Case Study - Fake Microsoft MFA-Setup QR Code Harvests Employee Credentials (2023)

LevelBlue's MDR SOC documented a real client quishing case in which a PDF impersonating a Microsoft MFA-setup notice, hiding a…

Incident 2023Read →

FTC Consumer Alert: QR Code Scams (Quishing)

The FTC's first major consumer alert on QR-code scams (Dec 6, 2023) warned of fake QR stickers on parking meters…

Incident 2023Read →

UK Council Car Park QR Code ("Quishing") Scams - Cheltenham, Swindon & Somerset

Fraudsters plastered fake QR-code stickers over genuine PayByPhone parking codes at UK council car parks in Cheltenham, Swindon and Somerset,…

Incident 2024Read →