The Adjacent Operator: Why AS197170 Is Not DMZHOST

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

Confidence: HIGH that AS197170 is a separate operator from DMZHOST — direct registration evidence plus the absence of any same-operator edge in the entity graph. This is a methodology letter: it is about a boundary the evidence draws and this series refuses to cross.

The finding in one paragraph

The easiest mistake in bulletproof-hosting attribution is the merge — sweeping every network that shares a tool, a wordlist, or a tenant into one giant "operator." This letter is a deliberate act of not merging. AS197170 (TechTies Inc., Seychelles; brand HostSlick) shares a great deal with DMZHOST: the same Go-scanner HASSH fingerprints, the same head -1 /proc/version command hash, the same weak-credential clusters, and at least one of the same tenants running across both. A careless graph would fuse them. But AS197170 is a freshly-minted Seychelles registration (created May 2026), maintained by techties-mnt — a maintainer with zero overlap with DMZHOST's TECHOFF-MNT/ro-btel2-1-mnt — and, most decisively, the entity-resolution engine that unified UNMANAGED LTD, TECHOFF SRV LIMITED and DMZHOST under one dmzhostabuse@gmail.com contact finds no equivalent same-operator edge between TechTies and DMZHOST at all. The shared tooling is real; it is just not evidence of shared ownership. AS197170 is a competing bulletproof host that happens to rent to some of the same customers. Keeping it separate is not timidity — it is the discipline that keeps this whole series from manufacturing a false conglomerate.

1. The doctrine, stated plainly

Bulletproof-hosting attribution has three layers that are constantly confused: the host (who owns the network), the tenant (who rents space on it), and the toolkit (what software the tenant runs). Shared toolkit is the weakest of all signals for shared host, because toolkits are commodities — a Go SSH scanner, a zmap/zgrab2 fingerprint, a weak-password list, and a kernel-recon one-liner are used by hundreds of unrelated actors. When two networks share a toolkit, the single most likely explanation is that they host the same kind of customer, not that they are the same owner.

This series has already applied that doctrine twice: 088D separated a tenant ("The Appraiser") from its DMZHOST host, and 088E refused to read a shared 486-host scanner fingerprint as one operator. This letter applies it to a peer host: AS197170 shares DMZHOST's tenants and tools, and is still a different operator. The test for "same operator" is not "do they share a tool" — it is "do they share control": the same registrant, the same maintainer credential, the same abuse infrastructure, the same SSH keys. On every one of those, AS197170 and DMZHOST diverge.

2. What AS197170 is — a separate registration

The registration record places AS197170 in a different world from DMZHOST's UK shells:

Two facts here are load-bearing. First, the maintainer — the credential that, in 088F, proved AS47890 and AS48090 are one operator because one TECHOFF-MNT signs both — is entirely different for AS197170. techties-mnt shares nothing with TECHOFF-MNT or ro-btel2-1-mnt. The single strongest same-operator signal in this series is absent between AS197170 and DMZHOST. Second, AS197170 is a fresh registration (May 2026), a Seychelles shell, not one of the aged UK companies. Different jurisdiction, different vintage, different maintainer.

[DOCUMENTED] AS197170 (TechTies Inc., Seychelles, techties-mnt, created May 2026) is a separate registration from DMZHOST's UK shells; it shares no maintainer with them.

3. The negative evidence — the edge that does not exist

The most rigorous part of this finding is not what the graph shows but what it refuses to show. The LSN entity-resolution engine is the same machine that collapsed three DMZHOST trading names into one operator — it did so by finding a shared abuse desk (dmzhostabuse@gmail.com), a shared maintainer, and a dual-origin prefix, and emitting a same_entity_org linkage. Run the same engine on AS197170 and enumerate its organisation-level edges, and the result is stark: there is exactly one org-type relationship — TechTies Inc. operating itself — and no same_entity_org edge to DMZHOST, UNMANAGED LTD, or TECHOFF SRV LIMITED anywhere.

