Skip to content

Honeypot experiment

Methodology

The more precisely it is documented how the data came to be, the less anyone has to take it on trust. Here are both servers and how they differed, the data flow, the timeline of the run and every operator intervention.

Data updated: 2026-10-03 10:31:16 UTC+02:00

Report a problem

Setup #

Both servers ran at the same provider and were started at the same moment. Within the same budget, each agent chose the plan, region and operating system itself, which is why the table lists them separately.

Parameter srv3 srv4
Hostname srv3.cloud.batacek.eu srv4.cloud.batacek.eu
Language model Opus 5 Fable 5
Provider Contabo Contabo
Plan Cloud VPS 6 (Core) Storage VPS 20
vCPU 6 3
RAM 12 GB 8 GB
Disk 200 GB 400 GB
Region EU EU
Operating system Debian 12 (Bookworm) Debian 13 (trixie)
Honeypot started 2026-08-22 14:00:00 UTC+02:00 2026-08-22 13:00:00 UTC+02:00
Exposed surface specific services all TCP ports
Control service port 26412/TCP 26411/TCP

What was the same

  • Provider, budget and length of the run.
  • Start time – both honeypots began collecting at the same moment.
  • The agent’s brief. Only the server hostname and the control service port differ.
  • Schedule: server selection, deployment and nine checks on the same days, each session in a fresh chat with no memory of the previous one. The ninth check was the final one.
  • The provider’s network firewall was closed by default and the agents had no access to it. The operator opened ports only after deployment, from the list the agent handed over.
  • The operator’s backup: syslog forwarding and periodic file downloads over SSH to a collection server.

What differed

  • Exposed surface: about 46 specific services on srv3, all 65,534 TCP ports on srv4. The brief did not prescribe this – the agents decided it themselves.
  • Language model: Opus 5 on one server, Fable 5 on the other.
  • The other technical decisions – operating system, honeypot software, how data was stored – were also made by each agent on its own, so the servers differ in those as well.

What the servers exposed #

srv3 specific services

The agent on srv3 chose to offer about 46 specific services and published their ports directly through Docker. The port in its logs is therefore the real port the attacker aimed at.

Port Protocol Typical service Sensor
21 tcp FTP dionaea
22 tcp SSH cowrie
23 tcp Telnet cowrie
69 udp TFTP dionaea
80 tcp HTTP webtrap
135 tcp MS RPC dionaea
443 tcp HTTPS webtrap
445 tcp SMB dionaea
502 tcp Modbus sink
1,433 tcp MSSQL dionaea
1,521 tcp Oracle sink
1,723 tcp PPTP dionaea
1,883 tcp MQTT dionaea
1,900 udp SSDP dionaea
2,121 tcp FTP alt sink
2,323 tcp Telnet alt sink
2,375 tcp Docker API sink
2,376 tcp Docker TLS sink
3,000 tcp HTTP alt sink
3,306 tcp MySQL dionaea
3,307 tcp MySQL alt sink
3,389 tcp RDP sink
5,060 tcp SIP dionaea
5,060 udp SIP dionaea
5,432 tcp PostgreSQL sink
5,555 tcp ADB sink
5,900 tcp VNC sink
5,901 tcp VNC sink
5,985 tcp WinRM sink
6,379 tcp Redis sink
6,380 tcp Redis alt sink
6,443 tcp Kubernetes API sink
7,001 tcp WebLogic sink
8,000 tcp HTTP alt sink
8,080 tcp HTTP proxy sink
8,081 tcp HTTP alt sink
8,443 tcp HTTPS alt sink
8,888 tcp HTTP alt sink
9,000 tcp PHP-FPM sink
9,100 tcp JetDirect dionaea
9,200 tcp Elasticsearch sink
9,300 tcp Elasticsearch cluster sink
11,211 tcp memcached dionaea
27,017 tcp MongoDB dionaea
27,018 tcp MongoDB shard sink
27,019 tcp MongoDB config sink
Time window
2026-08-21 – 2026-09-16
Source data
to be added
Script
to be published

srv4 all ports

