The Nexus 5: Nine Hundred and Sixty-Four Addresses Wearing One Dead Phone

The Census counts things. This letter is about a population built so that counting fails.

Between 2026-06-19 and 2026-08-04, 964 distinct addresses across 470 distinct autonomous systems made 1,204 requests to this estate. Eight hundred and forty-four of them made exactly one request and were never seen again.

Every single one of those 1,204 requests carried the same User-Agent string. Not a similar one. The same one, byte for byte:

Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/65.0.3325.181 Mobile Safari/537.36

That is a Google Nexus 5 — a phone released in October 2013 and discontinued in March 2015 — running Android 6.0 Marshmallow, browsing with Chrome 65, which shipped in March 2018.

Nine hundred and sixty-four addresses, in eighty countries, on four hundred and seventy separate networks, all claiming to be the same eleven-year-old phone that has not received a security update since the year Chrome 65 was current.

They came to read the dossiers. They took 755 distinct pages of the published threat-intelligence corpus.

Why this is hard to count

Every defensive mechanism on this estate takes the IP address as its unit of analysis. Rate limits count requests per address. CrowdSec scenarios count events per address. The ban pipeline bans an address. The intent classifier profiles an address.

Here is the distribution of requests per address in this population:

Nearly eighty-eight percent of this population made one request. There is no rate to limit. There is no pattern within an address to profile, because there is nothing within an address — one request contains no behaviour, only a fact.

And the address space is not reusable as a signal either:

Four hundred and seventy networks. The largest single contributor supplied eight addresses. Blocking an ASN would remove, on average, two addresses from a pool that clearly has thousands more.

Nor does geography help:

Eighty countries in all. This is a residential proxy pool — addresses rented by the request, drawn from consumer connections across the world, which is precisely what you buy when you want one request from one address and never the same address twice.

Against a per-IP defence, this population is not stealthy. It is invisible by construction. There is no threshold low enough to catch a single request that is also high enough to permit an ordinary reader.

And yet

They all wear the same dead phone.

The entire operation — 964 addresses, 470 networks, seven weeks, 1,204 requests — collapses to a single fact you can express in one string. The proxy pool is enormous and the tooling behind it is one script with one hardcoded header.

That string is not an arbitrary choice. Nexus 5 Build/MRA58N with Chrome/65.0.3325.181 is the stock mobile-emulation User-Agent that shipped as a default in headless-browser automation tooling of that era. It is what you get when you enable phone emulation and never change the default. It has been copied into scraping tutorials, StackOverflow answers, and template repositories for years.

Nobody chose to look like a Nexus 5. Somebody chose not to choose, and the default has been propagating ever since.

You can watch other people inherit the same template. Searching the corpus for the Nexus 5 Build/MRA58N fragment rather than the exact string finds three further variants, all trivial in volume:

The third row is my favourite thing in this corpus. Someone took the same stale template, updated the Chrome version to a current one to make it look less obviously ancient — and mistyped AppleWebKit/537.36 as AppleWebKit/5d7.36. A token that has been identical in every browser User-Agent for fifteen years, fat-fingered by hand.

Those three variants are ten requests from nine addresses and are almost certainly unrelated parties using the same copied string. They are excluded from every figure in this letter, which uses exact-match on the first row only.

What gives it away

Three things, none of which is volume.

First, there is no referer. Not once.

Every request arrived as though the client had typed the URL directly, 1,204 times in a row, across 1,069 distinct paths. Real readers arrive from somewhere — a search engine, a link, another page on the site. This population arrives from nowhere, always, because it is working from a list.

Second, it does not load the page. On www.shuffle-on.com — 813 requests across 748 addresses — it fetched zero stylesheets, scripts, images, or fonts. A browser rendering a dossier page pulls /site-stats.js and a favicon at minimum. This fetched the HTML and stopped.

Third — and this is the one that settles it — the exception proves it. On lsn.sonatural.life, a WordPress site, the same population did fetch 85 static files: theme stylesheets, fonts, uploaded images.

At first glance that looks browser-like. It is the opposite, and the proof is in the first table: those 85 subresource requests also carried no referer.

