Three Addresses in the Advisory Are One Machine. It Claims to Be Windows 7 and the Protocol Says It Is Samba.

We republish twenty-one indicators from joint advisory AA26-097A — free, confidence 90, no registration — for water operators who have no threat-intel budget. We have done that since 27 July.

Today we looked at what is actually answering on those addresses. We had never done it. As far as we can tell, nor had anyone else.

Every claim below is checkable with a URL you can paste into a browser. Our enrichment endpoint is public and needs no key:

analytics.dugganusa.com/api/v1/threat-intel/enrichment?ip=[88.80.150.200](https://analytics.dugganusa.com/stix/register?ref=ioc-click&q=88.80.150.200)

Swap the address for any indicator in this post and you get the same AbuseIPDB and VirusTotal data we worked from. Agents can reach the same corpus through our MCP server at analytics.dugganusa.com/api/v1/mcp — the enrich-ioc tool takes any IP, domain, URL or hash.

The list is not one thing

Start here, because it reframes everything else (see diagram 1).

Grouped by what actually links them, twenty-one indicators separate into four unrelated populations. They share no operator fingerprint. The only thing they have in common is the page they were printed on.

That matters because every consumer downstream — us included — treats an address list as a single adversary estate. It isn't one, and a hit on one address tells you very little about the others.

Four addresses, one SSH host key

The four WorldStream entries all present the identical SSH host key:

1b:42:46:fb:e8:a9:50:26:c2:ca:37:93:6a:55:7b:51

Host keys are generated per install from randomness. Four hosts sharing one means one image, cloned. That is a far harder linkage than a shared ASN or a similar port profile — it is the strongest correlation in the whole set.

They also share byte-identical TLS certificates on ports 21 and 25, both CN=main-ultra.vps, issued 44 seconds apart in one provisioning run.

Then look one layer up (see diagram 2).

The port-443 certificates are different on every host and short-lived: static.vps-vids.com, cosplay-porn.cam, vpsvps.cam, dev.swapps.app. Add nginx and SeaweedFS object storage.

Identical below, different above. That is the signature of shared hosting — the platform owns the SSH key and the internal certs, the tenants own the web certificates. These are multi-tenant VPS nodes, not dedicated attack boxes.

Which resolves something we got wrong twice. We had a theory that the gaps in the numbering were rotation-pool siblings — burned hosts listed, quiet neighbours still live. We tested it two ways and got null both times. The reason is now obvious: there were never siblings. It is a hosting provider's address range, and listed and unlisted nodes alike are just customers. Querying the shared certificate surfaces [175.110.121.38](https://analytics.dugganusa.com/stix/register?ref=ioc-click&q=175.110.121.38) and .40 as estate members nobody listed — and .38 we had never even tested, because we only looked at gaps between listed addresses and never below the lowest. That was sloppy of us.

Three addresses, one machine

The Redcluster three — [88.80.150.199](https://analytics.dugganusa.com/stix/register?ref=ioc-click&q=88.80.150.199), .200, .202 — all report the machine name WIN-UIFT12B70G4. .200 gives it up through its RDP handshake; .199 and .202 leak it through the RPC endpoint mapper as \\WIN-UIFT12B70G4\PIPE\InitShutdown.

WIN- names are what Windows generates when nobody supplies one. They are random, and exactly three hosts on the entire internet report this one. Independent installs do not collide — the namespace is roughly 36¹¹.

Both web servers return the default IIS 7.5 page with the same ETag and the same Last-Modified, to the second. The MSMQ banner on port 1801 is byte-identical on both, padded with several hundred literal `Z` characters, which no real message queue does.

One image, three addresses. A defender blocking all three is blocking one thing.

The protocol contradicts the banner

Then the SMB, which is where it stops being a curiosity (see diagram 3).

The banner says Windows 7 Ultimate 7601 Service Pack 1. The same session returns NativeOS Unix, NativeLanMan Samba 3.0.28a.

Banner strings are cheap to fake, so we went to the capability bitmask — not a string, but what the implementation advertises about its own protocol support, which the rest of the conversation depends on.

0x0080f3fd: `CAP_UNIX` is set — the UNIX extensions bit, which Windows never sets. `CAP_EXTENDED_SECURITY` is not set — which Windows 7 always sets.

Mutually exclusive, in one handshake. This is Samba, or something emulating it, wearing a Windows label. Samba 3.0.28a specifically is the fingerprint carried by Metasploitable and copied into a great many honeypot configurations.

Also, since people keep asking whether the timezone points anywhere interesting: ServerTimeZone is 0. UTC+0, unconfigured. Not UTC+8, not UTC+9. And an unconfigured emulator reports zero regardless, so it is weak evidence in every direction. We checked because it cost nothing, not because it settled anything.

Why these protocols give it all up

Worth saying plainly, because it is the reusable part: SMB, RPC and MSMQ are enormously talkative. They were designed for a trusted LAN in the 1990s, where announcing your OS, machine name, workgroup, named pipes and capability set to anyone who asked was helpful. That design never changed. It just got exposed to the internet.

Every fact in this post came from a service voluntarily describing itself. We ran no exploit and sent no crafted packet — a scanner asked politely and the hosts answered in detail. The RPC endpoint mapper handed over an internal machine name through a named-pipe reference. SMB handed over its OS, dialect, capabilities and clock.

That porousness cuts both ways, which is the useful bit. It is why an exposed Windows box near your plant network is a liability before anyone attacks it, and it is why a poorly-built emulator cannot keep its story straight under a free scan.

The certificate is younger than the advisory

Now the operational part (see diagram 4).

[88.80.150.200](https://analytics.dugganusa.com/stix/register?ref=ioc-click&q=88.80.150.200)'s self-signed RDP certificate was issued 3 July 2026. The advisory naming that address published 7 April 2026. Eighty-seven days apart. Whatever answers there now was built long after it was listed.

The mundane explanation is almost certainly right: address used, burned, listed, recycled by the provider, something else moved in. VPS addresses churn constantly and nobody did anything wrong.

That is exactly the problem. An indicator list is a photograph and everything downstream treats it as a live feed. We are downstream — we republished these twenty-one at confidence 90 for Minnesota water operators and had never once looked at what was answering on them. That is our failure to name, not CISA's. Six agencies published what they saw when they saw it. Keeping it current is the consumer's job, and we are the consumer.

About the sophistication

Since "nation-state infrastructure" is doing heavy lifting in the coverage of this campaign: three addresses in a six-agency advisory currently present as one un-sysprepped Windows image with a factory-default machine name, an untouched 2019 IIS welcome page, SMB version 1, a message-queue banner padded with hundreds of the letter Z, and an OS claim its own capability bitmask contradicts. Four more are shared VPS nodes hosting adult-video sites.

Either the operator was sloppy, or the list has rotted. We think mostly the second. But the genuinely sophisticated part of this campaign was never the infrastructure — it was noticing that a small water utility leaves a controller on the internet and nobody watches it. That takes no craft at all, which is the part that should bother people.

What a water operator does tonight

None of this changes the work.

Block the twenty-one. Still correct, still free. No treatment plant needs to reach a video CDN, an adult-content host, or a recycled Bulgarian VPS. Blocking a stale address costs nothing.

But do not read a hit as a catch. If one of these lights up in your SIEM, you may have found a honeypot or a hosting customer who inherited a burned address. Investigate, do not conclude.

Check exposure from outside, not from the diagram. Whether any PLC or HMI in your plant answers from the internet is a question you settle with a scan, not an architecture drawing.

Try running the plant on manual on a scheduled morning, with the person who would actually have to do it, and write down what breaks.

Know which physical cable is the cut point between the control network and everything else.

And if you run Windows anywhere near that network: SMBv1 off, RDP off the internet, and accept that anything left listening will describe itself in detail to anyone who asks. That is not a vulnerability to patch. That is what the protocol is.

Confidence capped at 95%. Every observation is passive third-party scan data (Shodan, AbuseIPDB, VirusTotal) read on 31 July, plus protocol decoding of banners it captured — we sent nothing to any of these hosts. Point-in-time and designed to expire. We do not claim to know what was on these addresses in April, we do not claim tenancy on the shared hosting can be proven from outside, and we do not claim the operator is unsophisticated — only that what is answering today does not match the label.

---

Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register