The Fourth Prefix: 193.32.162.0/24, and the Discipline of Not Over-Claiming

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

Confidence: HIGH that the prefix is DMZHOST operator space and that 193.32.162.84 is an active cluster node — direct RIPE registration + live honeypot capture. A deliberately narrower confidence is placed on the prefix's second host, and that narrowing is the point of this report.

The finding in one paragraph

The parent dossier inventoried the DMZHOST operator's known Romanian address space — the AS47890 prefixes 2.57.121.0/24, 2.57.122.0/24, 80.94.92.0/24, and 92.118.39.0/24. The operator has a fifth /24 that the inventory missed: 193.32.162.0/24. Its RIPE registration carries the exact institutional fingerprint that defines the cluster — netname DMZHOST, registrant TECHOFF SRV LIMITED, maintainer TECHOFF-MNT, abuse desk dmzhostabuse@gmail.com, origin AS47890 — and the prefix is on the Spamhaus DROP list under SBL636059. One host in it, 193.32.162.84, is a currently-active SSH brute-force node coordinating with the documented DMZHOST botnet by a shared command-automation fingerprint. But its neighbour, 193.32.162.86, is not a botnet node — it is a Tor exit relay that merely shares the registration. The prefix is the operator's; the two hosts are not the same story. Reporting them as one would be the easy, wrong move.

1. What the registry says — the institutional triad, intact

RIPE RDAP and whois for 193.32.162.0/24 return, verbatim, the same operator signature the parent dossier used to collapse three trading names into one operator:

That combination is not generic. The maintainer + registrant + abuse-desk triad is the durable, hard-to-forge fingerprint of the DMZHOST operator: TECHOFF-MNT maintains it, TECHOFF SRV LIMITED holds it, dmzhostabuse@gmail.com fronts abuse for it, and AS47890 announces it. The presence of ro-btel2-1-mnt on the route object is the same Bunea-TELECOM maintainer thread documented for AS47890 itself (see TI-2026-088C). This is the operator's own space, not a co-tenant renting a corner of it.

[DOCUMENTED] 193.32.162.0/24 is DMZHOST operator space by registration. It should be blocklisted as the same operator as the AS47890 prefixes already on Spamhaus ASN-DROP, not evaluated as an independent network.

2. What the honeypot saw — one live node, precisely characterised

193.32.162.84 is not a paper finding. The honeypot has been recording it hitting the estate since 2026-06-29, and it was still active on 2026-07-21, the day this report was compiled:

• 65 sessions, 12 of them reaching a shell, 108 commands executed, 0 malware downloads.
• Behaviour classifier: scan / brute-force, confidence 0.7.
• Credentials: root-only dictionary spray — 29 distinct passwords across the captured attempts, topped by 111111, !root, 123456, 123123, 1234, 12345. This is precisely the cheap, high-volume credential-guessing profile of the wider cluster.
• Post-auth commands: a single dominant fingerprint, command hash 668c13b46ed6fac0 — the innocuous-looking head -1 /proc/version kernel-recon probe — which the entity graph shows shared across a 28-host command-automation cluster.
• SSH client fingerprint: HASSH 2ec37a7cc8daf20b10e1ad6221061ca5, client banner SSH-2.0-Go.
• External reputation: AbuseIPDB 100/100 across 14,785 reports (last 2026-07-21); GreyNoise verdict MALICIOUS_SCANNER; ~50 AlienVault OTX pulses.

A word on the temporal signature, because it separates a live threat from a historical one. .84 did not fire once and vanish. It has been present continuously for roughly three weeks — first contact 2026-06-29, still hitting the estate on the day of writing — with 65 discrete sessions in that window. That cadence is the operational tempo of an always-on brute-force node, not a one-off scan. Of those 65 sessions, 12 "reached a shell," but that phrasing needs the same honesty applied throughout this series: the honeypot is configured to accept certain weak credentials, so a "successful" session means the guesser hit one of those allowed defaults and was admitted to the sandbox — a measure of how indiscriminately it sprays root:<weak>, not evidence that it compromised anything real. Inside those admitted sessions, the 108 captured commands are overwhelmingly the same low-value reconnaissance — the head -1 /proc/version kernel probe and its neighbours — the behaviour of an automated loader checking what it landed on before deciding whether to proceed. Zero downloads were recorded: on the honeypot, .84 looked, fingerprinted, and did not stage anything further.

