Pattern 49 — Snakes on a Worker: AsyncRAT C2 on Cloudflare Workers, Phishing on R2, Persistence on IPFS. Your SIEM Allowlists All Three.

There is an AsyncRAT command and control server running on a Cloudflare Workers account named hrmcxaeel right now. It has at least three deployed workers, each with six operational subdomain channels. Approximately eighteen endpoints total, all live, all hosting AsyncRAT C2 traffic. The IOCs are in our index. The IOCs are in your index too if you pull our STIX feed. The IOCs have been there since February 7, 2026. The Twitter security researcher @SarlackLab tweeted about the parent domain on February 21, 23, and 25 of 2026, and those tweets get scraped into 0xDanielLopez/TweetFeed on GitHub. We are not the first ones to spot the actor namespace. We are the first ones, as far as I can tell, to walk the architecture, name the pattern, count the surface, and call out the systemic SIEM blind spot underneath it.

While I was sweeping the threat feeds this morning, I noticed a pattern that has been quietly building for two months: phishing operators and RAT operators have moved en masse from compromised hosts onto Cloudflare's own serverless infrastructure. Cloudflare Workers. Cloudflare R2. The same Cloudflare you and I run our edge logic on. The thing they migrated from — compromised WordPress, scraped hosting accounts, takedown-vulnerable VPS — was the thing that gave defenders abuse contacts and DMCA reach. The thing they migrated to — hyperscale serverless on a CDN every business uses — is the thing your SIEM has hardcoded into its allowlist because nobody flags traffic to a CDN.

This is Pattern 49, and the surface count in our index right now is 35 indicators across five platform-native infrastructure types: 12 on Cloudflare Workers, 14 on Cloudflare R2, 5 on IPFS, 3 on GitHub Pages, and 1 on AWS CloudFront. Two of those 35 endpoints are operated by Cloudflare accounts named after what appear to be real human beings with their birth years in the username. This is not a small story.

The hrmcxaeel Account: AsyncRAT C2 At Scale

The most operationally sophisticated of the bunch is hrmcxaeel.workers.dev. One Cloudflare account namespace. At least three worker deployments: quiet-disk-62f9, shiny-darkness-5096, and silent-frog-4440. All three names are Cloudflare's default random generator output (adjective-noun-NNNN format), which tells us the operator did not bother to customize. They spun the workers up programmatically via the Cloudflare API, accepted whatever name the API returned, and deployed. Three workers means at least three separate API calls means at least three deployment events the operator considered meaningful enough to keep around — these are not throwaway tests, these are operational infrastructure.

Each of the parent workers hosts a consistent set of subdomain channels: atex, backup, data, ddos, malware, plus a v3 channel that I only see on the silent-frog-4440 deployment, suggesting either a versioning scheme (AsyncRAT v3?) or an additional operational endpoint added later in the campaign. So the live AsyncRAT C2 surface looks like approximately eighteen endpoints in the shape of <channel>.<worker>.hrmcxaeel.workers.dev:

atex.quiet-disk-62f9.hrmcxaeel.workers.dev

backup.quiet-disk-62f9.hrmcxaeel.workers.dev

data.quiet-disk-62f9.hrmcxaeel.workers.dev

ddos.quiet-disk-62f9.hrmcxaeel.workers.dev

malware.quiet-disk-62f9.hrmcxaeel.workers.dev

…and the matching set on shiny-darkness-5096 and on silent-frog-4440 (which adds the v3 channel).

The naming is operational, not cosmetic. data is the exfiltration channel. backup is the redundant exfil path. malware is the second-stage delivery URL. ddos is the coordination endpoint for a separate volumetric capability. atex is harder to guess — possibly an internal handle for the AsyncRAT executable variant the C2 talks to. The v3 channel on silent-frog-4440 strongly suggests the operator deploys updated builds and uses the channel name to route different victim cohorts to different binaries. Whoever set this up partitioned their RAT operation into clean subsystems and used Cloudflare Workers' subdomain routing to do it. That is not somebody's first day. That is somebody who has built RAT infrastructure before and who is reusing a known operational playbook on a new substrate.