When a browser loads a page and that page references a stylesheet, the browser fetches the stylesheet with Referer: <the page that referenced it>. That is not optional behaviour; it is what makes a subresource a subresource. A fetch for /wp-content/themes/legacy-news/style.css with no referer at all did not come from a browser rendering a page. It came from something that parsed the HTML, extracted the asset URLs, and requested them as fresh top-level fetches.

So the difference between the two hosts is not two different clients. It is one client whose HTML parser follows asset links, meeting a WordPress theme that references a great many of them and a static site that references almost none.

What they took

755 distinct /threat-intel/ paths. Against a published corpus of roughly eight hundred pages, that is materially the whole thing — the dossiers, the series, the findings.

The last row is worth a moment. lsn-pihole.shuffle-on.com does not exist. It is one of the 324 invented hostnames counted in Letter H — in fact the second most-guessed of them, with 3,504 hits from 223 addresses across that letter's corpus. This population tried it too, once. A corpus harvester has no need of a subdomain wordlist; something in this toolchain carries one anyway.

The requests were not distributed evenly. They arrive in waves:

Roughly every ten days, a burst — and each burst uses a fresh set of addresses. On 2026-08-03, 268 addresses made 307 requests: 1.15 requests each. That is a rented pool being drawn down for a job and released.

And it worked. The estate served them:

131.7 MB delivered, nine failures. There was never a moment at which this estate declined to answer, because from any single address there was never anything to decline — one request for one public page, indistinguishable from a person following a link. The operation did not evade a defence. It arranged for no defence to have grounds to fire.

The instrument saw half of them

This estate's intent classifier labels this population distributed_scraper, and its registry entry describes the problem accurately:

"A residential-proxy cohort: many ASNs, ~one request per address, no static assets and no referer. Invisible to per-IP rules by construction."

That is a correct description. The classifier knows what it is looking at. It nonetheless found 505 of the 964 addresses:

Fifty-two percent. Four hundred and fifty-nine addresses, sending 645 requests, wearing the identical User-Agent, carrying no referer, arriving in the same waves, went through this estate unlabelled.

The reason is not a bug. It is the same structural fact the population was built to exploit. The classifier is a per-address profiler: it accumulates behaviour against an address and decides what that address is. An address that makes one request has no accumulated behaviour, so it falls below every threshold the classifier has — including the threshold for the category that exists specifically to describe it.

To be classified as invisible-by-construction, an address had to be visible enough to classify.

That is the fourth time this series has caught its own instrument, and it is a different failure from the previous three:

The first three are the same mistake in different clothes: reading a value that describes a request as though it were the request. This one is structural. Nothing was forged and nothing was misread. The pipeline asked the right questions of the wrong object.

What actually identifies them

The signal that works is the one that does not live on any single address.

A per-address view of this population sees 964 nearly-empty observations. A per-string view sees one operation. The User-Agent is shared by every member; the absent referer is shared by every member; the arrival waves are shared by every member. Group by any of those and the population resolves instantly — 1,204 requests, one actor, seven weeks.

This is a general point and it is worth stating plainly, because it is the most useful thing in this letter. When an adversary distributes across addresses, the address stops being the entity. Continuing to profile addresses is not merely ineffective — it produces a confident, well-populated, entirely misleading picture in which 844 separate one-request "visitors" are indistinguishable from 844 curious humans.

The correct unit here is the request fingerprint: the tuple of User-Agent, referer presence, requested-path shape, and arrival window. Against that unit, this population is not stealthy at all. It is one of the loudest things in the corpus.

What this is, and what it is not

It is a scraping operation harvesting a published corpus. That is worth being unexcited about in the right way.

Everything they took is public. The dossiers are published deliberately, the methodology is published deliberately, and Letter I made the point that nothing here goes behind a paywall. Someone taking 755 pages of it has taken 755 pages of something that was placed on the open internet to be read. There is no breach here and no loss.

