Unboxing Phishing Kits: Huntress Examines 3 Real Kits
Recap of a Huntress Tradecraft Tuesday session (October 2026) on phishing kits that target Microsoft 365 tokens, including EvilTokens (a device-code phishing campaign abusing Railway) and the Kali365 control panel. It explains device-code phishing, adversary-in-the-middle and token replay. It lists detections (unfamiliar cloud sign-ins, device-code auth, new devices) and response steps (revoke refresh tokens, remove rogue devices, block device-code flow).
What it is
A Huntress Tradecraft Tuesday session (October 2026) with Staff Threat Intelligence Analyst Andrea Hatcher and Staff Product Manager Rich Mozeleski. They walked through three phishing kits aimed at Microsoft 365 tokens: EvilTokens, the Kali365 control panel, and a third the page does not name. EvilTokens is a device-code phishing campaign that abused the Railway PaaS to harvest and replay tokens. A Microsoft Digital Crimes Unit and FBI effort led to the arrest of one alleged operator a few weeks before the session. Huntress found the campaign in February.
How it works
In device-code phishing, the victim authenticates with the real identity provider and the attacker captures the resulting authorization, so no password is surrendered. In adversary-in-the-middle (AitM) phishing, the attacker relays the login in real time and captures the session after the victim completes MFA. With a stolen token, the kit replays it into a live session to reach cloud resources and email. Hatcher describes Kali365 as covering infrastructure, credential collection, persistence and scaling, including AI features.
Preconditions / Affected
Microsoft 365 tenants that leave device-code flow enabled. Mozeleski says "the vast majority of Microsoft environments do not need device code flow." Huntress ITDR estimates that one in six of its incidents involved a rogue device registration. In a live audience poll, 36 percent of respondents had seen device-code phishing in the wild.
What to do
Prevention: restrict or block device-code authentication, using Conditional Access Policies as Mozeleski recommends.
Detection, correlated across identity provider, endpoint, browser, network and mailbox (Hatcher: one signal is weak, the sequence is strong):
- Successful sign-ins from unfamiliar cloud infrastructure.
- Device-code authentication and automated token refresh.
- New devices, new authentication methods and mailbox activity.
Containment must target identity artifacts, not just the lure:
- Revoke refresh tokens.
- Remove unauthorized devices and Windows Hello credentials.
- Check mailbox access, forwarding rules and outbound phishing.
- Keep hunting after the original phishing domain disappears, watching for replay or re-entry.
In the audience poll, sign-in address and new device registration were the top two signals to check first when token theft is suspected.
Caveats
The page gives no queries, log field names or Conditional Access configuration steps. The one-in-six figure is Huntress's own estimate, and the 36 percent figure comes from a self-selected webinar audience poll.
Organisations named here
- FBI
- Microsoft Digital Crimes Unit
- token replay
Technologies named here
- Microsoft 365
- Huntress ITDR
- Microsoft environments using device code flow
- Conditional Access policies
- Railway PaaS
- Tradecraft Tuesday
- Windows Hello credentials
- Microsoft Entra ID
- Huntress
- Railway
Techniques named here
- Token theft and replay
- Audience poll
- Device code phishing
- Adversary-in-the-middle
Threat actors named here
- EvilTokens
- Kali365
Related in Threat Intel
Reverse Engineering the Six Stages of MacSync Stealer and RAT
AI-Coded Malware | Analyzing Vibe-Coded AD Enumeration | Huntress
