Author Archives: Adam Hostetler

The Same Ten Passwords, Twenty Years Later

Posted on by

We’ve been logging the credentials that bots throw at an SSH honeypot (our HoneyPoint Security Server™). Nothing exotic: listeners that accept the handshake, record the username/password pair, and the source IP. After letting this run for a bit, the first thing we noticed was how little the dictionary has changed.

HoneyComb

The numbers

Top usernames over the capture window:

Username Tries Sources
root 45,302 350
admin 3,254 256
user 1,978 132
enable 1,863 12
test 1,414 101
ubuntu 1,142 125
user2 452 26
debian 433 39
deploy 387 47
support 372 104

root alone accounts for more attempts than everything else combined, by a factor of about four. That’s not surprising. What’s worth noticing is the sources column: 350 distinct IPs tried root, 256 tried admin. This is the broad, low-effort campaign layer to find the most basic common hanging fruit.

Top passwords:

Password Tries Sources
123456 1,916 233
linuxshell 1,841 8
1234 746 180
123 728 124
password 532 151
12345 393 116
12345678 393 88
1 367 68
admin 365 139
root 322 108

Strip out linuxshell for a second (I’ll come back to it) and this list is indistinguishable from a 2006 SSH brute-force wordlist. 123456, password, 1234, admin, root. Nine of the top ten passwords have been in every public leaked-password top-25 for two decades.

The pair frequency shows it well:

Username Password Tries Sources
enable linuxshell 1,841 8
admin admin 134 108
root 123456 116 89
root root 112 91
root 1234 104 83
root admin 102 82
root password 101 83
root 12345 94 72
user user 92 74
admin 1234 91 79

root:root, admin:admin, user:user, root:password. These are the first guesses in any credential scanner I’ve ever seen.

Why this is the depressing part

A botnet operator doesn’t keep root:123456 in the list out of tradition. They keep it because it’s still working somewhere. The credential lists in these tools get pruned and reweighted based on what actually produces shells. If a pair stopped working at scale, it would drop off in favor of something that does, because brute forcing takes time and they don’t want to waste time on passwords that never work.

So the fact that the dictionary hasn’t moved in twenty years isn’t a statement about attackers being lazy. It’s a statement about the install base. Somewhere out there, a measurable fraction of internet-facing SSH is still root with a password from the top ten, and the population is stable enough that the guessing strategy hasn’t needed to evolve.

That’s the number I’d actually like to know and can’t measure from this side: the hit rate. The honeypot only sees the attempts. But the attempts are the derivative of the success rate, and the derivative is flat.

The outlier: enable / linuxshell

One pair dominates the table and doesn’t fit the pattern. enable:linuxshell was tried 1,841 times from only 8 sources. Compare root:123456: 116 tries from 89 sources.

Eight IPs hammering one specific pair means a single campaign, not the ambient background. enable is the Cisco IOS privilege-escalation command, and enable-as-a-username shows up in IoT and embedded-device wordlists that were forked from Mirai. linuxshell could be a default from a specific device family or firmware. This particular scanner seems to be built for a particular class of embedded gear, and it doesn’t care that it’s talking to something that isn’t that gear. It’s going to try the same pair 200+ times per source regardless.

If you filter this out, the remaining data is almost pure legacy dictionary.

The newcomers

Here’s the list of usernames that aren’t in the standard brute-force set:

Username Tries Sources
enable 1,863 12
prueba 235 40
noreply 220 30
claude 127 22
testuser 109 35
deployer 103 29
frappe 100 24
openclaw 78 13
alex 69 33
trader 67 15

Most of these are explainable. prueba is Spanish for “test”. frappe is the default service account for the Frappe/ERPNext stack. trader is aimed at crypto trading bots, which tend to run on cheap VPSes with hastily created accounts. deployer and testuser are what people name accounts when they’re not thinking about it.

Two are new: claude and openclaw.

claude got 127 tries from 22 sources; openclaw got 78 from 13. Neither existed in any wordlist I’ve seen before the last year or two. What they have in common is obvious: both are names of AI agent tooling, and both are the kind of name someone would pick for a dedicated Unix user when standing up an agent on a box. useradd claude, drop the agent config in its home directory, give it a password so you can su into it, forget about it.

Attackers have noticed. The reasoning is straightforward from their side: agent hosts are a new class of machine that is (a) internet-facing, (b) frequently set up in a hurry by people who aren’t primarily sysadmins, (c) holding API keys and credentials for whatever the agent has been wired into, and (d) often running with more privilege than a web app would because the agent needs to “do things”. That’s a better target than a generic VPS, and the username is a cheap fingerprint for it.

Twenty-two sources for claude is small compared to the 350 for root. But ubuntu got 125 sources and debian got 39. Usernames get added to lists when someone believes there’s a population worth probing. That a couple dozen distinct scanners already carry claude and openclaw means the operators think the population exists.

What to do with this

None of this is novel advice. The point is that the data says the advice is still not being followed.

  • Firstly, don’t expose SSH (or any similar service) at all if it’s not necessary, allow only IPs that need to access it.
  • Disable password authentication on SSH. Keys only. This closes the entire top-ten list in one config line.
  • If you can’t, PermitRootLogin no. root is 80% of the attempts.
  • If you’re running an agent under a service account, don’t name it after the product, don’t give it a password, and don’t let it own the SSH login path at all. The agent needs to run as something; it doesn’t need to be reachable as that something.
  • Rotate anything the agent’s account can read, on the assumption that the account name is now on a list.

