The Estate Map: How One Hostname Becomes a Hypothesis of the Whole Network

TI-2026-086T · Series: The Wardrobe · Case 20 · Classification: HIGH · Confidence: HIGH

The harvest cases showed the wardrobe reaching for secrets. This case shows the phase that comes first: the mapping. Before you can steal a service's .env, you have to believe the service exists — and the fleets spend enormous effort guessing what a target runs. Read those guesses in aggregate and something appears that no single probe shows: a map of the estate, drawn entirely by the attackers, from the outside, one guessed hostname at a time. It is mostly wrong, it reaches from web services all the way to the router and the NAS, and the estate's own architecture makes sure the attackers can never tell which parts of it are right.

Executive Summary

The web-threats host-type census divides every hostname the edge has ever seen into what it actually is:

Those 252 nonexistent-guessed hostnames are the finding. They are not real; they are what 4,331 IPs collectively guessed the estate might contain — a crowd-sourced hypothesis of the network, assembled by Host-header enumeration against a single ingress. And they read like a homelab shopping list:

• Service topology — portainer (Docker management), guacamole (remote desktop), lsn-grafs (Grafana), lsn-jupyter, lsn-netdata, lsn-pihole, lsn-wireguard, lsn-auth-manager, lsn-ai-staging, onyx, draw, sandstorm, library/books.
• Inferred hardware — 5d9104581876.sn.mynetname.net (a MikroTik router's cloud DNS), lsn-nas1/lsn-nas2.direct.quickconnect.to (a Synology NAS).
• Proxy probing — www.msftncsi.com, Microsoft's connectivity domain, requested through the ingress to test whether it can be abused as an open relay.

The whole thing is enumerable because the estate has one front door, and it is unfalsifiable because that front door answers every guess the same way. The reconnaissance produces a map of 252 hypotheses and zero confirmations.

One Front Door, a Thousand Guessed Rooms

The mechanism is the estate's own topology. Everything at *.shuffle-on.com resolves to a single residential ingress — a GoDaddy dynamic-DNS apex A-record pointing at one home IP, DNAT'd by a MikroTik router into a Traefik reverse proxy. Every service, real or imagined, lives behind that one address, distinguished only by the Host header Traefik reads to decide where to route.

That makes vhost enumeration trivial and DNS-free. An attacker does not need to look up portainer.shuffle-on.com in DNS (it may not exist there at all); it simply opens a connection to the known ingress IP and sends GET / HTTP/1.1 with Host: portainer.shuffle-on.com, then Host: guacamole.shuffle-on.com, then Host: lsn-grafs.shuffle-on.com, reading Traefik's response to each. The Host header is the probe. The whole vhost namespace — every service the estate could plausibly run — is a single wordlist fired at a single IP, which is exactly what the Vhost Sweep campaigns do: AS8075 with 19 IPs and 10,849 requests, AS396982 with 16, AS16509 and AS14618 with 13 and 16. This is the mapping phase, and it is separate from the harvest: first you enumerate which rooms exist, then you send the .env sweep at the ones you believe do.

The Map Reaches the Router and the NAS

The service-subdomain guesses are the expected part — portainer, grafana, jupyter, netdata are what any homelab runs, permuted against the lsn- convention the attackers learned from one exposed host (086R). But two entries in the 252 show the reconnaissance reasoning past the web layer into the hardware, and they are the most interesting thing in the dataset.

5d9104581876.sn.mynetname.net drew 2,716 hits. That is not a shuffle-on.com subdomain at all — it is a MikroTik router's default cloud-DNS hostname, the mynetname.net dynamic-DNS name every MikroTik device can register. And lsn-nas1.direct.quickconnect.to / lsn-nas2.direct.quickconnect.to (1,952 and 1,694 hits) are Synology NAS QuickConnect hostnames — the default remote-access DNS for Synology appliances. Nobody published these. The attackers inferred them: from "this is a homelab reachable at a residential IP," they concluded "it probably runs a MikroTik router and a Synology NAS," and then guessed those vendors' default cloud-DNS naming schemes against the ingress to see if the router admin panel or the NAS were reachable.

That is a materially more sophisticated recon model than "guess web subdomains." It says the adversary's map of a target includes the appliance ecosystem — the specific vendor gear a homelab of this shape is likely to contain — and that it will probe vendor-default DNS to reach management interfaces the site never named as its own subdomains. Your router and your NAS are on the map even if you never gave them a shuffle-on.com name, because the attacker knows what a homelab is made of.

The Estate Answers Every Guess the Same Way

Here is why all 252 of those hostnames are filed nonexistent_guessed and not "confirmed real" or "confirmed fake": the estate refuses to tell the difference. Traefik's catchall and block_unknown routers answer an unrouted Host header with a uniform 200 (a login SPA or a default page) or 403 — the masked-200 mechanic of 086P. So when the attacker sends Host: portainer.shuffle-on.com and gets a 200, that 200 means nothing: it is the same 200 a real service would return and the same 200 a nonexistent one returns. The response carries no bit of information about whether the guess was right.

Follow what that does to the map. The attackers have a naming convention (they learned lsn- from one exposed host, 086R) and a service catalogue (portainer, grafana, jupyter…), and from those they generate 252 plausible hostnames. But to turn a hypothesis into a confirmed target, they need the estate to say "yes, that one is real" — and the catchall never says it. Every guess gets the same answer. So the reconnaissance terminates in a map of 252 candidate rooms, none of which the attacker can confirm is behind an actual door. The estate leaks its naming scheme (unavoidable, once one host is exposed) but hides its topology (which of the schematically-plausible hosts actually exist).

This is the same defensive property 086P found in the harvest, now operating on the map: uniformity of response starves reconnaissance exactly as it starves the harvest. The real services are hidden not by being unnamed — the attacker guessed several of their conceptual names correctly — but by being indistinguishable from the 251 wrong guesses around them. A catchall that answers everything identically is a fog the map cannot see through.

Steelmanning: "The attackers don't need confirmation — they just fire the harvest at all 252"

The sharp objection: reconnaissance-denial is pointless if the attacker skips it. Why bother confirming which vhosts are real? Just send the .env sweep at all 252 guessed hostnames — the marginal cost of a hypothesis that turns out fake is one wasted request, and the harvest itself reveals the real ones when a real .env finally returns.

Two things blunt this, and one concedes it. First, the concession: yes, an attacker can skip confirmation and spray the harvest across every guess, and the volume data shows some do — which is precisely why the harvest also had to be starved (086P: the real .env returns the same masked-200 as the fake, so even spraying all 252 yields no confirmed hit). The two defences compose: the map cannot confirm a vhost, and the harvest cannot confirm a file, so spraying the harvest across the unconfirmed map still terminates in no confirmation at either layer. Second, confirmation is not free at scale: an operator running 252 hostnames × a 150-path .env dictionary is 37,800 requests per target, and the fleet-and-rhythm detection of 086A/086S catches that volume-and-synchrony long before it completes — the reconnaissance that would have pruned the 252 to the handful of real ones is exactly what makes the subsequent harvest cheaper and quieter, so skipping it trades stealth for coverage. The objection is right that confirmation is optional; it is wrong that skipping it escapes the starvation, because the starvation was built at both layers precisely so that neither the map nor the harvest can be confirmed.

What Holds, and What Is Bounded

Documented, HIGH confidence: the host-type census (252 nonexistent_guessed hosts, 4,331 IPs); the service-topology and appliance-DNS guesses (MikroTik mynetname.net, Synology quickconnect.to); the single-ingress Host-header enumeration mechanism; the catchall/masked-200 that files every guess as nonexistent_guessed; the Vhost Sweep campaigns.

Inferred, MEDIUM confidence: the reasoning attributed to the appliance-DNS guesses ("inferred a homelab runs a MikroTik and a Synology") is a strong reconstruction from the specific vendor-default hostnames guessed, not a stated intent; and the www.msftncsi.com entry is read as a proxy-abuse probe from its well-known role, which is the standard interpretation but not confirmed against the request's full context here.

Why It Matters

The Estate Map shows the reconnaissance half of the wardrobe operation — the part that runs before the harvest and decides what the harvest aims at — and it reframes a pile of 404-less junk traffic as what it actually is: the adversary drawing your network from the outside. Two hundred and fifty-two guessed hostnames, from four thousand IPs, is not noise; it is a collaborative, continuously-updated hypothesis of your service topology and your hardware, assembled Host header by Host header against your single front door, reaching from your Docker manager to your Grafana to your router's cloud DNS.

And it shows why the estate's architecture is quietly doing more than the harvest cases credited. The shared ingress that makes the whole vhost namespace enumerable is the same ingress whose catchall makes that enumeration unconfirmable — the property that seems to help the attacker (one address, all services) is inseparable from the property that defeats them (one address, one uniform answer). The attacker learns your naming scheme the moment you expose a single host, and there is no preventing that. What the estate can control, and does, is whether learning the scheme lets them confirm the map — and by answering all 252 guesses identically, it hands the adversary a beautifully detailed map with every "you are here" erased. The reconnaissance succeeds at imagining your estate and fails at verifying it, and the gap between the two is the whole defence.

Cross-references

• TI-2026-086P — The Two-Hundred Mask — the catchall/masked-200 that starves the map as it starves the harvest.
• TI-2026-086R — The Wordlist as a Blueprint — the lsn- convention, learned from one host, permuted into the 252-name map.
• TI-2026-086B — The Flagship Mask — the Fake-Googlebot vhost_enum sub-mode as a member of this mapping operation.
• TI-2026-086S — The Rhythm — the fleet-and-synchrony detection that catches the sweep before it completes.

Next in the series — TI-2026-086U, The Corroborators: how independent reputation sources converge on the same nodes, and why four sensors agreeing collapses the false-positive space.

TLP:WHITE. Guessed (nonexistent) hostnames and attacker reconnaissance telemetry only; the hostnames listed are attacker guesses, not confirmations of real infrastructure. No internal addresses or secrets disclosed.