In March 2026, researchers monitoring phishing-focused cybercrime communities uncovered EvilTokens, a new turnkey phishing-as-a-service (PhaaS) platform that had been quietly circulating since mid-February 2026 — and rapidly adopted by cybercriminals specializing in adversary-in-the-middle phishing and business email compromise. What sets EvilTokens apart isn't just its technical sophistication; it's the clinical, SaaS-like packaging of every stage of the attack chain, from initial phishing lure to AI-powered inbox intelligence.

At the heart of the platform is an abuse of Microsoft's Device Code OAuth flow — a legitimate OAuth 2.0 mechanism designed for contexts where interactive browser-based authentication isn't practical, such as CLI tools, developer environments, and input-constrained devices. Attackers abuse it by initiating the flow themselves and socially engineering the target into entering a device code on Microsoft's own authentication page — meaning the target completes real MFA against real Microsoft infrastructure, with no fake login pages involved. No credential harvesting in the traditional sense. The target simply enters a code handed to them by the attacker, and unknowingly hands over persistent token-based access — refresh tokens remain valid until revoked, with a 90-day default inactivity window.

Once inside, operators are equipped with a full post-compromise toolkit: MailVault, an Outlook-clone webmail client with AI-driven email summarization, Telegram-based keyword alerting, and send-as-target functionality. As of March 2026, no other major PhaaS platform offers device code phishing at this scale — and the operator has already signaled plans to expand support beyond Microsoft 365 to Gmail and Okta.

This is not a phishing kit. This is a criminal SaaS product.

Sekoia documented EvilTokens as a PhaaS platform with SMTP-based delivery infrastructure — Exim mail servers pushing credential harvesting links. Abnormal Security profiled the social engineering side: DocuSign-branded lure pages designed to harvest enterprise credentials. Huntress identified 23 DocuSign phishing instances and documented abuse of Cloudflare's workers.dev platform for hosting campaign infrastructure. CISA added CVE-2021-36260 and CVE-2017-7921 to the Known Exploited Vulnerabilities catalog, documenting active exploitation of the exact camera models we found in this dataset.

The railway.com IPs that Huntress reported do not appear in our dataset. The Exim mail servers that Sekoia documented do. The Cloudflare CDN abuse that Huntress flagged is the dominant pattern in our data. The DocuSign lures that Abnormal profiled show up in our HTTP title data verbatim. Complementary coverage — different angles on the same op.

While prior research from Sekoia, Abnormal Security, and Huntress has done excellent work documenting EvilTokens from the victim's perspective — the lures, the credential harvesting flows, the Cloudflare Workers abuse — we wanted to answer a different question: what does this operation look like from the outside, at the infrastructure level?

We started with 95 IP addresses: published indicators of compromise from the EvilTokens campaign. In most workflows, a list like this gets ingested into a threat intel feed, blocked at the perimeter, and forgotten. Instead, we fed them into ClusterHawk, our infrastructure fingerprinting pipeline. No traffic logs, no sandbox detonations — purely passive analysis. The whole thing took about 30 minutes.

What came back wasn't just a list of bad IPs. It was an architecture.

Four tiers emerged from the clustering without labels — the pipeline grouped by behavioral similarity, and the possible operational roles became visible in the results.

CDN Frontend (~75 Assets)

The dominant layer. Approximately 75 assets — the majority of the dataset — sit behind Cloudflare (AS13335), and the clustering separated them into multiple CDN sub-groups based on port configuration and HTTP response characteristics.

The cPanel management ports are telling. Standard Cloudflare-proxied sites don't expose 2082-2087 — those are cPanel and WHM administration interfaces. Someone configured these Cloudflare accounts to proxy management traffic alongside the phishing frontend. The "Direct IP access not allowed" response on nearly every asset means the operator explicitly configured Cloudflare to reject requests that bypass the CDN. That's active management. These aren't compromised sites with Cloudflare in front by default — they're purpose-built. We see this title because Shodan scans IPs directly — it doesn't go through Cloudflare's reverse proxy. Someone actively configured these IPs to enforce that connections come through Cloudflare only.

A shared HTTP headers hash (144737606) appears across the CDN clusters, creating a cross-cluster correlation visible in the medoid analysis. Same Cloudflare configuration template, deployed across all frontend assets.

Backend (~19 Assets)

This is where the phishing operation lives. Two backend clusters — one with 15 assets, one with 4 — running the infrastructure that serves credential harvesting pages and handles campaign operations.

Service Stack (Primary Backend Cluster, 15 Assets):

