When Proxy Infrastructure Monitors Itself: An ASOCKS → 100UP Pivot via Exposed Prometheus

TL;DR

A Shodan search for asocks returns 15 hosts. Fourteen of them expose Prometheus node_exporter on TCP/9100, almost all on WorldStream B.V. in the Netherlands.

The match is not a loose keyword hit. It comes from the operator-set nodename published by node_uname_info. In other words, the infrastructure identifies itself through its own telemetry.

Those exporters leak a shared node_exporter build fingerprint:

branch: HEAD

goversion: go1.25.3

revision: 654f19dee6a0c41de78a8d6d870e8c742cdb43b9

That combination points to a from-source build pinned to a specific commit, not an official release.

Pivoting on:

revision:654f19dee6a0c41de78a8d6d870e8c742cdb43b9 AND Fujitsu

returns 160 hosts, dominated by Hetzner with a long WorldStream tail.

Inside that cluster is 138.201.196.166, whose nodename is 100up.ru — a separately branded operator carrying the identical build artifact.

The ASOCKS hosts name themselves with the pattern:

Lpm-unlim-asocks-

The 100UP host names itself:

100up.ru

Same build artifact, different brands.

The strongest supported conclusion is reuse of an identical self-compiled node_exporter build artifact across separate operators. Shared provisioning infrastructure is a leading hypothesis, but the available telemetry does not support attributing both brands to a single operator.

Background

ASOCKS is a residential-proxy seller that has appeared repeatedly in threat intelligence reporting. HUMAN's Satori team tied it to the PROXYLIB campaign in 2024, and on 28 — 29 May 2026 Dutch authorities and NCSC-NL seized roughly 200 ASOCKS command servers.

The public site remained up.

The point of this note is not to relitigate the takedown. The point is to map what remains visible and show how exposed monitoring infrastructure can reveal clustering signals that are stronger than the proxy infrastructure itself.

Analyst Note: What Drove This

The trigger was the orphaned-bot problem.

Public reporting has placed the ASOCKS ecosystem in the tens of millions of compromised devices, including routers, mobile devices, and IoT systems. Seizing command-and-control infrastructure does not remediate those devices; it temporarily removes coordination.

The obvious question is where that control re-aggregates.

The residential-proxy market has already demonstrated the pattern. After the IPIDEA disruption in January 2026, Bitsight observed device counts at successor infrastructure returning to pre-disruption levels within a day.

Demand migrates. It does not disappear.

Similar patterns have appeared across multiple disruption campaigns. Operations such as ASOCKS, IPIDEA, FrostArmada, and First VPN Service differ in purpose, operators, and targeting, yet draw from the same broad pool of compromised consumer devices and abuse-tolerant infrastructure.

The point is not that these operations are linked. The point is that compromised-device ecosystems routinely outlive individual takedowns.

Mapping the infrastructure and provisioning artifacts that survive those disruptions provides visibility into where future proxy capacity may reappear.

Step 1 — The Seed: A Shodan Search for asocks

The asocks search returns 15 results:

14 in the Netherlands

1 in Russia

14 on port 9100

1 on port 5001

The organizations are overwhelmingly WorldStream B.V., with a single Russian outlier on NewLines Ltd.

Every WorldStream hit is a Prometheus node_exporter carrying the same build revision.

The seed host is:

89.39.105.78

Reverse DNS:

89-39-105-78.hosted-by-worldstream.net

Provider:

WorldStream B.V. / AS49981 / Netherlands

The reason these hosts answer to asocks at all is the nodename.

node_exporter republishes the OS hostname in:

node_uname_info{nodename=…}

The operator named these boxes with an ASOCKS-flavored string. That makes the ASOCKS association an artifact stamped into the operator's own monitoring, not an incidental keyword.

It also becomes a fleet selector.

The lone Russian result, 109.69.17.247, is a different animal. It presents an HTTP/200 Werkzeug/Python app, not a node_exporter. I am flagging it here but not folding it into the fleet without separate evidence.

Step 2 — The Exposed node_exporter

node_exporter on TCP/9100 volunteers system telemetry by design.

The seed host's /metrics exposes the build identity:

branch: HEAD

goarch: amd64

goos: linux

goversion: go1.25.3

revision: 654f19dee6a0c41de78a8d6d870e8c742cdb43b9

The build is the tell.