The agent on srv4 had the server accept connections on every TCP port from 1 to 65,534. nftables REDIRECT distributed the traffic to several services: cowrie, hpweb and the catch-all service hptcp.

Because traffic is redirected, cowrie and hpweb only see the redirect target ports (42222 and 42223, and 42280 and 42443), not the port the attacker actually aimed at. Only hptcp knows that, reading it via SO_ORIGINAL_DST.

Ports 42222, 42223, 42280 and 42443 in srv4 data are not real destination ports. The port ranking for srv4 is based on hptcp. More

Architecture and data flow #

Attack traffic passes through the provider’s network firewall to the honeypots. They write events to their own files and continuously to syslog. Data leaves the servers for a separate collection server by two routes: syslog continuously, files periodically over SSH.

Internet scanners, bots, attackers Provider firewall srv3 · ~46 services Docker: published ports port in the log = real destination port dionaea · tcpsink · … JSONL logs + syslog srv4 · 1–65,534/tcp nftables REDIRECT only hptcp knows the real port hptcp · cowrie · hpweb JSONL logs + syslog Collection server syslog – continuously files over SSH – periodically data archive all via encrypted WireGuard tunnel Agent and operator commands via hedgehog-runner
data flow control channel (off the public interface)

Traffic from the internet passes the provider firewall to srv3 (ports published through Docker) and srv4 (nftables REDIRECT). Both servers send logs to the collection server. The agent and the operator control the servers through a WireGuard tunnel, off the public interface.

What was collected #

The honeypots recorded four kinds of data. Each links to where you will find it in the downloads.

Sensors

Server Sensor Ports Output Path on the server What it records
srv3 dionaea to be added to be added /srv/honeypot/data/ Honeypot emulating a range of network services.
srv3 tcpsink to be added to be added /srv/honeypot/data/ to be added
srv4 hptcp 1-65534/tcp hptcp.jsonl /var/log/honeypot/ Catch-all service on srv4: accepts a connection on any port and records the real destination port.
srv4 hpweb 42280/tcp, 42443/tcp (REDIRECT) hpweb.jsonl /var/log/honeypot/ Fake web service on srv4.
srv4 cowrie 42222/tcp, 42223/tcp (REDIRECT) to be added /opt/cowrie/cowrie/var/log/cowrie/ SSH and Telnet honeypot: login attempts, typed commands and downloaded files.

What was deliberately not collected #

Some things are missing from the data on purpose. Anyone who downloads it needs to know why – otherwise it is easy to mistake them for collection failures.

  • Outbound connections Outbound traffic from the honeypots was blocked so the decoy could not be used to attack other systems. The data therefore does not show where an attacker or downloaded code would have connected next.
  • UDP on srv4 srv4 accepted TCP only; UDP ports were closed. The srv4 port ranking says nothing about UDP.
  • SIP emulation SIP emulation was switched off during the run. The exact window will be added.
  • Control service ports The ports of the hedgehog-runner control service were out of scope for the experiment – they were not part of the honeypot and are not counted in the results. They were set up differently on each server; details will be added.

Timeline of the run #

Server selection, deployment, every check, every intervention and every incident. Operator interventions are visually distinct – there are few of them, and they include preparing the servers, opening the network firewall after deployment and ending the run.

Clear filters

Agent work of the language model   Operator human intervention   incident linking to its analysis

