TI-2026-065F — The Mirror That Masks

Series: The Return · Part F · Classification: INFORMATIONAL · Confidence: HIGH

Part E ended on a single odd probe: /?rd=https://lsn-photos.shuffle-on.com/. Pull that thread and it does not lead back to Tencent. It leads to 4,029 requests from 431 machines across half the cloud industry, all knocking on the same door — and all being handed the same blank mirror. This part is not about an attacker. It is about the door.

Executive Summary

The rd= probe is a hunt for an open redirect — CWE-601, the flaw that lets a trusted domain bounce a victim to an attacker's site for phishing. The OSINT library is full of it: WeGIA, Capgo, Next.js, IBM Verify, PrivateGPT, Noptin, PMB — dozens of CVEs where a redirect/nextPage/rd parameter was honored without validation. The probing population knows the pattern and sweeps for it at scale.

Against the LSN estate it finds nothing, and the way it finds nothing is the story:

• 4,029 rd= probes, 431 IPs — led by Amazon (1,390) and Google Cloud (755), with DigitalOcean, M247, CDN77 behind them. AS132203/Tencent is a sliver. This is internet-wide background enumeration, not one actor.
• Zero external redirect targets. Every rd= value points at an LSN-owned subdomain. No probe carried rd=https://evil.com — and none could, because Authelia validates the parameter against its own cookie domains. The open-redirect class is structurally closed.
• One uniform response. All 4,029 hit the SSO portals (lsn-auth.shuffle-on.com, auth.sonatural.life) and every one returns HTTP 200 whose effective status is 401 — the masked login SPA (the same mask from Part A). Thirty-six different protected services, one identical face.

The portal is a mirror that masks: it reflects your intended destination straight back at you and shows you nothing behind it. In one architectural stroke it defeats two attacks at once — the open redirect and the reconnaissance that precedes it.

I. What the Probes Wanted

An open redirect is small-sounding and quietly dangerous. A link like https://trusted-sso.com/?rd=https://evil.com shows the victim a domain they trust; the server obligingly forwards them to the attacker. It is the perfect phishing primitive — the credibility of the real domain, the destination of the fake one. The library catalogues the class in volume (all CWE-601):

The rd parameter on an authentication portal is the highest-value place to find this bug — an SSO login page is designed to redirect you onward after you authenticate. If it forwards to any URL you name, it becomes a weaponizable phishing lure wearing the organization's own name. That is precisely what 431 machines were checking for.

II. What the Probes Got — The Two Masks

Mask 1: the redirect goes nowhere it is told

Across 4,029 probes, the rd= value was always an LSN domain — 36 distinct subdomains, never once an external host. That is not restraint on the attackers' part; it is the shape of a closed door. Authelia only honors rd for destinations inside its configured cookie-domain scope. Feed it https://evil.com and it discards it and shows the login page anyway. There is no version of this request that ends at an attacker's site. The class the probes hunt for is simply not present — and the absence is by design, not by luck.

Mask 2: every service wears the same face

The second mask is subtler and arguably more valuable. The 36 subdomains the probes enumerated — media, storage, git, mail, maps, the AI services, the MCP endpoint — are wildly different applications with wildly different attack surfaces. But hit any of them unauthenticated and you get the identical response: 200-status, 401-effective, the same login SPA. An enumerator cannot tell from the outside which service is live, which is a decoy, which runs a vulnerable version, which is even real. The forward-auth portal collapses 36 distinct doors into one mirror. Reconnaissance — the mandatory first stage of every playbook in Part E — returns a flat, uniform nothing.

III. The Seven Questions

Who is this? 431 cloud-hosted machines, mostly Amazon and Google, running redirect-scanning. Why did it probe? To find a CWE-601 open redirect for phishing. Who does it claim to be? A mix — some benign auth-flow crawlers, some deliberate scanners; the portal treats them alike. Who is it really? The internet's ambient enumeration layer, the same population that sweeps every SSO on earth. Whom is it related to? Everyone and no one — this is background radiation, not a campaign. Where is the money? In the phishing kit that a working open redirect would enable — which is why the closed class matters. What is the official anchor? CWE-601 and the dozens of CVEs that make the probe worth running.

IV. Steelman — "You Are Taking Credit for Nothing"

The strongest objection: most of those 4,029 requests are just normal Authelia bounces — a bot hits a protected subdomain, gets forwarded to the login page with rd= set to where it came from. You are dressing up routine auth traffic as a defended attack, and congratulating a config file for doing its job.

This is fair and we concede the large part of it: yes, much of this volume is the ordinary forward-auth flow, and we do not claim 4,029 deliberate attacks. Intent here is genuinely mixed and mostly unknowable per-request. But the objection misses the actual claim, which is not about intent at all. The claim is architectural: whatever the intent — benign crawler or phishing scout — the outcome is identical and safe. The open redirect cannot be reached; the catalog cannot be read. A defense that only works when you can tell attackers from crawlers is not a defense. This one does not need to tell them apart, and that is the point worth publishing. The config file doing its job — uniformly, for hostile and benign alike — is exactly the property most estates lack.

V. Read Between the Lines

• The best defenses are boring and invisible. There is no alert here, no ban, no drama — just 4,029 requests that quietly amounted to nothing. The absence of an incident is the result.
• Centralization cuts the other way from Part D. A single SSO chokepoint is a single thing to harden — and hardened once, it protects thirty-six services identically. The same concentration that makes a glass house fragile makes a mask strong.
• Enumeration and open redirect are the first and last stages of the Part E playbook. Closing both at the front door is why the playbook, for this estate, never gets past its opening move.

VI. The Human Layer

Somewhere in those 431 machines is a scanner tuned by a person who has, elsewhere, found a real one — a login portal that did forward to any URL, that did become a phishing lure wearing a hospital's or a bank's name, that did cost someone their password and their savings. That person's tool is good; their premise is sound; the flaw they hunt is real and common. They simply knocked on a door built by someone who had read the same CVEs they had. The quiet 401 behind the 200 is the difference between a victim and a non-event — and it is invisible to everyone it protects.

VII. Verdict

The LSN SSO portal is a mirror that masks: across 4,029 rd= probes from 431 mostly-cloud IPs, zero could reach an external redirect (CWE-601 closed by rd validation) and all 36 protected services returned an identical 200-masked-401 login face (catalog enumeration defeated). Confidence: HIGH for the defensive facts; the mix of benign vs. hostile intent behind the probes is deliberately left unclaimed. The finding is architectural, not attributive — and it is the series' first look at a defense that closes a whole vulnerability class by design.

VIII. Defensive Response

Nothing to do — which is the finding. The forward-auth rd-validation and uniform challenge are standing architecture; CrowdSec bans the noisier scanners on top (Parts A/E). The open-redirect class was closed before the first probe arrived.

Crosslinks

• ← TI-2026-065E — The .env Playbook — the probe that opened this thread; enumeration is stage one of that kill chain, closed here.
• ← TI-2026-065A — The Second Front — the 200-mask methodology this part turns into a defensive asset.
• TI-2026-065D — The Glass House — centralization as fragility; here, centralization as strength.

Sources: LSN web-threats requests (rd= corpus, host + effective_status + external-target analysis) mapped to OSINT library CWE-601 CVEs/Nuclei templates. Method: hypothesis (open-redirect surface) tested and inverted into a defensive finding. Hostnames referenced are public via Certificate Transparency. TLP:WHITE.