Threat Research · Fleet Telemetry · Part 1 of 2

One Source, Twenty Decoys

One automated attacker touched our fake Linux servers, our fake hospital, and our fake water plant in a single sweep. To the machines doing the scanning, there is no line between IT and OT.

Deception Check | July 2026 | Fleet telemetry | ~9,600 distinct sources analyzed
216 crossed the IT/OT line | Part 1 of 2

The short version We watched a single source address walk across more than twenty of our decoys in one pass. Not one type of decoy: a fake Linux server, a fake enterprise VPN, a fake hospital imaging system, a fake Windows domain, and a fake water-treatment plant. In a short window the same IP spoke SSH, RDP, FTP, SMB, and HTTP to the enterprise boxes, then Modbus and ATG to the industrial ones. To that attacker there was no such thing as an IT target or an OT target, just a list of open ports. And it was not alone: in the same window 216 different source addresses crossed that same line, touching both an ordinary IT service and an industrial protocol on our fleet.

~9,600

distinct sources in the window

216

crossed IT and OT (2.3%)

20+

decoys hit by the widest single source

What we saw

Our fleet runs decoys that look like real systems, side by side, in cities around the world. Some look like Linux servers and VPN appliances. Some look like PLCs, RTUs, and building controllers. Every one of them logs who knocks and what they say. When we lined up two weeks of traffic and asked a simple question, which single sources touched the most different decoys, one external address stood out. Redacted here as 3.129.x.x, an Amazon-hosted node in the US-East region, it reached more than twenty of our decoys across five regions in one loose sweep. The part that matters is that the protocols it used were not from one world.

To the servers it spoke SSH, RDP, FTP, SMB, and HTTP, ordinary remote-access and web probing. To the industrial decoys it spoke Modbus, ATG, and a PLC's own web interface, the languages of controllers and fuel-tank gauges. Same source, same sweep, a fake water plant and a fake login server checked off the same list.

One automated source spoke IT protocols to fake servers and OT protocols to a fake plant in a single sweep, crossing the IT/OT wall — One source reached both sides of a boundary most security programs treat as a wall. The wall is an org chart, not a control.

To the machine, there is no IT/OT divide

Here is the uncomfortable part for anyone who runs critical infrastructure. The reconnaissance that hits your industrial edge is, more often than not, the exact same automation that hits your office network. It is not a separate, sophisticated, OT-specialist adversary tiptoeing toward your plant. It is the broad, tireless, indiscriminate scanning of the whole internet, and your Modbus port is just another line item.

That cuts both ways. The good news: most of what reaches an exposed PLC is opportunistic, not a targeted nation-state operation. The bad news: opportunistic is enough. The same bot that brute-forces a Linux box will happily fingerprint a water-treatment controller if the port answers, and automation never gets bored, never goes home, and never decides your small utility is not worth the trouble.

The internet's background scanning does not respect the IT/OT boundary. If your industrial gear is reachable, it is already in the same sweeps as everything else.

We are not claiming these were coordinated attacks on critical infrastructure. We are claiming something quieter and, honestly, more useful to know, and we are careful to keep those two claims separate.

It was not one bot

Zoom out from the single source and the pattern holds. Across the window we saw roughly nine thousand six hundred distinct sources, and 216 of them, about 2.3 percent, touched both an IT service and an OT protocol on our fleet. Some hit a dozen decoys, some hit twenty, from datacenters on several continents. Plotted on a map, one of these sources alone reaches from the US to Europe to Asia in a single spread. Multiply that by two hundred and you have the real shape of the thing: a constant, global, machine-speed census that treats a substation the same way it treats a laptop.

They did not knock, they spoke

It is tempting to picture all of this as port-scanning: a bot rattling doorknobs, noting which are unlocked, and moving on. Some of it is. But a striking amount of what crossed into our OT decoys was not a knock, it was a sentence in the plant floor's own language. The same sources that brute-forced SSH and probed HTTP also spoke Modbus, IEC-104, DNP3, BACnet, EtherNet/IP, and GE-SRTP, the protocols that run pumps, breakers, fuel tanks, and building controllers. Ranked by how often the crossers used them, a PLC's web interface came third and Modbus fourth, both ahead of FTP; industrial protocols were not a fringe of the activity, they were in the thick of it.