That absence is not a gap in the data; it is a positive result. The engine that does link the DMZHOST shells to each other, when pointed at TechTies, declines to link it — despite every shared tool it can see. The graph crosses freely into "same renter's toolkit" and stops at the border of "same infrastructure operator." Two of the highest-confidence same-operator signals it tracks — shared SSH keys and shared authorized-keys (confidence 0.90) — never appear between the 91.92.40.0/24 nodes and any DMZHOST IP. The line the machine draws is exactly the line this dossier draws.

Negative evidence of this kind is often dismissed as weak — "absence of evidence isn't evidence of absence" — but that objection misreads what is being claimed. This is not the absence of a search; it is the presence of a result from a search that demonstrably works. The entity-resolution engine is not silent on same-operator links in general: it emitted one for AS47890↔AS48090 (via TECHOFF-MNT and the dual-origin prefix), it emitted the three-name DMZHOST unification (via dmzhostabuse@gmail.com), and it emits shared-tooling and shared-credential edges for AS197170 readily. So the engine is fully capable of linking AS197170 to things — it links it to its tenants' tools all day. What it will not emit is the ownership link to DMZHOST. A detector that fires correctly on positives and stays dark only here is giving a real negative, not a blind spot. The absence is load-bearing precisely because the same detector's positives are everywhere around it.

[DOCUMENTED] No same_entity_org edge, and no shared-SSH-key edge, exists between AS197170 and DMZHOST in the entity graph — the same engine that unified the DMZHOST shells finds no comparable link.

4. The overlap, honestly stated — shared tenants, shared tools

None of this denies the overlap; it reclassifies it. AS197170's 91.92.40.0/24 genuinely carries DMZHOST's toolkit:

• HASSH fingerprints: both 2ec37a7cc8daf20b10e1ad6221061ca5 (go_scanner) and 16443846184eafde36765c9bab2f4397 (Go_SSH) appear on 91.92.40.x hosts (.7, .237, and a dozen others).
• Command hash 668c13b46ed6fac0 — the head -1 /proc/version recon probe — runs on 91.92.40.7 and .237, in the same 28-host automation cluster as the DMZHOST nodes.
• Weak-credential clusters (guest:12345, postgres:1234, ubuntu:111111) tie 91.92.40.x to a wider set of bulletproof-hosted IPs, including the 87.251.64.0/24 (ISAEV) space.
• Curated shared_tooling edges (confidence 0.75) connect 91.92.40.7/.237 to DMZHOST IPs across 2.57.122.x, 195.178.110.x, 80.94.92.x, 92.118.39.x, and 193.32.162.84.

Read correctly, this is the signature of a shared tenant, not a shared owner. The Appraiser (088D) already demonstrated the mechanism: a single campaign renting compute from multiple rival bulletproof hosts to diversify against takedown. The same customer, deploying the same commodity kit, on both DMZHOST and TechTies, produces exactly this overlap — and produces it without the two hosts sharing a maintainer, an abuse desk, or an SSH key. The toolkit is the tenant's; the networks are two different landlords'.

The credential-cluster edges make the shared-tenant reading concrete rather than abstract. The guest:12345 / postgres:1234 / support:1234567 clusters that link 91.92.40.7 do not stop at DMZHOST — they reach 87.251.64.0/24 (the ISAEV space, itself a separate shell host noted elsewhere in the corpus for sharing a channel with the TECHOFF orbit), 91.92.240.199, and 216.48.191.18. In other words, the same commodity credential list appears on TechTies, on DMZHOST, and on a third unrelated bulletproof host. If shared credentials proved shared ownership, these three independent operators would collapse into one — which is absurd, and which is exactly why the entity engine treats a shared wordlist as a 0.85-confidence tooling edge, not a same-operator edge. The wordlist is a commodity passed between customers; it tags the tenant population of the bulletproof market, not the identity of any one landlord. A signal that would "prove" three known-separate hosts are one operator is, by construction, not a signal of operator identity at all.

