The Attack That Doesn’t Need a Fake Login Page
Most phishing attacks rely on a convincing replica of a login page. The user types credentials, and the attacker grabs them. Simple. But a campaign spotted by ZeroBEC between late June and early July 2026 took a different approach. It didn’t need a fake Microsoft password page at all.
Instead, attackers pushed victims into the legitimate Microsoft device login experience. The trick? Weaponizing a feature designed for convenience: device-code flow, also known as device-code authentication.
The tooling behind this campaign, tracked as DEBULL, represents a growing threat to Microsoft 365 (M365) accounts. And the lures? They look like collaboration invites — the kind employees click without thinking twice.
How Device-Code Flow Becomes a Weapon
Device-code flow was built for devices that can’t handle a full browser login — smart TVs, IoT gadgets, or command-line tools. The user gets a code, enters it on a separate device, and authenticates. It’s useful. But it also has a dangerous property: the authentication happens on the attacker’s session, not the victim’s.
Here’s how the DEBULL campaign exploits that:
- The attacker initiates a device-code authentication request for a legitimate M365 application.
- The victim receives a lure — typically an email or message about a shared document, calendar invite, or team collaboration — that directs them to
microsoft.com/devicelogin.
- The victim enters the code shown in the lure. This ties the attacker’s session to the victim’s approval.
- The attacker now holds a valid token. They can access the victim’s email, files, and contacts without ever knowing the password.
No fake page. No stolen password. Just a clever abuse of a legitimate flow. The victim thinks they’re approving access to a shared file. In reality, they’re handing over their account.
Collaboration Lures: The Hook That Works
ZeroBEC’s analysis highlights that the campaign leaned heavily on collaboration-themed phishing lures. These aren’t generic “your account has been compromised” scare tactics. They’re specific: a shared OneNote notebook, a Teams meeting invitation, a document from a colleague.
For someone working in a busy office, that’s plausible. You get a message saying “Sarah shared a file with you” — you click. The page looks official because it is official. Microsoft’s own login flow. The only difference is the attacker chose the code.
This is social engineering at its most surgical. The attacker doesn’t need to spoof Microsoft’s UI. They just need the victim to trust the context of the message.
DEBULL Tooling: What Makes It Different
The name DEBULL refers to the specific tooling used to automate this attack. Unlike manual device-code phishing, DEBULL operates at scale. It can generate device codes, send lures, and harvest tokens automatically.
Key characteristics of DEBULL include:
- Automated code generation – The tool requests multiple device codes from Microsoft’s OAuth 2.0 endpoint, cycling through them to avoid detection.
- Integration with email or messaging platforms – It sends lures that appear to come from trusted collaboration services.
- Token harvesting – Once a victim enters the code, DEBULL captures the resulting access token and refresh token, granting persistent access.
This isn’t a one-off phishing kit. It’s a modular framework designed for repeated use. And because the authentication happens on Microsoft’s own servers, traditional security filters — the ones that flag fake login pages — don’t catch it.
Why This Is Hard to Detect
Device-code flow abuse is notoriously tricky to stop. Here’s why:
- No phishing domain – The victim never leaves Microsoft’s legitimate site. URL filters see
login.microsoftonline.com and allow it.
- No credential entry – Passwords aren’t typed or stolen. The attacker authenticates using the victim’s approval, not their password.
- Tokens live longer – Refresh tokens can remain valid for days or weeks, even if the victim changes their password.
ZeroBEC noted that the campaign targeted M365 accounts specifically, likely because of the rich data inside: email threads, SharePoint files, Teams chats. Once inside, an attacker can pivot to business email compromise (BEC) or data exfiltration.
Organizations relying solely on password-based security miss this entirely. Multi-factor authentication (MFA) helps — but only if the MFA challenge is tied to the legitimate session. In device-code flow, the MFA prompt appears on the attacker’s device, not the victim’s.
How to Defend Against Device-Code Phishing
There’s no single fix, but several measures reduce the risk:
- Disable device-code flow – For most users, device-code authentication isn’t necessary. Administrators can block it in Azure AD conditional access policies.
- Educate users – Train employees to recognize that entering a code on
microsoft.com/devicelogin grants access to someone else. If they didn’t initiate the request, they shouldn’t enter the code.
- Monitor for unusual token activity – Security teams can audit token grants and look for device-code authentications from unexpected locations or devices.
- Use token binding – Where possible, enforce token binding to tie tokens to specific devices, making stolen tokens harder to reuse.
Microsoft has also taken steps to limit abuse, including rate-limiting device-code requests and adding warnings in the device-login interface. But attackers adapt. DEBULL is proof that device-code phishing isn’t going away.
The bottom line? The most dangerous attacks don’t always look like attacks. Sometimes they look like a shared file from a colleague — and a code that seems harmless to type.
