TI-2026-095F — The Roll Call: Harvesting the WordPress Register Before the Siege

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

Before an army lays siege it takes a roll call of the defenders: who is inside, who commands, where the gate is. This campaign does the same to a website. Forty-one hosts, most of them arriving in a single day, converge on one address and — behaving like ordinary browsers — ask it, politely, for its list of usernames, which one is the administrator, and where the login door and its battering-ram are. They are not attacking yet. They are reading the register. This is the reconnaissance that precedes a credential attack, and it hides not behind a spoofed crawler or a dead CVE, but behind looking exactly like a visitor.

1. A Third Way to Hide

The earlier letters in this series hid by rarity, by age, and by a spoofed benign-crawler identity. This one hides by being unremarkable. Every node presents an ordinary desktop-browser user-agent — Windows NT 10.0; Chrome — the single most common string on the internet. There is no exotic scanner banner to alert on, no forged Wayback bot to unmask. Just a browser, asking a website some questions.

And it hides a second way, behind the HTTP 200 mask. The target sits behind Authelia forward-auth, which answers every unauthenticated request with a 200 and a login page instead of the 404 an unprotected host would return. To a defender reasoning on raw status codes, the whole campaign reads as a wall of successful 200s — benign traffic, nothing to see. The intent only re-appears when the 200 is un-masked: the web-threats pipeline decodes the ?rd= redirect parameter and recovers the real target the visitor was reaching for — /wordpress/xmlrpc.php, /?author=3&feed=rss2. Behind the browser costume and the 200 curtain, a roll call is underway.

Below the noise floor once more — this time beneath ordinary browser traffic and a proxy's polite 200.

2. The Kit — Reading the Register

Pull any node's full request set and it is not a single probe but a complete WordPress reconnaissance kit, run in three movements.

Movement one: the user register. The fleet enumerates who exists on the site and who runs it:

/?rest_route=/wp/v2/users/3&_fields=id,slug        # user #3 → its login slug
/?rest_route=/wp/v2/users/6&_fields=id,slug        # walk the IDs
/wp-json/wp/v2/users?per_page=100                  # the whole roster in one call
/wp-json/wp/v2/users?slug=admin&_fields=id,slug    # is there an 'admin'?
/wp-json/wp/v2/users/9?_fields=id,slug,roles       # …and what ROLE does it hold?
/?author=3&feed=rss2                               # classic author-slug leak (pre-REST)
/wp-json/wp/v2/search?search=a&_embed=author       # authors via the search embed

This is WordPress's oldest and most reliable information leak: the REST API and the author feeds hand out real usernames, IDs, and — via _fields=…,roles — which account is the administrator, to anyone who asks, unauthenticated. That is CVE-2017-5487, the enumeration itself. The output is a target list: not "some WordPress site," but "the admin is janedoe, and here are the other nine editors."

Movement two: the battering ram. The fleet then hunts for xmlrpc.php across every place it might live:

/xmlrpc.php   /blog/xmlrpc.php   /wordpress/xmlrpc.php   /wp/xmlrpc.php   /wp-includes/xmlrpc.php

xmlrpc.php is not sought for information — it is sought as a weapon. Its system.multicall method lets an attacker pack hundreds of password guesses into a single HTTP request, turning a slow one-guess-per-request brute-force into a fast, amplified one; the same endpoint enables pingback-based DDoS. Finding it is finding the fastest road from "we know the admin username" to "we have the admin password."

Movement three: the gate. Finally it confirms the login surface: /wp-login.php, /wp-login.php?action=lostpassword, /wp-admin.

Read the three movements together and the intent is unambiguous. Know who to attack (the register), find the fastest way to attack them (xmlrpc), confirm where (wp-login). It is the complete preparation of a credential attack — everything except the passwords, which come next, in a phase this dossier does not cover because it had not yet begun.

3. The Fleet — Diverse, Offshore, Bulletproof-Anchored

Here the campaign breaks sharply from the two before it. The Struts2 fleet was 100% DigitalOcean; the secret-harvest fleet was 100% Google Cloud. This one is a diverse grab-bag — 41 IPs scattered across unrelated networks: commodity VPS in the US and EU, APNIC space in Asia, and — the verified, telling anchor — offshore, bulletproof-adjacent hosting.

The heaviest node, 78.142.18.172, resolves to AS213438, ColocaTel Inc., Seychelles-registered (RIPE-delegated, Netherlands-geolocated), carrying a threat score of 96 and flagged bulletproof-adjacent in the entity graph. That is a deliberate origin. Offshore, low-accountability hosting is chosen precisely because abuse complaints to it tend to go unanswered — it is the classic launch pad for reconnaissance and credential campaigns that expect to run undisturbed. Where the cloud fleets of the other letters traded attributability for elastic scale and clean IP reputation, this operator traded reputation for durability: a Seychelles host is harder to take down than an EC2 instance.