SSH prevalence in the backend is 5.7x the dataset average. The operator needs shell access to these hosts. FTP at 80% means file deployment — uploading phishing kits, updating lure pages. Exim SMTP on port 465 confirms what Sekoia documented: these servers send phishing emails directly. The full operational chain — development, deployment, delivery — runs on the same machines.

Provider Diversification:

The backend provider distribution is the opposite of the CDN layer. Fifteen unique providers across all analysis passes, no single provider dominant.

That's deliberate fragmentation. If any single provider gets an abuse report and acts on it, the operator loses at most one or two servers. The CDN frontend is homogeneous because Cloudflare is the product — you need the WAF and the CDN for domain fronting. The backend is diversified because those servers are expendable.

Geographic Distribution:

• United States: 50-62%
• Germany: 20-29%
• South Africa: 6-7%
• Turkey: 6-7%
• India: varies by cluster
• Poland: varies by cluster
• Australia: 6.7%

Phishing Infrastructure:

The backend serves DocuSign-themed phishing pages. HTTP title "DocuSign - Review Document" on port 443. The associated fingerprints:

These hashes describe the phishing page template. Combined, they form a compound fingerprint for the DocuSign lure — specific enough to distinguish EvilTokens pages from legitimate DocuSign infrastructure.

Domains:

• suctwocesonesstory.com — Let's Encrypt certificate
• mail.serenitygovsupplys.com — Let's Encrypt certificate
• autoconfig.f316.fuchsia.dedicated.server-hosting.expert — FTP certificate CN

The domain names follow a pattern: long, awkward strings designed to look plausible in a URL bar for a fraction of a second. serenitygovsupplys.com with the misspelled "supplys" and the government reference — targeting someone who expects official correspondence.

Certificates:

A self-signed certificate with CN www.example.com sits alongside Let's Encrypt certificates for operational domains. That's a default — someone stood up a server, got the default self-signed cert, then added Let's Encrypt for the phishing domains without removing the original. Sloppy, but detectable. The self-signed cert is a fingerprint for infrastructure that hasn't been fully configured.

Cobalt Strike:

Five IPs carry Cobalt Strike labels at 100% confidence:

172.67.191.79 is a Cloudflare IP with Cobalt Strike. That's domain fronting in action — C2 traffic routed through Cloudflare's CDN to blend with legitimate HTTPS traffic. The operator isn't just using Cloudflare for phishing page delivery; they're running command-and-control through it.

103.211.216.225 is the most interesting IP in the entire dataset. Cobalt Strike at 100% confidence and flagged as a CRITICAL anomaly in two of three analysis passes. It lands in different clusters with different neighbors across runs — the clustering can't stably place it because it doesn't fully match any single operational tier. It sits between the backend and the noise. Highest-priority investigation target.

Bridge (5 Assets)

Five Cloudflare IPs that the clustering separated from the main CDN frontend. The distinguishing feature: their TLS certificates.

Standard Cloudflare-proxied sites get Cloudflare-issued certificates. These five have Google Trust Services certificates with 256-bit ECC keys. That means the operator uploaded custom certificates through Cloudflare's dashboard — a deliberate choice that requires a paid plan and domain validation through Google's CA. Why use Google Trust Services when Cloudflare provides certificates automatically? Separate certificate management. If Cloudflare revokes their own certificates as part of an abuse action, Google-issued certs on a custom upload are a different revocation chain.

Certificate Domain CNs:

These are real business domains. A law firm, a UAE financial entity, a truck manufacturing company, a brewery, a wealth management firm. Either compromised domains or domains acquired through expired registration — the kind of names that pass casual inspection in a URL bar.

Two CRITICAL anomalous IPs in this cluster:

These are the two highest anomaly scores in the entire dataset. Bridge infrastructure that the clustering can't stably assign — they share characteristics with both the CDN frontend and something else entirely. Assets at the boundary of operational tiers are worth watching.

IoT Proxy Layer (8 IPs)

This is the finding that doesn't appear in any existing EvilTokens research. Eight IPs that the primary clustering classified as noise — and when we re-analyzed the noise, they grouped into a coherent cluster of compromised surveillance cameras.

Hikvision cameras. Dahua NVRs. Running VxWorks 6.9 — a real-time operating system for embedded devices. RTSP streaming on port 554. Hosted on Chinese telecom infrastructure. These are surveillance cameras, and they're sitting in an EvilTokens PhaaS campaign's IOC list.

Vulnerability Profile:

