The Docsearch Probe: Reconnaissance Read from Your Own Website

TI-2026-079B · The Harvest, Part B Confidence: HIGH on the probe; MEDIUM on the discovery-method inference Classification: TLP:WHITE

The freshest touch

Part A mapped the harvest as a whole — a cheap, almost-uniformly-hostile network running a credential army. This letter zooms to a single machine, and it is worth zooming to because of when it acted: hours before this was written. At 17:58 on 10 July 2026, a brand-new Advin address reached into this estate, spent about two seconds, and touched exactly one service.

65.110.40.130 is an IP on the Octopus Web Solution sub-allocation (65.110.40.0/24) of AS22295. It is so fresh that the intel-enrichment database has no record of it at all — a newly-provisioned address with no history. It made eight GET requests over roughly two seconds, and its target was singular: lsn-docsearch.shuffle-on.com, the estate's document-search service.

Not a broad sweep. Not the whole lsn-* namespace. One named internal service, touched precisely, by a fresh machine, in the space of a breath. The interesting question — the one this letter answers — is how a brand-new IP knew to go straight there, because the answer is a reconnaissance method distinct from anything else in the record, and it is the one most squarely under the defender's own control.

How it probed

First, how it touched docsearch, because the mechanism is familiar. The requests went through the Authelia single-sign-on portal's redirect: /?rd=https%3A%2F%2Flsn-docsearch.shuffle-on.com%2F&rm=GET, returning the masked login response, with a second redirect aimed at a specific asset path under the same service.

This is the masked-200 auth-probe pattern that The Control Plane Lie (TI-2026-073B) documented and that the Google estate-sweep (078B) also used: a protected service, probed through the SSO portal, returns a generic login response that masks the true target, while the real intent hides in the ?rd= redirect parameter. To a naive log reader the request looks like innocent traffic to the login page; the actual target — lsn-docsearch — is in the redirect. The attacker was testing the front door of the protected document-search service.

But the mechanism of probing is not what makes this probe notable. What makes it notable is the one request that reveals how the attacker knew lsn-docsearch existed at all.

The tell: it fetched the exact bundle

Among its eight requests, 65.110.40.130 fetched this: /static/js/index.CXslS62G.js.

That is the document-search application's specific, content-hashed JavaScript bundle — the actual file the docsearch web front-end loads to run itself. And the crucial property of that filename is the string CXslS62G: a build hash. Modern web apps append a content hash to their asset names so browsers cache them correctly, and that hash is not guessable. You cannot arrive at index.CXslS62G.js by trying common paths. There is exactly one way to know that filename: read it from the application's own references — the app tells the browser which bundle to load, and the attacker read that instruction and pulled the file.

So this was not blind path-guessing. Requesting a content-hashed bundle by its exact name proves the attacker had reached the application far enough to see, and follow, its own published structure — the real asset references the genuine front-end uses. It was following the target's own map. Which raises the question of where that map came from.

The discovery: it read your website

Here is the inference at the heart of the letter, and it is the answer to "how did a fresh IP know to go straight to lsn-docsearch, down to its JavaScript bundle?"

The most parsimonious explanation, consistent with every piece of evidence, is discovery-by-public-surface. lsn-docsearch is referenced or linked from the public website, www.shuffle-on.com. An attacker crawling that public site would extract the reference to the internal document-search service, follow it, and — reaching the app — follow its asset references in turn, right down to the hashed bundle. The whole chain, from "found the service" to "fetched its exact JS," flows naturally from one act: reading the defender's own published website.

This matters because it is a third, distinct reconnaissance method, different from the two others already in this body of work:

• The Namespace Sweep (073C) guesses internal names from a pattern — it knows the estate uses lsn-* and tries plausible names.
• The Estate Sweep (078B) holds a non-public identifier — the Google recon arm knew the NAS's private QuickConnect ID, obtained from somewhere off-site.
• This probe does neither. It reads the target list directly from what the defender chose to publish. The knowledge is not guessed and not pre-held; it is harvested from the public surface.

Of the three, this is the one most completely within the defender's control — because the attacker's entire source of knowledge is the website the defender themselves put online. You cannot stop an attacker from guessing, and you cannot easily find where a leaked identifier went; but you can decide what your public site links to.

The disguise, again

For completeness: across its eight requests, 65.110.40.130 rotated several spoofed desktop-browser user-agents — Windows Chrome, Linux Chrome, macOS Chrome — the same blend-in disguise the Google estate-sweep wore (078B). A budget-host VM dressing as a home browser, so its probing reads as ordinary human traffic. And, as everywhere in this work, the disguise addressed appearance and not behaviour: the estate-specific target, the masked-200 auth-probe, and the exact-asset fetch identified the intent regardless of the costume. You cannot spoof your way out of what you did.

What held, and what did not

Two honest facts to close, because the letter should neither over- nor under-state.

What held: there is no sign the probe succeeded. The masked-200 auth-probe met the Authelia portal, lsn-docsearch sits behind SSO, and the IP is on a network already being handled by CrowdSec and MikroTik. The control plane did its job.

What did not hold — and this is the finding — is the exposure. A service the estate may have thought of as semi-private was discoverable, and discovered, within seconds, by a fresh attacker, because it is linked from the public website. "The login held" is not the same as "not exposed." The defensive action here is not about the auth (which worked) but about the surface: treat lsn-docsearch as a known, named, public-facing target from now on — confirm SSO and strong auth on it, and review the public site's references to internal services against whether they need to be advertised at all. What you link publicly, you expose. The attacker did not break in; it simply read your website, and your website told it where the document library was.

The translation, for everybody

In plain words: you put up a public noticeboard — your website — and, without quite meaning to, one of the notices had a little map on it showing where your private study is. A stranger walked past, read the map off your own noticeboard, walked straight to the study door, and rattled the handle — all in about two seconds, wearing a disguise so you would not notice. The door was locked, and he has been moved along. But he did not pick the lock or guess the address. He read your own sign.

The lesson is gentle but real: the door held, so nothing was lost today — but the map is still on the noticeboard, and the next stranger will read it too. The fix is not a bigger lock (the lock worked). It is to look at your own noticeboard the way a stranger would, and decide which of the little maps really need to be up there. You cannot stop people reading what you publish. You can decide what you publish.

Indicators (TLP:WHITE)

Cross-references

• TI-2026-079A — The Harvest — the Advin network this probe belongs to.
• TI-2026-073B — The Control Plane Lie — the masked-200 auth-probe via the SSO redirect.
• TI-2026-073C — The Namespace Sweep / TI-2026-078B — The Estate Sweep — the two other recon methods (guessing; prior knowledge) this one differs from.

This dossier documents targeted reconnaissance of a named internal service, for defensive purposes. No compromise was observed. The finding concerns discovery-by-public-surface — an internal service reached because it is linked from the public website — and the surface-reduction that follows. TLP:WHITE.