Official node_exporter releases typically carry semantic release information. Here, branch: HEAD with no release version strongly suggests someone built it directly from a git checkout.

That pins the fleet to one exact source commit — a tighter selector than a normal version number. The go1.25.3 toolchain narrows the build window further.

The seed also reports a Fujitsu identity in node_dmi_info.

Note on the Hardware

The Fujitsu D-series mainboards behind these DMI strings are common in low-cost dedicated-server environments.

That matters, but only in a limited way.

"Fujitsu" is a poor per-operator fingerprint. It mostly tells us about the hosting tier: budget dedicated hardware, often older-generation boxes, where cost and abuse tolerance matter more than current hardware.

So I treat Fujitsu as a tier signal, not an actor fingerprint.

Useful context. Weak attribution.

Step 3 — The Pivot

Querying the shared build revision plus Fujitsu:

revision:654f19dee6a0c41de78a8d6d870e8c742cdb43b9 AND Fujitsu

expands the seed into 160 hosts.

Distribution:

Countries:

Germany: 87

Finland: 39

Netherlands: 29

Japan: 2

Switzerland: 1

Organizations:

Hetzner Online GmbH: 121

WorldStream B.V.: 26

Hetzner Online AG: 5

RootLayer Web Services: 2

ABB Asea Brown Boveri: 1

Ports:

9100: 158

9110: 1

9998: 1

Two things stand out.

First, the pivot surfaces more WorldStream hosts than the asocks keyword did. The brand keyword found 12 WorldStream hits. The build artifact found 26.

Second, the center of mass shifts to Hetzner: 126 hosts across Germany and Finland.

That does not make Hetzner suspicious by itself. AS24940 is enormous. Provider alone proves nothing.

The revision is the claim.

The provider is context.

Step 4 — The Find: 100up.ru on Hetzner

Among the 160 hosts is:

138.201.196.166

Provider:

Hetzner Online GmbH / AS24940 / Germany

It carries the same node_exporter revision:

654f19dee6a0c41de78a8d6d870e8c742cdb43b9

But its node_uname_info nodename is:

100up.ru

This is the decisive comparison.

The ASOCKS hosts name themselves:

Lpm-unlim-asocks-

The Hetzner host names itself:

100up.ru

Same build artifact.

Different nodename scheme.

Different brand.

That cuts cleanly.

The evidence does not support "ASOCKS and 100UP are the same operator."

The evidence supports a narrower and more defensible conclusion:

ASOCKS and 100UP appear to have deployed the same self-compiled node_exporter build artifact.

That points toward a shared provisioning artifact, shared base image, copied deployment playbook, reseller-managed environment, or some other common upstream layer.

It does not prove common ownership.

What This Actually Shows

The binding evidence is a shared, self-compiled node_exporter commit:

654f19dee6a0c41de78a8d6d870e8c742cdb43b9

It appears across at least two independently branded proxy operations on two different budget providers:

ASOCKS on WorldStream in the Netherlands.

100UP on Hetzner in Germany.

Each operator stamps its own identity into node_uname_info.

ASOCKS:

Lpm-unlim-asocks-

100UP:

100up.ru

That means the operators are distinct, but the plumbing underneath them is not fully independent.

The strongest supported conclusion is reuse of an identical self-compiled node_exporter build artifact across multiple proxy operators.

Shared provisioning infrastructure, a common base image, a copied deployment playbook, or a reseller-managed environment remain plausible explanations, but the available telemetry does not support attributing the infrastructure to a single operator.

Operators harden their exit infrastructure and leave the supervisory plane exposed.

The same telemetry meant to keep the fleet healthy hands analysts:

The operator's self-chosen name

The exact build artifact used to connect otherwise unrelated infrastructure

A path to identify additional fleet members beyond simple brand keywords

A brand search found 15.

The build artifact found 160.

The nodename tells you which are ASOCKS, which are 100UP, and which are neither.

Why Defenders Should Care

Defenders often focus on proxy exit nodes while overlooking the operational infrastructure that manages them.

Exposed monitoring systems can reveal:

Fleet naming conventions

Build and deployment fingerprints

Provisioning artifacts

Relationships between otherwise distinct proxy operators

In this case, the monitoring layer exposed stronger clustering signals than the proxy infrastructure itself.

The operator's own telemetry provided both the fleet identifier and the build artifact used to connect infrastructure across multiple hosting providers and brands.