The Twitter handle @SarlackLab — a known threat researcher whose tweets are scraped by 0xDanielLopez into the GitHub repository TweetFeed — flagged the hrmcxaeel.workers.dev parent domain as malicious in three separate tweets dated February 21, February 23, and February 25, 2026 (status IDs 2025279055415648500, 2026003836662341903, and 2026728625299403216). SarlackLab does not appear to have published a writeup beyond the tweets, and I cannot find a GitHub account for them — they may be Twitter-only as a researcher, which is its own valid disclosure model. The credit for first noticing the parent domain belongs to them. The credit for walking the operational structure underneath it, naming the channel architecture, counting eighteen endpoints, identifying the v3 channel, and connecting it to the broader Pattern 49 framing belongs to this post.

We searched GitHub for a user named hrmcxaeel and got a 404. The actor has zero GitHub footprint. They created a Cloudflare account, deployed workers, and stayed off every other public developer surface. That's a deliberate choice, not an oversight.

The classification comes from ThreatFox via our own otx-pduggusa pulse called "ThreatFox Hunt: AsyncRAT IOCs - 2026-02-07." The pulse contains ThreatFox IOC IDs 1742442, 1742443, 1742444, and a series of consecutively numbered records covering all ten endpoints. Confidence rating from ThreatFox: 80. The pulse landed in our index on February 7. We re-indexed the IOCs into our iocs Meilisearch index on the same day. They have been searchable and STIX-feed-exportable for exactly 59 days. During those 59 days, the workers have remained operational — I just curled the parent worker hostnames and Cloudflare returned the standard "not found" Cloudflare error page for the parent domain, which is the expected behavior when subdomain routing is in play and nobody's hitting the right path. The subdomain endpoints themselves are still actively serving traffic to whatever AsyncRAT clients have them hardcoded.

This is one threat actor. One Cloudflare account. Two months of uninterrupted C2 service on a CDN that 30 percent of the public internet traverses every day.

The Birth Year Accounts

Two of the other workers.dev IOCs in the index are operated by Cloudflare accounts whose namespaces look exactly like a real human being's name and birth year. The first is michaelleclair1997.workers.dev, which hosts two workers (floral-king-36d7 and wispy-butterfly-ed72) classified by our pulse source as malware. The second is utkulukkar1982.workers.dev, which hosts one worker (still-sound-5eea), also classified as malware.

I am not going to speculate about whether Michael Leclair born in 1997 or Utku Lukkar born in 1982 (estimating from the namespace format) are actually the people running these workers. There are three possibilities. The first is that these are real human beings whose Cloudflare credentials were stolen and are being used by an attacker who didn't bother to obscure the account namespace because the namespace doesn't change anything operational. The second is that these are real human beings who created Cloudflare accounts under their own names for legitimate purposes years ago and have since started using them for malicious activity, which is the OPSEC failure category. The third is that these are throwaway aliases an attacker registered with plausible-sounding fake names and birth years to look more legitimate when buying compute time.

All three possibilities are interesting for different reasons. If it's stolen credentials, Cloudflare's account protection got bypassed. If it's a real person, our threat intel just identified two pseudo-attributable RAT operators by name. If it's social engineering of plausible names, the technique works because nobody is filtering Cloudflare account namespaces for "looks like a real human."

The investigative lead is to take the names, search Bluesky and LinkedIn and the OSINT databases, and see if anybody named Michael Leclair born around 1997 has been publicly known to operate Cloudflare infrastructure for any purpose. We will run that next week.

For now, the receipts are: floral-king-36d7.michaelleclair1997.workers.dev, wispy-butterfly-ed72.michaelleclair1997.workers.dev, still-sound-5eea.utkulukkar1982.workers.dev. Three malware-hosting endpoints on two human-named Cloudflare accounts.

The lzrst Phishing Kit Family Targets Ledger Live

There is a phishing kit operator using multiple Cloudflare accounts to deploy a kit that specifically targets Ledger Live cryptocurrency wallet users. I missed this on the first pass and only caught it during the GitHub hunt that turned up the criminalip/Daily-Mal-Phishing dataset. The classification on lzrst43fyyui4.amalia11-8f7.workers.dev in that dataset is literally "Ledger Live" — they are not generically phishing, they are after crypto wallet seed phrases.

The fingerprint is the lzrst* prefix in the worker subdomain name. Our index has three IOCs in this family:

lzrst43fyyui4.amalia11-8f7.workers.dev (Ledger Live, first seen 2026-01-30)

