1.5 Million SSH Attacks, and the Passwords Haven't Changed

Run any Linux box with port 22 open to the internet and you already know the ambient hum: thousands of login attempts a day from strangers guessing root/123456. A researcher at Uphill Security just put hard numbers on that hum — 15 low-interaction SSH honeypots across five VPS providers logged 1.53 million login attempts in July alone, from roughly 6,800 IPs in 129 countries. The credentials attackers tried are almost comically stale. The infrastructure they're attacking from is not, and that's the part worth your attention.

The dictionary hasn't changed since 2008

The top of the list is exactly what you'd guess: root accounts for around 648,000 of the attempted usernames, trailed by admin and ubuntu. The most-tried passwords are 123456, 123, and 1234. The single most popular pair across the whole month was root/123456.

If that sounds familiar, it should — a Clarkson University study of SSH brute-force attacks published at LEET in 2008 found essentially the same distribution. Eighteen years of security tooling, and the mass-scanning economy still runs on the same few hundred guesses. That's not attacker laziness; it's rational economics. When you're spraying the entire IPv4 space, you don't need a clever dictionary. You need the one that hits the long tail of forgotten VPSes, default-credential IoT devices, and Docker containers someone exposed by accident. The dumb list still pays, so nobody's paying for a smarter one.

Independent telemetry backs this up, with one twist the Uphill dataset shares context with: SANS ISC and TEHTRIS honeypots have reported that the strings 345gs5662d34 and 3245gs5662d34 — believed to be default credentials for Polycom CX600 IP phones — show up in roughly 30% of global SSH brute-force attempts, often typo'd into the username field by sloppy bots. When a decade-old desk phone's factory password is a top-three guess internet-wide, you're looking at botnets recycling each other's target lists, not reconnaissance.

Two attack economies, one port

The genuinely interesting finding is the asymmetry in how different regions attack. Asian sources contributed about 60% of unique IPs but averaged only ~111 attempts each — the signature of large botnets of compromised consumer devices and residential proxies, each node spraying gently to stay under rate limits. European sources were the mirror image: under a fifth of the IPs but 60% of total volume, averaging 712 attempts per IP. The Netherlands alone produced roughly 686,000 attempts — nearly 45% of everything the network saw.

That Dutch concentration isn't random, and it's where this dataset intersects with the year's bigger security story. The Netherlands has spent 2025–2026 as ground zero for bulletproof hosting enforcement: Dutch police seized over 800 servers from the Stark Industries/PQ Hosting network in May and arrested two administrators, after earlier takedowns of Zservers and a 250-server anonymous-hosting operation. Reporting on the aftermath noted successor networks like THE.Hosting ramping to millions of scanning sessions per month almost immediately. High-volume, single-IP brute forcing is what rented, disposable datacenter infrastructure looks like in a honeypot log. The takedowns keep landing; the attempt counts suggest the business model shrugs them off.

One honest caveat the raw numbers deserve: 60% of the honeypots sat in Europe, which plausibly inflates European attack volume if scanners weight nearby ranges. And a low-interaction Paramiko-based honeypot is fingerprintable, so this data captures the mass-scanning economy, not targeted attackers — who wouldn't touch a box like this. That's fine. The mass-scanning economy is the threat model for 99% of internet-facing servers.

What to actually do with this

The defender's position here is unusually good, which is what makes the persistence of these attacks so damning. Every one of those 1.53 million attempts dies against three lines of OpenSSH config:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Key-only auth doesn't shrink your risk from this attack class — it eliminates it. There is no dictionary for an Ed25519 key. If you take one action off this article, it's auditing which of your hosts still say PasswordAuthentication yes, because cloud-init defaults have been key-only for years and the stragglers are almost always old pet servers and hand-provisioned boxes.

The two-economy split also changes how you should think about the usual mitigations. Fail2ban-style per-IP banning works well against the European pattern — one IP making 700+ attempts trips any threshold. It does almost nothing against the Asian pattern, where thousands of IPs make a hundred attempts each and rotate before your ban matters. Moving sshd to a nonstandard port cuts log noise dramatically but is trivially defeated by anyone who cares; treat it as log hygiene, not security. GeoIP blocking is mostly theater when the top volume source is Dutch datacenter space that also hosts legitimate infrastructure.

The higher-leverage move is fixing your alerting. If password auth is off, a failed SSH attempt on a public host is weather, not signal — 1.5 million attempts against 15 honeypots works out to over 3,400 per host per day as baseline noise. Alerting on failures will train your team to ignore the channel. Alert on successful logins from unexpected sources instead, and ship the failure firehose to something cheap. If you want to be a good citizen, feed it to AbuseIPDB, which is exactly what Uphill Security plans to do with future data.

The verdict

As threat intelligence, this dataset tells experienced operators little they didn't suspect — and that's precisely its value. It's current, it's CC-licensed with the raw credential data published, and it confirms that the internet's background radiation in mid-2026 is still 2008-vintage dictionaries fired from an industrialized, increasingly European hosting layer. No AI-crafted credential stuffing, no novel tradecraft, just volume.

The uncomfortable conclusion: attackers keep running the cheapest possible playbook because it keeps working, and it keeps working because the fix — a config flag that's been best practice for two decades — still isn't universal. The honeypot data isn't a portrait of attacker sophistication. It's a census of defender procrastination.