Nobody Knocked: The Login Portal Is the Least-Attacked Surface on This Estate

Letter H counted 324 hostnames that were invented and 92,466 requests addressed to them. It ended on a recommendation about what this estate publishes to the world.

This letter is about what the world does with it once it arrives — specifically, about the one surface everybody assumes is under siege.

Three hostnames on this estate sit behind an authentication portal. Over seventy days they took 18,517 requests from 1,603 distinct addresses. Stated that way, it reads like a sustained assault on the front door.

It is not. Over the same corpus, the single path through which a password can physically be submitted — Authelia's /api/firstfactor — was requested four times, by two addresses, both of which belong to account holders. Both attempts failed. Neither was hostile.

Here is the entire letter in one line:

That ratio is 8,115 to 1. By distinct addresses it is 1,687 to 2, or 843 to 1.

Nobody is attacking the lock. They are checking whether the key was left in the mat.

The corpus

Every figure in this letter comes from one of two sources, and they are never mixed. Where a claim depends on which source it came from, the source is named.

The second source is the important one, and its smallness is the finding. It is not a sample. It is the complete record of every credential decision this estate made in five months.

The three protected hosts:

The address column does not sum: 1,231 + 380 + 146 is 1,757, because addresses overlap between the three hosts — 154 duplicate memberships. The true distinct count is 1,603. This matters more than it looks: the estate's own host-taxonomy view reports the sum, so any figure derived from it overstates this population by about 10%.

What 18,517 requests to a login portal actually consist of

The method breakdown is the first thing that should have been suspicious:

A login attempt is a POST. There are 129 of them in seventy days. And of those 129:

Twenty of the 129 POSTs are looking for a GraphQL API. Six are looking for a Next.js server action. Four are the portal's own JavaScript talking to its own backend. Four are somebody typing a password.

The rest of the picture, by response:

Ninety percent of the traffic to the authentication surface was refused before authentication was ever a question.

Where the 18,517 actually came from

Here is the mechanism, and it explains most of the number.

Authelia runs as Traefik forward-auth. Any unauthenticated request to any protected host is answered with a redirect to the portal, carrying the original destination and the original method as query parameters:

GET /?rd=https%3A%2F%2Flsn-storage.shuffle-on.com%2Fwp-admin%2Findex.php&rm=GET

That request is logged against the auth host. The scanner never chose to visit the login portal. It was sent there.

More than half of the traffic to the "front door" is the shadow of scans aimed somewhere else entirely. The top redirect origins:

The two single busiest paths on the entire authentication surface are these:

/?rd=https%3A%2F%2Fhome.shuffle-on.com%2Fwp-admin%2Findex.php&rm=GET     244 hits, 1 address
/?rd=https%3A%2F%2Flsn-storage.shuffle-on.com%2Fwp-admin%2Findex.php&rm=GET   244 hits, 1 address

Four hundred and eighty-eight requests — 2.6% of all "attacks on the login portal" — are one address looking for a WordPress admin panel on two hosts that do not run WordPress, hammering wp-admin/index.php and being politely redirected to a login page it never read.

What they were looking for once they got there

Having been redirected to an authentication portal, a meaningful fraction of arrivals did what they were always going to do:

One hundred and forty-three addresses arrived at a single-sign-on portal and searched it, across 459 distinct path spellings, for a plaintext configuration file. Sixty-eight of them asked a login page for its Git repository configuration.

And then there is the group that actually looked at the door:

Two hundred and twenty-three clients rendered the login form. Two typed into it.

The lock's own record

Everything above is the edge log — what arrived. This section is the authentication server's own database, which records what it decided. Different source, longer window, and it is the one that settles the question.

2026-03-09 to 2026-08-08. Five months. 570 authentication events. 15 distinct addresses. 9 distinct usernames.

Forty-seven failures in five months. Here is every address that produced one:

Read the last column. Eight of the nine addresses that ever failed a login also hold a working account. The ninth failed three times on a single day in June, with one username, from a consumer connection — and it belongs to the same person as one of the addresses above, on a different network. Every failure in five months is an account holder failing to reach their own account.

There is not one hostile credential submission in five months of authentication logs. Not a failed one. Not a throttled one. Not a slow one. Zero.

Nine usernames exist. Nobody outside the household has ever guessed at one.

What is actually being attacked

The credential attack did not disappear. It moved. Classified by intent across the 70-day corpus:

Counting only paths that are unambiguously hunting a stored secret — .env in all its variants, .git/, wp-config, .aws/, .ssh/, id_rsa, .htpasswd:

Seven hundred and sixty-five distinct spellings. Not a list of services — a list of places a developer might have left a file:

.bak, .old, .save. Those are not deployment artifacts. Those are the filenames a human being creates by hand at two in the morning before changing something, and then forgets. The scanners are not modelling the software. They are modelling the operator's bad night.

Nine hundred and ten distinct addresses asked for /.git/config — a file which, if present, hands over the repository URL and frequently the credentials embedded in it. That is one request per address, from nearly a thousand independent sources, for the same file. It costs nothing and it works often enough.

