The Tenant: What Actually Runs on the Bulletproof Floor

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

Confidence: HIGH that a documented loader campaign runs on the DMZHOST network and shares nodes with it; the tenant's identity is held at MEDIUM confidence, and the distinction between host and tenant is the entire point of this report.

The finding in one paragraph

Every previous letter in this series has been about the landlord — the operator who owns the bulletproof address space, the shells, the ASNs, the maintainer. This one is about a tenant. Sitting on DMZHOST's floor is a distinct, documented operation — cross-referenced in the corpus as TI-2026-083C, "The Appraiser" — a careful, profile-first SSH loader that fingerprints every machine it lands on (down to whether it has a GPU) before it commits a payload, and that probes for honeypots before it trusts a shell. Its infrastructure overlaps DMZHOST's: all five of The Appraiser's documented IPs sit inside DMZHOST's already-mapped prefixes, and one of them, 195.178.110.232, carries a live AdaptixC2 classification. But the same toolkit also runs from a rival bulletproof provider's network — and a landlord does not rent capacity from its competitor. The evidence points to a customer, not the host: DMZHOST is the high-confidence bulletproof floor; The Appraiser is a medium-confidence tenant operating on it. Keeping those two apart is not pedantry. It is the difference between attributing a crime to the building and attributing it to the occupant.

1. Why host ≠ tenant, and why it is easy to get wrong

A bulletproof host sells one thing: infrastructure that will not answer abuse complaints. Its customers are, by selection, people who need that — malware operators, credential-stuffing crews, C2 hosters. So a bulletproof network's address space is densely populated with malicious activity that the host does not itself perform. This creates a standing attribution trap: every malicious thing observed on the network looks, at first glance, like the host's own operation.

The parent dossier's own actor schema already encodes the fix. It separates hoster identity — UNMANAGED LTD, TECHOFF SRV LIMITED, named directors, Companies House records — held at high confidence, from operator identity — the crew actually running a given campaign — held at medium and often unnamed. The AS itself gives the game away: AS47890's RIR name is literally UNMANAGED-DEDICATED-SERVERS. The business model is leasing dedicated servers on which customers get root. A tenant running a botnet on a leased box does not make that botnet the landlord's. This report applies that discipline to one specific tenant.

2. The Appraiser — a loader that looks before it leaps

TI-2026-083C documents a compact but distinctive operation. Across 19 active IPs the honeypot logged 3,035 SSH attempts, 251 accepted logins, 2,102 commands, and zero downloads between 2026-05-21 and 2026-07-13. The zero-downloads figure is the first clue to its character: this is not a smash-and-grab loader. It is an appraiser.

On every successful root login, the operation runs one nearly-identical ~2KB profiling script that harvests, in a fixed order:

• OS / kernel / architecture — uname -s -v -n -m, with five fallback paths (/bin/uname, /usr/bin/uname, busybox uname, /etc/os-release, /proc/version) so it works on stripped or embedded systems.
• CPU — nproc, lscpu, /proc/cpuinfo, and /proc/device-tree/model (the last targets ARM SBCs and appliances).
• GPU presence — lspci | grep -i 'vga\|nvidia'. This is the tell. A credential-stuffing bot does not care about your graphics card. Something that checks for an NVIDIA GPU on every box it opens is triaging for compute value — mining, model theft, or resale of GPU capacity.
• Uptime and login history — uptime, last — to gauge whether the box is a stable, unattended target or a monitored workstation.

Then, before it will trust the shell enough to drop anything, it runs an anti-honeypot probe: it executes deliberately nonexistent commands (./xxxxxx, xxxxxx) to fingerprint the shell's error strings, and writes, chmods, and executes a small sentinel script to confirm the environment actually runs code rather than merely echoing success. Only a shell that passes gets a payload. The internal name the source dossier gives this doctrine is exact: "profile-first, drop-on-proof." It is the disciplined inverse of the loud, immediate-drop Mirai/Nexus-style loaders documented elsewhere in the corpus (083A/B) — a tenant that spends reconnaissance to avoid wasting payloads on honeypots and worthless boxes.