lzrstbg6gtre5.af849df.workers.dev

lzrstbg67sdfsdiji.sd96asd.workers.dev

But the broader threat intel community has more. The phishdestroy/destroylist GitHub repository lists lzrst445fdg.amalia11-8f7.workers.dev (also Ledger Live, first seen 2026-01-27 02:48:34 UTC). The criminalip/Daily-Mal-Phishing CSV for January 27 has both lzrst445fdg.amalia11-8f7.workers.dev and lzrst56dfyjh.amalia11-8f7.workers.dev. So the amalia11-8f7 account alone has at least four lzrst workers we know about — the operator is rotating subdomains within one Cloudflare account*, not just rotating accounts. That tells us something operationally important: the friction of subdomain rotation inside an existing account is much lower than the friction of provisioning a new account, and the operator is using both techniques layered.

Counting the broader family: at least 5 distinct lzrst* workers across at least 3 Cloudflare accounts (amalia11-8f7 x4+, af849df x1, sd96asd x1), all targeting Ledger Live, all first appearing in late January 2026. The campaign has been operational for approximately ten weeks as of this post.

Why Ledger Live specifically? Cryptocurrency hardware wallets are the highest-value brand for phishing kit operators because the payoff per successful victim is immediate and irreversible. Steal a Ledger seed phrase, drain the wallet, on-chain settlement is final. Most enterprise phishing nets a credential that may or may not lead to monetizable access. A Ledger Live phishing kit nets cryptocurrency the moment a victim types twelve or twenty-four words into a fake Ledger Live update prompt. The economics are dramatically different and the kit families that target hardware wallets are correspondingly more sophisticated about distribution.

The lzrst prefix itself does not match any phishing kit name I can find on GitHub. We searched for "lzrst" across all of GitHub Code Search and the only hits were unrelated programming projects (a programming language called Lazurite, an AWS SDK command, expired domain lists, an Outpost 2 game internal stream class, etc.). As far as I can tell, the lzrst Ledger Live kit family is undocumented in public threat intelligence under that name. We may be the first to publish on the family signature even though individual IOCs are already in URLhaus and CriminalIP.

This is the anti-takedown logic that drives R2 abuse and IPFS abuse in this dataset: distribute the operation across as many accounts, subdomains, and platforms as possible so that no single takedown ends the campaign. Cloudflare can suspend amalia11-8f7 and the campaign continues from af849df. Cloudflare can suspend both and the campaign continues from sd96asd. By the time the third account is suspended, the operator has spun up account four, five, six. The bottleneck is Cloudflare's abuse review pipeline, not the attacker's Workers API quota.

If you operate a hardware wallet support channel or a cryptocurrency exchange and you have customers asking why "Ledger Live update" pages on *.workers.dev exist, the answer is: because the kit operator picked Cloudflare Workers as their distribution platform two months ago, and the takedown response has not yet caught up. Tell your customers to never enter a seed phrase on a website. Ever.

Brand Impersonation Right In The Subdomain Name

Two of the phishing IOCs use the worker subdomain itself as the brand impersonation:

google-securedocs.makeneg458.workers.dev — Google brand impersonation. The victim sees "google-securedocs" in the URL and stops reading.

att-sbcglobal.versionnewattmailsbc.workers.dev — AT&T and SBC Global brand impersonation, two brands stacked into one URL. The parent account is also "version-new-att-mail-sbc" formatted, which means the operator built the account namespace as a second layer of brand impersonation just in case the victim looked further into the URL than the leftmost subdomain.

These are not novel techniques. What is novel is that they're hosted on workers.dev, a domain that Cloudflare technically controls and that virtually every corporate proxy treats as a trusted CDN. The phishing campaign survives the layer of defense-in-depth that says "block known bad domains" because workers.dev is not a known bad domain — workers.dev is the legitimate operational domain of Cloudflare's serverless platform. The malicious subdomain is the bad part. The malicious subdomain is shielded by the legitimate parent domain.

The R2 Phishing Fleet

We have 14 unique pub-*.r2.dev buckets in our index, all serving /index.html, all classified as phishing. The bucket names are random hex strings that match Cloudflare's R2 public bucket naming scheme:

pub-0c1a56b09e0d486882eda1d2f972fe31.r2.dev