Two CVSS 9.8 vulnerabilities, both on the CISA Known Exploited Vulnerabilities catalog. CVE-2021-36260 gives unauthenticated remote code execution on Hikvision cameras. CVE-2017-7921 bypasses authentication entirely. These cameras are compromised — the question is what role they play.

Why are compromised surveillance cameras in a PhaaS campaign's IOC list? Three hypotheses:

Proxy relay. The cameras serve as proxy nodes between the CDN frontend and the backend. Phishing traffic hits Cloudflare, routes through compromised IoT devices, reaches the backend servers. The proxy layer makes backend IP attribution harder and adds a disposable hop that can be replaced without touching the core infrastructure. Compromised cameras on Chinese telecom networks are cheap, plentiful, and nobody patches them.

C2 relay. Cobalt Strike beacons on the backend route through IoT proxies to reach the operator. Camera firmware running VxWorks doesn't have EDR. Network monitoring on Chinese telecom residential connections is unlikely to flag outbound HTTPS as suspicious. The cameras are invisible C2 relays.

Credential exfiltration. Harvested credentials from DocuSign phishing pages get staged on compromised cameras before collection. If law enforcement seizes a backend server, the harvested data has already moved to infrastructure that nobody thinks to look at.

All three hypotheses share a common logic: the IoT layer exists to create separation between the operation and its operator. Eight cameras on Chinese ISPs, running firmware with known critical vulnerabilities, appearing alongside a phishing campaign's infrastructure. This is weird. It should get more attention.

The clustering pipeline generates compound Shodan queries per cluster — multi-parameter fingerprints that describe each operational tier's specific configuration. Individual fingerprints like a JA3S hash are generic TLS responses; their value comes from combining them with other parameters into compound queries.

Compound Detection Queries

Backend TLS + Certificate:

ssl.ja3s:574866101f64002c6421cc329e4d5458 ssl.cipher.name:TLS_AES_256_GCM_SHA384 ssl.cipher.version:TLSv1.3 http.html_hash:-1441230826,-1583688385,-1105398786 http.status:200 ssl.cert.subject.cn:autoconfig.f316.fuchsia.dedicated.server-hosting.expert

Multi-Service Hosting:

ssl.cipher.name:ECDHE-RSA-AES256-GCM-SHA384 org:"Public domain registry Operations","WebNX, Inc.","Odeaweb Bilisim Teknolojileri" hash:488069555,-410503285,-198830288 http.status:200

Bridge / Certificate Cluster:

hash:-1815016599,-1273691823,-1825263417 ssl.cert.pubkey.bits:256 ssl.cert.subject.cn:rodgersandassoc.com,qic-uaq.ae,martintruckbodies.com http.waf:"Cloudflare (Cloudflare Inc.)" http.html_hash:134289477,655638983,1574090600

CDN Frontend:

http.component_category:CDN http.waf:"Cloudflare (Cloudflare Inc.)" hash:767421064,1272309570,-1929496188 http.status:400 http.html_hash:1017324132,-875512959,816673406 http.title:"400 The plain HTTP request was sent to HTTPS port"

IoT Proxy Layer:

http.title:"dahua.local - Powered by RTSP server","nvr.local - Powered by RTSP server","dahua.local - Powered by Hikvision" product:Dahua,"RTSP server" http.html_hash:1917181721,257076913,-1693941985

Each query combines 5-8 parameters. A single parameter match is noise. The full compound query describes one operational tier and very little else.

Key Fingerprints

The clustering results align with existing research — and extend it.

The Railway.com absence is significant. It means our IOC set and Huntress's IOC set sample different parts of the same operation. Neither is complete. Combined, they cover more of the infrastructure than either alone — our data maps the persistent backend and CDN architecture, theirs captures the ephemeral delivery infrastructure.

The DocuSign match is the strongest corroboration. Huntress reported 23 instances of DocuSign-themed phishing. Our clustering independently surfaced "DocuSign - Review Document" as the HTTP title on backend infrastructure — the same lure template, confirmed from the infrastructure side rather than the victim side.

The IOC Durability Problem

Traditional IOCs — IP addresses and domain names — are ephemeral. The 95 IPs in this analysis will rotate. Some already have. Domains get burned and replaced. Blocking them is necessary but insufficient; it's playing defense against yesterday's indicators.

Victim-side IOCs — phishing kit artifacts, credential harvesting logs, email headers — come after compromise. They're useful for incident response but reactive by definition. By the time you have them, the damage is done.

