DEBULL Device-Code Phishing Against Microsoft 365

Executive summary:

Reporting available through July 14, 2026 indicates that DEBULL is a reusable Microsoft 365 device-code phishing broker and operator platform rather than a single phishing page. During the late June to early July campaign, attackers used payment, shared-folder, and collaboration-themed lures to direct victims into Microsoft's legitimate device authentication flow. The DEBULL backend generated and polled device codes, allowing the operator to obtain valid OAuth tokens after the victim completed authentication and then reuse the authenticated session from attacker-controlled infrastructure. The same activity linked Microsoft Authentication Broker sign-ins to infrastructure hosting a DEBULL management panel and identified a post-authentication artifact named GraphSpy-Device. The observed tradecraft is consistent with Storm-2372-style device-code phishing, although there is no evidence attributing the activity to Storm-2372 itself. 

The primary objective is token theft rather than credential theft. Device-code authentication is a legitimate OAuth workflow designed for devices with limited input capability, where authentication is completed on a separate trusted page while the requesting application receives the issued tokens. DEBULL abuses this workflow by generating a legitimate device code and persuading the victim to complete authentication. Once the user approves the request, the attacker receives valid tokens that can be used until sessions and refresh tokens are revoked and the account is fully contained. 

We assess with moderate confidence that DEBULL is part of the broader criminal device-code phishing ecosystem that emerged during 2026. This assessment is based on the exposed operator panel, reusable broker endpoints, multiple lure templates, and a token-centric workflow consistent with other phishing platforms, including EvilTokens, ARToken, and Tycoon 2FA device-code variants. Device-code phishing first appeared in state-sponsored operations during 2024 and 2025 before expanding into criminal phishing-as-a-service offerings. Recent campaigns demonstrate the same authentication abuse being adapted for mailbox compromise, SharePoint access, business email compromise (BEC), and other cloud-focused post-authentication activity.

Activity observed:

The observed DEBULL chain is straightforward. A victim clicks a payment, shared-folder, or collaboration-themed link, including a compromised-site path such as /Team_Meets/. The page does not collect a password. Instead, it shows a fake secure-message or collaboration prompt, calls a DEBULL broker endpoint, opens the Microsoft device login page, and keeps polling the backend while the victim enters the code. In the reported case, the endpoint was frenksv[.]sbs/user/email/office_poll.php?uid=4, and the actions included get_auth_broker_device_code and poll_auth_broker_token. After the code was entered, the victim was redirected to outlook.office[.]com to lower suspicion.

The post-authentication activity carries the higher operational risk and showed an attacker-side Microsoft Authentication Broker session from 162[.]35[.]167[.]138, followed by OfficeHome or One Outlook Web activity from 96[.]126[.]176[.]130. The first IP address also exposed the DEBULL panel. The affected tenant later showed a GraphSpy-Device object, which supports a high-confidence assessment that GraphSpy, or a GraphSpy-derived tool, was used after authentication. The deployment layer also appeared to support page templates, analytics, custom domains, and Cloudflare Workers, which is consistent with an operator platform rather than a single phishing page. 

DEBULL fits the progression seen in earlier device-code cases. In early 2025, researchers documented Teams, Signal, WhatsApp, political, and collaboration-themed lures aimed at Microsoft 365 accounts. In August 2025, AWS described an APT29 watering-hole campaign that redirected visitors from compromised websites into Microsoft's device-code workflow. By April 2026, Microsoft reported criminal activity using on-demand device-code generation, serverless redirects, and post-compromise automation. DEBULL uses the same legitimate authentication surface, with criminal tooling layered around it.

Figure 1. DEBULL device-code phishing attack flow showing lure delivery, device-code initiation, token issuance, session reuse, post-authentication operations, and business impact.

Securonix Threat Labs summary:

Securonix Threat Labs recommends treating DEBULL-style activity as an identity-driven cloud intrusion, not as ordinary credential phishing. The campaign abuses the legitimate OAuth device-code flow: the victim completes authentication on Microsoft infrastructure while the attacker receives the usable session on the backend. The front-end lure can change, but the durable pieces are the broker, token handling, cloud persistence, and operator panel. Across DEBULL, EvilTokens, ARToken, and Tycoon 2FA variants, the lure is disposable. The broker and post-authentication workflow are what matter. 

The strongest detection signal is sequence. Look for an external collaboration lure, device-code authentication, Microsoft Authentication Broker activity, token or session use from attacker-controlled infrastructure, and follow-on mailbox, Graph, or device-registration activity. A single URL, sender, IP address, or device-code prompt may not be enough to identify the intrusion. During response, treat suspected activity as token-backed account takeover until session use, cloud persistence, mailbox access, and device registration have been reviewed. 

