Anatomy of a modern phishing kit: quishing, device codes and ClickFix

A phishing kit is a product#

When people say "phishing page" they usually picture a bad copy of a login form on a throwaway domain. That picture is about ten years out of date.

What attackers buy today is a platform. The best documented example is Tycoon2FA, which Microsoft's analysis describes as one of the most widespread phishing-as-a-service kits, behind tens of millions of phishing messages a month reaching over 500,000 organisations. Buyers got a web panel with pre-built lure templates, attachment generators, domain and hosting configuration, redirect logic and a live dashboard of victims. It was advertised on Telegram and Signal, starting at $120 for ten days or $350 for a month.

Its successor in the headlines, EvilTokens, appeared in February 2026 and Microsoft reports it compromised more than 12,000 inboxes in over 10,000 organisations. It sold at $1,500 up front and $500 a month, with 44 lure themes and an AI assistant for writing targeted emails and sifting through stolen mailboxes. ClickFix builders, sold on hacker forums since late 2024, run from $200 to $1,500 a month.

That is the real change. The skill needed to run a convincing, MFA-bypassing campaign has dropped to a monthly subscription. This post takes the kit apart, then looks at three techniques that matter most right now: QR code phishing, device code phishing, and fake CAPTCHA ClickFix attacks.

The anatomy of a kit#

The detail varies, but nearly every serious kit has the same layers. I am using Tycoon2FA as the reference because Microsoft has published the most complete teardown.

1. The lure. The email, attachment or link that starts it. Notably the kit often does not send the mail itself. Tycoon2FA did not include a mailer, so operators brought their own sending infrastructure or hijacked real mailboxes. Lures are templates that impersonate Microsoft 365, SharePoint, DocuSign, Okta and others, and they often arrive in a genuine conversation thread from an account that has already been compromised.
2. The container. What carries the link. For Tycoon2FA that meant PDFs or Word files with QR codes, SVG files with embedded redirect logic, small HTML attachments, and redirect links through trusted services.
3. The redirect chain. Victims are bounced through several intermediate hosts, including Azure Blob Storage, Firebase, Wix and Cloudflare Workers, so that no single URL looks bad and static URL extraction or sandbox detonation struggles.
4. The gate. Before the phishing content appears, the victim passes a CAPTCHA. It looks reassuring to a person and blocks automated scanners. Tycoon2FA rotated custom CAPTCHA challenges built on randomised HTML5 canvas elements so that signatures kept going stale.
5. The cloak. The kit checks who is looking. It fingerprints the browser, filters datacentre IP addresses, restricts by geography, profiles user agents, blocks right click and developer tool shortcuts, and detects automation tools. If it suspects analysis it serves a decoy page or a 404. This is why a URL a user reported can look perfectly clean when an analyst opens it.
6. The engine. The part that actually steals access. For an adversary-in-the-middle (AiTM) kit it is a reverse proxy that shows the victim the real sign-in flow, relays their password to the real service, relays the real MFA challenge back, and keeps the session cookie that results. For other kits the engine is a device code poller or a clipboard payload, which I cover below.
7. The capture and exfiltration. Credentials, cookies and tokens are shown in the panel and often forwarded to a Telegram bot in real time.
8. The follow-on. With a valid session, the operator reads mail, creates inbox rules to hide their tracks, registers their own authenticator app or device for persistence, and sends the next wave of phishing from the victim's real account. EvilTokens added AI triage to find the finance and executive mailboxes worth the effort.
9. The infrastructure churn. Campaign domains are short lived, often 24 to 72 hours, spread across cheap generic top-level domains and hosted mostly on Cloudflare. Subdomains moved from random strings to readable words such as "cloud", "docker", "sharepoint" and "azure" to defeat detection that looks for gibberish.

None of the layers is clever on its own. The strength is the integration and the maintenance. Updates are pushed to customers through an announcement panel, like any software product.

Takedowns do not end the model#

Both kits have been disrupted. Microsoft's Digital Crimes Unit, with Europol and industry partners, took action against Tycoon2FA's infrastructure, and coordinated a disruption of EvilTokens. That matters, and it is worth supporting.

It also does not make the problem go away. Barracuda's follow-up, Tycoon 2FA didn't die, it's scattered everywhere, describes the capabilities redistributing across competing kits. Microsoft itself notes Tycoon2FA grew partly because earlier services like Caffeine and RaccoonO365 were disrupted. Kits are replaceable. Your defence needs to work against the technique, not the brand.

