DEBULL — Microsoft Device-Code Phishing (Storm-2372-style Tradecraft)

DEBULL is a reusable phishing-as-a-service (PhaaS) tooling layer that abuses Microsoft's legitimate OAuth 2.0 Device Authorization Grant (RFC 8628, the "device code" flow) to hijack Microsoft 365 and Entra ID accounts. ZeroBEC identified and blocked a campaign running from the last week of June 2026 into early July 2026. The Hacker News reported it on 2026-07-07.

Why it defeats conventional controls: there is no fake Microsoft login page and no adversary-in-the-middle proxy to fingerprint. A collaboration-themed lure (payment / shared-folder pretext) pushes the victim into the real Microsoft device-login experience at microsoft.com/devicelogin, while a backend broker generates and polls Microsoft Authentication Broker device-code tokens. The user authenticates on genuine Microsoft infrastructure and satisfies MFA legitimately — then unknowingly authorizes the attacker's session. No password is ever stolen, so credential-theft and AitM detections do not fire.

Why the Microsoft Authentication Broker client matters: Microsoft documented Storm-2372 shifting to this specific client ID because it returns a refresh token that can be exchanged for a device-registration token, letting the actor register an attacker-controlled device in Entra ID and obtain a Primary Refresh Token (PRT). That is persistence which survives a password reset — so password-reset-only response is insufficient.

Post-exploitation: after authentication in the observed case, a device object named GraphSpy-Device appeared in the tenant. ZeroBEC assesses with high probability that DEBULL uses GraphSpy or a GraphSpy-derived workflow for Microsoft Graph / Entra post-exploitation. The attacker session was created from the DEBULL origin and then continued from a second, separate attacker egress IP — geo-plausible US datacenter space chosen to avoid tripping obvious impossible-travel logic.

Bottom line for the hunt: this is an identity-plane threat. Endpoint EDR sees only the lure fetch (DNS/network to attacker infrastructure). Everything that matters — the device-code grant, the broker sign-in, the device registration, the PRT, the mailbox and SharePoint abuse — lives in Entra ID sign-in and audit logs and M365 unified audit logs. Hunt there first.

Analyst notes & caveats