5. Seven questions

Q1. If they share tools, tenants, and a Spamhaus category, why aren't they one operator? Because "same operator" means shared control, and control shows up as shared registrant, maintainer, abuse desk, or keys — none of which they share. Everything they do share is downstream of hosting the same customers. Co-tenancy is not co-ownership.

Q2. Isn't the shared HASSH strong evidence? It is strong evidence of a shared tool, which is the weakest link for shared ownership. HASSH tracks the SSH client build; a popular scanner produces one HASSH across hundreds of unrelated deployers. 088E already showed one such HASSH spanning 486 hosts. A shared client build is not a shared owner.

Q3. What single fact most cleanly separates them? The maintainer. TECHOFF-MNT proved DMZHOST's two ASNs are one operator; techties-mnt is a completely different credential with no overlap. The exact signal that merges AS47890 and AS48090 separates AS197170 from both.

Q4. Could TechTies be a DMZHOST front, like UNMANAGED LTD? The fronts in this cluster are unified by shared maintainer, shared abuse desk, and dual-origin routing. TechTies has none of those ties to DMZHOST. A front leaves the seams the entity engine detects; TechTies leaves no such seam. It is a competitor, not a costume.

Q5. Why does 91.92.40.0/24 also have a dual-origin route object? It does — with origin AS209630 alongside AS197170 — which is TechTies' own internal complexity, structurally its own story, and specifically not a link to DMZHOST's AS47890/AS48090 pattern. Noting it here is itself an act of discipline: a superficially similar dual-origin pattern is not the same operator's pattern.

Q6. Does keeping them separate weaken the case against DMZHOST? The opposite. An attribution that over-merges is brittle — one wrongly-absorbed network discredits the whole. By excluding AS197170 on principled grounds, the DMZHOST attribution becomes more defensible, not less: it claims only what the control evidence supports.

Q7. What would make them the same operator? A shared maintainer, a shared abuse contact, a same_entity_org edge, or a shared SSH key between the networks. None exists today. If one appeared, this verdict would change — that is what calibrated confidence means.

6. The counter-narrative, steelmanned — then defeated

Steelman: "You have two bulletproof hosts on ASN-DROP, sharing scanner fingerprints, a command hash, credential clusters, and tenants, one even echoing the other's dual-origin routing trick. Occam says it's one operator running two ASNs, exactly like AS47890/AS48090. You're inventing a distinction to avoid the obvious merge."

Defeat: Occam favours the hypothesis that fits the control evidence, and "one operator" fails on all of it: no shared maintainer (the very signal that unified AS47890/AS48090), no shared abuse desk, no same_entity_org edge, no shared SSH keys, a different jurisdiction (Seychelles vs GB), and a different vintage (weeks old vs years). The shared items — scanner HASSH, command hash, credential lists — are precisely the commodity signals this series has repeatedly shown to be tenant-level, not owner-level. To merge on those while ignoring the total absence of every control signal is not parsimony; it is the exact error — "shared tooling ⇒ shared owner" — that manufactures phantom mega-operators. The disciplined reading is the harder one: two competing landlords, one shared class of tenant.

7. Read between the lines

The value of this letter is what it protects. Every prior letter in the series makes an affirmative claim about DMZHOST; this one makes a boundary claim, and boundaries are what make the affirmative claims trustworthy. An intelligence product that merges everything adjacent is easy to write and impossible to defend — the first analyst to find one wrongly-absorbed network unravels it. By drawing the line at AS197170 on the same evidentiary rules used to draw the DMZHOST cluster together, the series demonstrates that its merges are principled, not greedy: it fuses AS47890 and AS48090 because a maintainer proves it, and it holds AS197170 apart because no maintainer, abuse desk, or key connects it. Same rules, opposite results — that symmetry is the credibility. The bulletproof underground is a market with many landlords and shared tenants, not a single conspiracy, and mapping it honestly means being as rigorous about the lines you won't cross as the ones you will.

