Unadvertised servers on three continents drew first scanner within 48 seconds

A developer rented three cloud servers — in Frankfurt, New York and Singapore — told absolutely no one their addresses, and watched the internet discover them anyway. According to a post on dev.to, the first unsolicited connection arrived 48 seconds after the Singapore machine booted. Over roughly three quarters of an hour the three boxes logged 3,480 connection attempts from 860 distinct addresses, including 1,085 login tries that carried real passwords.

Three disposable honeypots

The addresses appeared in no DNS records, certificates or repositories, according to the post; only the cloud providers themselves knew the machines existed. Each box ran a small Python program posing as the services scanners actually knock on: telnet on 23, HTTP on 80 and 8080, and TLS on 443, with an SSH honeypot parked on 2222 so the machine's real SSH could keep port 22 for administration. Every listener was a decoy — the telnet service displayed an Ubuntu login prompt and refused every password, while the HTTP service logged requests and returned 404. A tcpdump capture counted every inbound TCP SYN, so probes against ports with nothing listening were tallied too. Each region ran for about 45 minutes before the setup destroyed itself; the whole experiment cost under three cents.

The clock starts at routability

First-contact times were 48 seconds in Singapore, 107 in Frankfurt and 324 in New York. The author's takeaway is that the address space is swept continuously and indiscriminately, so exposure begins the instant an IP becomes routable — not when an application is deployed or announced.

The raw regional totals look skewed — 2,325 attempts in Frankfurt versus 516 in Singapore — but a single host on Korea Telecom's network sent 1,663 packets to Frankfurt on its own, nearly all aimed at telnet. Discounting the busiest source, the regions converged on 829, 759 and 677 attempts per hour, which the author reads as a baseline of roughly 700 to 800 unsolicited connections per hour for any fresh public IP, plus the occasional host that fixates on a target. The crowd itself was shallow: 672 of the 860 source addresses, about 78%, sent exactly one packet during the entire window.

Telnet, mail ports and factory defaults

Ranked by connection attempts across all three machines, the most-requested ports were 23 (telnet, dominant once the Korea Telecom host is counted — the territory of routers, cameras and DVRs that IoT botnets never stopped working over), 8088 (Hadoop YARN and assorted admin panels), 22 (SSH), 587 and 465 (mail submission; one New York host probed each 50 times, reflecting the spam-sending value of a cloud IP no one has reported yet), and 5555, the Android Debug Bridge port. Nearly all HTTP requests were bare probes to the root path with no Host header — scanners checking whether anything answers, not browsers.

The telnet decoy gathered 1,085 password-bearing logins spanning 107 distinct username and password pairs. The most frequent passwords were annie2015 (43 tries), OxhlwSG8 (42), S2fGqNFs (40), annie2014 (40), annie2016 (39), motorola (39), tlJwpbo6 (39), 7ujMko0admin (37), epicrouter (34) and 123456 (33). The author notes these track familiar Mirai-style lists: 7ujMko0admin is a Dahua camera backdoor, epicrouter a Conexant DSL default, and Zte521, lower down, a ZTE router default. What is absent is telling — almost no dictionary runs against plausible human passwords. The traffic is machine-speed enumeration of factory defaults for mass-produced devices, not an attempt to crack any individual's account. Capturing the passwords at all hinged on one detail: bots wait for the server to negotiate telnet options before sending a password, so the decoy had to answer that negotiation like a real daemon before anything beyond usernames appeared.

When your instrument lies to you

The post also owns two mistakes. Relocating the machine's real SSH off port 22 by editing sshd_config did nothing on Ubuntu 24.04, because systemd socket activation ignores the config's Port line; an attempt to fix it through the systemd socket cut the box off the network entirely, and a second attempt repeated the failure. Automatic teardown kept the dead machines from billing overnight. Separately, a TLS parser bug — an IDNA decode wrapped in a broad exception handler — reported no server names in every handshake, nearly producing a false finding that clients never send SNI to a bare IP. The remedy was testing the instrument against a known positive before trusting a zero.

Why it matters

The experiment puts hard numbers on something defenders usually treat as folklore: every routable address is probed continuously, from its first second online, overwhelmingly by automated campaigns mining default credentials over IoT-era protocols. The practical conclusions are blunt — hardening has to precede exposure rather than follow it, any reachable service still using a factory default is effectively unlocked, and even clean, freshly rented cloud IPs are hunted for spam-relay potential. And for anyone running their own measurement: a believable zero can simply be a broken instrument, so validate against something you know works.