The Azure Shell Game: An Empty-User-Agent Botnet Inside Microsoft's Cloud

TI-2026-059B · Series: The Front Door · Classification: HIGH · Confidence: HIGH

Second in The Front Door series. Where 059A followed the credential harvesters across the whole cloud, this dossier stays in one building — Microsoft Azure — and watches a single botnet pace its hallways, trying every door marked shell.php.

Executive Summary

Our web edge sees 338 IP addresses carrying the shell_upload intent. That number is a mirage. When you cluster them, 200 of the loudest collapse into one operation: web Campaign 126, "Empty-UA Botnet AS8075" — 36,342 requests between 4 and 30 June 2026, every node inside Microsoft Azure (AS8075), every node sending an empty User-Agent, every node reading from the same list of webshell filenames.

It is not 200 attackers. It is one attacker wearing 200 disposable Azure addresses.

And it is mostly not uploading anything. Seventy-one percent of its requests return 404. The botnet is hunting for backdoors that already exist — shells dropped by earlier compromises or by rival crews — because finding someone else's open door is cheaper than breaking in yourself.

One ASN, One Header, One Wordlist

Campaign 126 was flagged by a detector that looks for a specific coincidence: many IPs, same ASN, all sending an empty User-Agent. Legitimate browsers and honest crawlers announce themselves. A blank UA across 200 hosts in a single cloud is not diversity — it is one program, launched 200 times.

The member IPs geolocate all over the map — US, Singapore, Great Britain, Japan, Brazil, Ireland — but that is just Azure's region list. Every single address resolves to AS8075. The geography is Microsoft's; the operator is one.

What They Knock On

Read the top paths from node 20.104.203.253 (1,479 requests, empty UA) and 20.197.238.124 (750 requests, MikroTik-banned), and the intent is unmistakable — this is a webshell dictionary:

/x.php           /dx.php          /1.php           /155.php
/term.php        /666.php         /ppp.php         /aaf.php
/elp.php         /ws54.php        /adminfuns.php   /admin.php
/wp-content/admin.php
/wp-content/plugins/hellopress/wp_filemanager.php
/this_is_a_new_hello_world.php
/classwithtostring.php
/wp-admin/       /wk/index.php    /wp-content/uploads/

Two things stand out.

First, the 404 rate. These are GET requests to shell names, and they almost all miss. The botnet is not planting these files — it is checking whether they are already there. A 200 on /term.php means the host is already owned, and the bot can walk straight into a pre-existing backdoor. This is a documented pivoting technique: the SANS Internet Storm Center's "What Web Shells are Attackers Looking for?" catalogues exactly this hunt for reusable c99/r57/wso and bespoke shells.

Second, the bespoke names. /x.php and /666.php are generic. But this_is_a_new_hello_world.php and classwithtostring.php are not names you find in a public wordlist — they are toolkit artifacts. Their appearance across many otherwise-unrelated Azure nodes is the tell that a single automated framework is driving the whole botnet.

Why Azure, Specifically?

Here is the finding that should make a Microsoft abuse engineer uncomfortable. All three hyperscalers appear in our data. Their locally-computed risk scores do not match their reputations:

Azure carries two to three times the risk of AWS or Google Cloud against our edge, despite identical legitimacy on paper (ARIN-allocated, PeeringDB "Content," clean Spamhaus record). Something about Azure makes it the preferred launch pad for this class of abuse.

The most parsimonious explanation is cost and friction: abused free trials, student credits, and compromised tenants turn Azure into near-free disposable compute — and the attacker inherits Microsoft's IP reputation for free. You cannot blocklist AS8075; it hosts half the SaaS you use. That asymmetry — trusted range, trivial to rent, painful to block — is exactly what a disposable botnet wants.

Read Between the Lines

