Honeypot telemetry has quietly become one of the best sources of ground truth about what internet-wide scanning actually looks like, and this piece breaks down what years of that data show about scan traffic, attacker behavior, and what it means for anyone running a public-facing server. If you operate infrastructure with a public IP, the traffic hitting your honeypots is the same traffic hitting your production boxes, just without a real service to respond.
Honeypots are decoy systems – fake SSH servers, fake databases, fake IoT devices – deployed specifically to get scanned and attacked so researchers can log what happens. Projects like the Shadowserver Foundation, GreyNoise, and the SANS Internet Storm Center’s DShield sensors have run these for over a decade, and the aggregate data tells a consistent story: the internet is scanned continuously, automatically, and mostly by machines that don’t care what they find.
What honeypot logs actually capture
A honeypot doesn’t just log “port 22 was hit.” It captures the full interaction: source IP, TCP flags, timing between packets, the exact banner-grab sequence, and in interactive honeypots like Cowrie, the actual commands an attacker types after a fake login succeeds. That last part is what separates honeypot data from a plain firewall log.
GreyNoise runs thousands of sensors globally and classifies incoming traffic into three buckets: known benign scanners (Shodan, Censys, security researchers), opportunistic mass scanners, and targeted attackers probing specific IP ranges. In 2024 GreyNoise reported that over 70% of daily internet scan traffic came from fewer than 500 distinct scanning operations, many of them commercial or academic – meaning most of the noise your firewall logs isn’t a person, it’s infrastructure like Shodan re-crawling IPv4 space roughly every 15 minutes for common ports.
The busiest ports, and why they never change
Across five years of DShield sensor data, the same handful of ports dominate: 22 (SSH), 23 (Telnet), 445 (SMB), 3389 (RDP), 80/443, and increasingly 5900 (VNC) and 6379 (Redis). Telnet in particular is striking – a protocol most organizations retired years ago still accounts for a large share of honeypot connection attempts, almost entirely from Mirai-derived IoT botnets scanning for default credentials like admin/admin or root/12345.
What’s less obvious from raw counts is the timing pattern. Honeypot data shows scanning isn’t random – mass scanners like those built on Masscan or ZMap sweep entire /8 ranges in hours, then the same IP ranges get a second, slower pass days later from what looks like manual or semi-automated follow-up. That second wave is the one worth worrying about, because it usually means an automated scanner flagged something interesting on the first pass and a human, or a more targeted tool, is now taking a closer look.
What happens after the port opens
Interactive honeypots that let attackers “log in” with weak credentials reveal the post-compromise playbook, and it’s remarkably uniform. On Cowrie SSH honeypots, the median time between a successful fake login and the first command is under 10 seconds. The first commands are almost always reconnaissance: `uname -a`, `cat /proc/cpuinfo`, checks for existing cryptominers, then a download attempt via wget or curl pointed at a shell script that installs a botnet client or miner. This mirrors what’s covered in how attackers use port scanning in the reconnaissance phase – the scan is just step one of a scripted chain, not a standalone event.
Busting the myth: “scanning is harmless noise”
The common misconception among sysadmins is that scan traffic is background radiation – annoying, constant, and safe to ignore because “everyone gets scanned.” Honeypot data contradicts this directly. Shadowserver’s 2023 analysis of exposed RDP honeypots found that roughly 1 in 20 scanning sessions escalated to a credential brute-force attempt within the same connection window, not a separate visit days later. The scan and the attack are frequently the same event, executed by the same tool, in the same TCP session. Treating a port scan hit in your logs as noise rather than as step one of an attack chain is exactly the mistake that leads teams to under-respond to early warning signs.
A second myth worth killing: that obscure or non-standard ports are safe from this traffic. Honeypot deployments on random high ports (like 48291 or 55443) still get hit within days, because scanners increasingly sweep the full 0–65535 range rather than a fixed port list. Service fingerprinting tools identify what’s actually listening regardless of the port number, a point covered in more depth in understanding service fingerprinting in port analysis – moving SSH to port 2222 slows down unsophisticated bots by maybe a day, not weeks.
Common mistakes teams make interpreting this data
Three patterns show up repeatedly when organizations try to act on scan-traffic intelligence. First, treating every scan hit as equally urgent, which burns analyst time on noise from known-benign research scanners that are clearly labeled as such in GreyNoise’s own classification feed. Second, assuming a quiet period means the exposure went away, when it more often means the scanning wave simply moved to a different /16 block and will cycle back. Third, and most costly: not correlating scan timing with configuration changes, so a spike in RDP probes two days after a new EC2 instance goes live gets missed because nobody’s watching for it.
Where AI changes this picture
Newer honeypot data through 2025 shows scanning tools getting faster at triaging what they find – less brute-force guessing, more targeted follow-up based on banner content, likely aided by cheap LLM-based classification of scan results. That shift is explored further in how AI is changing the port scanning threat landscape, but the practical takeaway for a sysadmin is the same one honeypots have shown for a decade: the gap between “port gets scanned” and “port gets attacked” keeps shrinking.
FAQ
Does honeypot data mean my server is being personally targeted?
Almost never at first. The overwhelming majority of scan traffic against any public IP is mass, automated, and IP-range based rather than targeted at a specific organization. It only becomes targeted if the initial scan reveals something worth a closer manual look, such as an outdated service banner or an open admin panel.
How quickly does a newly opened port get discovered?
Honeypot studies consistently show first contact within 5 minutes to a few hours for common ports (22, 80, 443, 3389, 445), driven mainly by continuous internet-wide scanners like Shodan and Censys plus criminal-operated Masscan sweeps.
Is running my own honeypot a substitute for monitoring my real servers?
No – a honeypot tells you what the internet is scanning for in general, not what’s actually exposed on your production systems. For that, continuous external checks of your own IP are what catches drift, which is the core idea behind services like port monitoring.
The clearest lesson from a decade of honeypot data is that scan traffic isn’t background noise to tune out – it’s the first, visible half of an attack chain that often completes within seconds of finding a weak spot, so the ports it’s probing are exactly the ones worth watching continuously rather than checking once a quarter.