Read the profiler's shopping list as a whole and an intent falls out of it. It does not check what a spam operator checks (mail-sending reputation), or what a proxy operator checks (residential IP, clean geolocation). It checks compute: how many cores, which CPU model, whether there is an NVIDIA GPU, whether the box is stable and unattended. That is the appraisal of a compute hunter — an operation that monetises stolen processing power, whether by cryptomining, by reselling GPU capacity, by training or stealing machine-learning models, or by staging further attacks from a beefy anonymous host. The /proc/device-tree/model probe (which only returns anything on ARM single-board computers and appliances) shows it also inventories the cheap embedded end of the spectrum, the classic cryptomining-botnet substrate. The GPU grep is the headline, but the whole script is a valuation engine: it is deciding, in the first two seconds of every intrusion, what this machine is worth before spending a payload to take it. A loader that appraises before it drops is optimising for yield, and yield here is measured in FLOPs.

[DOCUMENTED] The Appraiser is a profile-first SSH loader that fingerprints OS/CPU/GPU and probes for honeypots before committing a payload; its fingerprint set is a compute-valuation profile (cores, CPU model, NVIDIA GPU, ARM SBCs), consistent with a compute-monetising operation.

3. The overlap — five shared nodes, one live C2

The Appraiser is not merely near DMZHOST; it runs on it. Cross-checking TI-2026-083C's five documented IPs against TI-2026-088's twenty-node infrastructure map, all five appear in both:

The shared anchor node, 195.178.110.232 (AS48090, DMZHOST/TECHOFF SRV LIMITED), is independently one of the nastier addresses in either investigation:

• Behavioural classification botnet / c2_infrastructure (confidence 0.9); ThreatFox family AdaptixC2; AbuseIPDB 100/100; DShield 24,779 attacks; 50 AlienVault OTX pulses; 15 VirusTotal-malicious detections.
• On our honeypot: 325 sessions, 38 accepted logins, 342 commands, 0 downloads, active 2026-07-02 → 2026-07-17; HASSH 2ec37a7cc8daf20b10e1ad6221061ca5, client SSH-2.0-Go.
• Its command log carries The Appraiser's profiler verbatim — uname -s -v -n -m, the /bin/uname/busybox uname fallbacks, the /etc/os-release and /proc/version checks, each at count 38, one per accepted session. This is not a family resemblance; it is the same script running on a DMZHOST node.
• Its credential attempts are root: against a weak-password list, and a shared-credential edge on dev:12345678 (cluster size 5) ties it to four external IPs (43.245.97.82, 185.141.24.44, 103.143.238.100, 86.139.23.230) at confidence 0.85 — the tenant's footprint reaching beyond DMZHOST space.

The corpus already carries an explicit edge for this: org:DMZHOST —[cross_reference]→ org:TI-2026-083C The Appraiser loader, annotated "[XCLUSTER] TI-2026-083C documents the server-profiling loader run FROM this DMZHOST network (AS47890+AS48090)." This is a pre-established, dossier-native link, not a fresh inference.

[DOCUMENTED] All five Appraiser IPs sit inside DMZHOST prefixes; 195.178.110.232 (AdaptixC2, DShield 24,779) runs the Appraiser profiler and is a DMZHOST node.

4. The load-bearing distinction — tenant, not landlord

If the overlap were the whole story, the lazy conclusion would be "DMZHOST runs The Appraiser." The evidence specifically resists that, and the piece that resists it is the same doctrine the parent series used to reject merging DMZHOST with TechTies/HostSlick:

The Appraiser's credential wordlist, Go-scanner HASSH, and command fingerprint also appear on 91.92.40.0/24 — a prefix announced by AS197170 (TechTies Inc. / HostSlick, Seychelles), a separate, competing bulletproof operator the parent dossier explicitly holds apart from DMZHOST.

A landlord has no reason to run its own botnet from a competitor's network. A tenant renting capacity from several bulletproof providers at once has every reason to — it is diversification against takedown. The Appraiser's toolkit spanning DMZHOST's ASNs and a rival's ASN is the signature of a customer shopping multiple hosts, not of either host operating the campaign. Three further facts point the same way:

• The parent dossier's hypothesis language is that DMZHOST is "knowingly hosting" the botnet — a complicity/negligence framing appropriate to an ISP, not a direct-operation framing.
• The host/operator confidence split is baked into the data: hoster identity high (legal records), operator identity medium and unnamed.
• Zero CVE weaponization across the cluster (established in 088E) fits a narrow, single-purpose tenant tool better than a full-service in-house operation.

Verdict: co-tenancy / customer-of-a-bulletproof-host, at MEDIUM-HIGH confidence. DMZHOST (UNMANAGED LTD / TECHOFF SRV LIMITED) is the documented, high-confidence landlord; The Appraiser is an unnamed, medium-confidence tenant whose footprint also touches a rival provider.

It is worth being honest about what "medium" means here, because the confidence is doing real work. The host attribution is high because it rests on legal records that do not move — Companies House filings, RIPE org objects, a maintainer credential. The tenant attribution is medium because it rests on behavioural overlap — shared scripts, shared credentials, shared C2 family — which is strong evidence of one campaign but weak evidence of which human. TI-2026-083C is itself a data-thin dossier (four actors, four findings, no timeline), and it names no operator. So this letter deliberately claims only what the evidence carries: that a coherent, GPU-hunting loader campaign runs on DMZHOST's floor and on at least one rival's, and that its relationship to DMZHOST is tenancy, not identity. Who the tenant is remains open — and saying so plainly is more useful than a confident guess that later has to be retracted.

5. Seven questions

Q1. If The Appraiser runs on DMZHOST's own nodes, how is it not DMZHOST? Because "runs on" is a hosting relationship, not an ownership one. 195.178.110.232 is a DMZHOST-hosted box; the Appraiser script is what a tenant deployed onto it. The whole bulletproof business is selling boxes to people who deploy exactly this kind of thing.

Q2. What's the single fact that most separates tenant from host? The toolkit's presence on AS197170, a competing bulletproof operator. That one overlap is very hard to explain if DMZHOST is the operator, and trivial to explain if the operator is a customer of both.

Q3. Why does the GPU check matter so much? Because it reveals intent and therefore value. lspci | grep nvidia on every box means the operation triages for compute — GPUs are the target, whether for mining, ML-model theft, or reselling stolen capacity. It reframes the campaign from "generic loader" to "compute hunter."

Q4. Why zero downloads if it's a loader? Because it is "drop-on-proof." Most boxes never pass the honeypot probe or the value triage, so most sessions end at reconnaissance with nothing dropped. The zero-download honeypot figure is the point of the doctrine, not a gap in it — it means our sensors looked like poor targets and were correctly skipped.

Q5. Could DMZHOST and The Appraiser be the same crew after all? Possibly — the medium confidence is honest. If future evidence tied the Appraiser's operator to TECHOFF-MNT or the DMZHOST shells directly, the verdict would move. It does not, today. Today the toolkit's spread across rival hosts is the stronger signal, and it says tenant.

Q6. Is AdaptixC2 the operator's own framework? AdaptixC2 is an open post-exploitation/C2 framework; its presence identifies the capability on 195.178.110.232, not a bespoke tool. Like the shared Go scanner, it is a commodity component — informative about what the tenant runs, not proof of who they are.

Q7. What would break this finding? If the five "shared" IPs turned out to be misattributed, or if the Appraiser toolkit were shown not to touch AS197170, the tenant-vs-host balance would shift. Neither is the case: the five IPs are in both investigations' infrastructure lists, and the cross-host tooling overlap is documented in the parent dossier itself.

6. The counter-narrative, steelmanned — then defeated

Steelman: "You are overthinking it. A botnet runs on DMZHOST's boxes, from DMZHOST's IPs, on DMZHOST's ASNs. Occam says DMZHOST runs the botnet. The 'tenant' story is you inventing a phantom customer to avoid the obvious."

