Mapping the Estate: The WordPress xmlrpc.php Amplification Hunt

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

Third in The Front Door series. Our classifier calls this traffic cms_detect — "CMS detection." That name is a polite fiction. The scanners do not care which content-management system you run. They care about one file, and what that file lets them do to everyone else.

Executive Summary

The cms_detect surface is 446 IPs and 2,741 requests (3 June – 5 July 2026). Sorted by path, almost all of it converges on a single target: xmlrpc.php, probed across a fan of WordPress sub-directory prefixes — /xmlrpc.php, /blog/xmlrpc.php, /news/xmlrpc.php, /old/xmlrpc.php, /wordpress/xmlrpc.php — plus /wp-login.php and /wp-admin/.

This is not fingerprinting. It is target acquisition. xmlrpc.php is the WordPress feature that lets an attacker (a) pack a thousand password guesses into one HTTP request via system.multicall, defeating rate limits, and (b) turn your site into a DDoS reflector via pingback.ping. Before you can abuse either, you need a list of who exposes the endpoint. The cms_detect scan is that list being built.

And it is being built by one operation wearing 28 different national flags.

The Tell: One Wordlist, Twenty-Eight Addresses

Two IPs, on completely unrelated networks, caught doing the identical thing:

Their top paths:

62.164.177.222 (HK-shell / DE)      90.156.142.60 (RU / Masterhost)
/xmlrpc.php                          /xmlrpc.php
/blog/xmlrpc.php                     /blog/xmlrpc.php
/news/xmlrpc.php                     /news/xmlrpc.php
/old/xmlrpc.php                      /old/xmlrpc.php
/site/xmlrpc.php                     /site/xmlrpc.php
/web/xmlrpc.php                      /cms/xmlrpc.php
/new/xmlrpc.php                      /main/xmlrpc.php
/wp-login.php                        /wordpress/xmlrpc.php

A Hong-Kong shell company and a Russian hosting provider do not independently arrive at the same ten paths in the same window. The platform grouped them — and 26 more — into one Shared-Exploit Cluster (28 IPs, 10 paths). The shared wordlist is the fingerprint; the four continents are a costume.

The Shells and the Cover

The cluster deliberately blends two kinds of infrastructure, and the difference matters for defence.

Purpose-built shells. AS215929 "datacampus, Data Campus Limited" is registered in Hong Kong (RIPE NCC, allocated 2023-11-29), announces just five IPv4 prefixes, and has no PeeringDB website. Its 62.164.177.0/24 geolocates to Germany. Registration in one jurisdiction, use in another, no visible legitimate service — the classic shell profile. It contributed three consecutive IPs (.222, .223, .224), all blacklisted.

Abused mainstream hosting. Alongside the shells sit real ISPs with real customers: Russia's Masterhost (AS25532) and Beget (AS198610), the Dominican Republic's national telecom (AS6400), a Brazilian host (AS264345), and — again — Microsoft Azure (AS8075). These are not shells; they are legitimate networks whose VMs are rented or whose customers are compromised.

The mix is not accidental. Shells give deniability; mainstream ISPs give reputation and complicate blocking. An operator who wants both structures the botnet exactly this way.

Why xmlrpc.php Is Worth a Four-Continent Hunt

The endpoint is a Swiss-army knife of abuse, which is why mapping it justifies real infrastructure:

• Brute-force amplification. system.multicall bundles hundreds to thousands of wp.getUsersBlogs login attempts into one POST. A firewall that allows "one login attempt per request" waves through a thousand. Sucuri documented this in 2015; it still works because the endpoint is on by default.
• Rate-limit and log evasion. Your security dashboard shows a handful of requests. Behind them, thousands of passwords were tested. The signal a defender watches (request count) is decoupled from the attack (attempt count).
• DDoS reflection. pingback.ping coerces your site into fetching a URL of the attacker's choosing — turning your bandwidth against a third-party victim. Every mapped xmlrpc.php is also a potential reflector.

So the recon is dual-use: the same scan builds both a brute-force target list and a DDoS reflector list. One survey, two weapons.