Infrastructure patterns sit between these two. Deployment templates, provider diversification strategies, port profiles, certificate choices, service stack configurations — these persist across campaigns because changing them means rebuilding the operation. An operator who runs Apache/nginx with Pure-FTPd, OpenSSH 8.9p1, and Exim on 15 fragmented hosting providers doesn't switch to IIS on AWS overnight. The CDN frontend running Cloudflare with cPanel management ports doesn't suddenly move to Fastly. The bridge cluster using Google Trust Services certificates with 256-bit ECC doesn't swap to Let's Encrypt without reconfiguring the entire certificate management pipeline.

ClusterHawk extracts these patterns from Shodan metadata. The compound queries in this article describe infrastructure architecture, not individual indicators. They're the detection layer between ephemeral IOCs and post-compromise artifacts.

Practical Workflow

Don't enrich everything. The 95 IPs in this article belong in your threat intel platform and your blocklists — that's table stakes. But the compound fingerprints serve a different purpose.

At the email gateway: Use simpler signals to quarantine. Sender reputation, SPF/DKIM failures, URL reputation, attachment analysis. These are fast, inline, and handle volume. The infrastructure fingerprints don't belong here.

In the investigation pipeline: When a suspicious email hits your analysis queue — quarantined by the gateway, flagged by a user, or caught by a detection rule — that's when you enrich against infrastructure patterns. Pull the sending IP. Check it against the compound Shodan queries. Look for the service stack. Does it match the EvilTokens backend profile? Does the TLS configuration align? Is the hosting provider one of the 15 fragmented providers? Infrastructure-level enrichment during investigation, not inline at the gateway.

Detection Rules

Two high-confidence rules for deployment:

Rule 1: DocuSign Phishing Infrastructure (HIGH Confidence)

title: EvilTokens DocuSign Phishing Page Detection
description: Detect HTTP responses matching EvilTokens DocuSign lure infrastructure
detection:
  selection:
    http.title: "DocuSign - Review Document"
    http.dom_hash: -1290345239
    http.html_hash: 292582549
    http.headers_hash: -848751785
  condition: all of selection
fields:
  - destination.ip
  - tls.certificate.subject
note: >
  Compound fingerprint for EvilTokens DocuSign phishing pages. All four hashes must match — individual hash matches are
  not sufficient. Deploy on port 443 traffic in investigation pipeline.

Rule 2: Backend SSH + Service Stack (HIGH Confidence)

title: EvilTokens Backend Infrastructure Detection
description: Detect SSH connections matching EvilTokens backend hosting profile
detection:
  selection_ssh:
    ssh.hassh: "41ff3ecd1458b0bf86e1b4891636213e"
    ssh.key_type: "ecdsa-sha2-nistp256"
  selection_context:
    destination.port: [21, 22, 80, 443, 465]
  condition: selection_ssh and selection_context
fields:
  - destination.ip
  - source.ip
  - ssh.banner
note: >
  HASSH fingerprint for OpenSSH 8.9p1 on EvilTokens backend servers. Combine with multi-port context to reduce false
  positives. Backend servers expose SSH, FTP, HTTP/S, and SMTP on the same host.

A detection signature for your neighbour's environment might be too broad for yours, and vice versa. Stop using default, out-of-the-box detection rules — create your own, based on the threats your environment actually faces.

For SOC / IR Teams

The compound Shodan queries in this article are investigation-time enrichment tools. When you're analyzing a suspicious email or a flagged URL:

1. Extract the destination IP
2. Query Shodan for the service profile
3. Compare against the EvilTokens infrastructure fingerprints — backend service stack, CDN port profile, bridge certificate characteristics
4. If the profile matches, escalate with infrastructure context attached

Don't try to run Shodan queries inline at the gateway. Infrastructure enrichment is for the investigation pipeline.

For Threat Hunters

• The IoT proxy layer (8 IPs on CHINANET/China Telecom) is the least-reported finding. Hunt for Hikvision/Dahua devices in your network telemetry communicating with known PhaaS infrastructure.
• The bridge cluster's Google Trust Services certificates on Cloudflare are unusual. Hunt for 256-bit ECC certificates from Google Trust Services WE1 CA on Cloudflare-proxied domains that don't match the domain's expected certificate chain.
• 103.211.216.225 — Cobalt Strike with CRITICAL anomaly status in multiple passes. If this IP appears in your logs, treat it as high-priority.

For Email Security

• Block or quarantine emails originating from IPs matching the backend service stack profile (OpenSSH 8.9p1 + Exim + Pure-FTPd on fragmented hosting)
• Flag DocuSign-themed emails where the sending infrastructure resolves to budget VPS providers rather than DocuSign's actual infrastructure
• Monitor for domains following the EvilTokens naming pattern: long compound words, government-adjacent terminology, minor misspellings (serenitygovsupplys.com)

