When Your Honeypot Works Too Well: An OVH & Netcraft Story
Sometimes the best compliment your honeypot can get is being mistaken for actual malware. Here's what happened when automated security scanners decided our ICS honeypot was a command-and-control server.
The discovery
One evening I noticed that the SSH service on our pre-production sensor (hosted on an OVH
bare metal server) wasn't responding. The server was answering ICMP echo requests and SSH
appeared active on the default port — which I initially assumed was fine, since we run
an SSH honeypot on port 22. The real sshd listens on a non-standard port.
I'd been dealing with some load average issues in the past, so my first thought was that the performance optimizations I'd applied hadn't fully solved the problem. Maybe the sensor was just overloaded and dropping connections.
Then I logged into the OVH customer panel.
"Your server has been hacked, and has been switched to FTP rescue mode."
What actually happened
The chain of events that led to our sensor being shut down:
- The IP has history. The OVH IP address assigned to our server still carries stale VirusTotal entries from ~4 years ago — likely from a previous tenant. Several security vendors continue to tag it as malicious based on that old data. This means the IP was already "pre-flagged" before we ever deployed our sensor on it.
- Shodan scanned our server and found an open port running the IEC 60870-5-104 protocol (a standard SCADA/ICS protocol used in power grid telecontrol). Combined with the IP's existing reputation, Shodan's automated classifier tagged our IEC 104 honeypot response as "Remcos Pro RAT trojan" — a remote access trojan.
- Netcraft picked up Shodan's classification (and likely the VirusTotal vendor flags) and generated an incident report flagging our IP as hosting active malware.
- OVH received Netcraft's report and, without further verification, switched our server to rescue mode — effectively killing all services.
No human at any point in this chain actually verified what our server was running. Stale threat intelligence from years ago, a protocol misidentification by an automated scanner, an automated reporting service, and an automated abuse process — four layers of automation, zero layers of verification.
The forensics
With the server in rescue mode, we mounted the disks and performed a full forensic investigation:
- All SSH logins traced to known IP addresses, authenticated via ED25519 public keys
- No unauthorized SSH keys, user accounts, or crontab entries
- No rootkit indicators (
ld.so.preload, modified system binaries) - RPM package verification clean — only expected config file changes
- All 34 sensor systemd services accounted for
- The "malicious" port was our IEC 104 honeypot, logging 1,500+ inbound attack events from external scanners
The server wasn't hacked. It was doing exactly what it was designed to do — pretending to be a vulnerable SCADA system and logging everyone who tried to attack it.
The irony
Shodan simultaneously tagged our IP as "ics" (industrial control system) and "malware" (Remcos RAT). It correctly identified our Modbus honeypot as a "Schneider Electric PM5560", our FortiGate honeypot as a firewall, and our Kubernetes honeypot as a kube-apiserver — but decided that the IEC 104 honeypot on port 2404 was a trojan.
The ICS tags were correct. The malware tag was the error. Our honeypot was convincing enough to fool the scanner, which is arguably a success for the honeypot — just not a convenient one.
And the VirusTotal angle makes it worse — the IP was flagged by vendors based on activity from years before we even rented the server. OVH recycles IPs, but the threat intelligence ecosystem never forgets. So our honeypot inherited a criminal record from a previous tenant, and nobody thought to check whether the current activity matches the old reports.
Questions nobody asked
- Did Netcraft verify what the service actually was before filing the report?
- Did OVH check whether the "malware" was actually a well-known ICS protocol running on its standard port?
- Does anyone in this automated pipeline consider that security researchers might intentionally run services that look suspicious?
- How many legitimate honeypot operators have had their infrastructure killed by this process?
Resolution
We responded to OVH with a detailed technical explanation, including evidence that the flagged port runs a honeypot with 1,500+ logged attack events. We also contacted Netcraft directly, explaining the Shodan misclassification and requesting they close the incident as a false positive.
The sensor is restored and running. All services came back cleanly after a normal reboot — no data loss, no configuration changes needed.
Will probably not be extending the OVH bare metal subscription for next month. Waiting for their responses. Update soon.