What you're looking at
badpwd.com publishes credentials captured by sensors deployed across the public internet, impersonating the services attackers target most — remote access gateways, SSL-VPN portals, and exposed administrative interfaces. They respond like the genuine products down to the protocol level, hold nothing of value, and have no account that can ever be logged into.
Because nothing legitimate ever connects to a sensor, there is no noise to filter out. Every username and password here was submitted by someone attempting to break in — and a credential appearing on this site means one thing: it is in active use against internet-facing infrastructure right now.
About the bad passwords
- This isn't a leaked password dump or a generated wordlist. A leaked dump tells you what people were using on some site that got hacked, often years ago. This tells you what attackers are typing at internet-facing servers today.
- Attackers don't guess randomly. Trying every possible password takes far too long to be worth it. Instead they run short lists that pay off often enough, against millions of hosts at once. A password on this list isn't weak in theory — it's already in rotation, and trying it against you costs them nothing.
- Defaults dominate. The top entries are consistently vendor and OS defaults —
root,ubuntu,admin,debian,ubnt,ftpuser. A host exposed with one of these is typically found by automated scanning within hours, not months. - Complexity rules won't save you. Plenty of entries here satisfy a standard policy — uppercase, digits, a symbol, eight or more characters.
Admin@123passes most corporate password checks and is sprayed constantly. Length and character classes are a poor proxy for "not already on a list." - A denylist catches what a complexity rule can't. Checking new and rotated credentials against a list of values known to be in active use is a different test from counting character classes. That's what the password feed below is for.
FAQ
What is a HASSH?
A fingerprint of an SSH client. During the handshake — before any authentication — a client advertises the key exchange, cipher, MAC, and compression algorithms it supports, in its own particular order. HASSH is an MD5 of those ordered lists.
Different tooling produces different values: OpenSSH, libssh, a Go-based scanner, and a Mirai variant each look distinct. Because the fingerprint describes the software rather than the host, a botnet keeps the same HASSH as its source IPs rotate. That lets you group thousands of unrelated-looking attempts into a handful of actual campaigns.
What is a JA3 hash?
The same idea for TLS. JA3 hashes the client's TLS ClientHello — version, cipher suites, extensions, elliptic curves, and point formats — into a single value. Our SSL-VPN and Citrix sensors record it on every connection, including ones that never submit credentials.
Worth knowing: JA3 is a grouping signal, not proof of identity. Modern TLS 1.3 clients are less distinguishable than older ones, unrelated tools can produce the same hash if they use the same TLS library, and some clients deliberately randomize part of the handshake (we strip those values out, as the specification requires). Use it to cluster activity, not to attribute it.
Why show the ASN?
An IP address identifies one host. The ASN — Autonomous System Number — identifies whose network that host sits on. That's usually the more actionable fact.
Attack traffic clusters hard by provider: a small number of hosting networks account for a disproportionate share of what we see, because attackers rent disposable infrastructure in bulk. Blocking a single offending address buys you until the next one spins up. Knowing the traffic originates from a particular hosting AS lets you make a deliberate decision about that entire network — and lets you tell "compromised home router" apart from "rented attack infrastructure," which are very different problems.
How do I use the feeds?
Three CSV files, regenerated daily, one value per line after a header row. They're plain text and unauthenticated, so they drop straight into most tooling.
| Feed | Contents | Typical use |
|---|---|---|
| IP List | Source addresses observed attacking our sensors | Firewall blocklist, SIEM watchlist, alert enrichment |
| Username List | Accounts being attempted | Detection rules, spotting which of your accounts are targeted |
| Password List | Passwords submitted | Denylist for new and rotated credentials |
Be clear about what these are not: there are no confidence scores, no severity ratings, and no automatic aging. An address that attacked us today may be a compromised machine that gets cleaned up tomorrow. Treat the IP list as "observed hostile, recently" and expire entries on your own schedule rather than blocking permanently. The password and username lists don't go stale the same way — a password that was sprayed once stays a bad choice forever.
Are these real credentials?
They are the exact strings that were submitted. Nothing is sampled, truncated, cleaned up, or hashed — what an attacker sent is what gets recorded and shown. None of them ever authenticated anything: the sensors have no accounts and never grant access, so there is no system anywhere that these credentials open.