The input was 95 IPs. The output was everything in this article.

ClusterHawk's ensemble clustering took the raw IP list, enriched it against Shodan metadata, and produced the four-tier infrastructure architecture, the anomaly intelligence, the compound detection signatures, and the noise re-analysis that surfaced the IoT proxy layer. No manual feature selection. No threshold tuning. No human in the loop until the results came back.

What the pipeline delivered:

• Four operational tiers — CDN frontend, backend hosting, bridge, and IoT proxy — each with distinct behavioral profiles and detection signatures
• Anomaly detection — 5 CRITICAL IPs per pass, including the Cobalt Strike + anomaly overlap on 103.211.216.225
• Compound Shodan queries — multi-parameter detection signatures per cluster, ready for deployment
• Noise re-analysis — the IoT proxy layer was invisible in primary clustering and emerged only when outlier IPs were re-clustered independently

Most of this analysis doesn't happen in practice. SOC and IR teams work the alerts, close the tickets, block the IOCs — and the infrastructure patterns behind those IOCs go unexamined. How the attacker builds, where they host, what deployment templates they reuse, what kind of infrastructure keeps getting exploited. Those patterns persist across campaigns, but analyzing them manually takes specialized skills and time that most teams don't have. ClusterHawk handles that part. Feed it an IP list, get back the architecture, the fingerprints, and the detection signatures.

ClusterHawk is Chawkr's infrastructure clustering platform. Learn more at clusterhawk.chawkr.com.

Infrastructure Fingerprints

Certificate CNs

Cobalt Strike IPs

103.211.216.225
104.219.233.87
159.69.228.160
172.67.191.79
209.38.215.185

CRITICAL Anomalous IPs

172.67.129.36 (score: 19.8)
172.67.143.56 (score: 17.8)
103.211.216.225 (Cobalt Strike overlap)

All 95 Campaign IPs

103.211.216.225
104.21.14.53
104.21.14.64
104.21.15.167
104.21.2.118
104.21.20.39
104.21.21.243
104.21.23.187
104.21.29.80
104.21.30.98
104.21.33.170
104.21.33.39
104.21.34.220
104.21.36.115
104.21.36.35
104.21.37.12
104.21.39.49
104.21.42.163
104.21.46.157
104.21.49.78
104.21.55.107
104.21.55.136
104.21.56.50
104.21.61.2
104.21.64.3
104.21.66.42
104.21.68.45
104.21.69.193
104.21.70.38
104.21.72.184
104.21.73.166
104.21.74.105
104.21.75.240
104.21.76.167
104.21.78.60
104.21.80.189
104.21.82.237
104.21.86.49
104.21.95.55
104.219.233.87
159.69.228.160
161.97.83.18
162.0.229.151
170.205.52.126
172.237.138.218
172.67.129.36
172.67.140.108
172.67.143.56
172.67.143.72
172.67.146.72
172.67.148.52
172.67.153.218
172.67.153.73
172.67.157.219
172.67.157.51
172.67.158.148
172.67.158.34
172.67.160.105
172.67.163.138
172.67.163.36
172.67.165.11
172.67.171.108
172.67.171.25
172.67.172.185
172.67.173.182
172.67.177.146
172.67.183.166
172.67.184.179
172.67.186.166
172.67.191.79
172.67.192.212
172.67.197.124
172.67.200.184
172.67.201.112
172.67.202.102
172.67.204.79
172.67.209.190
172.67.209.72
172.67.212.101
172.67.212.191
172.67.215.20
172.67.217.57
172.67.219.111
173.231.22.251
185.241.208.193
192.185.174.50
196.41.127.42
197.189.199.98
199.188.201.198
203.170.84.9
209.38.215.185
216.126.227.101
217.195.207.180
41.76.104.31
89.163.155.33

• Sekoia — New Widespread EvilTokens Kit: Device Code Phishing-as-a-Service, Part 1 (March 2026) https://blog.sekoia.io/new-widespread-eviltokens-kit-device-code-phishing-as-a-service-part-1/

• Abnormal AI — EvilTokens: OAuth Device Codes in BEC Operations (2026) https://abnormal.ai/blog/eviltokens-oauth-device-codes-bec-operations

• Huntress — Riding the Rails: Railway.com PaaS as M365 Token Attack Infrastructure (March 2026) https://www.huntress.com/blog/railway-paas-m365-token-replay-campaign

• CISA — Known Exploited Vulnerabilities Catalog https://www.cisa.gov/known-exploited-vulnerabilities-catalog