• Attribution is deliberately loose. ZeroBEC states this is Storm-2372-style tradecraft, not Storm-2372. DEBULL appears to be a reusable tooling layer possibly operated by several operators. Do not report this to leadership as "Russian state actor" — that overstates the source.
• Turkish-language developer markers (Code'u otomatik kopyala in the lure page, SAYAÇ (expiration) in the panel header) are assessed by the source at only low-to-medium confidence as a code-lineage clue. They are not evidence of operator nationality.
• Single-vendor primary source. The DEBULL-specific infrastructure detail rests on one vendor report (ZeroBEC) plus THN's restatement of it. The technique is corroborated independently by Microsoft, Talos, Sekoia and Proofpoint. Weight the technique detections higher than the atomic indicators.
• Indicator perishability is high. The CloakGuard module lets operators publish new lures to Cloudflare Workers and custom domains on demand while the backend broker stays stable. Treat the domain/IP list as short-lived and lead with the behavioural queries (Q3–Q10).

Hunt hypotheses (fidelity-ordered)

Run these in Microsoft Sentinel or Defender Advanced Hunting. They are the authoritative view of the device-code flow and should be run first, before the CQL in §8 — if your Entra logs are not yet in Falcon NGSIEM, these are your entire hunt.

N1 · Device-code URL clicks (Microsoft-published)

Microsoft's own detection query for possible device-code phishing: correlate clicks on the device-login URLs with a risky sign-in in a narrow window, then confirm the 50199-then-success pattern.

let suspiciousUserClicks = materialize(UrlClickEvents
 | where ActionType in ("ClickAllowed", "UrlScanInProgress", "UrlErrorPage") or IsClickedThrough != "0"
 | where UrlChain has_any ("microsoft.com/devicelogin", "login.microsoftonline.com/common/oauth2/deviceauth")
 | extend AccountUpn = tolower(AccountUpn)
 | project ClickTime = Timestamp, ActionType, UrlChain, NetworkMessageId, Url, AccountUpn);
let interestedUsersUpn = suspiciousUserClicks | where isnotempty(AccountUpn) | distinct AccountUpn;
let suspiciousSignIns = materialize(AADSignInEventsBeta
 | where ErrorCode == 0
 | where AccountUpn in~ (interestedUsersUpn)
 | where RiskLevelDuringSignIn in (10, 50, 100)
 | extend AccountUpn = tolower(AccountUpn)
 | join kind=inner suspiciousUserClicks on AccountUpn
 | where (Timestamp - ClickTime) between (-2min .. 7min)
 | project Timestamp, ReportId, ClickTime, AccountUpn, RiskLevelDuringSignIn, SessionId, IPAddress, Url);
let interestedSessionUsers = suspiciousSignIns | where isnotempty(AccountUpn) | distinct AccountUpn;
let shortIntervalSignInAttemptUsers = materialize(AADSignInEventsBeta
 | where AccountUpn in~ (interestedSessionUsers)
 | where ErrorCode in (0, 50199)
 | summarize ErrorCodes = make_set(ErrorCode) by AccountUpn, CorrelationId, SessionId
 | where ErrorCodes has_all (0, 50199)
 | distinct AccountUpn);
suspiciousSignIns
| where AccountUpn in (shortIntervalSignInAttemptUsers)

N2 · Broker sign-in followed by OWA from a different IP

The core DEBULL session-handoff signature: a Microsoft Authentication Broker sign-in, then OfficeHome / One Outlook Web for the same user from a different IP inside 15 minutes.

let window = 15m;
let mab = SigninLogs
 | where TimeGenerated > ago(14d)
 | where AppDisplayName =~ "Microsoft Authentication Broker"
 | project MabTime=TimeGenerated, UserPrincipalName, MabIp=IPAddress,
   MabLocation=Location, MabResult=ResultType, MabUserAgent=UserAgent;
let owa = SigninLogs
 | where TimeGenerated > ago(14d)
 | where AppDisplayName in ("OfficeHome", "One Outlook Web")
 | where ResultType == 0
 | project OwaTime=TimeGenerated, UserPrincipalName, OwaIp=IPAddress,
   OwaLocation=Location, OwaApp=AppDisplayName, OwaUserAgent=UserAgent;
mab
| join kind=inner owa on UserPrincipalName
| where OwaTime between (MabTime .. MabTime + window)
| where MabIp != OwaIp
| project MabTime, OwaTime, UserPrincipalName, MabIp, OwaIp, MabLocation, OwaLocation,
   MabResult, OwaApp, MabUserAgent, OwaUserAgent
| order by MabTime desc

N3 · Device registration artifacts (incl. tool-derived names)

AuditLogs
| where TimeGenerated > ago(30d)
| where TargetResources has_any ("GraphSpy-Device", "GraphSpy")
   or OperationName has_any ("Register device", "Add device", "Add registered owner to device")
| project TimeGenerated, OperationName, Result, InitiatedBy, TargetResources
| order by TimeGenerated desc

N4 · Newly registered devices via Device Registration Service

CloudAppEvents
| where AccountDisplayName == "Device Registration Service"
| extend DeviceName = tostring(parse_json(tostring(RawEventData.ModifiedProperties))[1].NewValue)
| extend UserPrincipalName = tostring(RawEventData.ObjectId)
| project TimeGenerated, DeviceName, UserPrincipalName

N5 · Manual checklist — run these against the tenant

• Enumerate all Entra devices registered in the campaign window; validate each against your asset inventory. Anything unrecognised is an incident, not a finding.
• Review authentication-method changes: new FIDO2 keys, passkeys, Windows Hello for Business registrations, phone/authenticator additions.
• Review OAuth consent grants and service principals created or modified in the window.
• Review inbox rules across affected mailboxes — especially forwarding to external addresses and auto-delete rules.
• Review mailbox delegation, Send-As / Send-on-Behalf, and mail-forwarding settings.
• Scope the lure: search message trace for the lure themes and pull the full recipient list — device-code campaigns are broad, and ATO jumping means the next wave may come from a trusted internal or partner account.

What to build instead

Alert package — primary detection

SCHEDULED SEARCH:  DETECT - Device-Code Grant by User Account (DEBULL / Storm-2372-style)
DESCRIPTION:       Fires when a human user account completes an OAuth 2.0 device-code
                   authorization grant outside the approved baseline. Device-code phishing
                   bypasses MFA without stealing a password and yields attacker-controlled
                   session tokens.
SEVERITY:          High
EMAIL SUBJECT:     [HIGH] Detection: Device-Code Grant - possible M365 account takeover

BODY:
  WHAT FIRED
    User {userPrincipalName} completed an OAuth device-code authentication from
    {ipAddress} ({location}) using app {appDisplayName} at {timestamp}.

  WHY IT MATTERS
    The device-code flow is designed for input-constrained devices. When a user
    completes one on a normal workstation it usually means they were socially
    engineered into entering an attacker-generated code on the genuine Microsoft
    sign-in page. The attacker - not the user - receives the resulting tokens.
    MFA was satisfied legitimately and provides no protection here.

  IMMEDIATE ACTIONS
    1. Contact the user out of band. Ask whether they entered a code from an email
       or a document link. Do not send that question by email to the account itself.
    2. If unexplained: revoke sessions and refresh tokens (revokeSignInSessions)
       AND reset the password. Neither alone is sufficient.
    3. Enumerate Entra devices registered for this user in the last 30 days and
       remove any not in asset inventory - a registered device means PRT
       persistence that survives the password reset.
    4. Review inbox rules, forwarding, delegation, and authentication methods.
    5. Check SharePoint/OneDrive download volume for this principal.

  ESCALATE IF
    A device was registered close in time, a PRT was issued, an inbox rule was
    created, or mass download is observed - treat as a confirmed account takeover
    and open an incident.

L1 triage checklist

1. Confirm the sign-in really used the device-code protocol (re-run Q4 scoped to the principal).
2. Check whether the account or device is on the approved device-code baseline — if yes, close as expected.
3. Contact the user out of band (phone/Teams call, not email to the affected mailbox).
4. Run Q5 for the correlation ID — does the 50199-then-success pattern appear?
5. Run Q6 and Q10 — is there an IP split across apps, or a first-time-seen source IP?
6. Run Q7 — was a device registered? This is the escalation trigger.
7. Run Q8 and Q9 — inbox rules or mass download for this principal?
8. Run Q1/Q2 scoped to the user's endpoints — did the lure fetch come from a managed device, and what else did that host touch?
9. Scope the campaign: message-trace the lure theme to find every other recipient.

Gate 1 — Telemetry is actually present

Before trusting any empty result, prove the data exists. An empty Q4 means either "no device-code phishing" or "no Entra logs" — those are very different answers.

1. Confirm Entra sign-in logs are ingested:  run Q4 with no filters and head(10)
2. Confirm Entra audit logs are ingested:    run Q7 with no filters and head(10)
3. Confirm M365 UAL is ingested:             run Q8 with no filters and head(10)
4. Confirm Falcon DNS telemetry:             #event_simpleName=DnsRequest | head(10)
5. If any of 1-3 return nothing, STOP - fix ingestion before reporting "no findings"

Gate 2 — Field shape matches your parser

Q4–Q10 use Microsoft Entra schema field names. Your connector may prefix them.

For each of Q4-Q10, run once with a 1-hour window and head(10).
If fields come back empty or missing, inspect a raw event and prefix accordingly, e.g.
  appDisplayName  ->  azure.signinlogs.properties.appDisplayName
  resultType      ->  azure.signinlogs.properties.resultType
Fix the query, re-run, and only then promote to a scheduled search.

Gate 3 — Positive control

Prove the detection fires before you rely on it. This is a safe, authorized self-test against your own tenant.

With change approval, from an admin workstation and a TEST account:
  1. Initiate a legitimate device-code sign-in you control
     (e.g. Azure CLI or Microsoft Graph PowerShell device-code login).
  2. Confirm the event appears in Q4 within the expected ingestion latency.
  3. Confirm the correlation ID shows in Q5 if you deliberately pause before
     entering the code.
  4. Document ingestion lag - it determines how fast your alert can respond.
  5. Remove the test account's tokens afterwards (revokeSignInSessions).
NOTE: this validates DETECTION only. Do not build or host a phishing lure to test.

Gate 4 — Baseline before alerting

Run Q4 over 30 days and classify EVERY result:
  - approved service account / automation  -> allowlist
  - conference room / kiosk / signage      -> allowlist by device ID
  - developer CLI workflow                 -> allowlist by account + app, review quarterly
  - anything else                          -> investigate now, then alert on it going forward
An unbaselined Q4 will be too noisy to action. A baselined Q4 is near-zero-FP.

Gate 5 — IOC provenance (applied to this pack)

Playbook A — Find every legitimate device-code user before you block (run this first)

# Microsoft Graph PowerShell - 30-day device-code baseline
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

$since = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogSignIn -Filter "createdDateTime ge $since" -All |
  Where-Object { $_.AuthenticationProtocol -eq "deviceCode" } |
  Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName, AppId,
                @{n="IP";e={$_.IpAddress}},
                @{n="City";e={$_.Location.City}},
                @{n="Country";e={$_.Location.CountryOrRegion}},
                @{n="Result";e={$_.Status.ErrorCode}} |
  Sort-Object UserPrincipalName |
  Export-Csv .\devicecode-baseline-30d.csv -NoTypeInformation

# Classify EVERY row before enforcing the CA policy in Playbook B.

Playbook B — Conditional Access policy: block device-code flow

# Entra admin center - Protection > Conditional Access > New policy
#
# Name:         BLOCK - OAuth 2.0 Device Code Flow
# Users:        All users
#               EXCLUDE: break-glass emergency access accounts
#               EXCLUDE: approved device-code accounts from Playbook A (if any)
# Target:       All resources (formerly "All cloud apps")
# Conditions:   Authentication flows -> Device code flow = Selected
# Grant:        Block access
# Enable:       Report-only FIRST -> review impact -> then On
#
# Validate after enabling:
#   1. Re-run Playbook A weekly - the result set should shrink to your allowlist only.
#   2. Attempt a device-code login with a non-excluded test account: expect a block.
#   3. Confirm break-glass accounts still authenticate.

Playbook C — Restrict device registration and enforce MFA to register

# Entra admin center - Identity > Devices > Device settings
#
#   Users may join devices to Microsoft Entra:            Selected (scoped group)
#   Users may register their devices with Microsoft Entra: Selected (scoped group)
#   Require Multifactor Authentication to register or
#     join devices with Microsoft Entra:                   Yes
#   Maximum number of devices per user:                    set a sane cap
#
# Then audit current registrations against asset inventory:

Connect-MgGraph -Scopes "Device.Read.All","AuditLog.Read.All"
Get-MgDevice -All |
  Select-Object DisplayName, DeviceId, OperatingSystem, TrustType,
                ApproximateLastSignInDateTime, RegistrationDateTime |
  Sort-Object RegistrationDateTime -Descending |
  Export-Csv .\entra-devices.csv -NoTypeInformation

# Anything registered in the campaign window that is NOT in asset inventory
# is an incident. Tool-derived names (e.g. GraphSpy-Device) are confirmed bad.

Playbook D — Restrict external auto-forwarding (BEC objective)

# Exchange Online PowerShell
Connect-ExchangeOnline

# Block automatic external forwarding tenant-wide
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode Off

# Audit existing inbox rules that forward externally or delete
foreach ($mbx in Get-Mailbox -ResultSize Unlimited) {
  Get-InboxRule -Mailbox $mbx.UserPrincipalName -ErrorAction SilentlyContinue |
    Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.ForwardAsAttachmentTo -or $_.DeleteMessage } |
    Select-Object @{n="Mailbox";e={$mbx.UserPrincipalName}},
                  Name, Enabled, ForwardTo, RedirectTo, DeleteMessage
} | Export-Csv .\suspicious-inbox-rules.csv -NoTypeInformation

