Fetch got blocked, so I’ll search the same stories and write from what’s already in the brief.TITLE: The Kit Is Dead. Your Tokens Are Not

Microsoft’s Digital Crimes Unit helped knock EvilTokens offline this week. The phishing-as-a-service shop had climbed into the top tier of device code kits, pairing AI-written lures with automated infrastructure and straight token theft. The sessions already sitting in attacker hands still work. Your users already approved the code that replaced a password, and most cybersecurity tools treated that as a successful login.

You will put the takedown in a briefing. The refresh tokens will not appear on that slide unless someone hunts them.

A Takedown Does Not Kill a Stolen Session

Device code flow exists for a boring reason. A TV, a CLI tool, a kiosk with no keyboard worth using. The user gets a short code, signs in on a real identity-provider page, and the waiting device receives tokens. Attackers copied the choreography and sold it as a service.

EvilTokens industrialized that handoff. Microsoft’s write-up put the scale in plain language:

EvilTokens has quickly become one of the top PhaaS platforms, enabling device code phishing attacks through AI-assisted lures, automated infrastructure, and token theft.

Read the last two words again. Token theft. The user authenticates on a genuine login page, often after MFA. Threat-protection controls that hunt fake domains miss a lot of this, because the domain is real. The code belongs to the attacker. The tokens come back to their infrastructure, then live on after the landing page is gone.

Once those tokens land, the phishing site is optional. Shutting down EvilTokens is good news for the next target. It is late for the tenant that already issued a refresh token last Tuesday. Password reset theater will look busy. The session keeps answering API calls until you revoke it.

Same week, a different door, same shape. Attackers used a compromised BigCommerce application key held by Ribon to reach customer data. No smash-and-grab on a storefront password. A partner-held secret that already authorized exports. If you run cyber security as a perimeter sport, both incidents look like someone else’s mess until the copy job finishes.

This is a bad look for identity programs that still measure success in blocked password sprays. The operator who bought EvilTokens did not need your hash dump. The operator who lifted Ribon’s app key did not need your users at all. Valid grants beat clever malware when you leave them lying around.

Device Code Phishing Walks Past Your Cybersecurity Stack

Your firewall is still doing its job. That is the trap. Device code phishing does not need to win a brute-force fight against VPN or RDP. It needs one person to type a code into a prompt that looks like IT, a shared file, or a printer onboarding flow. Defense in depth that stops at the edge never inspects the grant type.

Traditional phishing controls hunt lookalike sites, posted passwords, and impossible travel after a spray. This path skips the password. MFA succeeds because the user is the one completing it. Conditional access that only asks “did they pass MFA” will nod along and write a healthy sign-in. Your threat detection then files the event next to a laptop that actually belongs to the employee.

The logs do tell on it if you bother to parse them. Device code grants from user agents your fleet does not ship. Codes redeemed from address space that never touches your other apps. Sudden mail or directory API use from a session that started as a “device” sign-in. Token replay from hosting ranges your people do not sit on. If your pipeline never stores grant_type, you are guessing.

Incident response that starts with “reset the password” is slower than the attacker, because the password was never the prize. Security hardening for this is identity work. Disable device code flow where you do not have kiosks or headless tools that need it. If you do need it, bind it to named workloads, named networks, and named accounts. Treat unused device grants the way you treat unused VPN profiles: delete them before someone else uses them.

User awareness still helps at the margin. A help desk that never asks staff to enter a device code on a surprise ticket cuts a lot of EvilTokens-style lures. Training that only says “check the URL” does not, because the URL is legitimate. Teach the grant, not the domain.

The Ribon incident is the cousin you should keep in the same ticket queue. Third-party apps hold keys that skip your user MFA story entirely. An ecommerce platform key is a standing session with an export scope. If your SaaS inventory cannot list which partner integrations can pull customers, you are waiting for the same email those merchants are reading now.

Revoke the Grant, Then Hunt What You Missed

Do the ugly work this week, while the takedown is still in the news and leadership still cares. Then put the same checks on a calendar so the next kit does not get a free month.

• Disable the device authorization grant tenant-wide unless a named workload still needs it. Write down the exceptions, the owners, and the networks that may redeem a code. If nobody can name a kiosk that uses it, turn it off today.
• Query identity logs for device-code sign-ins over the last 90 days. Revoke refresh tokens on those accounts, force a new sign-in from a managed device, and review mail-forwarding, OAuth consents, and inbox rules before you close the ticket.
• Inventory SaaS apps and partner integrations with customer-data scopes. Rotate those keys on a schedule you can prove, and cut any integration that cannot show you who holds the secret. A vendor blog post is a late notification.
• Alert on device-code and consent grants from new ASNs the same way you page a VPN brute-force. If threat detection cannot see grant type, client app, and token replay, fix the pipeline before you buy another dashboard.
• Rewrite the incident response runbook so token revocation and app-key kill happen before password reset. The password was optional in both of this week’s stories. The session was the breach.

Takedowns are useful. They raise the cost of the next kit and they give you a week of air cover to change defaults. They do not retire a refresh token, and they do not rotate a partner key sitting in some contractor’s repo. If your cybersecurity program still celebrates blocked logins while device grants and app secrets stay on, you are counting the wrong wins.

Go pull the grant report. If it is empty, good. If it is not, you already know which accounts to call.

Sources

• Unmasking EvilTokens: Getting to the root of device code phishing
• BigCommerce Data Stolen via Ribon Apps Hack