Quishing: moving the attack to a phone#

QR code phishing, or quishing, puts the malicious link inside an image. It has three advantages for the attacker, and the NCSC spells them out well:

• People have learned to distrust suspicious links, but a QR code hides the destination.
• Not every email security tool scans images, so the link can slip past.
• People scan with a personal phone, which usually has none of the protections of a managed work laptop.

That last point is the heart of it. The FBI's warning about Kimsuky describes quishing as forcing the victim to pivot from a corporate endpoint to a mobile device, outside normal endpoint detection and network inspection. After the scan, victims go through attacker redirectors that collect the user agent, operating system, IP address, locale and screen size, and then show a mobile-optimised credential page impersonating Microsoft 365, Okta or a VPN portal. These operations frequently end in session token theft, which, in the FBI's words, bypasses MFA "without triggering typical 'MFA failed' alerts".

How big is it?#

Microsoft's Q1 2026 email threat report shows QR code phishing growing from 7.6 million messages in January to 18.7 million in March, a 146% rise over the quarter and the highest monthly volume in at least a year. PDF attachments carried 70% of them by March. A newer pattern is QR codes placed directly in the email body, which grew 336% in March, though from a small base of 5% of the total, and which removes the need for an attachment at all.

What helps#

• Decode the image. Ask your email security vendor whether it extracts and checks URLs inside QR codes in bodies, PDFs and images, rather than assuming it does.
• Do not make the phone the weak link. Require a compliant, managed device for access to core cloud apps, so a credential or session captured on a personal phone does not turn into access. The FBI also recommends mobile device management or endpoint security that can analyse QR-linked URLs before they load.
• Use phishing-resistant MFA. Passkeys and FIDO2 keys are bound to the real site, so a proxy page cannot relay them.
• Set a clear rule. A QR code that asks you to sign in to a work system is never a legitimate request. Nobody should authenticate by scanning a code from an email.
• Use the phone's built-in scanner, not a third-party app, as the NCSC advises.

Device code phishing: the attack that never asks for your password#

The device code flow exists for things that cannot show a proper sign-in page: smart TVs, printers, conference room devices. The device shows a short code, and you enter it at a Microsoft web address on your phone or laptop and sign in there.

Device code phishing turns that around. Per Microsoft's description, the attacker generates a real device code request and tricks the victim into entering the code on the legitimate sign-in page. When the victim approves it, the attacker receives valid access and refresh tokens.

Here is how a current kit runs it, based on Microsoft's EvilTokens analysis.

1. The victim gets a lure, such as "Action Required: Password Expiration", with a link or attachment.
2. The landing page runs a script that asks Microsoft's identity service for a live device code and shows it with a "Copy Code" button, then a "Continue with Microsoft" button.
3. The script often copies the code to the clipboard for them, and sends them to the real microsoft.com/devicelogin page.
4. In the background, the script polls the operator's server every few seconds across the 15 minute lifetime of the code, waiting for approval.
5. The victim pastes the code. If they are already signed in, one click completes it. If not, they sign in with their password and MFA, on the real site.
6. The attacker's session is now authorised. In some incidents the operator registered a new device within ten minutes to obtain a Primary Refresh Token for long-term persistence. In others they waited hours before creating inbox rules or pulling mail.

Why MFA does not stop it#

This is the part that surprises people. There is no fake sign-in page, so there is nothing to detect. The victim authenticates properly, with MFA, to the genuine service. They just authorise the wrong session. Microsoft notes that authentication is completed on a separate device, so the session that asked for access is not strongly bound to the user's original context.

That also means phishing-resistant MFA, which is what defeats an AiTM proxy, does not on its own stop device code phishing. A passkey proves you are on the real Microsoft site. It cannot tell you that the code you are approving belongs to someone else. That is why this one is best blocked at the flow level.

The technique is not new. Microsoft documented Storm-2372 using it in February 2025. What changed is industrialisation: EvilTokens put it in a kit with templates, AI lures and token management, and researchers at eSentire and LevelBlue have since reported Tycoon2FA infrastructure adopting device code payloads too.

What helps#