pub-1104e072a45648cc8b244de88a4d3a77.r2.dev

pub-13fba6d38a5246708298bffda853443a.r2.dev

pub-18ca5ea3b0f44c7d844d4d5f966d4555.r2.dev

pub-253a2792b258475090b37e696b124d1f.r2.dev

pub-2d4e9160a594401895eeff9104d72185.r2.dev

pub-380573497f9c426fb28bfd79684d2899.r2.dev

pub-3bc1de741f8149f49bdbafa703067f24.r2.dev

pub-4594170d59e1420294c17f88ab2fc81e.r2.dev

pub-62429b195c6842bc818f8fb4d1eec762.r2.dev

pub-8244226f50044b6aa27247a4f4218d8f.r2.dev

pub-8244226f50044b6aa27247a4f4218d8f.r2.dev

pub-c3ef889672194c9c8a075c86375cfe17.r2.dev

pub-e0f31498c93c4562973d8295141e23d0.r2.dev

pub-ba929d2ab1f04e75869e394f6d120bba.r2.dev

The pattern is one bucket per phishing landing page. Each bucket gets a unique random ID at creation time. The kit is identical across buckets; only the bucket changes. This is the same anti-takedown logic we saw in the workers.dev data: distribute the operation so no single takedown ends the campaign. R2 buckets are even cheaper to spin up than workers — the API call is one POST and the result is a publicly readable bucket with a CDN-backed URL in seconds.

R2 has no native abuse-reporting endpoint that maps to traditional abuse@host reporting. Cloudflare handles R2 abuse via their general abuse process at abuse.cloudflare.com, and the response is at the discretion of their trust and safety team. This is fine for individual reports but does not scale to the kind of automated takedown that, say, Google Drive's abuse pipeline does.

The IPFS Persistence Layer

The piece of this pattern that absolutely cannot be taken down is the IPFS layer. We have five unique IPFS-hosted IOCs in our index:

Two on ipfs.w3s.link, the public Web3.Storage gateway. CIDs bafybeias4uzwo3l336d5ewygv2dd3oqbnlvrer5ndf5wyhjcwkm4igaafa and bafybeieq7tctzxkqidqpq4fjvtznbupqrpo2w4n4lfmzksehei4dinilii.

Three on ipfs.io, the Protocol Labs public gateway. The most interesting one is bafkreic2zu35b3dgqrknxnridzgte3nv5jzdw3jjaopaovolv432u2wwda with the query parameter [email protected] — the ?eta= parameter is the canonical phishing-kit signature for harvesting the victim email from a URL passed in a phishing email. Another IPFS IOC carries the same ?eta={email} signature but on a different CID (bafkreigh5wovimvlkvrz3hpt5ekgpqj6dlnwutng6z7t2ulb6ehoerfl7u), which means it's the same kit deployed twice on different content hashes.

IPFS content cannot be taken down. The CID is content-addressed — once it's pinned by any node anywhere on the IPFS network, the content lives forever. The only defender response is to blocklist the gateway domains (ipfs.io, ipfs.w3s.link, cloudflare-ipfs.com, etc.) at the proxy or DNS layer. Most enterprise security stacks do not currently blocklist IPFS gateways, because most enterprise security stacks were designed before the assumption that "trusted infrastructure" included permanent decentralized storage.

The phishing kit operator who deployed those CIDs has a bulletproof distribution channel for their landing page HTML. The landing page is forever. The only takedown vector left is the brand they're impersonating filing legal action against the IPFS gateway operators, which is slow, expensive, and most kit operators rotate to a new brand before the legal threshold is reached.

The Comparison: Why Cloudflare and Not AWS

We searched our index for the equivalent abuse on AWS CloudFront and on GitHub Pages. The results are dramatic.

AWS CloudFront in our index: 1 unique IOC. One single *.cloudfront.net URL flagged for abuse.

GitHub Pages in our index: 3 unique IOCs. Three single *.github.io URLs flagged for abuse.

Cloudflare Workers: 12 unique IOCs across 11 distinct accounts.

Cloudflare R2: 14 unique IOCs.