There is a deeper reason the market structure matters for attribution. A model that merges hosts on shared tooling scales catastrophically: every commodity tool is shared by dozens of networks, so a merge-on-tooling rule does not stop at "DMZHOST + TechTies" — it chains onward to 87.251.64.0/24, to 91.92.240.199, to 216.48.191.18, to every host that ever touched the same wordlist, until the "operator" is a meaningless blob spanning half the bulletproof economy. That blob is not an intelligence product; it is the failure of one. The corrective is structural: attribute hosts by their control fingerprints (registrant, maintainer, abuse desk, keys), attribute tenants by their behavioural fingerprints (scripts, credential clusters, C2 families), and never let a tenant-level signal promote two hosts into one. AS197170 is the test case that keeps the model honest — it is the network most likely to be wrongly absorbed, and refusing to absorb it is what proves the DMZHOST cluster was assembled by control evidence, not by lazy tooling overlap.

8. What if

What if takedown treated shared-toolkit clusters as one target? You would blocklist AS197170 as "part of DMZHOST," mis-scope the enforcement, and hand a wronged third party (or a defence lawyer) a clean way to discredit the entire attribution. Treating them as separate hosts with a shared tenant is both more accurate and more actionable: pressure each landlord on its own registration and maintainer, and pursue the shared tenant by its portable signatures across both. The map that separates the layers lets you act on all three — DMZHOST, TechTies, and the tenant between them — without any one error collapsing the others.

9. Documented vs inferred — the honest ledger

10. Infrastructure & IOCs

AS197170   TechTies Inc. (Seychelles, reg-nr 250236) | as-name TECHTIES-AS | mnt techties-mnt
           created 2026-05-29 | Spamhaus ASN-DROP | bulletproof | risk 85.3
           prefixes: 91.92.40.0/24, 91.92.42.0/24, 45.156.87.0/24, 45.153.34.0/24, 85.11.167.0/24, …
           brand: HostSlick (UNCONFIRMED at primary-source level)

SEPARATION from DMZHOST (control signals — none shared):
   maintainer   techties-mnt        != TECHOFF-MNT / ro-btel2-1-mnt
   registrant   TechTies Inc. (SC)  != UNMANAGED LTD / TECHOFF SRV LIMITED (GB)
   abuse desk   (own)               != dmzhostabuse@gmail.com
   entity graph NO same_entity_org edge | NO shared-SSH-key edge

OVERLAP (tenant/toolkit — shared, NOT ownership):
   HASSH 2ec37a7cc8daf20b10e1ad6221061ca5 · 16443846184eafde36765c9bab2f4397
   command_hash 668c13b46ed6fac0 (head -1 /proc/version, 28-host cluster)
   creds guest:12345 · postgres:1234 · ubuntu:111111  | shared_tooling edges to DMZHOST IPs

Defensive action: track AS197170 as its own bulletproof operator (its own maintainer techties-mnt, its own prefixes, its own ASN-DROP listing) — do not blocklist it as "part of DMZHOST." Attribute the shared tooling to the tenant that rides both hosts (see 088D), and pursue that tenant by its portable signatures across both networks.

11. Sources

RIPE NCC RDAP/whois (AS197170 aut-num + TechTies Inc. org object + techties-mnt maintainer; comparison to AS47890/AS48090 maintainers); LSN entity-resolution graph (organisation-edge enumeration for AS197170 — the same_entity_org and shared-SSH-key absence; shared_tooling/HASSH/command-hash/credential-cluster edges on 91.92.40.7/.237); Spamhaus ASN-DROP (AS197170). Cross-references: TI-2026-088 (the DMZHOST cluster), 088D (the shared tenant), 088F (the maintainer as the same-operator proof). TLP:WHITE.