The Estate Sweep: Reconnaissance That Knows You by Name

TI-2026-078B · The Cloud Offensive, Part B Confidence: HIGH on the targeting; MEDIUM on prior-information inference Classification: TLP:WHITE

When the attack becomes personal

Part A described a front — two thousand machines, faceless and statistical. This letter is about one of them, and it is the letter where the offensive stops being a number and becomes personal, because this machine does not attack a server. It attacks this server, and it knows its name.

34.122.16.212 is a single Google Cloud VM. On paper it is unremarkable: threat score 2, one of 2,105. But read what it actually requested, and it is the most unsettling artifact in the whole offensive — not because of what it did, but because of what it knew. It arrived already holding a map of this estate, and it went straight for the crown jewels, by name.

There is a distinction at the heart of threat intelligence between weather and intent. Weather is the ambient scanning every server on earth receives identically — impersonal, indifferent, hitting your address the same way it hits everyone's. Intent is different. Intent knows who you are. This letter is about the moment the weather report turned into a targeted map, and the evidence that someone, somewhere, has been doing their homework on this specific infrastructure.

It enumerated the estate by its own names

A blind scanner fires a generic wordlist — admin, mail, vpn, test, dev — the same list at every target, hoping something sticks. 34.122.16.212 did nothing of the kind. It requested this estate's actual service names, ranked here by number of hits:

• lsn-nas1.direct.quickconnect.to — 19 (the network-attached storage)
• lsn-ai — 11 (across both .sonatural.life and .shuffle-on.com)
• lsn-auth — 5 (the single-sign-on portal)
• lsn-webtop — 4 (remote desktop)
• lsn-trivy — 3 (the vulnerability scanner)
• lsn-wifi — 3 (network/WiFi control)
• lsn-media, lsn-storage, lsn-meet, lsn-classroom — 2 each
• and singles for lsn-registry (the container registry), lsn-wireguard (the VPN), lsn-pihole (DNS), lsn-grafs (Grafana monitoring), lsn-images, lsn-webmail, lsn-amp, lsn-ai-k3s — plus the public site.

Twenty-four distinct hosts, and almost every one carries the lsn- prefix — this estate's own naming convention. The attacker is not guessing whether these services exist. It already knows their names. This is what the Namespace Sweep dossier (TI-2026-073C) named "namespace-native reconnaissance": the wordlist has stopped being a generic dictionary and become your dictionary — the specific names you gave your own machines. When your service names show up in an attacker's request log, the scanning has stopped being about the internet and started being about you.

It knows a name that isn't public

And then there is the top of the list — the target it hit nineteen times, more than any other — which is the single most telling piece of evidence in the letter: lsn-nas1.direct.quickconnect.to.

Read that hostname carefully. It is not lsn-nas1.shuffle-on.com — not a subdomain of the estate's public domain that could be guessed from the lsn- pattern once you know the pattern. It is a quickconnect.to address: the Synology NAS's QuickConnect relay ID, a hostname on Synology's own infrastructure that maps to this specific NAS. And a QuickConnect ID is not derivable from the public naming pattern. You cannot guess it from knowing the estate uses lsn-*. It is a distinct identifier that had to be obtained — from DNS history, from certificate-transparency logs, from a leaked or cached configuration, or from earlier reconnaissance that already found it.

That single hostname changes the character of the whole event. It means the attacker did not arrive at this estate fresh and start guessing. It arrived already holding information — a specific, non-public identifier for the most valuable machine on the network — and put it at the very top of its target list. No wordlist contains a QuickConnect ID. Its presence is proof of prior knowledge, and prior knowledge is the definition of a targeted operation. This is not first contact. It is a follow-up, building on homework already done.

The targets are the crown jewels

Now read the list not as names but as functions, and it resolves into a checklist that no indiscriminate scanner would produce — because it is organised by value:

• Data: lsn-nas1 (the NAS), lsn-storage, lsn-media, lsn-images — where the files, the backups, the media live.
• Network control: lsn-wifi (the WiFi/router), lsn-pihole (DNS), lsn-wireguard (the VPN) — the services that, if taken, give control of the network itself.
• Software supply chain: lsn-registry (the container registry) — poison what is stored here and you poison everything that pulls from it.
• Access: lsn-webtop (remote desktop), lsn-auth (the SSO portal) — the routes to a logged-in session.
• Monitoring: lsn-grafs (Grafana), lsn-trivy (the vuln scanner) — the estate's own eyes, worth blinding.

That is not a scanner cataloguing everything it can reach. It is reconnaissance prioritising the doors that matter — the routes to data, to network control, to supply-chain compromise, to persistent access. The target list is a statement of objective: it maps what the offensive is after. And for a defender, that same list is a gift in reverse — it is a map of your own crown jewels, ranked in the attacker's own hand. They told you what to harden first.

