TI-2026-095G — The Siege: The xmlrpc POST Assault That Follows the Roll Call

Classification: HIGH · Forensic threat intelligence · Web-threats vector · Series: Below the Noise Floor

The previous letter caught a fleet taking a roll call of a website — reading its user register with GET requests and locating xmlrpc.php, the battering ram. This letter catches what happened next. The same hands came back, and this time they did not read; they POSTed. For weeks, across every place a WordPress install might hide, from Russian and offshore hosting and a tight little cluster of consecutive IPs, they hammered xmlrpc.php with the one HTTP verb that turns that endpoint into a weapon. Two of the addresses are the very same ones that ran the roll call. This is the siege after the reconnaissance — and, rarely, we can prove they are one campaign.

1. GET Reads, POST Attacks

The whole distinction between this dossier and the last one lives in a single HTTP verb.

In TI-2026-095F the fleet sent GET requests: /?rest_route=/wp/v2/users/3, /wp-json/wp/v2/users?per_page=100, and — as discovery — GET /xmlrpc.php to find out whether the endpoint existed. GET reads. It asks a question and takes an answer. That was reconnaissance.

Here the fleet sends POST to xmlrpc.php. POST writes. And a POST body to xmlrpc.php is not a question — it is a payload. The XML-RPC protocol's system.multicall method lets an attacker pack hundreds of password guesses into a single request, collapsing a slow one-guess-per-request brute-force into a fast, amplified one; the same interface's pingback.ping enables reflected denial-of-service. A POST to xmlrpc.php is the attack the GET discovery was scouting for.

So when the web-threats engine records these nodes POSTing to xmlrpc.php — tagged, by its exploit dictionary, to the old XML-RPC RCE CVEs CVE-2005-1921 (42 IPs) and CVE-2007-1893 (63 IPs, 25,228 hits) — it is not seeing more enumeration. It is seeing weaponization. The roll call located the gate; the siege is battering it.

2. Every Place WordPress Might Hide

A single node's behaviour shows the method. Representative attacker 5.101.157.130 (AS198610, BeGet LLC, Russia) sent 72 POST requests, and it did not POST to one path — it POSTed to xmlrpc.php under an exhaustive set of install locations:

/xmlrpc.php        /wp/xmlrpc.php       /wordpress/xmlrpc.php   /blog/xmlrpc.php
/wpsite/xmlrpc.php /wp-site/xmlrpc.php  /cms/xmlrpc.php         /news/xmlrpc.php
/site/xmlrpc.php   /web/xmlrpc.php      /main/xmlrpc.php        /old/xmlrpc.php   /new/xmlrpc.php

— plus /wp-login.php and /wp-admin/, against library, mailserver, guacamole, shuffle-on.com and www. That path list is not random; it is a checklist of the sub-directories people install WordPress into — /blog, /cms, /wp, /old (the previous site), /new (the migration in progress). The operator does not know where the target's WordPress lives, so it tries every plausible mount and POSTs its payload at each. Wherever an xmlrpc.php answers, the amplified brute-force begins.

The engine already recognises the coordination: it clusters 5.101.157.130 as a member of a "Shared-Exploit Cluster (8 IPs)" — a group of addresses running the same exploit path-set against the same estate.

3. The Infrastructure — Coordinated, Persistent, Offshore

Two things about the fleet mark it as a deliberate, sustained operation rather than a disposable burst.

It persists. Where the roll call of 095F was a one-day swarm, these xmlrpc POSTs recur across weeks — first-seen in early June, last-seen in mid-to-late July 2026. The same addresses come back, day after day, POSTing at the same hosts. That is a campaign with a duration, not a drive-by.

It clusters. The CVE-2007-1893 roster contains a giveaway: 62.164.177.222, 62.164.177.223, and 62.164.177.224 — three consecutive addresses in one /24, all POSTing xmlrpc.php at mailserver and portainer over the same weeks. Adjacent rented IPs acting in concert are the fingerprint of a single operator who provisioned a small block and pointed it at one target set. Around that cluster sit a Russian anchor (BeGet), a spread of commodity and offshore hosting, and a couple of mainstream-cloud nodes — the same offshore-weighted, abuse-resistant hosting posture the roll-call fleet chose, and for the same reason: a weeks-long POST campaign needs hosting that will not answer an abuse complaint.

Every node wears an ordinary desktop-browser user-agent, the same unremarkable disguise as 095F. Nothing here announces itself as an attack tool. It looks like browsers, POSTing to a file.

4. The Proof: One Hand, Two Phases

This is the finding that lifts the dossier from "another xmlrpc campaign" to something the honeypot rarely gets to show: the reconnaissance and the attack are provably the same operator.

