30 Days on a Fresh Ubuntu: Attacker Dwell Time and What They Did

The setup

One Oracle Cloud VM, London region, Ubuntu 24.04, public IPv4, no firewall in front of it beyond the cloud security list. Inner Warden running in observation mode, which means everything is detected and logged but nothing is blocked. The goal was a clean baseline for what the open internet does to a brand new server before the operator types anything beyond apt update.

The numbers below are from one host over thirty days. They are not lab numbers, but they are also not a study. Anyone running a VPS with a public IP will see a similar shape. The exact numbers will swing with the IP block you land on and how exposed it is already known to be.

The headline numbers

Across thirty days, the host saw roughly 184,000 unsolicited inbound connection attempts. That averages around 6,100 per day, or one every fourteen seconds. Around 71,000 unique source IPs were seen. About 38 percent of attempts came from IPs that repeated within the same week, which suggests scan rotations rather than one-off probes.

Time to the first SSH login attempt with a username and password guess was about 11 minutes from boot. Time to the first authenticated shell attempt, defined as a successful TCP handshake on port 22 followed by a credential submission, was 19 minutes. No attempt succeeded, because no weak credential was available.

Top ports probed

SSH is dominant but not as dominant as people remember. RDP and SMB on a Linux host show that scanners do not bother profiling the OS first, they fire everything and see what answers.

Top SSH usernames tried

Over the month, around 22,000 distinct username, password combinations were submitted to port 22. The top usernames were the unsurprising classics:

root          ~31%
admin         ~9%
ubuntu        ~6%
user          ~4%
test          ~3%
oracle        ~2%
postgres      ~2%
git           ~1%
deploy        ~1%
ec2-user      ~1%
... ~3000 others in the long tail

The interesting one is ubuntu. Knowing the cloud-init default username is enough of a hint that scanners try it on every public IP. If you keep that username and only allow key auth, you are fine. If you keep that username and allow password auth, you are not fine.

Top source countries

By geo-IP of the source, the top origins were Vietnam, the United States, China, Russia, Brazil, and India, in that approximate order. The US figure is heavily skewed by hosting providers and scan services, so it does not say much about attackers. Vietnam consistently topped the SSH brute-force list, consistent with widely-reported botnet patterns.

Tor exit nodes were a tiny share, well under 1 percent. Most attackers do not bother. They have so many compromised IPs available that hiding behind Tor is unnecessary.

Web port surface

On port 80 and 443 with no service running, the host still received about 4,200 HTTP-style probes. The user-agent distribution was dominated by Mozilla/5.0 zgrab/0.x and other research scanners (Censys, Shodan, ONYPHE). Of the non-research probes, the most popular fake user-agents were "Googlebot" and "facebookexternalhit", both trivially spoofed.

Reverse DNS verification flagged about 92 percent of the "Googlebot" claims as spoofed. See Fake bot detection for how that check works.

ASCII timeline of day one

T+00:00  boot
T+00:11  first inbound TCP SYN (port 22, Vietnam)
T+00:11  first SSH banner grab
T+00:19  first credential attempt (root / 123456)
T+00:24  first port-23 telnet login attempt (Mirai-style)
T+01:03  first redis ping on 6379
T+02:18  first HTTP probe with /.env in the path
T+03:42  first /wp-login.php scan (no WordPress installed)
T+05:01  first /actuator/env probe (Spring boot scan)
T+09:30  /phpunit/Util/PHP/eval-stdin.php (CVE-2017-9841)
T+12:14  curl with "Googlebot" user-agent on port 80
T+18:55  /boaform/admin/formLogin (router botnet)
T+24:00  3,914 distinct source IPs seen on day one

What was reproducible, what was not

Reproducible: the rough volume per day, the dominance of SSH and Telnet, the presence of Redis and Mongo probes, the "Googlebot" spoofing on web ports, and the username distribution. Run this experiment on any public VPS and you will see the same shape within a factor of two on volume.

Not reproducible: any specific exploit attempt is partly luck. Whether your IP has been published in a recent breach dump, what ASN you are in, and which botnet rotation includes your subnet this week all matter. The exact CVE probes I saw will be a different list next month.

The honest takeaway

Nothing on the list above is exotic. None of it is targeted. All of it is automated, and all of it works often enough on someone else's server that the operators keep paying for the botnets that run it. The cheap defenses (key-only SSH, no root login, fail2ban or its replacement) handle 99 percent of this traffic. What they do not handle is the 1 percent where the first foothold actually happens, which is what behavioral detection is for.

For more context on baseline learning and what "normal" looks like on a host like this, see Baseline learning for zero-day detection.