Somebody Ran a List of Other People's Backdoors Against Our Site. Sixty-Five of the Ninety Paths Don't Exist in WordPress.
On October 26, two machines on Oracle Cloud asked our website for ninety specific files, one after another, about eleven minutes per run. They asked for exactly the same ninety paths, from two different addresses, thirteen hours apart.
Sixty-five of those ninety paths do not exist in WordPress. We checked against the authoritative list.
And we do not run WordPress.
What actually happened
Our edge canaries are decoy paths wired into the edge worker. When something requests a trap path, it gets a plausible-looking answer instead of a block, and we record the request. Over the two days from October 25, the canaries recorded 2,175 requests in total. That is the denominator for everything below.
Two addresses account for 194 of them:
168.138.170.54 ran 97 requests between 01:00:45 and 01:11:28 UTC. 129.221.188.111 ran 97 requests between 14:07:54 and 14:19:07 UTC. Both are AS31898, Oracle Corporation, geolocating to Austin, Texas. Both used the user agent Go-http-client/2.0. Both requested the same ninety distinct paths, and the two sets are identical — not similar, identical.
That is one tool with one target list, run twice from two rented hosts.
The part that makes it interesting
We took the ninety paths and checked each one against WordPress core version 6.9.5, using the checksum manifest WordPress itself publishes — 3,349 files, the authoritative answer to "does this file ship with WordPress."
Twenty-five of the ninety exist in core. Those are the ordinary ones: the login page, the admin index, the XML-RPC endpoint, several real directories. Requesting them tells you whether a site runs WordPress and roughly how it is laid out.
Sixty-five do not exist in core. Fifty-nine of those sixty-five are PHP files.
A file that does not ship with WordPress, sitting inside a WordPress admin directory, with a name designed to look like it belongs, is a backdoor. That is what these are. A few of them are worth reading closely:
wp-conflg.php — that is wp-config.php with two letters transposed. It is not a typo on the attacker's part; it is a filename chosen to survive a human skimming a directory listing.
/wp-admin/includes/media/images/modules/backup/8nx1.php — seven levels deep, inside a directory chain that does not exist in WordPress, ending in four random characters. Nobody guesses that path. You only ask for it if you already know it is there.
/wp-admin/includes/miniorange-malware-protection/index.php — named after a real WordPress security plugin, placed in a directory where no plugin ever lives. The backdoor wearing the malware scanner's name is a nice touch.
/wp-admin/wp-load.php and /wp-admin/wp-cron.php — both of those files are real, and both live at the site root, not inside wp-admin. A copy in the admin directory is a shell that bootstraps WordPress to borrow its database credentials.
It is reconnaissance, which is the first step and not a separate thing
Nothing in that list exploits anything. There is no payload, no injection, no CVE being tried. Every single request is a GET asking whether a file is present.
It would be easy to file that under "harmless" and move on. That would be a mistake, and it has a name: this is MITRE ATT&CK T1595.003, Active Scanning: Wordlist Scanning, which sits in the Reconnaissance tactic — the first phase of the chain, not an activity outside it. Recon is what an operator does immediately before the thing you actually care about. Treating it as noise is how you find out about phase two from somebody else.
Which means the operator was not trying to break in here. They were checking a list of backdoors against our address to see which ones answer. The ninety paths are a shell registry — the accumulated locations where somebody, at some point, planted something on somebody else's site.
We went looking for the rest of it after publishing this, and found the family: the same distinctive path names going back to June 3, across 59 addresses, mostly rented Azure rather than Oracle. Alongside it, from 26 Azure addresses in 17 countries, single requests to those same shell names carrying an empty parameter — asking a backdoor whether it answers. That is the step after the one described here, and it is in our records. The full breakdown is in the repository under research/hunts.
We have seen the other end of this. In July we wrote about an operator who left a Python file server facing the internet for twenty-two days, and inside it was an entire WordPress mass-compromise business: 1.4 million targets, twenty-seven weaponized CVEs, and a webshell kit. The list hitting us on Sunday is what the inventory stage of an operation like that looks like from the receiving end. We are not claiming it is the same operator and we have no evidence that it is; the shape is what matches, not the fingerprints.
Why we are confident, and where we are not
We are confident about the mechanical facts, because they are counts from our own instrument: two addresses, 194 requests, ninety distinct paths, identical sets, eleven minutes each, thirteen hours apart, out of 2,175 canary records. First-party, no third-party feed involved. Both addresses are in our indicator corpus at confidence 95 with source edge-honeypot, which means feed subscribers already have them.
We are confident that sixty-five paths are not WordPress, because the comparison is against WordPress's own published checksum manifest rather than our opinion.
We cannot tell you whose backdoors those are. A shell list does not say where it was collected. We cannot tell you whether the operator compromised those sites themselves, bought the list, or scraped it from somebody else's leaked tooling. We cannot tell you how many of the ninety are live somewhere else right now. And we would be guessing if we attached this to any named campaign, so we have not.
Call the whole thing 95% confident, which is our standing cap. Something here will be slightly off.
The cheap defense nobody runs
Here is the useful part, and it costs nothing.
A web application firewall tuned to exploit signatures sees this traffic as boring. There is no SQL injection, no traversal, no CVE pattern. Ninety GETs for PHP files is indistinguishable from a bad crawler unless you know what the files are.
But the discriminator is trivial once you say it out loud: somebody is asking for files that are not in your stack. You know what your application ships. Your package manifest, your container image, your core checksums — all of them already answer "should this path exist." A request for a file your own build does not contain is a much stronger signal than any payload pattern, it needs no threat intelligence subscription, and it does not go stale when the attacker changes payloads.
That is the same move we make everywhere: compare against what you already hold rather than buying a list of what to fear. We happened to catch this because our canaries answer decoys instead of blocking, so the operator kept going for all ninety paths and told us the whole list. A hard block at request one would have given us a single data point and nothing else.
What to do
If you run WordPress, go and look for files in wp-admin and wp-includes that are not in the core manifest. WordPress publishes checksums for every version. The comparison takes a minute and it is the single highest-value thing you can do to a site you inherited.
If you run anything else, the same principle applies to your own build. The question is not "is this request malicious." It is "does this file exist in what I shipped."
And if you want the two addresses, they are in our feed already, free, at confidence 95.
Sources
DugganUSA edge-honeypot canary records, 2026-10-25 to 2026-10-27, 2,175 requests scanned. First-party.
WordPress core checksum manifest, version 6.9.5, api.wordpress.org, 3,349 files, retrieved 2026-10-27.
ASN attribution: AS31898 Oracle Corporation.
Our earlier coverage of the other end of this operation shape: "A Hacker Left His Server Open for 22 Days. Inside: 1.4 Million WordPress Targets, 27 Weaponized CVEs, and a Webshell Kit Called WP-SHELLSTORM." (2026-07-19)
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
Comments