Defeat: Occam favours the explanation that fits all the evidence, and "DMZHOST runs it" fails on one hard fact: the same toolkit runs from AS197170, a rival bulletproof host. To keep the simple story you must claim DMZHOST also operates from its competitor's network — which is less parsimonious, not more, and commercially nonsensical. The tenant model explains the DMZHOST nodes and the AS197170 nodes with a single actor (a customer of both). It also explains why the parent dossier itself frames DMZHOST as "knowingly hosting" rather than operating, and why operator identity is unnamed while hoster identity is fully documented. The phantom is not the tenant; the phantom is a landlord who moonlights on a rival's floor.

7. Read between the lines

The interesting thing this letter exposes is structural: bulletproof hosting is a market, and its floor is shared. The Appraiser is one tenant; there are others, and the parent series has already met a different one on a different floor (TechTies). Attribution in this world is a layered problem — the building, the floor, the occupant — and collapsing the layers is how analysts manufacture false "mega-operators." The honest map keeps DMZHOST as the durable, named, legally-traceable landlord and treats the campaigns on its floor as separable tenants, each attributed on its own evidence. That is less dramatic than "one giant criminal conglomerate," and far more useful: you can seize a tenant without the landlord, or pressure the landlord without misattributing every tenant's crime to it. The GPU-hunting appraiser and the crypto-node hunter of 088F may be the same tenant or two different ones — the data does not yet say — but both are occupants, and the building is DMZHOST.

8. What if

What if takedown strategy respected the layers? Pressuring the landlord (Spamhaus ASN-DROP on AS47890/AS48090, registrar action on the shells, the maintainer pivot) degrades every tenant at once but names none of them. Pursuing the tenant (the Appraiser's cross-host toolkit, the dev:12345678 credential cluster, the AdaptixC2 nodes, the external IPs 43.245.97.82 et al.) can name and seize the operator without waiting on the host — and follows them when they migrate to their next bulletproof floor. The two efforts are complementary, and confusing them is how you spend a landlord-sized effort to catch a tenant, or a tenant-sized effort against a landlord and wonder why the floor refills.

9. Documented vs inferred — the honest ledger

10. Infrastructure & IOCs

Tenant campaign     TI-2026-083C "The Appraiser" — profile-first SSH loader (drop-on-proof)
                    19 IPs | 3,035 attempts | 251 logins | 2,102 commands | 0 downloads (2026-05-21 → 07-13)

Shared nodes (5, all in DMZHOST prefixes):
  195.178.110.232  AS48090 | AdaptixC2 | botnet/c2 (0.9) | DShield 24,779 | AbuseIPDB 100 | HASSH 2ec37a7c…
  2.57.122.238 · 92.118.39.71 · 193.46.255.86 · 80.94.92.55  (all AS47890, threat 100)

Profiler fingerprint  uname -s -v -n -m (+ /bin/uname, busybox uname, /etc/os-release, /proc/version)
                      nproc; lscpu; /proc/cpuinfo; /proc/device-tree/model
                      lspci | grep -i 'vga|nvidia'   <-- GPU triage (compute-hunting intent)
                      uptime; last                    anti-honeypot: ./xxxxxx sentinel probe before drop
Credential cluster    dev:12345678 (cluster_size 5) → 43.245.97.82, 185.141.24.44, 103.143.238.100, 86.139.23.230
Cross-host tell       same toolkit on AS197170 (TechTies/HostSlick) — marks operator as a multi-host TENANT

Defensive action: attribute the campaign (The Appraiser) and the host (DMZHOST) separately. Blocklist DMZHOST prefixes as landlord space; hunt the tenant by its portable signatures — the GPU-triage profiler, the dev:12345678 credential cluster, the AdaptixC2 nodes, and its presence across multiple bulletproof ASNs. GPU/compute operators (mining pools, ML infrastructure, GPU cloud) should treat this profiler's lspci probe as targeted reconnaissance of their hardware.

11. Sources

LSN honeypot command/session capture (TI-2026-083C "The Appraiser"; node 195.178.110.232 and the four AS47890 shared nodes); LSN entity-resolution graph (cross-reference edge DMZHOST → TI-2026-083C; dev:12345678 credential cluster); ThreatFox (AdaptixC2), DShield, AbuseIPDB, AlienVault OTX, VirusTotal reputation for 195.178.110.232; TI-2026-088 parent dossier (host/operator schema; AS197170 cross-host tooling finding). TLP:WHITE.