Case Library / Quishing (QR Code Phishing) / Fake Microsoft MFA-setup QR code: a SOC quishing case study (2023)
Quishing (QR Code Phishing) Documented incident

Fake Microsoft MFA-setup QR code: a SOC quishing case study (2023)

Employees scanned a QR code in a fake Microsoft MFA-setup PDF and gave up passwords on a cloned login. How AT&T's SOC (now LevelBlue) traced and cleaned it up.

Share:

Social Engineering Examples·4 sources

Several employees at an unnamed company received an email with a PDF saying they needed to set up Microsoft multi-factor authentication. The PDF held a QR code. Staff who scanned it with their phones landed on a fake Microsoft sign-in page and typed in their passwords. AT&T Cybersecurity's security operations team, now trading as LevelBlue, investigated and published the case in October 2023. Status: Vendor case study, single source.

Key takeaways

  • The lure was a security task: set up MFA. People expect those notices and act on them.
  • The QR code moved the click from the work computer to a personal phone, which usually has fewer protections.
  • The vendor says it was fully cleaned up with no data stolen. That's its own assessment of its own work.
  • The customer, its industry, the date and the number of employees affected were never disclosed.

How the attack worked

Step What happened
Email An urgent notice that Microsoft MFA must be set up on the account
PDF An attachment telling the recipient to scan a QR code to complete setup
Phone Staff scanned the code on their phones, away from work security tools
Fake login A convincing Microsoft sign-in page captured usernames and passwords

The vendor says "several users" had their credentials captured. Did the QR code slip past an email filter here? The write-up never says. As a rule, though, a code is just a picture, and plenty of filters that scan links in text never look inside pictures. That gap is half the appeal of quishing.

Tip: real MFA setup happens inside your company's own portal or authenticator app. You don't need to scan a code from an email to do it.

The investigation

The customer flagged the email as suspicious and called in its managed security provider. Analysts decoded the QR code, which pointed to srvc1[.]info/mcrsft2fasetup/index.html. Using a decoy email address and Chrome's developer tools, they watched what the fake page did after "Sign In" was clicked. They saw only one outside call, a harmless lookup to a marketing data service, and no sign of further data being sent out.

Checks on the domain turned up little: it had been bought recently and the owner's details were hidden. Hidden owner details are normal for domains these days, so that alone proves nothing. The customer confirmed neither domain was part of its normal business.

The clean-up

  • Kick out every live session before touching passwords. Otherwise the attacker just stays signed in.
  • Pull the email out of every mailbox it landed in.
  • Block the domains linked to the QR code.
  • Review the affected accounts for signs of data theft.

Nothing left the building, according to the vendor. Nobody outside has checked that, so it stays a claim.

What stops it

  • Show staff real examples, particularly codes dressed up as MFA or password chores.
  • Pick a mail filter that actually reads QR codes inside images and PDFs.
  • Passkeys or hardware keys. With those, a typed-in password on a fake page gets the attacker nowhere.
  • Check the address after scanning. A Microsoft login won't be on an odd domain.
  • Report and kill sessions fast. This customer's quick report limited the damage.

See also a similar MFA-themed QR attack on a US MSP and credential harvesting.

Common questions

What is a quishing attack?

It's phishing with a QR code where the link would normally be. Scan it and you land on a fake page, most often one that wants your login.

Why use a QR code in a PDF?

Because the link is hidden inside an image, and scanning it moves the victim onto a phone that may have weaker protection than a work computer.

Was data stolen in this case?

The vendor says no, after reviewing the accounts. That's its own assessment, not independently confirmed.

Who was the victim?

An unnamed customer of AT&T Cybersecurity's managed detection service. Its name, industry and location weren't disclosed.

Sources
  • Stories from the SOC: Quishing: Combatting embedded malicious QR codes. LevelBlue (primary). The vendor SOC case study, published 2023-10-10, bylined James Rodriguez, Senior Specialist, Cybersecurity. Full narrative of the lure, the investigation (QR decode, Chrome Inspector network analysis, OSINT on srvc1[.]info), and the remediation steps. This is the post-rebrand copy of the article: the byline and the October 10, 2023 date are as originally published, but the company name in the body was changed to LevelBlue after the May 2024 launch of that business, so the text now credits work that AT&T Cybersecurity did in 2023. Live-fetched 2026-09-02 and checked against every claim attributed to it here.
  • Stories from the SOC: Quishing: Combatting embedded malicious QR codes (pre-rebrand AT&T Cybersecurity capture). AT&T Cybersecurity (primary). The same article on the original AT&T Cybersecurity domain, and the version that preserves the wording as first published. The two texts are not identical, and this one, not the live page, is the historical record. Every place the live LevelBlue copy reads "LevelBlue", this capture reads "AT&T": "AT&T Managed Detection and Response (MTDR)" and "the AT&T analysts" in the executive summary, "contacted the AT&T team" and "AT&T SOC analysts" in the Investigation section, and "AT&T SOC analysts" again in Remediation. Nothing else differs. Fetched through the Wayback Machine 2026-09-02 and compared against the live copy.
  • "Quishing" - The New Trend?. WebCheck Security (secondary). Published 2023-10-27. Discusses the same MFA QR-code case as an example of the broader quishing trend and adds no independent facts. Written before the rebrand, so it attributes the research to "AT&T's Managed Detection and Response(MTDR) security operations center", which corroborates which wording came first. The author sells vCISO services, so treat it as promotional secondary material. It is also the only genuine third-party write-up located: everything else that reproduces this case is a content-scraper mirror, and no evidence was found of the case being used in any training curriculum.
  • Major Energy Company Targeted in Large QR Code Phishing Campaign. Cofense (secondary). Published 2023-08-16, bylined Nathaniel Raymond. Context, not a source on this incident: a larger contemporaneous QR-code campaign running the same account-security and MFA lures, "over 1000 emails containing malicious QR codes" across several industries with about 29 percent reaching a single US energy company. The counts are Cofense's own email telemetry, so they measure what Cofense could see, not the whole campaign. Cited here only to establish that the technique and the lure were already widespread months before the October 2023 write-up. Live-fetched 2026-09-02.