Ranked chart of protocols the crossers spoke, office protocols in teal and industrial protocols in amber, with Modbus and a PLC web interface ranking alongside FTP — What the most prolific crossers spoke. Industrial protocols are interleaved with office ones, from the same sources.

And they did not just open the connection. On our fake industrial controllers, sources sent real protocol commands and read back the answers a real device would give:

Captured exchanges on our decoy controllers
GE-SRTP       srtp controller-id        -> IC693CPU331           GE Series 90-30 PLC
EtherNet/IP   enip list-identity        -> 1756-L61/B LOGIX5561  Allen-Bradley ControlLogix
DNP3          link Request-Link-Status  src=0 dst=4              SCADA outstation handshake

Read those again. A source asked our fake GE controller to identify itself and got back a controller model. It asked our fake Allen-Bradley to list its identity and got a ControlLogix CPU. It ran the DNP3 link-status handshake a SCADA master uses to reach a remote outstation. Here is the twist, though: none of it requires a specialist on the keyboard. These exact enumeration requests are what off-the-shelf scanning tools emit automatically. Nmap's ICS scripts, PLCScan, and the big internet crawlers all issue List Identity and controller-identity reads without the operator knowing a ControlLogix from a coffee maker. The tool knows. Industrial-protocol reconnaissance has become commodity, folded into the same mass-scanning kits that rattle SSH and HTTP, which means plant-floor-fluent probing now arrives with the background noise instead of with a targeted adversary. That is the uncomfortable part. You do not have to be interesting to a nation-state to have your controllers interrogated in their own language. You just have to answer the port.

Why this is hard to see

Here is why most defenders never notice the crossover, even when it is happening to them. A single honeypot, or a single firewall log, shows you a sliver. You see an IP hit your SSH port. You do not see that the same IP hit a water plant in another city an hour earlier, because you are not the water plant and you cannot see its logs. The crossover only becomes visible when you run many decoys, in many places, that speak both IT and OT, and then correlate one source across all of them.

That is the entire point of a fleet. Any one sensor tells you that you were scanned. A correlated fleet tells you who is scanning, how widely, and whether the actor probing your office is the same one probing your plant floor. One of those facts is noise. The other is intelligence.

What defenders should take from this

Your OT edge is in the same scan sweeps as your IT. If a device answers on a routable port, treat it as internet-facing in every sense, including the reconnaissance it draws.
The IT/OT wall is an org chart, not a control. Attacker automation does not know or care which team owns which asset. Your visibility should not either.
Correlation is where the signal lives. One log line says you were scanned. The same source seen across many sensors, speaking many protocols, is the difference between trivia and threat intelligence.

The scanning never stops, and it never sorts your assets into "IT" and "OT" the way your budget does. The useful question is not whether your plant floor is being surveyed alongside your servers. It is. The question is whether you can see it happen.

Postscript: who was that one source

The widest-spread external address we can confidently classify, redacted above as 3.129.x.x, is an Amazon-hosted node in the US-East region that multiple security vendors independently flag as malicious. It is not a lone scanner. When we looked it up, it turned out to be a node of a coordinated botnet, one that stages through other organizations' exposed databases, and it was far from the only crosser on our fleet wired into that same infrastructure. (The single widest crosser of all was a stranger case, a self-described "ethical" scanner that we could not cleanly classify. We take that one apart in Part 2.)

Pulling on that one address led somewhere we did not expect. When we looked up the other top crossers the same way, most of them turned out to be wired into the same infrastructure, a coordinated botnet coordinating through other people's exposed databases. That is the subject of Part 2. Read Part 2: The Same Scanners Phone Home →

Sources & notes

Deception Check honeypot fleet, July 2026 (first-party). Correlation across the fleet's IT and OT decoys; management and self-test traffic excluded before counting. Narrative source addresses are redacted and fleet counts and locations generalized; the confirmed-malicious indicators are published in Part 2. Third-party reputation for the highlighted source is drawn from public OSINT (AbuseIPDB, VirusTotal, and Shodan host data), current as of July 2026.