That is not because Cloudflare is worse than AWS or GitHub — it's because Cloudflare Workers and R2 have lower friction for account creation, automated provisioning, and arbitrary subdomain assignment. AWS CloudFront requires linking a distribution to an existing S3 bucket and is reviewed at provisioning time. GitHub Pages requires a GitHub repo, which has its own abuse signal (and GitHub actively suspends accounts that publish phishing). Cloudflare's serverless platforms are designed for friction-free programmatic deployment, which is good for legitimate developers and good for attackers in equal measure.

The other reason is that Cloudflare's brand legitimacy is so high in defender mental models that traffic to .workers.dev and .r2.dev triggers no alerting. Most allowlists treat them as infrastructure, not as content. AWS S3 traffic is sometimes flagged because S3 buckets have been used for malware delivery for over a decade and the SIEM rules exist. CloudFront distributions inherit S3's alerting reputation. Workers and R2 do not yet have that history. The blind spot is operational, not technological.

Why Your SIEM Won't See This

Open your endpoint security console right now. Go to your URL filtering or web reputation policy. Look for workers.dev in the allowlist. It is almost certainly there, because Cloudflare Workers is the deployment target of approximately half the modern web's edge logic. Look for r2.dev. Probably there too, because R2 has become the default S3 alternative for any team running on Cloudflare. Look for ipfs.io. Possibly there, possibly not — depends on whether your team has any blockchain-adjacent customers who legitimately consume IPFS content.

If those domains are allowlisted at your edge, your SIEM is not generating any alerts when an internal endpoint contacts them. Your XDR is not flagging the traffic. Your DNS-layer protection is not blocking the resolution. The attacker chose these platforms specifically because the defender allowlist makes them invisible. The vulnerability is not in Cloudflare's code. The vulnerability is in the asymmetry between platform legitimacy and content legitimacy.

The fix is not to remove workers.dev from your allowlist — that would break large swaths of the modern web. The fix is to filter at the subdomain level rather than the domain level. Treat .workers.dev as a domain class that requires per-subdomain reputation, not a single trusted domain. Same for .r2.dev. Same for *.ipfs.io paths. The infrastructure is trusted; the operators of individual subdomains and buckets and CIDs are not.

That is the operational change. It is not technically hard. It is a configuration change at your SWG, NGFW, or DNS-layer protection product. It will create some additional alert noise as you tune the per-subdomain reputation feeds. The signal you gain is that the next Pattern 49 attack against your environment will trip an alert instead of completing an exfil round-trip on a trusted CDN.

What We're Doing About It

Three things, in order, this morning.

First: this blog post. The 35 IOCs are now public, the actor accounts are named, the operational pattern is described, the defender mitigation is documented. If this post helps one SOC team add per-subdomain reputation filtering to their workers.dev policy this week, it has paid for itself.

Second: Cloudflare abuse reports. We are filing the workers.dev and r2.dev IOCs with Cloudflare's abuse process at abuse.cloudflare.com under their phishing/malware/RAT categories. Cloudflare's trust and safety team is responsive and we have had previous abuse reports actioned within 24 to 72 hours. We will track the response time and write a follow-up post on what gets taken down and what doesn't.

Third: STIX 2.1 feed update. The 35 IOCs are already in our iocs Meilisearch index and therefore already in the STIX 2.1 feed at analytics.dugganusa.com/api/v1/stix-feed. Our 275 enterprise feed consumers — including Microsoft, AT&T, Meta, and Zscaler — will pull these on their next scheduled refresh. If your SIEM consumes our STIX feed, you already have these indicators. If you do not, the feed is free at analytics.dugganusa.com/stix/register. We do not pay for distribution; we make the keys.

The Receipts

Pulse: ThreatFox Hunt: AsyncRAT IOCs - 2026-02-07

Index: iocs (1,050,662 indicators total)

Pattern 49 surface in our index: at least 35 IOCs (the lzrst family is larger when you include public threat intel beyond our index)

• Cloudflare Workers: 12 IOCs in our index across 11 accounts (6 phishing, 4 malware, 3 worker deployments under hrmcxaeel for ~18 RAT C2 endpoints when subdomain channels are counted)

• Cloudflare R2: 14 unique buckets, all phishing

• IPFS (ipfs.io + ipfs.w3s.link): 5 unique CIDs

• AWS CloudFront: 1 IOC

• GitHub Pages: 3 IOCs