Playbook E — Verify identity logging is flowing to the SIEM

# Entra admin center - Identity > Monitoring & health > Diagnostic settings
# Ensure these categories are exported to your SIEM connector / Event Hub:
#   SignInLogs
#   NonInteractiveUserSignInLogs      <-- token replay shows up here
#   ServicePrincipalSignInLogs
#   AuditLogs                         <-- device registration lives here
#   RiskyUsers / UserRiskEvents
#
# Microsoft 365 - enable unified audit log and mailbox auditing:
Connect-ExchangeOnline
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
Get-OrganizationConfig | Select-Object AuditDisabled   # expect False
#
# Then re-run Gate 1 in section 11 to confirm the data actually lands in Falcon.

Phase 1 — Isolate (first 30 minutes)

1. Contact the user out of band. Phone call or in person — not email or Teams to the compromised identity, which the attacker may be reading in real time.
2. Revoke sessions and refresh tokens: Revoke-MgUserSignInSession -UserId <upn> (Graph revokeSignInSessions).
3. Reset the password and require change at next sign-in.
4. Enumerate and remove attacker devices: list every device registered to the user; delete any not in asset inventory. This is the step most responders miss.
5. Disable the account if the blast radius is unclear — you can re-enable after triage.
6. Confirm CAE is active so revocation takes effect immediately rather than at token expiry.