The old passwords are still being tried because they still work. The new usernames are being tried because someone expects them to. Both of those are fixable on the defender’s side in an afternoon, which is presumably why they’ve gone unfixed for twenty years.

Stop Patching Solely by Severity. Start Patching by Exploitation.

Posted on by

If your patch SLAs are still solely driven by CVSS base score, i.e., Critical in 7 days, High in 30, Medium “when we get to it”; you are optimizing for the wrong variable. The math stopped working a while ago, 2025 made it obvious, and 2026 is making it painful.

Roughly 48,000 CVEs were published in 2025, up about 20% from ~40,000 in 2024. So far in 2026, there are over 15,000 (as of mid-May), and we may well see well over the number from 2025 by the end of the year. Around 39% of those were rated Critical or High in 2025, and about 45% of 2026 CVEs are.

Worse, severity is a poor predictor of what is actually attacked. Only ~2% of published CVEs are ever exploited in the wild (768 of ~40k in 2024). CISA’s KEV catalog covers ~0.5% of all CVEs. So a severity-only program spends most of its effort on vulnerabilities no attacker will ever touch, while the handful that matter sit somewhere in the queue ranked by a number that doesn’t correlate with exploitation.

Continue reading →

What’s the data leakage that DLP can’t detect?

Posted on by

During our engagements, we routinely look for source code or other internal sensitive information that could have been inadvertently posted. The team has been doing this as part of our standard engagements for quite awhile, and we routinely identify information through this method that clients are always thankful of being notified about. “But I have DLP!” – quite frequently, DLP won’t detect uploads to sites like Pastebin or Github.

Continue reading →

New Attacks Against Misconfigured Amazon S3

Posted on by

Over the past few years we have seen plenty of news about data being stolen from misconfigured Amazon S3 buckets and other cloud based services. Now attackers are figuring out ways to further abuse these systems beyond simply stealing data.

Magecart, a threat actor group involved in a large amount of attacks, has a currently active campaign targeting S3 hosted sites; the attack infected these sites with malicious javascript that steals customer’s credit card data.

Their attack methodology involves specifically looking for buckets that have write permissions enabled for everyone. When one of these buckets is found, it looks for javascript in the bucket – increasing the likelihood that it’s being used to host a site, or serving assets for a site hosted elsewhere. Javascript files are then edited by the attacker and the Magecart malicious javascript is injected into it.

The javascript runs in the customer’s browser, looks for specific forms, and sends that data to another server when it is submitted. Without detailing this further, as there are many other good breakdowns of exactly what this attack entails that are available. The key take away here will be what can you do to make sure a site you have isn’t hosting this code.

Continue reading →

Vendor Printer Management and Security

Posted on by

Over the past couple years we’ve encountered increasing numbers of customers using various print management vendors. Many that we have encountered are using the same application suite to manage the printers, and by default it has a blank admin password. In most of the instances we’ve observed this parameter has not been changed, or a strong password set. Likewise most of the managed printers also are not configured to use authentication or are using the default credentials.

When we encounter this one of the “benefits” this application affords us, due to the fact that it keeps a fairly detailed inventory with model number, is that it allows us to pinpoint areas of attack and compromise. Printers that we know have issues, or printers with functionality such as saving to network shares, SNMP etc. can be leveraged without doing activities that would be easily detectible on the network.

Continue reading →

OSINT Yourself

Posted on by

If you’re unfamiliar with the term “OSINT” (open-source intelligence) it boils down to finding information that’s publicly and freely available about you, your company or anything else. How can this help you? OSINT covers a very broad array of sources and uses, and one way it can be used is to help verify your external network surfaces, and if user emails have been found in datadumps from compromised sites.

Continue reading →

Micro Podcast – Amazon AWS

Posted on by

In this episode of the MSI podcast, we discuss recent issues involving AWS misconfigurations that led to incidents, common problems, the importance of proper configurations to avoid these issues and how we can help you identify them in your environment.

Listen here

If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.

Do You Have Production Data in your Test Environment?

Posted on by

We’ve talked about development servers, and the perils of internet facing development environments.  Now, let’s talk about what is IN your development environment.

Another issue we run into fairly often with dev environments,…they are set up to use production data, and sometimes this data is piped in directly at night with no modification. This introduces a risk of not only exposing this data through vulnerabilities within the development environment but could allow a contractor or unauthorized employee to view sensitive information.

Continue reading →

There’s Still Treasure in the Trash

Posted on by

Most businesses have processes and policies for handling sensitive data on paper, whether thats selectively shredding papers or shredding everything, along with training about what goes in trash bins and what goes in shredding bins. However, how many are ensuring that these policies and processes are being followed? Brent asked

Which got me thinking about this. I couldn’t remember the last time an organization actually asked us about it beyond reviewing policies. I know this problem didn’t disappear, even as we move more and more away from paper. Paper still gets used, people write stuff down, things get printed, and no solution completely ensures that that paper doesn’t end up in the wrong bin. I know from doing it. I found something useful in almost every engagement that we’ve done in the past, whether it was an administrative password, or contact information that I can use for phishing.

Recently, some researchers performed a trash inspection of some hospitals in Toronto. What they found didn’t surprise me. They found PII and PHI, a good bit of it.  A resident in Palolo Hawaii found these too. A nuclear security complex was found to be dumping trash that had classified documents in it. None of these were reported breaches, just there for the taking. Who knows if anyone malicious found them too?

Let’s keep working on the most prevalent topics of the day, such as phishing defense and training, but we can’t forget all of the things that were an issue in the past, because they’re still an issue now even if they’re not making the big headlines in the current moment.