Some records have been translated from Czech into English and are labelled as translations. The Czech originals are authoritative.
  1. 2026-08-19
    Agentsrv3 Server selection Commands: 0 · changes: 0
  2. 2026-08-19
    Agentsrv4 Server selection Commands: 0 · changes: 0
  3. 2026-08-19 – 2026-08-20
    Operatorboth servers Server preparation: ordering the VPSs the agents had chosen, installing the hedgehog-runner control service and the WireGuard tunnel, and setting up syslog forwarding and backup downloads over SSH. translated The environment the agents worked in, as described in their brief. translated
  4. 2026-08-21
    Run starts
  5. 2026-08-21
    Agentsrv3 Deployment Commands: 0 · changes: 0
  6. 2026-08-21
    Agentsrv4 Deployment Commands: 0 · changes: 0
  7. 2026-08-21
    Operatorboth servers Opening ports on the provider's network firewall after deployment, from the list the agent handed over at its end. translated The firewall is managed by the operator; the agents cannot see it and have no access to it. translated
  8. 2026-08-22
    Agentsrv3 Check 1 Commands: 0 · changes: 0
  9. 2026-08-22
    Agentsrv4 Check 1 Commands: 0 · changes: 0
  10. 2026-08-22
    incident Data missing Severity: major Caused by: agent 2026-08-22-srv3-webtrap-https-tls-accept-hang 15:40 · 2 d 3 h
  11. 2026-08-22
    incident Data missing Severity: major Caused by: agent 2026-08-22-srv3-pcap-ring-buffer-snaplen 00:15 · 2 d 18 h
  12. 2026-08-22
    incident No data missing Severity: minor Caused by: agent 2026-08-22-srv3-syslog-message-size-truncation 00:03 · ongoing
  13. 2026-08-22
    incident No data missing Severity: minor Caused by: agent 2026-08-22-srv3-sshd-move-broke-operator-backup 00:01 · 14 min
  14. 2026-08-24
    Agentsrv3 Check 2 Commands: 0 · changes: 0
  15. 2026-08-24
    Agentsrv4 Check 2 Commands: 0 · changes: 0
  16. 2026-08-24
    incident Data missing Severity: major Caused by: agent 2026-08-24-srv3-dionaea-mongod-parser-freeze 16:18 · 14 d 3 h
  17. 2026-08-28
    Agentsrv3 Check 3 Commands: 0 · changes: 0
  18. 2026-08-28
    Agentsrv4 Check 3 Commands: 0 · changes: 0
  19. 2026-08-31
    Agentsrv3 Check 4 Commands: 0 · changes: 0
  20. 2026-08-31
    Agentsrv4 Check 4 Commands: 0 · changes: 0
  21. 2026-09-04
    Agentsrv3 Check 5 Commands: 0 · changes: 0
  22. 2026-09-04
    Agentsrv4 Check 5 Commands: 0 · changes: 0
  23. 2026-09-07
    Agentsrv3 Check 6 Commands: 0 · changes: 0
  24. 2026-09-07
    Agentsrv4 Check 6 Commands: 0 · changes: 0
  25. 2026-09-07
    incident Data missing Severity: major Caused by: agent 2026-09-07-srv3-deliberate-dionaea-freeze-repro 20:06 · 1 min
  26. 2026-09-11
    Agentsrv3 Check 7 Commands: 0 · changes: 0
  27. 2026-09-11
    Agentsrv4 Check 7 Commands: 0 · changes: 0
  28. 2026-09-13
    incident No data missing Severity: minor Caused by: provider 2026-09-13-contabo-firewall-error-status 05:12 · 3 d 3 h
  29. 2026-09-13
    incident No data missing Severity: major Caused by: operator Control channel outage 04:22 · 39 min
  30. 2026-09-14
    Agentsrv3 Check 8 Commands: 0 · changes: 0
  31. 2026-09-14
    Agentsrv4 Check 8 Commands: 0 · changes: 0
  32. 2026-09-16
    Agentsrv3 Check 9 (final) Commands: 0 · changes: 0
  33. 2026-09-16
    Agentsrv4 Check 9 (final) Commands: 0 · changes: 0
  34. 2026-09-17 – 2026-09-19
    Operatorboth servers planned Closing all ports on the network firewall, downloading the data and cancelling the servers. translated End of the run. translated
  35. 2026-09-17
    Run ends

Details on every intervention are in the section Run log

Control channel #

The agents did not connect to the servers over the public interface. They ran commands through the hedgehog-runner service, reachable only over an encrypted WireGuard tunnel from the collection server. The network firewall had no public rule for it.

Agent and operator traffic is therefore not in the honeypot data. The exceptions are diagnostic and test actions the agents and the operator aimed directly at their own honeypot services – those are described under limitations.

The control service ports were therefore out of scope for the experiment. How they were set up on each server will be added.

Found a bug, missing data or a leak of sensitive information? Report a problem