Phase 2 — Eradicate (first 4 hours)

1. Remove malicious inbox rules, forwarding, delegation, Send-As and Send-on-Behalf grants.
2. Review and remove attacker-added authentication methods — FIDO2 keys, passkeys, Windows Hello for Business registrations, authenticator app registrations, phone numbers.
3. Review OAuth consent grants and service principals created or modified during the window; revoke anything unexplained.
4. Block the confirmed-malicious §10 indicators at the proxy/firewall and import the CSV into Falcon IOC Management.
5. Scope the campaign. Message-trace the lure to every recipient. Run Q4 tenant-wide for the window — device-code campaigns target many users at once, and ATO jumping means the next wave arrives from a trusted internal or partner account.
6. Run Q7 tenant-wide, not just for the known victim — check whether any other device registrations occurred in the window.

Phase 3 — Recover & harden (24–72 hours)

1. Deploy the Conditional Access device-code block (§13 Playbook B). If this incident does not justify it, nothing will.
2. Restrict device registration and require MFA to register (§13 Playbook C).
3. Enable sign-in risk and user risk policies; confirm CAE is on.
4. Promote Q4, Q5, Q6 and Q7 to scheduled searches with alerting.
5. Assess data exposure: what mail, files, and SharePoint content were accessible during the token's validity window? Drive breach-notification decisions from that, not from assumption.
6. Targeted user education on the specific pattern — "a code sent to you to type in is always an attack."
7. Lessons learned: how long between token issuance and detection? That interval is the metric to improve.