Against that: four requests to the login form.

The classifier disagrees with me, and the classifier is wrong

This estate's own intent classifier labels six addresses auth_bruteforce. That is its most severe authentication verdict, and its registry entry makes an explicit promise about how it is derived:

"Repeated credential failures with ZERO successes. Confirmed by Authelia, not inferred."

Five of the six never submitted a credential at all. The label was inferred from request volume against a protected host — precisely what the registry text says it does not do.

Each one, checked individually:

18.118.155.138 — AS16509 Amazon, US. 965 requests across 621 distinct paths. Its path list is /sbin/.env, /lib/.env, /storage/.env, /portal/.env, /prestashop/.env, /.env.production, /var/www/html/.env. CrowdSec independently classified it crowdsecurity/http-sensitive-files. It made 4 POSTs, none to a credential endpoint. It is a .env scanner, and 538 of its 543 recorded auth-surface touches are Authelia intercepts of requests aimed elsewhere.

13.60.181.236 — AS16509 Amazon, SE. 262 requests, 258 distinct paths: /worker/.env, /mongodb/.env, /jenkins/.env, /cache/.env, /saas/.env, /kafka/.env, plus /preview/phpinfo.php. The pipeline's own assessment says "mainly hits protected_auth hosts" — which is true, and is exactly the artefact: it hit protected hosts, so Authelia bounced every request to the portal, so the portal is where the log recorded them. Zero credential submissions.

15.168.131.2 — AS16509 Amazon. 338 requests, same shape, 98 of 109 auth-surface touches are intercepts. Zero credential submissions.

185.177.72.58 — AS211590 Bucklog SARL, FR. The only one of the five with real POST volume: 34. But the targets are /api/auth, /api/auth/callback, /_next, /_rsc, /api, /graphql — a Next.js application probe walking a framework's conventional routes, not a login form. It is already autobanned by this estate for credential_harvest:24 and api_enum:3, plus crowdsecurity/CVE-2017-9841 (the PHPUnit RCE), and it is banned on the router. The entity graph resolves it to a RIPE-registered French hosting SARL. Threat score 46. Correctly hostile, wrongly labelled.

40.87.20.23 — AS8075 Microsoft, US. This one is the clearest, and it is worth stating precisely, because the mechanism is a genuine instrumentation failure rather than a judgement call. Its recorded paths are:

/?rd=https%3A%2F%2Flsn-wifi.shuffle-on.com%2F&rm=POST
/?rd=https%3A%2F%2Flsn-webtop.shuffle-on.com%2F&rm=POST
/?rd=https%3A%2F%2Flsn-ai.shuffle-on.com%2F&rm=GET
/?rd=https%3A%2F%2Flsn-ai-images.shuffle-on.com%2F&rm=POST

Those are Authelia's own redirect parameters. rm is the original request method, preserved by the authentication server so that it can replay the request after a successful login. The address touched 32 hosts and 12 paths; it is a subdomain sweep, already autobanned as vhost_enum:5.

The classifier read rm=POST — a string the defence wrote, describing a request that went somewhere else — as evidence of a POST to the authentication endpoint.

The defence manufactured the evidence that convicted the wrong crime.

The sixth address is the only one of the six that ever submitted a credential: three POSTs to /api/firstfactor on 2026-06-13, one username, zero successes. By the classifier's stated rule — repeated failures, zero successes, confirmed by Authelia — it is the only technically correct application of the label in the entire census.

It is also the estate's newest account holder, someone learning their way around the system, failing to log in to an account they were deliberately given. That is what the census's most severe authentication verdict found, in seventy days, out of 286,004 requests: a beginner, three times, on a Saturday. The address is redacted.

So the most severe authentication verdict this pipeline can issue was applied six times: five times to scanners that never touched a login form, and once — correctly by rule, and wrongly by any standard a human would recognise — to the estate's newest and least experienced legitimate user.

The inversion

The consequence is not academic, because these classifications feed the ban pipeline.

Both of those addresses belong to the same person — one account holder, on two of their connections, with thirty successful authentications against this estate between them. Both are sitting in an active blocklist on the router right now. The scenario that put the first one there reads web-threats/lsn-ai: probe_intent detected: someone using the AI service they hold an account for, exploring it fast enough to trip a rate heuristic.

That is what exploration looks like to a classifier built to find attackers. A new user clicking through everything, twice, is indistinguishable from a scanner if the only feature you measure is rate.

Meanwhile the address that made 965 requests across 621 paths looking for plaintext secrets, and which the same pipeline labelled with its most severe authentication verdict, has never been banned.

The instrument banned the users and left the scanner running. Stated plainly, because it is our instrument and nobody else's fault.

What this actually means

The reflex, in a small estate like this one, is to spend defensive effort on the login page: rate limits, ban thresholds, MFA nags, fail2ban rules, geo-blocking the portal. All of it is defending the least-attacked surface on the estate.