What is notable is the manner. A reader who wanted the corpus could have taken it from one address at a polite rate, and this estate would have served it without complaint — Letter C documented four crawlers doing exactly that, one of which has taken 4,744 distinct URLs, and none of them were impeded. Instead this operation spent money on a residential proxy pool to take the same public documents while defeating attribution.

That choice tells you something. You do not rent 964 residential addresses to read a website that would have let you read it. You rent them because your access pattern is one you do not want associated with you, or because your tooling is built for targets that would block you and it treats every target the same way.

I cannot distinguish those two from the edge log, and I am not going to guess. The honest reading is: this is commodity harvesting infrastructure applied indiscriminately, and this estate is one of many sites it swept.

The one detail that argues mildly against pure indifference is the single request for lsn-pihole.shuffle-on.com. That is not a generic guess — it is this estate's naming convention applied to a plausible self-hosted service, the exact behaviour Letter H documented across 324 invented names. A corpus harvester does not need a subdomain wordlist. Something in this toolchain does more than read.

What changes here

Add a request-fingerprint dimension to the classifier. The pipeline should group by (user_agent, referer_present, arrival_window) in addition to grouping by address, and emit a cohort identity when many addresses share a fingerprint within a window. This would have caught all 964 rather than 505, and it needs no new data — every field is already in the requests table.

Stop reporting one-request addresses as distinct visitors. Any figure in this estate's reporting that counts distinct addresses is inflated by this population and others like it. The 844 single-request addresses here are one actor; counted naively they are 844 data points in every "unique addresses" statistic the estate publishes. Letter I already found a 10% inflation from a different cause — summed per-host distincts. This is the same class of error at a larger scale.

Do not ban them. Banning 964 residential addresses would block real people who happen to be renting-out or sharing those connections, would not inconvenience the operator for more than the cost of the next address, and would achieve nothing — they are reading public pages at a rate of one request each. The defence against this population is to measure it correctly, not to block it.

Treat the shared default as the durable identifier. The Nexus 5 string is worth adding to the estate's fingerprint catalogue precisely because it is a lazy default rather than a deliberate disguise. Deliberate disguises rotate. Defaults persist for years, because the person who did not change it the first time will not change it the next time either.

Method and limits

Single source: the Traefik edge access log, corpus 2026-06-03 → 2026-08-11. This population is defined by an exact-match on the User-Agent string Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Mobile Safari/537.36, which yields 964 distinct addresses and 1,204 requests between 2026-06-19 and 2026-08-04.

That definition is the letter's main limitation, and it cuts in a specific direction. Selecting on a shared string guarantees the resulting group shares that string, so "they all wear one User-Agent" is true by construction and is not itself evidence of a single operator. The evidence for one operator is what the group turned out to share beyond the selection criterion: zero referers in 1,204 requests, the same absence of static-asset fetching on the same host, synchronised arrival waves, and a request-per-address distribution that no organic population produces. Any of those could occur alone; together, in a group selected only on a header, they do not occur by chance.

The converse limit is real and unmeasured: this method finds only the members that kept the default. If the same operator runs a second pool with a rotated User-Agent, that pool is not in these figures and I have no way to find it from this data.

Attribution stops at "one operation." No individual, company, or country is identified, and the proxy addresses tell you about the proxy vendor's supply, not about the customer — VN and US leading the country table reflects where residential exit nodes are cheap, not where anyone is sitting. Nothing in this letter was produced by contacting, probing, or fetching from any of the addresses described.

The claim that the corpus was "materially" fully harvested compares 755 distinct /threat-intel/ paths against a published corpus of roughly eight hundred pages; the exact denominator moves as pages are published, so the figure is a proportion of that order rather than a precise coverage rate.

Confidence: HIGH that this is one operation rather than many — the combination of shared string, universal absent referer, and synchronised waves is not reproducible by coincidence. Confidence: HIGH on the classifier gap, which is a direct count against the stored labels. Confidence: HIGH that the population is a residential proxy pool, from the 470-ASN spread at 2.05 addresses per network. Confidence: LOW on motive; the letter offers two readings and declines to choose.

The Census, Letter K. Previous: Letter J — The Hits We Advertised. The series counts what arrives at one small estate's edge and what the counting gets wrong.