674 Out of Six Million: Who Actually Knocks on a DICOM Port

Questo articolo è disponibile anche in italiano.

Five weeks of running a public honeypot, six million recorded events. Of those, 674 involved medical protocols: 639 on the DICOM sensor, 35 on the HL7 one.

That works out to 0.011% of the total. One event in every eight thousand nine hundred. Port 3389 alone collected two million; the DICOM sensor averaged a little over twenty a day.

The instinct is to file that away as irrelevant. Looking at how those 674 events break down, the opposite turns out to be true, because they resemble nothing that arrives on the other ports.

How Far They Got

Dicompot, the DICOM sensor, distinguishes three levels of interaction in its logs, and the distribution says considerably more than the total does.

Five hundred and thirty-two times somebody opened a connection to the port and closed it, which is what a scanner does when it checks whether a port is open without understanding what sits behind it. One hundred and four times the other end spoke DICOM properly, presenting an AE Title, the identifier DICOM nodes use to recognise each other; doing that requires an actual DICOM library rather than nc pointed at a port.

And three times, across five weeks, somebody got as far as exchanging data.

Three, out of six million events overall. My honeypot serves fifty fake images to anyone who asks for them, and nobody asked.

Who Was Behind It

One hundred and fifty-five distinct IP addresses touched the DICOM port. The surprise is who they belong to.

Across the 264 events where I have the network organisation, 86 come from Censys and ONYPHE, which is 33%. Both are companies that scan the internet for a living, catalogue what they find, and sell or publish the results as attack surface intelligence. They are not attacking anything; they are building a map. On HL7 the proportion is similar, with Modat and ONYPHE accounting for ten events out of thirty-five.

The rest splits between cloud providers (Google, Akamai) and a long tail of smaller hosters. Of the 266 events that carry a source address, 126 come from IPs already flagged as known attackers, 33 from mass scanners, and 107 from addresses that appear in no reputation database at all. That 40% is the part worth looking at, because those are connections no blocklist would stop.

One caveat on the reputation figures: only log lines of type “Connection from” carry the source IP, so the statistic covers 266 events out of 639. It is a sample rather than a census.

HL7 Is a Different Planet

Medpot, which emulates an HL7 endpoint for clinical messaging, saw 35 events in twenty-five days. One every eighteen hours, from twenty-one distinct addresses.

Statistics on numbers that small say very little, but one thing stands out: twenty of the thirty-five events come from Brazil, 57%, and the operators behind those addresses are mid-sized Brazilian providers (IPVDATA, Nova Serv, TASCOM, SKYMAX). Brazil ranks second after the United States in the honeypot’s overall traffic, so some presence is expected, though not at this concentration.

I do not have an explanation, and I would rather say so than construct one after the fact. It could be a single actor rotating across providers in the same country, it could be a regional campaign, it could be statistical noise on a sample of thirty-five. More data will tell.

There is one crossover worth flagging, though. IP 200.219.11.123 appears on both DICOM (16 events) and HL7 (8), ranking first on each sensor. The same holds for 191.242.209.98, with six on the first and five on the second. Somebody is systematically checking multiple medical protocols against the same target, which is a different behaviour from a scanner spraying ten thousand random ports.

The Signal to Noise Ratio Is Inverted

This is the part that matters most for anyone defending a hospital network.

On port 3389 my honeypot took two million events in five weeks. An alert there means nothing; it is the permanent background radiation of any public address, and anyone trying to monitor it seriously drowns in false positives by mid-afternoon.

On port 11112 it took 639, of which 104 involved a genuine DICOM handshake. No generic scanner tries port 11112 hoping to get lucky, because DICOM is not in the mass-scanning dictionaries. Anything that reaches it, and particularly anything that introduces itself with an AE Title, is either a search engine cataloguing the internet or something that knows exactly what it is looking for.

Which leads somewhere counterintuitive: the least attacked port is where monitoring pays off most. RDP needs correlation, thresholds and a great deal of patience before it yields anything useful. On DICOM every single event is potentially meaningful, and a trivial detection rule (any inbound connection to the DICOM port) produces few alerts and almost no false positives. It costs very little to implement, and almost nobody implements it.

What This Data Does Not Say

My server does not look like a hospital. It is called lupercus-honeypot, it has no DNS record pointing at a healthcare organisation, it does not sit in an address block assigned to a hospital group, and nothing about it suggests to an attacker that real clinical data lives behind it.

So what I measured is opportunistic scanning, not targeted scanning. An attacker who does reconnaissance before acting, who starts from a list of healthcare providers and maps their public addresses, would never find my honeypot interesting. Those 674 events are a floor rather than a ceiling: they tell you how much traffic reaches a medical port purely by accident, and nothing about how much a hospital PACS with a name that announces itself receives.

That is a structural limit of this experiment, and it is worth holding on to before drawing any reassuring conclusions from the numbers.

From Here

The sensors keep collecting. With six more weeks of data, by autumn, some of the open questions become answerable: whether the Brazilian concentration on HL7 holds up, whether the IPs touching both protocols come back, and above all whether those three DICOM data exchanges stay an isolated anomaly.

In the meantime the blog slows down. The weekly recaps end here, partly because after five weeks they would say the same things with different numbers, and partly because I sit the CompTIA Security+ exam on 25 August and the next four weeks belong to that. From September it comes back as monthly analyses, one subject at a time.

Data collected between 27 June and 26 July 2026 using T-Pot by telekom-security on Hetzner Cloud. The medical sensors are Dicompot (DICOM, ports 104 and 11112) and Medpot (HL7, port 2575).