Record: peeking inside the largest assigned blocks — 2026-09-12

What was asked

Phase 3 asked only the addresses that no operator holds, so a service hiding inside an operator’s own block was never probed. The owner asked for a minimally intrusive way to look inside a few large assigned blocks, and then supplied the search heuristic:

“Humans tend to allocate IP addresses from low to high. So a good hiding spot would be the high end of the block / subnet. For IP address of the form A.B.C.D - limit D to prime values above 128, and scan downwards, and for B.C scan prime values downward.”

The four blocks are the ones chosen on 2026-09-12 and approved by the owner:

The method, and its order

1. Paper census first — registry objects, routing, RPKI, reachability. No packet goes to the target.
2. Third-party corpus second — Shodan’s free InternetDB, which reports what someone else has already seen. No packet goes to the target.
3. One HTTP question last, to a strictly limited number of addresses, and only then. The question is the same one phase 3 asked: GET /, one connection, no parameters, no authentication.

The tool is sources/ip_block_peek.py, invoked through scripts/08-block-peek.sh and make peek. It writes its work product, reuses an existing one unless --refresh is passed, and records the rule it applied in the output. tests/12-block-peek.sh pins the ordering (highest first, B and C prime, D prime above 128 and descending) and proves the passive and active steps and the reuse rule against fixtures and a local server.

The paper census: two of the four have no route at the top

Two things are worth stating plainly.

• The 59.192.0.0/10 block and the 43.0.0.0/9 block have no route at the top, and no /24 under the control or the blob is announced as a more-specific either (RIPEstat’s BGP state holds no exact-prefix announcement for any of the four top /24s). Space that is not announced cannot be reached from the internet, so the high end of those two blocks is not a hiding place for a reachable service — whatever sits there is invisible outbound as well, unless it is behind something else.
• The top of the 151.3.0.0 blob is announced by a different operator than the delegation names. The registry record carries the maintainer MNT-IUNET; the route is Wind Tre’s. That is a registry/routing mismatch of the ordinary legacy kind, but it is the sort of thing worth flagging.

The passive census: 256 candidates, one known

Sixty-four candidates per block, 256 in all, drawn top-down by the owner’s rule, asked of Shodan’s InternetDB.

Exactly one had a record: 151.79.241.149, position 42 of the 151.3 block, with port 443 open and tagged self-signed. Every other address in the sample is unknown to the third party — no ports, no hostnames, no tags. That is the third-party view of the high end of four large blocks, and it is almost entirely empty.

The active pass: 44 questions, and one answer

Then one TLS handshake and one HTTPS request to the address the corpus had flagged, which is the only live thing this pass found.

The finding: an internet-exposed Zyxel firewall

151.79.241.149 serves, on port 443, the factory self-signed certificate of a Zyxel USG FLEX 100:

Three independent things agree on what it is:

1. The certificate names the model — USG FLEX 100 — and its own serial string.
2. D8ECE571942B is a MAC address whose OUI, D8-EC-E5, the local IEEE registry lists as Zyxel Communications Corporation. Zyxel’s factory certificate format is exactly this.
3. An HTTPS request to the address returns 200 with appliance-style Cache-Control: no-cache, private headers and an HTML login shell.

So the high-end search found an ordinary security exposure: a firewall’s management interface reachable from the open internet, still presenting the certificate it shipped with in 2021. Its neighbours are silent on 443 — .148 refuses port 80 and .150 says nothing — so the appliance is an island of one live host in an otherwise quiet /24, which is the same shape as the project’s strongest phase 4 hint, at a different scale.

No authentication was attempted, and none will be. This is an observation about a third party’s device, not a target. It is worth recording partly because it is what the method is for, and partly as a warning about a device somebody should fix. Whether to tell anyone is an open question for the owner, alongside the Site B abuse-report question.

What this says about the hiding-spot hypothesis

• The high end of the four chosen blocks is quiet. 32 of 32 addresses at the top said nothing on port 80, and the third-party corpus knows of one host in 256. If a rogue service is hiding at the top of one of these blocks, it is not answering an HTTP question and no third party has seen it.
• Reachability narrows where it could hide. Two of the four blocks have no route at the top at all. A hidden service needs addressing; unannounced space cannot serve one.
• The method works, and it is cheap. The paper census and the corpus together cost zero packets to the targets and surfaced the one address worth asking. The owner’s heuristic was decisive in where to point it: the flagged host sits at position 42 in a 64-address top-down sample of a 5,046,272-address blob. A uniform random sample of that block would have needed tens of thousands of addresses to reach the same /24.
• But the finding is ordinary. What the heuristic surfaced is an exposed appliance, not a hidden service. That is the honest result: no evidence of concealment in the sampled space, and one security exposure nobody asked about.

The intrusion ledger

No scan, no port sweep, no credential, no authentication attempt, and no request with a parameter of any kind. Every request carried the project’s own user agent, which names the project and the way to reach its owner.

What would change this reading

• An answer at the top of a block from an address the corpus does not know.
• A more-specific announcement inside one of these blocks, from an origin the delegation does not name — the classic rogue signature, and the thing the paper census searched for and did not find.
• A second sample, in different blocks, finding the same class of device or the same kind of quiet top end.
• For the Zyxel specifically: the operator replacing the factory certificate, or the console disappearing from the open internet.

Commits

• (this record)