Jul 09, 2026 · 7 min read
DEBULL Is the Third Device Code Kit to Hit Microsoft 365
A Turkish linked phishing as a service platform hijacked Microsoft 365 accounts through a compromised Croatian rental site and payment lures in June and July 2026, the third distinct device code kit in three months.
A phishing operator sends an email about a shared invoice. The victim clicks, lands on a real Microsoft login page, types a six character code, and approves it. No password stolen. No MFA prompt bypassed in the traditional sense. The attacker now holds a fully valid access token, and the victim just handed it over themselves. This is DEBULL, a phishing as a service platform that The Hacker News detailed on July 7, 2026, and it's the third distinct kit built around this exact technique to surface since April.
Key Takeaways
- DEBULL is a phishing platform documented by The Hacker News on July 7, 2026, and by threat research firm ZeroBEC, which observed campaign activity from late June through early July 2026.
- DEBULL abused a compromised Croatian rental website as a device code orchestrator and used payment and shared folder lures rather than the cloud collaboration themes seen in Kali365 or EvilTokens.
- The technique traces to Storm-2372, a Russia aligned actor Microsoft first documented in February 2025, and DEBULL's codebase carries Turkish language developer markers.
- Microsoft recommends organizations block the device code authentication flow entirely via Conditional Access, since legitimate business use of it is rare.
- DEBULL is the third named device code phishing kit gblock has tracked since April 2026, after Kali365 and EvilTokens, signaling the technique has moved from nation state tradecraft to a repeatable commercial product line.
What Is DEBULL?
DEBULL is a phishing as a service platform built specifically to package device code phishing against Microsoft 365 and Entra ID accounts. According to The Hacker News, the platform doesn't rely on a fake Microsoft password page at all, it pushes victims into the real Microsoft device login experience while a back end broker generates and polls device code tokens through the Microsoft Authentication Broker.
Operators running DEBULL get a self service kit: they define a page name and slug, edit the HTML, CSS, and JavaScript of the lure directly, then publish it through Cloudflare Workers or a custom domain. The embedded templates include a Microsoft 365 device code page, an OAuth callback handler, and a landing page with a copy code button linking straight to Microsoft's own device login URL. Post exploitation (mailbox access, Graph API reconnaissance, persistence) is handled separately through GraphSpy or a GraphSpy derived toolset, rather than a built in dashboard.
That last detail matters for defenders: DEBULL is a lure factory, not a monolithic attack platform. It's cheaper to build, easier to modify, and harder to fingerprint as a single signature because the front end and back end are decoupled.
How Does Device Code Phishing Defeat MFA?
Device code phishing works by abusing a legitimate protocol, not by breaking one. Microsoft's own OAuth 2.0 device authorization grant exists to let input constrained devices (smart TVs, printers, IoT hardware) authenticate without a keyboard: the device requests a short lived user_code, displays it, and the person authenticates on a second device by visiting a verification URL and entering that code, per Microsoft's identity platform documentation. By default the code is valid for 15 minutes, and once approved, Microsoft issues an access token, a refresh token, and an ID token, a fully legitimate credential set, no different from what any authorized device would receive.
Attackers exploit the gap between "user authenticates" and "user authenticates for the reason they think they are." A phishing email delivers a code and a link to the real microsoft.com/devicelogin page. The victim signs in with their own password, satisfies their own MFA (a push notification, an authenticator app, whatever their organization enforces) and then pastes in the code the attacker generated. Microsoft has no way to know that code belongs to a phishing kit's polling script rather than the victim's own smart TV. The token that gets issued is real, long lived, and travels home to the attacker's infrastructure the moment the victim clicks approve.
That's why this technique is structurally different from credential phishing or adversary in the middle proxy attacks, there's no password to steal and no session cookie to intercept. The MFA challenge gets solved, just not by the person who benefits from it.
How Is DEBULL Different From Kali365 and EvilTokens?
Three named kits now build on this same primitive, and each looks different operationally. Kali365 surfaced in April 2026, distributed through Telegram to affiliates and resellers, and layered on AI generated lures, a victim tracking dashboard, and a second attack mode called Cookie Link that proxies live browser sessions. EvilTokens compromised more than 340 Microsoft 365 tenants across five countries within five weeks, per earlier reporting, and runs a full featured operator dashboard with more than 80 API endpoints.
DEBULL breaks from both patterns. Rather than a self contained dashboard, it's a modular lure delivery layer that hands post exploitation off to GraphSpy. Rather than cloud collaboration or document sharing themes, DEBULL's June to July campaign used payment and shared folder pretexts routed through a legitimate but compromised Croatian rental website functioning as the device code orchestrator, borrowed infrastructure instead of dedicated attacker owned domains, which reduces the indicators a defender can block outright. And unlike Kali365 or EvilTokens, DEBULL's code carries Turkish language developer markers and tradecraft overlaps strong enough that researchers link it to Storm-2372, the Russia aligned group Microsoft first documented running Teams and WhatsApp themed device code lures against government and NGO targets in August 2024.
Why Email Users Should Care
Every device code phishing campaign starts in an inbox. Whether the lure is a fake Teams invite, a shared document notification, or, in DEBULL's case, a payment or folder sharing email, the initial delivery mechanism is identical to any other phishing attempt: a message designed to make a routine business action feel urgent enough to click without scrutiny.
What makes this family of attacks worse for email users specifically is that traditional advice, "check the URL before you log in," doesn't help. The victim genuinely lands on login.microsoftonline.com. There's no spoofed domain to spot, no fake certificate warning, nothing a browser's built in phishing filter is likely to catch, because the page itself is real. The only tell is the code and the framing around it: a message urging the recipient to enter a specific code on a login page they weren't expecting to visit.
This is also why device code lures increasingly ride alongside other inbox based reconnaissance and social engineering techniques rather than replacing them, a shared folder or invoice pretext works precisely because it mimics the volume of legitimate collaboration email most Microsoft 365 users receive daily.
How Should SOC Teams Detect and Defend Against This?
Detection has to move upstream of the login prompt, because by the time authentication succeeds, the token is already legitimate. Microsoft's own guidance is direct: block the device code authentication flow entirely through Conditional Access unless a specific, documented business case requires it, such as certain Teams meeting room devices. Microsoft explicitly states device code flow is "rarely used by customers, but is frequently used by attackers," and recommends organizations audit existing usage before rolling out a blanket block with break glass accounts excluded.
Beyond the blanket block, security teams should:
- Alert on
urn:ietf:params:oauth:grant-type:device_codegrant types appearing in sign in logs for any account or app not explicitly exempted. - Watch for the Microsoft Authentication Broker client ID appearing in device registration events, the same pivot Storm-2372 used to obtain persistent Primary Refresh Tokens.
- Treat "enter this code to continue" language in inbound email as a training worthy red flag on par with credential harvesting links, since neither a spoofed domain nor a certificate warning will appear.
- Correlate new device code grants with subsequent Graph API calls searching mailboxes for terms like "password," "admin," or "credentials," a known post compromise pattern from this attack family.
The Trend Behind DEBULL
Three named, independently built device code phishing kits in roughly three months is not noise, it's a technique that started as nation state tradecraft in 2024 and has now fully commercialized. Kali365 sells subscription access on Telegram. EvilTokens ships a dashboard rivaling legitimate SaaS products. DEBULL shows the next iteration: strip the kit down to a disposable front end and outsource everything else to existing tooling, making it faster to stand up and harder to kill by domain takedown alone. If this modular pattern proves cheaper to operate than a full dashboard, expect more of the device code phishing market to follow DEBULL's architecture rather than EvilTokens', which raises the bar for defenders who currently key their detections off a single kit's infrastructure fingerprints.