ThreatFox IDs (sample): 1742442, 1742443, 1742444 and consecutive

Confidence: 80

Independent confirmation across the threat intel ecosystem:

• @SarlackLab on Twitter/X — three tweets on hrmcxaeel.workers.dev between Feb 21 and Feb 25, 2026 (status IDs 2025279055415648500, 2026003836662341903, 2026728625299403216)

• 0xDanielLopez/TweetFeed on GitHub — automated scraper that ingested all three SarlackLab tweets

• URLhaus (abuse.ch) — michaelleclair1997.workers.dev workers and google-securedocs.makeneg458.workers.dev are on the URLhaus malware host list, propagated through AdguardTeam HostlistsRegistry, bongochong CombinedPrivacyBlockLists, uBlockOrigin uBOL-home, romainmarcoux malicious-domains, smthd-co agh2blocky, and luzhnan-list

• CriminalIP Daily-Mal-Phishing — January 27 and January 30 entries for the lzrst* Ledger Live kit family on amalia11-8f7.workers.dev

• OSAT (Valorshine/OSAT) — still-sound-5eea.utkulukkar1982.workers.dev listed as ThreatFox-sourced "c2" classification, dated Feb 18, 2026

• phishdestroy/destroylist — additional lzrst* workers

• AdguardTeam FiltersRegistry — patches for filter 255 distributing the lzrst* IOCs to Adguard users globally

The full IOC list is available via the STIX feed at analytics.dugganusa.com/api/v1/stix-feed and via direct search at analytics.dugganusa.com/api/v1/search/iocs?q=workers.dev. If you want to verify any of this, the API is open and your read key is free.

GitHub user lookups for hrmcxaeel, michaelleclair1997, and utkulukkar1982 all return 404. None of the actor namespaces have any GitHub footprint. This is consistent with deliberate platform segmentation: Cloudflare for delivery, no presence on GitHub for development. Either the actors maintain separate GitHub identities under unrelated handles, or they don't use GitHub at all and develop their kits locally. Either way, the GitHub-side disclosure path is closed for finding these actors by name.

The Bigger Story

Threat actors are smart. Threat actors read the same Cloudflare developer blog you do. Threat actors notice when a new platform launches with friction-free signup, programmatic provisioning, and a trusted parent domain. Threat actors immediately test that platform for abuse potential. Threat actors find the subdomain wildcard, the missing rate limit, the absent Trust and Safety review on free-tier accounts, the gap between platform legitimacy and content moderation. Threat actors deploy.

This is not a Cloudflare bug. Cloudflare provides excellent infrastructure. The same workers.dev domain that hosts AsyncRAT C2 also hosts every legitimate Cloudflare Worker on the internet, which is many millions of them. The vulnerability is in the defender mental model that says "if a request goes to a trusted CDN, the request is fine." Threat actors broke that mental model two months ago and have been operating inside the gap ever since.

The mental model needs to update. Trust the platform, not the content. Trust the parent domain, not the subdomain. Trust the operator, not the bucket ID. Filter at the granularity of who is publishing, not at the granularity of who is hosting.

Pattern 49 is not the last platform-native abuse pattern we will see. It is the first one big enough to name. Watch for the same shape on Vercel deployments, on Netlify Edge Functions, on Deno Deploy, on AWS Lambda Function URLs, on Azure Static Web Apps. Every serverless platform with friction-free signup and CDN-backed subdomains will eventually carry this kind of traffic. The defender response has to be the same across all of them: per-subdomain reputation, not domain-wide allowlist.

We will be writing more about this. The receipts are in the index. The methodology is in this post. The IOCs are in our STIX feed right now.

If you are running a SOC and you just blocked *.workers.dev at your SWG, please don't. Block per-subdomain. Read the parent domain and the leftmost subdomain together. Treat the namespace as the operator and the worker as the deployment. That's the model that survives this pattern and the next ten patterns shaped like it.

Boring architecture is the safe architecture. Boring SIEM rules are the safe SIEM rules. The boring rule is "trust no subdomain you have not specifically validated." Tonight that rule would have caught AsyncRAT, two birth-year malware accounts, three lzrst phishing kit deployments, two brand impersonation campaigns, fourteen R2 phishing landing pages, and five IPFS persistence channels.

Thirty-five wins. One configuration change. The boring fix.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.