Author Archives: Adam Hostetler

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.

Cloudy With a Chance of Misconfigurations

Posted on by

Many organizations have embraced cloud platforms now, like Amazon AWS or Microsoft Azure, whether they are using it for just a few services or moved part or all of their infrastructure there. No matter the service though, configuration isn’t foolproof and they all require specific knowledge to configure in a secure way.

In some cases we have seen these services configured in a way that isn’t best practice, which led to exposure of sensitive information, or compromises through services that should not have been exposed. In many instances there are at least some areas that can be hardened, or features enabled, to reduce risk and improve monitoring capabilities.

So, what should you be doing? We’ll take a look at Amazon AWS today, and some of the top issues.

One issue, that is seemingly pervasive, is inappropriate permissions on S3 buckets. Searches on S3 incidents will turn up numerous stories about companies exposing sensitive data due to improper configuration.  How can you prevent that?

Firstly, when creating your buckets, consider your permissions very carefully. If you want to publicly share data from a bucket, consider granting ‘Everyone’ read permissions to the specific resources, instead of the entire bucket. Never allow the ‘Everyone’ group to have write permissions, on the bucket, or on individual resources. The ‘Everyone’ group applies literally to everyone, your employees and any attackers alike.

Secondly, take advantage of the logging capability of S3, and monitor the logs. This will help identify any inappropriately accessed resources, whether through inadvertently exposed buckets, or through misuse of authorization internally.

Another common issue is ports unnecessarily exposed on EC2 resources. This happens through misconfigurations in VPC NACLs or Security Groups, which act as a firewall, sometimes found configured with inbound traffic allowed to any port from any ip. NACLs and Security Groups should be configured to allow the least amount of traffic to the destination as possible, restricting by port and by ip. Don’t forget about restricting outbound traffic as well. For example, your database server probably only needs to talk to the web server and system update servers.

The last issue we’ll discuss today is the IAM,  the Identity and Access Management interface. Firstly, you should be using IAM to configure users and access, instead of sharing the root account among everyone. Secondly, make sure IAM users and keys are configured correctly, with the least amount of privileges necessary for that particularly user. I also recommend requiring multifactor authentication, particularly on the root account, any users in the PowerUsers or Admins group, or any groups you have with similar permissions.

That’s all for today. And remember, the good news here is that you can configure these systems and services to be as secure as what is sitting on your local network.