Read Between the Lines

Q: If it's all 404s against our site, why care? Because the 404s are ours; the campaign's value is in everyone else's 200s. We are a single tile in an internet-wide census. The scanner is indifferent to us specifically — it is enumerating the WordPress estate of the entire IPv4 space, and our logs are just the fraction of that survey that happened to sweep past. The threat is not to us; it is what the completed map enables against the millions of sites that do answer.

Q: Twenty-eight IPs across four continents — isn't that just the normal background of the internet? No, and the platform's clustering is the proof. Background noise does not share a ten-path wordlist down to the sub-directory prefixes (/old/, /new/, /site/) and fire it in the same window from Hong-Kong shells and Russian hosts simultaneously. Independent scanners diverge; these converge. Convergence on a bespoke path set is the definition of coordination.

Q: Why bother with sub-directory prefixes like /blog/ and /wordpress/? Because that is where WordPress actually lives on real sites — not at the web root but under /blog, /news, /old (the abandoned install nobody patched), /wordpress. The prefix fan is an inference about human deployment habits. The attacker is modelling how administrators actually install and forget WordPress, and hunting the forgotten copies first. It is the same "read the careless deploy" logic as the .env.bak hunt in 059A — applied to whole CMS installs.

The Alternative Interpretation

Could this be a legitimate WordPress-security census — WPScan's telemetry, an academic study of xmlrpc.php exposure, or a CDN measuring its customers' attack surface?

Parts of the long tail, perhaps. But the cluster core fails every test. Legitimate researchers publish reverse-DNS and honest User-Agents; these nodes rotate forged consumer-browser strings. Researchers request one path to measure exposure; these fire ten prefixes to enumerate it for use. And no census launches from a Hong-Kong shell with no website whose IPs geolocate to Germany while synchronised with a Russian host that scores 99/100 on threat and is banned by two independent layers. Measurement does not need shells. Exploitation does.

Verdict

cms_detect is the reconnaissance stage of a WordPress brute-force amplification and DDoS-reflection campaign, executed by a single 28-node operation that distributes itself across HK shell space, Russian and Brazilian hosting, Dominican telecom and Azure to evade origin-based blocking. Its true target is xmlrpc.php; its true product is a target-and-reflector map of the WordPress estate. Confidence: HIGH on the coordination and purpose; MEDIUM on whether the mainstream-ISP nodes are rented or compromised.

Defensive Response

• Kill the endpoint, not the IPs. Disable xmlrpc.php (or block system.multicall and pingback.ping) — it removes the amplifier and the reflector at once and neutralises the entire cluster regardless of origin.
• Key on the path signature. The 10-path xmlrpc set is ASN-agnostic and survives geographic rotation; CrowdSec's admin_hunt autoban already fires on it. That is the durable control.
• Do not count requests — count attempts. Request-rate limiting is blind to system.multicall; mitigation must be at the XML-RPC method layer.
• Blocklist the shells, behaviourally-mitigate the ISPs. AS215929-class shells can be banned outright; mainstream hosts (Masterhost, Azure, Beget) require signature-based controls to avoid collateral damage.

Sources

• LSN web-threats platform — cms_detect pattern export, IP dossiers for 62.164.177.222 and 90.156.142.60, ASN profile AS215929 (Traefik logs + CrowdSec + MikroTik).
• Sucuri Blog — Brute Force Amplification Attacks Against WordPress XMLRPC — https://blog.sucuri.net/2015/10/brute-force-amplification-attacks-against-wordpress-xmlrpc.html
• Cloudflare Blog — A Look at the New WordPress Brute Force Amplification Attack — https://blog.cloudflare.com/a-look-at-the-new-wordpress-brute-force-amplification-attack/
• WordPress Trac / project guidance on xmlrpc pingback and multicall abuse.

Investigation TI-2026-059C · The Front Door series · 446 IPs / 2,741 hits, one 28-node xmlrpc cluster across four continents · Cross-referenced with Sucuri and Cloudflare amplification research · Confidence: HIGH.