Device Code Phishing Campaign — Infrastructure Update

Device Code Phishing Campaign — Infrastructure Update

A follow-up investigation mapping 1,337 phishing URLs across 326 workers.dev hostnames, confirming a PhaaS multi-tenant architecture, encrypted client-side payloads, and new lure variants targeting Adobe, DocuSign, and Outlook branding.

Threat Hunting entra microsoft threat hunting phishing device-code cloudflare token-theft phaas

Introduction

Following my initial post on this device code phishing campaign, I’ve had the chance to pull on the thread further and enumerate more infrastructure. What started as a handful of phishing URLs is now over 300+ workers.dev phishing domains, and over 1200+ unique phish URLs.
This post covers what that larger dataset reveals and the different lure variants being served by different operators, suggesting a common phish kit, but different operators.

Infrastructure at Scale

Probing all known URLs returned the following breakdown:

StatusCount%Notes
200 OK96672.3%Active, responding
403 Cloudflare phishing block14811.1%Cloudflare has flagged these workers
403 Access Denied (operator)13810.3%Worker alive, operator-side filtering
404 Not Found584.3%Route deleted or session expired
DNS / connection error211.6%Worker deregistered or DNS failure
Timeout20.1%No response within 12s
401 / 40030.2%Auth-gated external pages
Total1,337

The 966 responding pages form the core of the active infrastructure. The 11.1% blocked by Cloudflare is useful signal that the platform’s own phishing detection is catching some of this, though clearly not all of it. The 403 Access Denied responses from operators indicate a live worker with server-side filtering in place.

Encrypted JavaScript Payloads

Digging into the 966 active pages reveals something immediately notable: 924 of them (95.7%) serve no readable HTML at all. Instead, every page follows an identical skeleton:

<!DOCTYPE html><html><head><meta charset="UTF-8"></head>
<body><div id="r"></div>
<script>async function d(){try{var a="[~12KB base64 blob]"...

The async function d() decodes and executes a large base64-encoded, AES-encrypted payload entirely in the victim’s browser. The actual phishing content — the branded lure page, the device code prompt, and the OAuth polling logic — is never transmitted in plaintext. Automated crawlers, security scanners, and proxy inspection tools see only an opaque blob. This matches up with the previous analysis we did in my previous blog, where the content was served from a decrypted base64 blob.

Two distinct payload sizes were observed across the active infrastructure:

  • 12,700 bytes — 404 pages
  • 12,716 bytes — 441 pages

The size consistency across hundreds of independently deployed Cloudflare accounts is significant. These are not independently built pages but more likely the kit code is centrally distributed to operators, and the two variants could represent two sequential versions of the same kit.

Per-Victim Session Tokens

847 of the URLs contain a 16-character hex path segment — for example, /8e63bf26244fe394. These could be per-victim session tokens baked into the phishing link before each email is sent. Or may be used to track the device auth sessions.

MetricValue
URLs1,293
Unique workers.dev hostnames326
Active phish session paths (/16hexchars)1,061
Initial landing URLs (/?email=)246

Base64 Email Encoding

Some workers deliver the victim’s email address via a base64-encoded URL fragment (#email=<base64>) rather than the ?email= query string parameter seen in the original post. The below is an example from one of the URLs. Note how it’s a test email value, suggesting testing by an operator:

dGVzdDEyM0BvdXRsb29rLmNvbQ== → test123@outlook.com

Lure Variants

All three screenshots below were captured from active pages within this infrastructure. The underlying kit is identical, same device code flow, same clipboard pre-copy, same Microsoft login popup. The only difference is the branding overlay applied on top which is a minor change.

Phishing page using Adobe Acrobat Sign branding with device code prompt
Figure 1: Adobe Acrobat Sign Lure — device code pre-staged and ready to copy
Phishing page using DocuSign branding with device code prompt
Figure 2: DocuSign Lure — same flow, different brand skin
Phishing page using Microsoft Outlook branding with device code prompt
Figure 3: Microsoft Outlook Lure — meeting invite context used as the social engineering hook

The consistent “Copy Code → Continue to Microsoft” flow is present in all three. From the victim’s perspective, the branded context changes but the required action stays the same: copy the code, open the Microsoft device login portal, paste it in.

The existence of multiple brand skins across the same backend infrastructure is further evidence of a multi-operator PhaaS setup. Different operators are running slightly different campaigns.

Attacker-Controlled Infrastructure

Not all 326 hostnames follow the {prefix}.{accountname}-s-account.workers.dev pattern associated with compromised sender accounts that we looked into last time. 111 hostnames are attacker-registered and fall into distinct clusters suggesting different operators or kit variants.

Microsoft / OAuth Typosquat Cluster

Approximately 50 hostnames use systematic homoglyph substitution — 1 for l, ii for i, vv for w, onilne for online — to mimic Microsoft login, DocuSign, AWS, and MSCF infrastructure:

index-c1ientauthonilne.oauth-docusign-secure.workers.dev
index-c1ientauth1oginonilne.gateway-verify-msonline.workers.dev
index-c1ientauth1oginonilne.oauth-auth-go-msonline-secure.workers.dev
index-c1oudmcsfoninine.mscf-avvs-onilnee.workers.dev
index-ciientmscfoniinee.mscf-avvs-onilnee.workers.dev
index-c1ientauth1oginoniine.web-aws-verify-a17.workers.dev
index-c1ientauth1oginonilne.api-docusign-protect.workers.dev
index-c1ientauth1oginonilne.auth-go-verify-docusign.workers.dev
index-c1ientauth1oginonilne.oauth-docs-msonline.workers.dev
index-c1ientauth1oginonilne.web-docusign-verify.workers.dev
index-c1ientauthonilne.oauth-docusign-msonline.workers.dev
index-athc1ient.api-aws-qatevvay.workers.dev
index-athciient.aws-api-qatevvay-2df.workers.dev
index-qatevvayciient.api-avvss-onilne.workers.dev

These are not compromised-account workers, they are attacker-registered Workers domains designed to look like legitimate OAuth infrastructure at a glance.

HR / Employee Pay Lure Cluster

A separate cluster pivots to an entirely different social engineering theme, employee bonuses and pay distribution:

index-1oadininq.receive-employee-bonus.workers.dev
index-1oadininq.veiw-dstrbutd-bonusesacesss.workers.dev
index-1oadinninc1ient.pay-employee-bonus-8ce.workers.dev
index-1oadinnq.emplo-yeepay-bonus.workers.dev
index-ciientdstrbutd.emplo-yeepay-bonus.workers.dev

So we can see here, it looks to be the same kit being used but different lures. Where the compromised-account operators are running document-themed campaigns, this cluster is targeting employees with finance lures.

IOCs

The full deduplicated IOC list for this campaign, covering both the original post and this update, is maintained on the Tracked Campaigns page, which includes all known workers.dev hostnames observed across both investigations.

Infrastructure summary:

  • 1,337 total URLs probed
  • 326 unique workers.dev hostnames
  • 111 attacker-registered (non -s-account) domains
  • 1,061 active per-victim session paths

Resources

Back to all posts