• Block device code flow with Conditional Access. Microsoft recommends blocking it wherever possible. In Entra, create a policy that includes all users and resources, uses the Authentication flows condition set to device code flow, and blocks access. The Learn guidance says to start in report-only mode and review sign-in logs first, because exceptions are needed.
• Scope exceptions tightly. Teams devices and some shared hardware genuinely need the flow. Microsoft's Teams device guidance uses a block-by-default policy with a persistent group of Teams device resource accounts and an exclusion for the Device Registration Service resource.
• Find out who uses it today. Review your sign-in logs for the device code authentication protocol before enabling the block, so you know which legitimate scenarios exist.
• Turn on Safe Links. Microsoft says Safe Links, combined with Entra ID Protection, can raise high-confidence device code phishing alerts.
• Watch what happens afterwards. Alert on inbox rule creation, new device registrations and sudden Microsoft Graph activity after a device code sign-in.
• Contain properly. Revoke the user's sessions, but note Microsoft's warning that standard revocation often invalidates only refresh tokens, leaving existing access tokens usable for up to an hour. For a hands-on actor, Microsoft recommends temporarily disabling the account.

ClickFix: the user is the exploit#

ClickFix needs no vulnerability, no malicious attachment and no credential. It needs a person to run a command.

The pattern, per Microsoft's analysis:

1. The victim lands on a page that looks like a CAPTCHA, a browser error or a "verify you are human" check. Often it impersonates Cloudflare.
2. When they click the button, JavaScript quietly writes a command to their clipboard with navigator.clipboard.writeText.
3. The page then tells them how to "fix" the problem: press Win+R, paste, press Enter. Or open Windows Terminal and paste.
4. The command downloads and runs a payload, usually through PowerShell or mshta, often entirely in memory.
5. What the victim sees pasted looks harmless. Splunk documented one that displayed I am not a robot - reCAPTCHA Verification Hash: 328459 while the real command ran silently.

The payloads range from infostealers, with Lumma Stealer the most prolific in Microsoft's observations, to remote access tools such as Xworm, AsyncRAT and NetSupport, and loaders like Latrodectus. On macOS the pasted command asks for the user's password in a loop, validates it, and installs the AMOS stealer.

Why it works so well#

• It gets around the email gateway, because most of it never arrives by email. Push Security's 2026 data says four in five ClickFix pages it intercepted were reached from search engines, through compromised sites, malvertising and SEO poisoning. (Push is a vendor, so read its figures as one view, but the direction matches Microsoft's.)
• It runs in a legitimate shell, started by the user, so it does not look like a malicious process chain, and in-memory execution leaves no file to detonate.
• It converts. Microsoft's 2026 Digital Defense Report, as cited by Push, puts ClickFix growth at roughly 23x between December 2025 and May 2026, with 96.3% of ClickFix intrusions leading to malware.
• It teaches itself to look normal. The kits are sold for $200 to $1,500 a month and promise antivirus and SmartScreen bypass.

The family keeps growing#

• FileFix moves the trick into the File Explorer address bar.
• TerminalFix points victims at Windows Terminal or PowerShell instead of Run, so long multi-line scripts work. Microsoft's August 2026 report describes one chain using a fake Cloudflare overlay on compromised sites, DLL sideloading, steganography, Active Directory reconnaissance and a reverse tunnel implant.
• InstallFix clones real install pages, including for AI coding tools, and swaps in a malicious command. Push describes a page that shows the genuine install command while the copy button writes a different one.
• LLMshare hosts the lure on shared AI chats, artifacts or custom GPTs, so URL reputation checks see a trusted domain.
• ConsentFix is browser-native, and Push links a December 2025 campaign to APT29.

The AI angle matters. As more staff install tools by pasting a terminal command from a web page, the "paste this" instruction stops looking strange.

What helps#

Most of this comes straight from Microsoft's guidance.