Note the toolkit nuance, because it matters for honesty: 193.32.162.84 carries the Go-scanner HASSH 2ec37a7c…, which is not the canonical cluster HASSH 16443846184eafde36765c9bab2f4397 cited in the parent dossier. The tie that places .84 inside the DMZHOST operation is therefore not "identical HASSH" — it is the shared command-automation hash 668c13b46ed6fac0 and the shared root-only wordlist, on top of the shared registration. Two independent signals, each weaker than a smoking gun, converging on the same operator whose name is already on the registration. That is how the tie is built, and it is worth stating exactly which brick carries the load. The external reputation corroborates from outside our own telemetry: AbuseIPDB's 14,785 reports at 100/100 confidence are 14,785 other networks independently reporting this address, and GreyNoise's MALICIOUS_SCANNER verdict is a separate sensor network reaching the same classification. When your honeypot, a global abuse-report aggregator, and an internet-wide scan-sensor all describe the same host the same way, the finding is not resting on one telescope.

[DOCUMENTED] 193.32.162.84 is an active DMZHOST brute-force node, coordinating with the documented cluster by shared command automation and wordlist.

3. The peers — who .84 actually coordinates with

The entity graph gives 193.32.162.84 186 relations across 9 relationship types. Stripped of the noise types (discussed in §7), the load-bearing edges are shares_commands (conf 0.75, cluster size 28) and curated shared_tooling (conf 0.75) to a roster of already-documented DMZHOST and adjacent hosts:

• DMZHOST / TECHOFF (AS48090, NL): 195.178.110.217, 195.178.110.227, 195.178.110.228, 195.178.110.232 (threat 100).
• UNMANAGED (AS47890, RO): 80.94.92.55, 80.94.92.179, 80.94.92.234, 92.118.39.14/.49/.50/.71/.77, 2.57.122.150/.168/.209 (threat 90–100).
• TechTies / HostSlick (AS197170) — adjacent but distinct operator: the 91.92.40.0/24 block (threat 41–100), which the parent dossier already separated out as a different operator sharing tenants and tooling, not the same owner.

The single highest-confidence behavioural edge is a coordinates_with / temporal_correlation link (0.75) to 210.186.155.30. The .84 node sits squarely inside the coordination fabric the parent dossier mapped — the fourth prefix is not a stray, it is wired into the operation.

The TechTies/HostSlick (AS197170) hosts in that peer roster deserve one careful sentence, because they are the trap in this data. .84 shares command automation with the 91.92.40.0/24 block and with the DMZHOST hosts — the same tooling reaches both. A careless reading would merge all of them into one operator. The parent dossier already refused that merge: AS197170 is a separate bulletproof operator (Seychelles-registered, its own Spamhaus listing) whose tenants happen to run the same commodity scanner kit. So the peer edges to 91.92.40.x corroborate that .84 runs the cluster's tooling, but they do not extend DMZHOST's ownership to AS197170. Shared tooling maps the toolkit's blast radius, not the operator's boundary — and holding that line is what keeps the fourth-prefix finding about DMZHOST and not about everyone who ever compiled the same Go scanner. The edge that actually pins .84 to this operator, and not to the toolkit at large, is the registration triad on the prefix it lives in.

4. The neighbour that isn't — why 193.32.162.86 is held apart

Here is where a lesser report would round up. 193.32.162.86 sits in the same /24, under the same registration, one address away from a confirmed scanner. The temptation is to list it as a second botnet node and move on. The evidence forbids it:

• Zero honeypot sessions. The host has never attacked the estate. commands_total = 0. honeypot_ip_identity returns empty — no fingerprints, no HASSH, no shared-command edge.
• It is a Tor exit relay. 193.32.162.86 is carried in the tor_exit_nodes / ipsum threat feeds (delisted 2026-07-21), runs OpenSSH 9.6p1 on Ubuntu, and AbuseIPDB scores it 71 with is_tor = true across only 54 reports — an order of magnitude below .84.
• Its only tie to .84 is co-location. The entity graph connects the two by exactly one edge: same_spamhaus_netblock, confidence 0.5. There is no shared tooling, no shared command hash, no coordination edge.

So .86 is the operator's registered space being used as — or sublet for — a Tor exit, not a brute-force node. That is a genuinely different behaviour under the same landlord, and the honest finding is to say so: the prefix is DMZHOST's (documented), .84 is an active node (documented), and .86 is same-operator-by-registration but behaviourally distinct and not a confirmed botnet node (inferred co-location only). Shared prefix is not shared behaviour — the same doctrine the parent dossier applied one level up ("shared public artifact ≠ shared operator"), applied here one level down.

5. Seven questions

Q1. If the operator's known prefixes were already blocklisted, why does a fifth one matter? Because blocklists chase prefixes and operators rotate them. The prefix is disposable; the TECHOFF-MNT maintainer and the Gmail abuse desk are not. A fifth prefix under the same maintainer proves the footprint is enumerated by anchors, not by prefix lists — and tells you where to look for the sixth.

Q2. Why register bulletproof space under a company with a real London address? Because a real address that answers no abuse mail is more durable than a fake one. 35 Firs Avenue, London N11 3NE is a filing convenience; dmzhostabuse@gmail.com is where accountability goes to be ignored. The registration is designed to look answerable.

Q3. Is a Gmail address really the abuse contact for a routed European network? Yes — and read that plainly. A free consumer mailbox as the RIPE abuse-c for production address space is not an oversight. It is the deliberate lowest-friction way to satisfy the registry's contact requirement while guaranteeing nothing arrives at anyone accountable.

Q4. Why is a confirmed brute-force scanner living next door to a Tor exit in the same /24? Two readings. The charitable one: mixed-use bulletproof space, tenants doing different things. The less charitable one: a Tor exit inside operator space is convenient cover — legitimate-looking anonymised traffic sharing a registration with the operation. This dossier does not claim the second reading. It notes that the operator is comfortable with both under one roof.

Q5. Why does .84 use a different HASSH from the rest of the cluster? Because HASSH tracks the client build, and builds drift — recompiled scanner, different Go version, different library. It is exactly why HASSH is corroborative, not dispositive. The command hash and wordlist, which track behaviour, held constant where the HASSH did not.

Q6. Could 193.32.162.84 be a compromised third-party box, not the operator's own tool? It could — brute-force scanners are often themselves hijacked hosts. But it sits on the operator's registered prefix, on the operator's ASN, sharing the operator's command automation. Whether the operator owns the metal or rents it to whoever runs the botnet, the operator is the constant. That is the whole bulletproof-hosting business model.

Q7. What breaks this attribution? If RIPE showed 193.32.162.0/24 under a different maintainer and org, the prefix claim collapses to coincidence. It does not — the triad is intact. If .84 shared nothing behavioural with the cluster, it would be just another scanner on operator space. It shares the command hash with 27 documented peers. Both legs hold.

6. The counter-narrative, steelmanned — then defeated

Steelman: "You have one /24 that geolocates to Romania, announced by a commodity-adjacent ASN, with a UK shell registrant and a Gmail contact — none of that is unusual for cheap European hosting. One host on it runs a scanner; scanners live on cheap hosting everywhere. The other host is a Tor exit, which is legitimate infrastructure. You are assembling a conspiracy out of a discount VPS range."

Defeat: The argument fails at the maintainer. Cheap hosting does not share a bespoke RIPE maintainer (TECHOFF-MNT), a single registrant (TECHOFF SRV LIMITED), and one Gmail abuse desk (dmzhostabuse@gmail.com) with four other prefixes that are independently on Spamhaus ASN-DROP and independently named by Team Cymru's "Jingle Shells" research. And the scanner on it is not a lone box — it shares command hash 668c13b46ed6fac0 with a 28-host automation cluster of already-documented DMZHOST nodes. The Tor exit is conceded outright: this report does not claim it. The conspiracy is not assembled; four of the five bricks were already load-bearing in the parent dossier, and this prefix is the fifth brick in the same wall.