Recent landing-page hunting found hundreds of matching device-code phishing pages, including samples observed close to the reporting window. That suggests device-code phishing remains active and scalable across multiple infrastructure sets, not just a single DEBULL cluster.

Detection and hunting:

Treat DEBULL as an identity-flow problem, not only as a phishing URL. Start with the chain of events: lure delivery, device-code initiation, Microsoft Authentication Broker sign-in, session continuation from another IP or hosting provider, and post-authentication operations such as device registration or inbox-rule creation. That sequence is consistent across 2025 and 2026 reporting. 

In Microsoft Entra sign-in logs, use AuthenticationProtocol = deviceCode to identify the initial device-code authentication event. Correlate this with OriginalTransferMethod = deviceCodeFlow, which can remain associated with later refreshes and downstream activity even when subsequent sign-ins no longer report deviceCode as the current authentication protocol. Together, these fields help reconstruct device-code authentication activity across the lifecycle of a compromised session. 

Next, correlate Microsoft Authentication Broker sign-ins with OfficeHome or One Outlook Web activity from a different IP address within a short time window. This sequence is a strong indicator of potential session handoff following device-code authentication. In DEBULL activity, Microsoft Authentication Broker activity from 162[.]35[.]167[.]138 was followed by OfficeHome or One Outlook Web activity from 96[.]126[.]176[.]130 within approximately 15 minutes. Hunt for the GraphSpy-Device artifact where present, but do not depend on that indicator alone. Review device-registration events, including Register device, Add device, and Add registered owner to device, to identify potential post-authentication persistence. 

Post-compromise hunting should include both mailbox and broader cloud activity. Hunt for suspicious inbox-rule creation and MailItemsAccessed events following device-code authentication. One observed pattern involves Exchange Online activity with ApplicationId == "20893" creating inbox rules whose names consist only of special characters. Another involves mailbox access originating from an uncommon ISP or hosting provider. These behaviors are consistent with post-authentication activity observed in recent device-code phishing campaigns, including mailbox reconnaissance, finance-thread discovery, SharePoint access, and business email compromise (BEC) preparation after token acquisition. 

Web and content artifacts can provide useful pivots during investigations. For DEBULL, review /user/email/office_poll.php, /user/email/deploy.php, ajax/deploy_ajax.php?action=deploy_page, "DEBULL Secure Mail System", and "DEBULL Admin Panel". For related phishing kits, hunt for EvilTokens API paths such as /api/device/start and /api/device/status/<sessionId>, the X-Antibot-Token header, ARToken panel and C2 domains, the artoken_jwt localStorage artifact, and hardcoded operator UUIDs associated with ARToken tooling.  

Landing-page artifacts provide another useful detection layer. Recent device-code phishing campaigns used HTML attachments that referenced a clickable image attachment before directing victims to a landing page that displayed a device code and sent them to the legitimate Microsoft device authentication page. The landing page inserted invisible Unicode format characters, including zero-width space, zero-width non-joiner, and word joiner, to fragment common phishing terms such as "Agreement," "Verify," "Microsoft," and "account." Defenders should inspect HTML attachments, HTTP response bodies, and crawled landing pages for these artifacts, particularly when they appear alongside device-login URLs, device-code parameters, or repeated polling requests to the phishing infrastructure.

Mitigation and response guidance:

Block device-code flow by default unless there is a documented business requirement. Begin with a report-only deployment to identify legitimate usage, then enforce restrictions after validating dependencies. Because device-code authentication is uncommon in most enterprise environments, broad restriction typically has limited operational impact. 

Where exceptions are required, keep them narrowly scoped and limited to approved users, devices, or workloads that depend on device-code authentication for registration or reauthentication. Roll out changes in phases, monitor sign-in activity, exclude device-registration resources only where necessary, and require every exception to have a documented owner, business justification, and periodic review. 

Treat suspected DEBULL-style activity as an active account takeover until the investigation determines otherwise. Immediately revoke active sessions and refresh tokens, review active sign-ins, remove unauthorized mailbox rules, inspect OAuth grants, review registered devices, and verify recent authentication method changes. If there are signs of ongoing session use, temporarily disable the affected account, preserve relevant logs, and restore access only after all persistence mechanisms have been removed. A successful password reset alone should not be treated as evidence of containment, as valid access tokens may already have been used to access mailboxes, stage invoice fraud, identify finance workflows, or distribute follow-on phishing messages from the compromised account. 

User awareness should address device-code phishing specifically. Users should not enter a device code received through email, chat, shared documents, security notifications, or collaboration messages unless they initiated the sign-in themselves on another trusted device and expected the authentication request. Because the authentication page is legitimate, validating the URL alone is not a reliable defense. Users should instead confirm that they initiated the authentication flow and recognize the application or service requesting the device code.

