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.

Continue reading →

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.