In Letter A, we documented a professional credential harvesting operation — 54 Google Cloud IPs scanning for .env files with military-grade OPSEC. Zero SSH overlap. Daily rotation. A specialist.

Letter B is the opposite. This is a blunt instrument. A horde.

269 Microsoft Azure IPs. Empty user-agents. No stealth whatsoever. And they're not looking for vulnerabilities to exploit — they're looking for backdoors that are already there. Someone else planted the shells. This fleet just checks which ones still work.

Welcome to the supply chain of web exploitation.

In the criminal web exploitation economy, there are layers:

1. The Exploiter — finds a WordPress vulnerability, exploits it, plants a webshell (a PHP file that gives remote command access)
2. The List Seller — collects thousands of compromised URLs, sells lists of "active shells" on dark markets
3. The Checker — buys/receives the list, systematically verifies which shells still work
4. The Operator — uses verified shells for spam, crypto mining, DDoS, phishing hosting, or further lateral movement

The Azure fleet documented here is Layer 3 — The Checker. It doesn't plant shells. It doesn't use them. It just verifies they exist. The paths it requests are not WordPress core files — they are specific backdoor filenames that were planted by someone else, probably months ago.

The detection was immediate. Empty user-agent is the most basic fingerprint in web security — no browser, no crawler, no legitimate tool sends requests without identifying itself. Yet here were 308 IPs doing exactly that, generating 41,384 requests to 1,437 unique paths across our infrastructure.

When we filtered by ASN, one provider dominated everything:

Not Google this time. Not DigitalOcean. Not some obscure bulletproof hoster. Microsoft Azure — the second-largest cloud platform on Earth — hosting a botnet that makes no attempt to hide itself.

This is the key to understanding the operation. None of these files exist in a legitimate WordPress installation. Every single path below is a known webshell filename or backdoor marker:

The naming patterns reveal three strategies:

• WordPress disguise — wp-blog.php, wp-the.php, wp-temp.php, wp-good.php — look like WordPress core files but aren't
• Minimalist naming — x.php, 1.php, dx.php, ppp.php — tiny names that blend into directories with many PHP files
• Marker/callback — this_is_a_new_hello_world.php, hellopress/wp_filemanager.php — unique identifiers that confirm "yes, our shell was installed here"

The operation is not blind. Before checking for shells, a reconnaissance subset of 21 IPs first confirms the target runs WordPress:

Only after confirming WordPress does the full shell-checking fleet engage. This is an efficiency optimization — why waste 50+ requests checking for WordPress shells on a server running Nginx + Node.js?

The version-specific checks (jQuery 3.7.1, WordPress 7.0) suggest the shell planter exploited a vulnerability in that specific version. The checker only visits targets running the vulnerable version because only those could have been compromised.

Remember Letter A's key finding? The Google Cloud .env fleet had zero SSH honeypot overlap — proving a specialist. The Azure ghost fleet is the opposite:

Every. Single. One. The same machines that check for WordPress backdoors over HTTP are simultaneously brute-forcing SSH logins on every server they can find.

This tells us exactly what we're dealing with:

• This is a commodity botnet — it runs every available attack module against every target
• The operator does not value stealth — volume over precision
• The Azure instances are likely compromised themselves — running botnet agents installed via stolen credentials or supply chain compromise
• Contrast: The Google .env operator (Letter A) would NEVER expose their infrastructure to SSH blacklists. Different operator, different tier, different market.

Two completely different operational philosophies attacking the same target. One is a scalpel. The other is a battering ram.

If the Azure ghost fleet finds one of these files on your server, it means you were already compromised. The shell was planted days, weeks, or months ago by a different attacker. The ghost fleet is just the latest visitor to your already-open back door.

The terrifying implication: If any of these paths return HTTP 200 on your server, an attacker already has full command execution on your machine. They can:

• Read your wp-config.php (database credentials)
• Upload additional malware (crypto miners, spam relays)
• Modify your WordPress content (SEO spam injection, redirect chains)
• Use your server as a proxy for further attacks
• Exfiltrate your users' data (emails, passwords, PII)
• Pivot to other services on the same network

If you run WordPress: Check RIGHT NOW whether any of the files listed in this dossier exist in your installation. If they do, you've been compromised and need immediate incident response — not just file deletion, but full forensic investigation of what was accessed.

This is not the first time AS8075 has appeared in our investigations:

• 501 known threat IPs from AS8075 in our honeypot threat intelligence database
• 99 Azure IPs with threat_score ≥ 70 actively attacking SSH honeypot
• 3 IPs confirmed planting SSH backdoors (documented in earlier investigations)
• Outlaw botnet has been observed using compromised Azure instances as infrastructure nodes
• TI-2026-025J ("The Victims") documented Microsoft Azure as a major attack source

Microsoft Azure isn't a malicious actor — it's being abused. But the scale of abuse (269 IPs for a single botnet, 501 known threats total) raises serious questions about the effectiveness of Azure's automated abuse prevention. For comparison: Google Cloud had 54 IPs in the .env fleet and nobody stopped that either.

1. This is a post-compromise verification operation. The Azure fleet does not exploit — it checks. The filenames it probes are pre-planted backdoors from previous attacks. This represents Layer 3 in the criminal supply chain: access verification before resale.
2. The two-phase operation (CMS detect → shell check) proves coordination. A reconnaissance subset confirms WordPress before the main fleet engages. This is not blind scanning — it's targeted harvesting with an efficiency optimization layer.
3. 100% SSH overlap reveals a commodity botnet. Unlike the specialized Google .env fleet (Letter A, 0% overlap), this is a general-purpose attack tool running every module against every target. Volume over precision.
4. Empty user-agent is a deliberate choice, not laziness. At 41,384 requests with no UA, the operator either does not care about detection (because targets lack WAFs) or uses empty UA as a primitive authentication mechanism for the planted shells.
5. Microsoft Azure's abuse response is failing. 269 IPs, 23+ days, 41K+ requests, trivially detectable pattern (empty UA). Either Azure's automated detection cannot handle this volume, or abuse reports are being deprioritized for this activity class.
6. The attack economy has clear specialization layers. Letter A showed the credential thieves (specialists). Letter B shows the access verifiers (commodity). Different actors, different infrastructure, different operational philosophies — but all feeding the same underground market.

📍 You are here: Letter B — The WordPress Ghosts

• 🕸️ A: The .env Harvesters — Google Cloud credential scanning fleet
• 👻 B: The WordPress Ghosts — Azure empty-UA shell checker fleet (this article)
• 🔭 C: The Reconnaissance Industrial Complex — Palo Alto, LeakIX, DeepSeek
• ⚔️ D: The Multi-Vector Operators — 1,751 IPs in both SSH + HTTP
• ☁️ E: The Cloud Mercenaries — Cloud providers as attack platforms