Two source IPs appear in both campaigns. 146.19.78.227 and 157.22.126.251 are in the TI-2026-095F WordPress user-enumeration recon (CVE-2017-5487) and in this xmlrpc POST assault (CVE-2005-1921). Several more (5.101.157.130, 90.156.142.60, 62.164.177.224, 159.89.172.177) appear in both xmlrpc CVEs at once. The overlap is not a coincidence of a busy IP; it is a documented link that fuses two separate observations into one campaign with a temporal order:

1. The roll call (095F, one day, GET) — read the user register, find the admin, locate xmlrpc.php.
2. The siege (095G, weeks, POST) — return and POST at xmlrpc.php across every mount, amplifying the brute-force the recon set up.

Most threat telemetry sees enumeration and attack as two unrelated noise events and dismisses both. Here the shared addresses let us watch the transition — the exact moment a fleet stops reading and starts writing — and attribute both phases to one hand. The roll call was never idle curiosity. It was the first move of this.

5. What It Hit

Nothing. library, mailserver, portainer, and guacamole run no WordPress and expose no xmlrpc.php; every POST returned 404. No password was guessed, no request amplified, no pingback reflected. These are attempts.

But the value was never a body count. It is the chain — proven, by shared IPs, from recon to weaponization — the mount-point map of where the operator expects WordPress to hide, and the coordination and persistence signatures (the /24 cluster, the weeks-long recurrence, the Shared-Exploit-Cluster tag). It is the closing act of the story the previous letter opened: the roll call was answered, and the answer was a siege.

6. The Counter-Narrative

Steelman: "xmlrpc.php POSTs are the most common WordPress attack on the internet — everybody sees them, from everywhere, all the time. It's 404s against hosts that aren't even WordPress. This is background noise with a story stapled on."

Each clause holds a little, and the finding survives:

• "Everybody sees it." True, and irrelevant to whether it matters. xmlrpc.php POST abuse is the commodity WordPress credential-attack vector precisely because system.multicall amplification works; its ubiquity is a reason to understand it, not to ignore it. And commodity technique does not mean commodity operator — the shared-IP link to a specific recon campaign makes this a tracked actor, not anonymous noise.
• "404s against non-WordPress hosts." Stated plainly (§5): attempts, no compromise. The claim is the campaign, its coordination, and — uniquely — the proven recon→attack chain, not a breach.
• "A story stapled on." The story is not stapled on; it is in the data. The same source IPs ran the enumeration and the POST assault. That overlap is the evidence, and the narrative (roll call → siege) is the literal temporal reading of it. Remove the story and you still have two campaigns sharing addresses; the story is just the honest name for what that overlap means.

What is not claimed: attribution to a named operator (diverse/offshore origin, browser UAs, a /24 recorded as a coordinated cluster rather than resolved to a named owner — an honest gap); that any credential was compromised (all 404); or that the two campaigns are the operator's only activity (they are the two phases observed against this estate).

Confidence: HIGH that a coordinated, weeks-long, offshore-weighted fleet POSTed xmlrpc.php across the LSN estate in June–July 2026, and that shared source IPs link it to the 095F user-enumeration recon as one operator's sequential phases; MEDIUM on named-operator identity and on the /24's ownership.

7. Defence Response

• Disable xmlrpc.php — the single highest-value step. It is the amplifier the whole siege depends on. Almost nothing legitimate needs it in 2026; removing or blocking it (all mount-point variants, not just /xmlrpc.php) deletes the system.multicall brute-force road and the pingback-DDoS vector in one move.
• Treat enumeration as an early warning of the attack. 095F showed the recon; 095G is what it foretold. If your telemetry catches a user-enumeration + xmlrpc-discovery pass, do not dismiss it — the same addresses may return to POST, and you now have their IPs before they do.
• Block the block, not just the IP. The 62.164.177.222/223/224 /24 sequence and the Shared-Exploit-Cluster tag are coordination signatures; range-blocking the /24 and the cluster is more durable than chasing single addresses, and the offshore anchors will not answer an abuse report anyway.
• Correlate across campaigns by source IP. The whole finding rests on noticing that two "separate" campaigns shared addresses. Build that correlation into triage: an IP that both enumerated and attacked is a tracked operator, not noise, and its full path history is the intelligence.

8. A Note on Method

Built entirely through the web-threats MCP layer, with no direct database access — the per-CVE actors endpoint (wt_cve_actors / GET /api/web-threats/cves/{cve}) for both xmlrpc CVE rosters and the cross-campaign IP overlap, and dossier_web_threats_intel for the per-node POST behaviour, mount-point set, ASN and Shared-Exploit-Cluster context. The recon→attack link was recovered by intersecting the actor rosters of CVE-2017-5487 (095F) and CVE-2005-1921/CVE-2007-1893 (this letter) — a cross-CVE correlation the per-CVE MCP endpoint makes routine.

9. Investigation Metadata

Cristian Lișneanu · shuffle-on.com · Threat Intelligence