• Remove the Run dialog where nobody needs it, through Group Policy: User Configuration, Administrative Templates, Start Menu and Taskbar, Remove Run menu from Start Menu.
• Use App Control to stop native binaries like PowerShell being launched from Run.
• Warn on multi-line paste in Windows Terminal.
• Log PowerShell script blocks and send them to your detection platform. See PowerShell guardrails for admins.
• Turn on network protection and web protection, SmartScreen and cloud-delivered antivirus protection, so the download stage is blocked even if the paste happens. Microsoft reports that blocking the command and control domains early is what makes the attack fail.
• Enable attack surface reduction rules for obfuscated scripts and downloaded executable content.
• Do not rely on PowerShell execution policy. It is not a security boundary and does not stop an inline command.
• Hunt for the shape. A shell or mshta started by explorer.exe with CAPTCHA, "verify" or hidden-window wording in the command line, and entries in the RunMRU registry key. Elastic publishes a fake CAPTCHA detection rule that shows the logic.
• Cover the machines without EDR. Macs, contractor laptops and developer workstations are where the paste often lands unprotected. A managed browser that sees the page can help too, which is the argument in the office is a browser tab.

One idea behind all three#

Each of these techniques moves a security boundary somewhere defenders are not looking.

• Quishing moves the device. The decisive step happens on a phone that your endpoint tooling cannot see.
• Device code phishing moves the authentication session. The right user does the right MFA on the right site, for the wrong session.
• ClickFix moves the execution. Your own user starts the process, in a legitimate shell, in memory.

That is the same grey zone I described in the post on living off the land: nothing that looks obviously malicious, and every individual step valid. It is also why the account takeover that follows, described in the post on identity risk and ITDR, is the part you can still reliably catch.

A practical priority list#

If I had to order the work for a Microsoft-based organisation:

1. Block device code flow in Conditional Access, in report-only first, with tight exceptions. It is a small change that removes a whole attack class.
2. Require phishing-resistant MFA for admins first, then everyone, and require compliant devices for core apps. See conditional access patterns that survive real users.
3. Lock down Run and the shell where it is not needed, and log PowerShell script blocks.
4. Enable time-of-click link checking and make sure your email security decodes QR images.
5. Alert on what attackers do next: inbox rules, new MFA methods, new device registrations, and unusual Graph activity.
6. Practise containment. Revoke sessions, disable the account, remove malicious rules, devices and authentication methods, and rehearse it so it takes minutes.
7. Teach three short rules instead of a long awareness course:
   • A QR code in an email is never a reason to sign in.
   • Only enter a code you generated yourself, on a device you are setting up.
   • No website will ever need you to paste a command into Run or a terminal to prove you are human.

The same controls also line up with the MFA and patching expectations in the Cyber Essentials walkthrough, where leaving MFA off a cloud service is now an automatic fail.

Closing#

The phishing page is the least interesting part of a phishing kit. The interesting parts are the redirect chains that hide it, the gates that filter who sees it, the engines that harvest tokens instead of passwords, and the support channel that keeps customers one step ahead. QR codes, device codes and fake CAPTCHAs are three different front ends on the same business.

The encouraging part is that each has a specific, practical answer. None of them needs a bigger awareness budget. They need identity policy that does not trust a captured session, endpoints that do not let a pasted command run freely, and a response process fast enough that a stolen token has little time to be useful.

References#

Sources and further reading for the claims above.

• Microsoft Threat Intelligence, Inside Tycoon2FA: how a leading AiTM phishing kit operated at scale
• Microsoft Threat Intelligence, Unmasking EvilTokens: getting to the root of device code phishing
• Microsoft Threat Intelligence, Storm-2372 conducts device code phishing campaign
• Microsoft Threat Intelligence, Think before you Click(Fix)
• Microsoft Threat Intelligence, TerminalFix campaign deploys a reverse tunnel through multistage intrusion
• Microsoft, Email threat landscape: Q1 2026 trends and insights
• Microsoft Learn, Authentication flows as a condition in Conditional Access
• Microsoft Learn, Restrict device code flow for Microsoft Teams devices with Conditional Access
• NCSC, QR codes: what's the real risk?
• FBI, Kimsuky actors leverage malicious QR codes in spearphishing campaigns
• Push Security via BleepingComputer, ClickFix has never been bigger, and AI tools are its most convincing lure yet
• Barracuda, Threat spotlight: Tycoon 2FA didn't die, it's scattered everywhere
• eSentire, Tycoon 2FA operators adopt OAuth device code phishing
• LevelBlue SpiderLabs, The device code phishing tsunami
• Splunk, Beyond the click: unveiling fake CAPTCHA campaigns
• Proofpoint, ClickFix social engineering technique floods the threat landscape
• Elastic, Potential fake CAPTCHA phishing attack detection rule