Username Attack Database — See What Credentials Hackers Actually Try

We just shipped a new feature: a searchable database of every username attackers have tried against our global honeypot network. Over 33,000 unique usernames, 4.7 million attack sessions, 13 protocols — all free to browse at /usernames.

Why Usernames Matter

Most security tools focus on IP addresses. That's useful, but it misses half the picture. When an attacker connects to your SSH server and types root, admin, or ubnt — that username tells you something. It tells you whether you're being hit by a generic scanner, a targeted campaign, or a botnet cycling through default credentials.

Until now, there wasn't a good public source for this data. Individual honeypot operators see their own logs, but nobody was aggregating usernames across protocols and geographies at scale. That's what this does.

What's In The Database

Our sensor network runs honeypots on 14 different protocols. Every time an attacker authenticates — or tries to — we capture the username. Here's what we've collected so far:

• 33,000+ unique usernames observed in real attacks
• 4.7 million total attack sessions
• 13 protocols — SSH, FTP, Telnet, MySQL, PostgreSQL, SMTP, SMB, MongoDB, HTTP, MSSQL, SIP, IMAP, and RTSP
• Updated daily as new attacks hit our sensors worldwide

The top 10 most attacked usernames won't surprise anyone who's managed a Linux server:

The usual suspects are there — root, admin, ubuntu, postgres. But then there's sol, solana, and 345gs5662d34 in the top 6, all SSH-only. That's crypto-related botnet activity targeting validator nodes — something you wouldn't see from a single honeypot, but it's obvious at scale.

Further down: IoT defaults (ubnt, support, pi), cloud platform usernames (centos, debian), and application-specific credentials (git, hadoop, mysql, oracle). The full ranked list with all 25 top entries is at /usernames.

Per-Username Detail Pages

Every username in the database has its own page. Search for any username and you'll see:

• Total attack sessions across all protocols
• Protocol breakdown — which protocols this username appears on, with a visual bar chart
• Active period — first and last time we observed the username in an attack
• Context — whether this is a common default credential or something more unusual

For example, root appears across 10 protocols with over 1.2 million sessions. But sa (the default SQL Server admin) is concentrated on MSSQL, and solana is SSH-only — crypto botnet operators hunting validator nodes. Each username tells a different story about how attackers operate.

Try it: /usernames/root, /usernames/admin, or search any username at the top of the page.

Protocol Coverage

This release adds username tracking for four additional protocols we weren't previously indexing:

• HTTP — basic auth credentials from web brute-force attempts
• Redis — AUTH command usernames
• RTSP — camera and media server credential attacks
• SIP — VoIP infrastructure authentication attempts

Combined with the nine protocols we were already tracking (SSH, FTP, Telnet, MySQL, PostgreSQL, SMTP, SMB, MongoDB, MSSQL), this gives username coverage across 13 protocols — virtually every common network service.

You can explore attack data by protocol on the protocol breakdown page, or drill into specifics like SSH, FTP, or MySQL.

How We Collect This Data

Our sensors accept all credentials — that's the point of a honeypot. When an attacker connects and authenticates with root / password123, we record the full session: username, protocol, timestamp, source IP, and everything that happens after login.

The behind the scenes page explains the full architecture, but the short version is:

1. Sensors capture raw authentication events across all protocols — 14 of which involve usernames
2. Events are shipped to the Collector, our central processing server
3. The Collector normalizes usernames (trimming whitespace, lowercasing), counts sessions per username per protocol, and tracks first/last seen timestamps
4. The public username database is updated in real time as new attacks arrive

Every data point comes from a real attack against a real honeypot. No synthetic data, no guessing.

What You Can Do With This

Audit your systems. Search your server usernames against our database. If deploy, backup, or monitoring shows up in thousands of attacks, you know automated scanners are looking for it. Consider disabling password auth for those accounts or using SSH keys only. Our Fail2Ban integration automatically reports banned IPs to the threat database.

Harden your defaults. The database exposes which default credentials attackers target by protocol. If you're running MySQL, check whether your admin username appears. Same for PostgreSQL, Redis, or MongoDB. The IP check API can tell you whether the IPs hitting those usernames are known threats.

Feed your detection rules. Export the top targeted usernames for your protocol and write SIEM rules that flag authentication attempts using them. If someone logs in as ubnt on your non-Ubiquiti server, that's a strong signal.

Research attacker behavior. The detection catalog tags attack sessions with behavioral patterns. Cross-referencing usernames with behaviors reveals which credentials are used by which types of attackers — botnets vs. manual operators vs. targeted campaigns.

Free to Use

The username database is free to browse — no account required. Search any username, view the top list, explore protocol breakdowns.

The sikker CLI will be adding username lookup commands in an upcoming release.

Need higher limits? Check pricing — every feature is available on the free tier, paid plans just expand capacity.