Known gaps — state these explicitly when reporting

• Unmanaged and personal devices. Q1–Q3 only see Falcon-managed endpoints. A user clicking the lure on a phone or home computer produces no endpoint telemetry — but the identity-plane queries (Q4–Q10) still catch it. This is precisely why the identity queries are the primary detection and the endpoint queries are supporting.
• No Entra log ingestion = no detection. If Entra sign-in and audit logs are not in Falcon NGSIEM, this pack degrades to three endpoint queries against perishable indicators. Fix ingestion before concluding "no findings."
• Graph API call-level telemetry is not consistently available, so post-authentication enumeration is inferred from artifacts and effects rather than observed directly.
• Indicator perishability. The CloakGuard deployment module publishes new lures to Cloudflare Workers and custom domains on demand. The §10 domain/IP list will decay quickly — the behavioural signatures (B1–B10) are the durable coverage.
• Single-vendor infrastructure sourcing. DEBULL-specific infrastructure detail rests on one vendor report. The technique is independently corroborated; the atomic indicators are not.
• Falcon Identity Protection contributes little here. This is a cloud-native identity attack that never touches on-prem AD authentication. Do not expect Identity Protection detections to fire.

1. ZeroBEC — DEBULL: Storm-2372-Style Microsoft Device-Code Phishing With GraphSpy Post-Exploitation, 2026-07-04. zerobec.com — primary technical source. Snapshot: 01-zerobec.txt
2. The Hacker News — DEBULL Tooling Abuses Microsoft Device-Code Flow to Target M365 Accounts, 2026-07-07. thehackernews.com. Snapshot: 02-thn.txt
3. DIAMATIX — Microsoft Device Code Flow Abuse Creates a New Risk for M365 Accounts. diamatix.com. Snapshot: 03-diamatix.txt
4. Cisco Talos — ARToken: Inside an EvilTokens affiliate panel targeting Microsoft 365. blog.talosintelligence.com — adjacent platform. Snapshot: 04-talos-artoken.txt
5. Microsoft Security Blog — Storm-2372 conducts device code phishing campaign, 2025-02-13 (updated 2025-02-14). microsoft.com — background & mitigation authority. Snapshot: 05-microsoft-storm2372.txt
6. Microsoft Learn — Conditional Access: Block authentication flows. learn.microsoft.com — hardening authority. Snapshot: 06-ms-ca-block-devicecode.txt
7. MITRE ATT&CK — T1528 Steal Application Access Token; T1550.001 Application Access Token; T1098.005 Device Registration; T1621 MFA Request Generation. attack.mitre.org
8. IETF RFC 8628 — OAuth 2.0 Device Authorization Grant — the legitimate specification being abused. datatracker.ietf.org

Generated 2026-07-19 · HuntPack v0.2 · Defensive content only — hunt, detection, and hardening guidance. Source snapshots retained in DEBULL-DeviceCodePhishing-Hunt-sources/ for indicator provenance verification.