Q: If 71% of requests 404, is this even a threat? They're not getting in. They are not getting in to us — because we are not already compromised. But the scan is only worthwhile because it often succeeds elsewhere. A 200-node botnet does not spend three weeks GETting /term.php across the internet unless a meaningful fraction of hosts answer 200. Every one of those probes is a census of the already-breached. We are watching the reconnaissance half of somebody else's successful campaign.

Q: Why an empty User-Agent? Isn't that trivially detectable? It is trivially detectable by us — which is precisely why the campaign was caught and clustered. But most WordPress installs and small PHP apps do not log or filter on User-Agent at all, and an empty UA is faster (no string to construct) and gives away no toolkit version. The operator traded stealth against sophisticated defenders for speed against unsophisticated ones. Given the target class — mass, low-value, unpatched CMS — that is a rational bet.

Q: 200 Azure IPs — did Microsoft do something wrong? Not maliciously, but structurally. Every hyperscaler faces trial-abuse; Azure's numbers here suggest its onboarding is currently the softest of the three. The uncomfortable truth is that the same cloud reputation that lets you trust login.microsoftonline.com is what the botnet is renting to slip past your WAF. Reputation is transferable; accountability lags behind it by the length of an abuse-report queue.

The Alternative Interpretation

Could Campaign 126 be benign infrastructure scanning — Microsoft's own security team, a partner's ASM product, or a misconfigured uptime monitor sweeping customer sites?

No, and the paths settle it. Microsoft's scanners identify themselves and do not hunt /666.php. An uptime monitor requests your homepage, not hellopress/wp_filemanager.php. No legitimate service on earth has a business reason to GET this_is_a_new_hello_world.php from 200 addresses. The empty UA could be an accident; the webshell wordlist cannot be. Benign scanners measure availability. This one is taking attendance at a roll-call of backdoors.

Verdict

The shell_upload surface is not internet-wide noise — it is a single empty-User-Agent botnet living inside Microsoft Azure, using the cloud's reputation as cover and its trial economy as fuel, primarily reconnoitring for pre-existing webshells to reuse rather than uploading new ones. Its bespoke filename artifacts fingerprint one automated toolkit across all 200 nodes. Confidence: HIGH that this is one clustered operation on AS8075; MEDIUM that the mechanism is trial/tenant abuse rather than a single compromised subscription.

Defensive Response

• Cluster, don't chase. Ban on the signature (empty UA + AS8075 + shell-name paths), which CrowdSec already does, instead of listing 200 individual /32s that Azure will recycle anyway.
• Turn the scan into a detector. Any 200 response to /x.php, /term.php, /666.php, wp_filemanager.php or the bespoke names is a compromise alarm — alert on it. The botnet is doing your breach-detection for free.
• Keep the filename IOCs. this_is_a_new_hello_world.php and classwithtostring.php are durable toolkit fingerprints that outlive IP rotation.
• Report to Azure abuse. Ephemeral IPs make blocking pointless, but provider abuse reports are the only lever that removes the fuel.

Sources

• LSN web-threats platform — Campaign 126 export, IP dossiers for 20.104.203.253 and 20.197.238.124, ASN profile AS8075 (Traefik access logs + CrowdSec scenarios + MikroTik bans).
• SANS Internet Storm Center — A Little Bit Pivoting: What Web Shells are Attackers Looking for? — https://isc.sans.edu/diary/32874
• NSA / CISA — Detect and Prevent Web Shell Malware (joint advisory) — https://media.defense.gov/2020/Jun/09/2002313081/-1/-1/0/CSI-DETECT-AND-PREVENT-WEB-SHELL-MALWARE-20200422.PDF
• Kaspersky Securelist — SOC files: a web shell chase — https://securelist.com/soc-files-web-shell-chase/115714/

Investigation TI-2026-059B · The Front Door series · 200-node Azure botnet, 36,342 requests, empty User-Agent, webshell-reuse reconnaissance · Cross-referenced with SANS ISC and NSA/CISA web-shell guidance · Confidence: HIGH.