Nobody brute-forces a login they cannot fingerprint. There is no value in guessing at nine unknown usernames on an unbranded Authelia portal when 765 file-path spellings can be tried against every host on the internet at one request each, in parallel, at no cost, with a non-trivial hit rate. Credential harvesting has strictly better economics than credential guessing, and the traffic reflects that with an 8,115-to-1 margin.

Three consequences follow, and they are not intuitive:

1. Auth-surface volume is a bad signal, and here it is an actively misleading one. Fifty-two percent of the traffic to these three hosts is the echo of scans aimed at 28 other hostnames. Any alert, dashboard, or classifier that counts hits on the authentication host is counting the defence's own redirects and calling them attacks. That is how five .env scanners became brute-forcers.

2. The real perimeter is the file system, not the login form. Every .env, every .git directory, every wp-config.php.bak that reaches a web root is a bypass of authentication rather than an attack on it. The 1,687 addresses hunting them are not trying to get past the door; they are checking whether the door is load-bearing.

3. A quiet authentication log is evidence, and it should be read as such. 570 events, 15 addresses, 9 usernames, five months. That is not an absence of data. It is a complete record demonstrating that the credential surface of this estate has never been meaningfully engaged. The correct response is to stop hardening it further and move the effort to where the 32,460 requests are going.

There is a smaller observation folded inside the larger one, and it is the part worth keeping. In seventy days and 286,004 requests, exactly one party behaved the way a credential attacker is supposed to behave — repeated failures, no successes, one username, one sitting. It was a beginner learning to use a system they had been given an account on. Every model of the hostile user this estate has built was, in the end, only ever accurate about a person who belonged here.

What changes here

Concrete, in order of how much they matter:

Fix the auth_bruteforce classifier to match its own documentation. The label must require a confirmed credential submission — an auth_events row, or a POST to /api/firstfactor — and not request volume against a protected host. Every address carrying it today except one is mislabelled.

Exclude redirect-carrying requests from auth-surface intent scoring. A request whose path contains Authelia's rd=/rm= parameters is, by construction, traffic aimed at a different host. It is already parsed out into rd_target_host in the requests table; the classifier should attribute it to that host rather than to the portal. This is the same class of error as Letter E's forged X-Forwarded-For: the pipeline treating a value that describes a request as though it were the request.

Unban the account holder, and separate account-holder addresses from the autoban path entirely. An address that appears in auth_events with a successful authentication has proven it holds a credential — no attacker in this corpus ever has. That fact should suppress probe_intent autobans outright, or at minimum route them to review instead of to the router. Until it does, the people most likely to be banned by this estate are the people who have accounts on it.

Ban the .env fleet that is not banned. 18.118.155.138 and 13.60.181.236 between them made 1,227 requests across 671 distinct paths, 746 of those requests spread over 209 distinct secret-file spellings — and neither address is on any blocklist. The classifier spent its severity budget on the wrong addresses and, having done so, apparently spent the ban budget too.

Leave the login portal alone. No new rate limits, no new thresholds. There is nothing there to defend against.

Method and limits

Two sources, never mixed: the Traefik edge access log (2026-06-03 → 2026-08-11, 286,004 requests) and Authelia's authentication_logs (2026-03-09 → 2026-08-08, 570 events), synced independently into the same database. Where the two disagree in scale — Authelia records 47 failures while the edge log shows 4 credential POSTs — the explanation is window and semantics, not contradiction: the authentication log begins twelve weeks earlier and records the server's decisions, while the edge log records only the requests that arrived during its own retention. No figure in this letter combines them.

One detail worth stating because it nearly cost a claim: one of the four credential POSTs was logged by Traefik as HTTP 200. Authelia's front end is a single-page application; it returns 200 and renders the failure client-side. The pipeline's mask-correction pass records that request's effective_status as 401, which is what it actually was. Without that correction this letter would have reported one successful hostile login. There were none.

Addresses belonging to account holders are redacted throughout, along with their networks, countries, and any detail that would narrow them to a person — including the one address correctly classified as a brute-force attempt, which is a legitimate user who could not get into their own account. There are nine usernames on this estate and all of them belong to people who were invited. Hostile addresses are named in full; that asymmetry is deliberate.

Attribution of the named addresses comes from this estate's existing entity graph and enrichment (Team Cymru origin, CrowdSec decisions, Shodan InternetDB, the honeypot corpus), not from live probing. Nothing in this letter was produced by touching any of the addresses described.

Confidence: HIGH on the central claim — two independent sources, complete rather than sampled, agreeing that no hostile credential submission exists. Confidence: HIGH on the classifier fault, which is reproducible from the stored paths of the five addresses. Confidence: MEDIUM on the economic argument in What this actually means, which is an interpretation of one estate's traffic and may not generalise to a target where a login page is branded, indexed, and worth guessing at.

The Census, Letter I. Previous: Letter H — The Wildcard. The series counts what arrives at one small estate's edge and what the counting gets wrong.