7. Read between the lines

The graph handed us 186 relations for .84. Most of them are noise: shared_rdap_org to a dozen other TECHOFF IPs (a registrant is not a co-conspirator), and same_spamhaus_netblock — the very edge that would have let us wrongly promote .86. The attribution in this report deliberately rests on the two signals that survive scrutiny (registration triad, command automation) and discards the fifteen that don't. That discipline is not caution for its own sake. It is what separates a fifth confirmed prefix from a hundred false positives — and it is why .86, the easy win, is the one host in this report we refuse to claim.

8. What if

What if you tracked the operator by TECHOFF-MNT and dmzhostabuse@gmail.com instead of by prefix? You would already have 193.32.162.0/24 before it appeared on any blocklist, and you would catch the sixth prefix the day it is registered — not the day it starts spraying root:123456. The lesson of the fourth prefix is that the operator's identity is in the registry metadata, not in the addresses, and the addresses are the part they are happy to burn. It reframes the whole detection posture: prefix blocklists are a lagging indicator, updated after damage is reported; a maintainer watch is a leading one, tripping at registration. The operator has optimised against the former — rotating /24s is cheap and expected — but cannot cheaply change the TECHOFF-MNT maintainer or the dmzhostabuse@gmail.com desk without dismantling the very continuity that lets them keep re-registering. Their durability and their traceability are the same property, seen from two sides. That is the quiet gift of the fourth prefix: it proves the anchor holds across address space the operator thought was disposable, and it hands the defender the one pivot the operator cannot afford to burn.

9. Documented vs inferred — the honest ledger

10. Infrastructure & IOCs

Prefix     193.32.162.0/24   netname DMZHOST | org TECHOFF SRV LIMITED (ORG-TSL73-RIPE)
                             mnt-by TECHOFF-MNT | abuse dmzhostabuse@gmail.com | origin AS47890
                             Spamhaus DROP SBL636059

193.32.162.84   ACTIVE SCANNER   AS47890 (RO) | AbuseIPDB 100 (14,785 reports) | GreyNoise MALICIOUS_SCANNER
                                 HASSH 2ec37a7cc8daf20b10e1ad6221061ca5 (SSH-2.0-Go)
                                 command_hash 668c13b46ed6fac0 (shared, 28-host cluster)
                                 root-only brute force: 111111, !root, 123456, 123123, 1234, 12345
                                 first_seen 2026-06-29 | last_seen 2026-07-21 (active)

193.32.162.86   TOR EXIT (NOT a botnet node)   AS47890 (RO) | AbuseIPDB 71 (is_tor=true, 54 reports)
                                 0 honeypot sessions | OpenSSH 9.6p1 / Ubuntu | tor_exit_nodes/ipsum feeds
                                 only tie to .84: same_spamhaus_netblock (conf 0.5)

Operator anchors (durable):  mnt-by TECHOFF-MNT | abuse dmzhostabuse@gmail.com | route mnt ro-btel2-1-mnt
Coordination fingerprint:    command_hash 668c13b46ed6fac0

Defensive action: blocklist 193.32.162.0/24 as DMZHOST operator space (same as the AS47890 prefixes). Track the operator by TECHOFF-MNT and dmzhostabuse@gmail.com, not by prefix. Do not treat 193.32.162.86 as a brute-force source; treat it as a Tor exit and apply your normal Tor policy.

11. Sources

RIPE NCC RDAP / whois (inetnum, route, org, maintainer objects for 193.32.162.0/24 and AS47890); Spamhaus DROP (SBL636059) and ASN-DROP (AS47890); LSN honeypot session and command capture for 193.32.162.84; LSN entity-resolution graph (relation-type audit for both hosts); AbuseIPDB, GreyNoise, and AlienVault OTX reputation. All claims reproducible from public RIR data and the SOC intelligence API. TLP:WHITE.