Cite this case

Social Engineering Examples. “Fake Microsoft MFA-setup QR code: a SOC quishing case study (2023)”. Accessed 3 November 2026. https://socialengineeringexamples.com/levelblue-mtdr-quishing-mfa-setup-2023

Attack Chain & Defense
1Target and infrastructure preparation
What happened

The threat actor needed employee email addresses at the target organization. The vendor write-up describes no reconnaissance and does not say how the address list was assembled, so its sourcing is unknown. The credential-harvesting page was hosted at srvc1[.]info, a domain the vendor's analysts found had been recently purchased and whose registrant identity was hidden, with no further data available.

The control that would have stopped it

Corporate employee email addresses are widely obtainable through data brokers, breach dumps, or predictable naming conventions, and privacy-protected domain registration is legal and hard to police preemptively; the realistic control sits downstream, at delivery and employee reporting, rather than at blocking address harvesting or domain registration itself.

2Lure construction
What happened

Attackers built a PDF styled as an urgent Microsoft/Windows multi-factor-authentication (MFA) setup notice, embedding a malicious QR code rather than a clickable hyperlink. The vendor does not say what email controls the customer had or what the code got past. As a general property of the technique, a QR code travels as an image, so link and text scanners do not decode and inspect it the way they do a URL.

The control that would have stopped it

Deploy email/attachment security tooling that extracts and reputation-checks QR-code payloads embedded inside PDFs and images, not just links and text, so the QR-in-a-PDF evasion technique is caught at the gateway before it reaches an inbox.

3Delivery
What happened

The phishing email carrying the PDF attachment was circulated to several employees at the customer organization, using urgency language to discourage the recipient from pausing to verify the request.

The control that would have stopped it

Train staff that legitimate MFA enrollment is initiated by internal IT/identity systems, never by an unsolicited PDF with a QR code, and give employees a fast, low-friction way to report suspicious QR-code emails, exactly as the customer in this case did before wider harm occurred.

4Mobile-device pivot
What happened

Recipients scanned the QR code with a phone and completed the sign-in there, moving the interaction onto a mobile device. The vendor frames steering users to a phone as a standard tactic, on the reasoning that a mobile device typically has fewer security measures in place than a network-connected corporate device.

The control that would have stopped it

Set policy and technical controls against scanning work-related QR codes with personal or unmanaged devices, and use mobile device management or conditional access so authentication flows must complete on an enrolled, monitored device, closing the exact weaker-security surface the attacker relied on.

5Credential harvest
What happened

Victims who scanned the code landed on a fake Microsoft sign-in page at srvc1[.]info/mcrsft2fasetup/index.html and entered their real usernames and passwords, which were captured by the threat actor.

The control that would have stopped it

Verify the destination domain before entering credentials (checking that it matches microsoft.com or the organization's actual identity provider), and deploy phishing-resistant MFA such as FIDO2/WebAuthn hardware security keys, which cannot be relayed through a look-alike page even if a password is typed into it.

6Objective completion
What happened

The threat actor obtained valid credentials for several employees, achieving credential theft and initial-access/account-takeover conditions. The vendor reported that its investigation and the remediation it guided closed the incident before any confirmed further use, such as data exfiltration or lateral movement, was observed. That assessment is the vendor's own and is not independently corroborated.

The control that would have stopped it

On any confirmed credential submission, immediately close all active sessions before resetting passwords (an unclosed session lets the attacker retain access through the reset), purge the phishing email fleet-wide, block the malicious domains, and audit account activity logs for exfiltration or lateral movement before declaring the incident closed, the exact remediation sequence the vendor's analysts guided the customer through.

Quick Facts
Victim
Unnamed AT&T Cybersecurity Managed Detection and Response (MDR/MTDR) customer; the vendor now trades as LevelBlue
Location
Not disclosed (customer identity, industry, and location withheld by the vendor in the published case study)
Date
Incident date not disclosed; described as recent in a vendor report published 2023-10-10
Impact
Not disclosed.
BasisunquantifiedCredentials compromised for several users, no figure stated
The vendor case study does not state any dollar figure, ransom, fraud loss, or breach-notification cost. Impact is described only as compromised credentials for "several users," which is the vendor's characterization rather than a measured count, with no confirmed data exfiltration.
Status
Documented incident
Case Type
Real-World Incident
Sector
Not Disclosed / Unspecified
Threat Actor
unknown
Explore more

Related Cases

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