The diversity itself is a choice too. A single-provider fleet is one abuse report from termination; a swarm spread across a dozen unrelated hosters has no single desk to notify. What the cloud fleets gained in convenience, this one gives up for resilience.

4. A Swarm, Not a Partition

The other structural break is in the shape of the assault. The Struts2 and secret-harvest fleets used the one-node-per-host partition — one rented box per target subdomain, spreading across the estate. This fleet does the opposite: it concentrates. Most of the 41 IPs pile onto a single host — lsn-storage.shuffle-on.com — mostly within one day, 2026-06-23, from roughly 04:57 to 22:56.

That is a swarm: many nodes, one target, one window. And it makes sense for the objective. The one-per-host partition is for sweeping — checking every door in an estate for the same weakness. A swarm is for working a single door hard — many hands enumerating one site's register in parallel, from many IPs so no single one trips a rate limit. Partition is breadth; swarm is depth. The tradecraft fits the mission: to read one site's roll call quickly and quietly, you send a crowd that each asks a few questions and blends into the day's traffic.

5. The Register That Wasn't There

There is an irony at the centre of this. lsn-storage.shuffle-on.com runs no WordPress. It is a storage application; it has no wp-json, no author feeds, no xmlrpc.php, and no user register to read. The swarm came for a roll call that does not exist, and left with nothing — 401s and 404s behind the Authelia 200-mask, all the way down.

This is not a failure of the analysis; it is a feature of the campaign. The fleet does not know or care which of its targets run WordPress. It runs the same recon kit blind against every reachable host on the internet, cheaply, and harvests from whichever fraction actually answer with a user list. Against LSN it drew a blank. But the kit it revealed by running it is the intelligence: a precise, current template of exactly how a WordPress site is profiled before it is attacked, plus a standing list of 41 reconnaissance nodes to block. The swarm handed us its playbook by running it against the wrong door.

6. The Counter-Narrative

Steelman: "This is the most ignorable traffic on the web. WordPress user enumeration and /xmlrpc.php probes hit every site on earth, constantly, from everywhere. It's a browser getting 401s against a host that isn't even WordPress. There is no attack and no story."

Each clause holds a little, and the finding survives:

• "It's ignorable / everyone sees it." Ubiquity is not harmlessness. User enumeration is the step that converts a two-unknown problem (username and password) into a one-unknown problem (just the password) — and xmlrpc discovery is what makes guessing that one unknown fast. A commodity technique that reliably feeds credential compromise is worth naming precisely because it is dismissed.
• "It's just a browser getting 401s." The browser UA is the disguise, and the 401s are behind an Authelia 200-mask that a naive log-reader would file as benign success. The intent is only visible once the 200 is un-masked — which is the whole point of the web-threats pipeline, and the reason this isn't invisible.
• "Not even WordPress / no attack." Stated plainly (§5): misdirected, attempts only, nothing harvested. The claim is the coordinated recon campaign and its captured kit — the pre-siege roll call — not a breach. A reconnaissance that fails against one target is still reconnaissance, and its methodology is intelligence.

What is not claimed: attribution to a named operator (diverse/offshore origin, browser UA — the anchor is a bulletproof-adjacent hoster, not a person); that any username was actually harvested here (the host runs no WordPress); or that the campaign is only enumeration (it is the recon phase; the credential attack it prepares for is a separate, later act not observed in this window).

Confidence: HIGH that a 41-node diverse/offshore swarm ran a coordinated WordPress user-enumeration + xmlrpc-discovery reconnaissance against one LSN host in June 2026, disguised as browser traffic and behind the Authelia 200-mask; MEDIUM on operator identity and on downstream (the follow-on credential attack).

7. Defence Response

• Break the enumeration chain. Disable WordPress REST user enumeration (restrict /wp-json/wp/v2/users to authenticated requests, block ?author= redirects, strip the X-Redirect-By/author-feed leak). If they can't read the register, the credential attack starts from zero-knowledge again.
• Disable xmlrpc.php. Almost nothing legitimate needs it anymore, and it is the brute-force amplifier and pingback-DDoS vector the swarm was hunting for. Removing it deletes the fastest road from a known username to a cracked password.
• Un-mask the 200 before you trust it. Behind an auth proxy that returns 200 to everything, raw status codes lie. Decode the ?rd=/redirect target (as the web-threats pipeline does) so enumeration behind Authelia is scored on its real intent, not filed as benign success.
• Block the swarm; expect the offshore anchor to persist. The 41 IPs are a standing IOC set — but the ColocaTel/bulletproof anchor will not respond to abuse reports. Rely on local blocking (MikroTik/CrowdSec) and on breaking the technique, not on takedown. When you cannot remove the source, remove the capability.

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 the 41-node roster, and dossier_web_threats_intel for each node's full path kit, ASN classification, Authelia-un-masked intent and campaign context. As with the other web letters, the honeypot and entity-graph CVE tools see none of this: it is a pure web (L7) reconnaissance campaign.

9. Investigation Metadata

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