Priority actions:

Recommended hunt sequence:

Start by identifying users with recent device-code authentication or Microsoft Authentication Broker sign-ins. Correlate those events with email clicks, web activity, and mailbox operations within the same timeframe. Then determine whether the authenticated session was reused from a different IP address, whether new device objects were created, and whether follow-on Graph or Exchange activity occurred. 

Add a hunt for repeated POST requests from the victim endpoint to the phishing kit host at roughly four-second intervals after the Microsoft device-login flow starts. In the reported campaign, the POST body used URL-form encoding and included the device code in a dc key-value pair. This pattern can help connect the landing page, the device-code workflow, and backend polling activity. 

Prioritize hunting for the following sequence: 

• Successful device-code authentication, particularly when preceded by a waiting or interrupted authentication event. 

• Microsoft Authentication Broker activity originating from unfamiliar infrastructure. 

• OfficeHome, Outlook, Exchange, SharePoint, OneDrive, Teams, or Microsoft Graph activity from a different IP address shortly after the broker sign-in. 

• Changes to mailbox rules, forwarding, delegation, OAuth consent, mail access, or file downloads. 

• New device registrations, unfamiliar device objects, or recent authentication method changes. 

• Outbound phishing or suspicious email activity originating from the compromised mailbox. 

Network-sequence hunting logic:

Network telemetry can also help identify the early stages of device-code phishing. Hunt for a user endpoint visiting a suspicious landing page, followed by authentication traffic to aka.ms, login.microsoftonline[.]com, aadcdn.msftauth[.]net, and login.live[.]com in a short window. A second authentication sequence may include login.microsoftonline[.]com, aadcdn.msftauth[.]net, browser.events.data.microsoft[.]com, and login.live[.]com. The Microsoft authentication traffic is not malicious by itself. It becomes suspicious when it occurs close in time to the phishing page visit and repeated POST activity from the endpoint back to the phishing kit.

Appendix A: Indicators of compromise:

Appendix B: MITRE ATT&CK mapping:

Appendix C: Detection artifacts:

References:

1. DEBULL: Storm-2372-Style Microsoft Device-Code Phishing With GraphSpy Post-Exploitation | ZeroBEC. https://zerobec.com/blog/debull-storm-2372-microsoft-device-code-phishing-graphspy 

2. OAuth 2.0 device authorization grant - Microsoft identity platform | Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-device-code 

3. Storm-2372 conducts device code phishing campaign | Microsoft Security Blog. https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/ 

4. Inside an AI-enabled device code phishing campaign | Microsoft Security Blog. https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/ 

5. Multiple Russian Threat Actors Targeting Microsoft Device Code Authentication | Volexity. https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ 

6. Block authentication flows with Conditional Access policy - Microsoft Entra ID | Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows 

7. Restrict device code flow for Microsoft Teams devices with Conditional Access - Microsoft Entra ID | Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-teams-devices-device-code-flow 

8. When checking the URL isn't enough: phishing via the Microsoft identity platform | Securelist. https://securelist.com/microsoft-device-code-phishing-attack/120350/ 

9. ARToken: Inside an EvilTokens affiliate panel targeting Microsoft 365 | Cisco Talos. https://blog.talosintelligence.com/artoken-inside-an-eviltokens-affiliate-panel-targeting-microsoft-365/ 

10. Spectra Analyze in Action: Hunting Device Code Phishing Pages | RL Research Team. https://www.reversinglabs.com/blog/device-code-phishing-walkthrough

11. Device Code Phishing is an Evolution in Identity Takeover | Proofpoint. https://www.proofpoint.com/us/blog/threat-insight/device-code-phishing-evolution-identity-takeover 

12. New widespread EvilTokens kit: device code phishing as-a-service | Sekoia. https://www.sekoia.com/blog/new-widespread-eviltokens-kit-device-code-phishing-as-a-service-part-1 

13. EvilTokens: an AI-augmented phishing kit for automating BEC fraud | Sekoia. https://www.sekoia.com/blog/eviltokens-an-ai-augmented-phishing-as-a-service-for-automating-bec-fraud-part-2 

14. Tycoon 2FA Operators Adopt OAuth Device Code Phishing | eSentire. https://www.esentire.com/blog/tycoon-2fa-operators-adopt-oauth-device-code-phishing 

15. Amazon disrupts watering hole campaign by Russia's APT29 | AWS Security Blog. https://aws.amazon.com/blogs/security/amazon-disrupts-watering-hole-campaign-by-russias-apt29/