An IT director at a midsize logistics firm gets a Teams ping that looks like it’s from procurement. The message says a vendor portal needs her to authenticate, just enter this short code on microsoft.com. The URL is Microsoft’s. The code page is Microsoft’s. She types it in, approves the prompt on her phone, and attackers walk into her tenant. No password was stolen. No MFA was bypassed in any obvious way. The Tycoon2FA phishing kit now supports exactly this flow, and it’s quietly reshaping how cybersecurity teams have to think about Microsoft 365 account takeover.

The login flow built for things without keyboards

Microsoft’s device-code grant exists for a reason. Smart TVs, printers, CLI tools, and IoT devices can’t easily render a full browser login. So Microsoft built a flow where the device shows a short alphanumeric code, the user types it into microsoft.com/devicelogin on a separate device, authenticates normally, and the original device gets an access token. It’s elegant. It’s also exactly what a phishing kit needs: a Microsoft-hosted, MFA-completing, token-issuing endpoint that the victim approves on a real device.

BleepingComputer’s reporting on the Tycoon2FA update describes the operator workflow plainly. The attacker initiates a device-code request against the victim’s tenant, gets back a code, and sends that code to the target wrapped in a plausible pretext. The victim enters it, completes MFA on their own phone, and the kit collects the refresh token. Because the user really did authenticate, conditional access policies that hinge on MFA being present see a perfectly clean sign-in. The session lives until the refresh token expires, which on most tenants is measured in weeks.

Why a security vendor’s tracker became the delivery vehicle

The other detail in the writeup deserves more attention than it’s getting. Tycoon2FA is now routing victims through Trustifi click-tracking URLs. Trustifi is an email security vendor. Its tracking domain sits on the allow-lists of essentially every secure email gateway that integrates with it, and its URLs pass through reputation filters without triggering anything.

That’s the bind. The link in the phishing email points to a legitimate, paid security service that wraps the real malicious destination. The recipient’s mail security stack inspects the wrapping URL, sees a known-good vendor, and lets it through. Click-time URL rewriting was supposed to be the answer to attacker-side payload swaps. In this case, it’s the delivery mechanism.

This isn’t a knock on Trustifi specifically. Any click-tracking or URL-rewriting service can be weaponized this way, and most have been at some point. The wider lesson is that allow-listing on vendor reputation creates exactly the kind of trusted channel that mature kits look for. Defense in depth assumes no single layer is sound; URL-rewriter trust quietly violates that.

What actually works against device-code phishing

Brute-force password protection doesn’t help here. No password was ever asked. Conventional MFA doesn’t help either, because the user is the one completing it. The defense has to move up the stack to identity policy and threat detection.

Start with conditional access. Microsoft Entra supports a policy that blocks the device-code grant outright for users and groups who don’t need it, which is most of your workforce. If your finance team has never authenticated a printer or smart TV through your tenant, they should not be able to complete a device-code flow. Carving out a narrow exception group for the handful of users who legitimately need it, developers running Azure CLI on shared machines for instance, costs almost nothing operationally and removes the attack surface for everyone else.

Pair that with shorter refresh token lifetimes and continuous access evaluation, so a session that does get hijacked dies the next time the user’s risk score changes. Egress monitoring on Graph API patterns helps catch the post-compromise behavior. Bulk mailbox enumeration, OAuth app consent grants, and inbox rule creation are the classic post-AiTM moves and they look the same after device-code theft. Your incident response runbooks for adversary-in-the-middle kits mostly still apply; only the initial access vector changes.

For the URL-rewriter problem, the answer is less clean. Stop blindly trusting any single vendor’s tracking domain in your detection pipeline, and feed click-time destinations into your URL detonation and reputation lookups, not just the wrapper. Some EDR vendors will detonate the unwrapped target automatically. Most secure email gateways will not, unless you tell them to.

The patching story underneath

While Microsoft 365 defenders chase device-code abuse, the NGINX team is dealing with CVE-2026-42945, a heap buffer overflow in the rewrite module that’s now being exploited in the wild for worker crashes and possible remote code execution. VulnCheck flagged active exploitation within days of public disclosure. If you run NGINX Plus or NGINX Open in versions 0.6.27 through 1.30.0 with rewrite rules in your configs, patching is not optional this week. Web application firewall rules in front of the vulnerable endpoints can buy time while you stage updates, but they aren’t a fix.

The thread connecting Tycoon2FA and the NGINX exploitation is unflattering. Both stories show defenders losing ground at the points they previously considered solved: an authentication flow blessed by the platform vendor, and a load-balancer module that has shipped since the Bush administration. Security hardening teams need to stop treating either category as background noise. The maturity of a system has stopped predicting its risk.

Frequently Asked Questions

Does our existing MFA stop device-code phishing?

No. The victim completes MFA themselves on a trusted device, so the attacker inherits a fully authenticated session. The fix lives at the policy layer (block or scope the device-code grant), not at the MFA layer.

Is it still safe to keep our email security vendor’s URL rewriting enabled?

It’s still worth doing for the cases it catches. Just don’t allow-list the wrapper domain in downstream detection tools, and make sure your sandbox detonates the unwrapped destination rather than the rewriter URL.

Sources

• Tycoon2FA hijacks Microsoft 365 accounts via device-code phishing
• NGINX CVE-2026-42945 Exploited in the Wild, Causing Worker Crashes and Possible RCE