It tried the locks, through the portal

This was not a passive listing. The request breakdown is 61 POST to 6 GET — overwhelmingly POST, because POST is how you submit a login, not just look at a page. 34.122.16.212 was not merely noting which services exist; it was auth-probing them.

Specifically, it POSTed to lsn-auth.shuffle-on.com — the Authelia single-sign-on portal — with redirect parameters aimed at the protected services behind it: /?rd=https%3A%2F%2Flsn-wifi.shuffle-on.com%2F&rm=POST, and the same for lsn-webmail and lsn-webtop. This is the exact pattern The Control Plane Lie (TI-2026-073B) documented: a protected service, probed through the SSO portal, returns a 200 login page that masks the true target — so the attack looks like innocent traffic to the portal, while the real intent is hidden in the ?rd= redirect parameter. The masked 200 is the disguise; the redirect is the tell.

The behavioural engine read the tell. CrowdSec's ban scenarios for this IP name it exactly: web-threats/lsn-ai: probe_intent detected and LePresidente/http-generic-403-bf — a 403 brute-force against a protected endpoint. The portal held (there is no sign anything opened), but the probing was unambiguous: it walked down the list of protected crown jewels and tried each lock through the front-desk redirect.

It wore a disguise

One more detail completes the profile: 34.122.16.212 did not present as a scanner. Across its requests it rotated multiple spoofed desktop-browser user-agents — Windows Chrome, macOS Chrome variants — deliberately dressing its traffic to look like an ordinary human browsing from a home computer.

Think about how incongruous that is: a Google Cloud data-center VM, presenting itself as someone's Windows laptop. That mismatch is the disguise — an attempt to blend targeted reconnaissance into the background noise of normal web traffic, so that a defender glancing at user-agents sees "just another browser." It is the network-layer cousin of the borrowed face (TI-2026-075T): wear the identity that does not get a second look.

The disguise failed, and how it failed is the lesson. It was not caught because its user-agent looked wrong — the user-agent looked fine, which was the point. It was caught because of what it did: the estate-specific target list, the POST-heavy auth-probing, the per-service intent. Behaviour gave it away where identity was engineered to pass. Once again, across the whole body of this work: the disguise hides what the attacker looks like; it never hides what the attacker does.

The reassurance, and the residue

Two honest closing facts, because the letter should neither under- nor over-alarm.

The reassurance: a defensive verification probe of lsn-nas1.direct.quickconnect.to returned no response at all (HTTP 000) at the time of writing. That strongly suggests the NAS is not openly reachable through that QuickConnect path from the public internet — so the nineteen probes likely met a closed door, and there is no evidence of any success anywhere in this reconnaissance. The estate's exposure appears limited, and the defence caught and banned the machine (MikroTik crowdsec-blacklist since 30 June, a fresh brute-force ban on 10 July).

The residue: none of that changes the finding. The attacker holds the QuickConnect ID and ranked it first. Whether or not the door was open today, someone knows exactly where the most valuable door is, and cared enough to name it before anything else. Absence of success is not absence of intent — and here the intent was specific, prioritised, and aimed at the NAS. That is worth acting on regardless of the current exposure: confirm the NAS is not needlessly reachable, harden its own authentication, treat the QuickConnect ID as known-to-adversaries, and audit where a non-public identifier like that could have leaked (certificate transparency, DNS history, old configs). The attacker did the homework; the defender should now check the same sources the attacker used.

The translation, for everybody

In plain words: most of the people who rattle your doors are strangers trying every house on the street the same way. This one had your address written down. It walked up knowing your name, went straight to your safe — not the front door, the safe — tried it nineteen times, then worked down a list it had clearly made in advance: the safe, the network box, the spare-key drawer, the back office. And it was dressed like a neighbour so you would not look twice.

The safe was locked, and the neighbour has been escorted off and banned. But the unsettling part is not whether the safe opened. It is that someone made a list of your valuables, in order, with your safe at the top — which means someone was watching before they knocked. The right response is not panic; it is to check the locks on everything they named, and to figure out where they got your list.

Indicators (TLP:WHITE)

Cross-references

• TI-2026-078A — The Cloud Offensive — the front this recon arm belongs to.
• TI-2026-073C — The Namespace Sweep — namespace-native enumeration, here on the estate's lsn-* naming.
• TI-2026-073B — The Control Plane Lie — the masked-200 auth-probe via the SSO redirect.
• TI-2026-075T — The Borrowed Face — spoofed identity to pass unremarked; caught on behaviour.

This dossier documents targeted reconnaissance against this homelab's named infrastructure, for defensive purposes. No compromise was observed. The finding concerns the attacker's demonstrated prior knowledge of a non-public identifier and its prioritised targeting of critical services, and the defensive actions that follow. TLP:WHITE.