Defaults in Documentation = Vulnerability?

9–8–2025 (Monday)

Hello, and welcome to The Intentional Brief - your weekly video update on the one big thing in cybersecurity for middle market companies, their investors, and executive teams.

I’m your host, Shay Colson, Managing Partner at Intentional Cybersecurity, and you can find us online at intentionalcyber.com.

Today is Monday, September 8, 2025. Fall is around the corner, football is back, and we’re going to take a look at a CISA advisory with an eye towards both how these sort of vulnerabilities come to life, and how they are leveraged by attackers.

Defaults in Documentation = Vulnerability?

Last week, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a new Known Exploited Vulnerability (KEV) to their list, also known as the KEV list.

The vulnerability is found in a platform called SiteCore, including their Managed Cloud solution, where the software “contain[s] a deserialization of untrusted data vulnerability involving the use of default machine keys. This flaw allows attackers to exploit exposed ASP.NET machine keys to achieve remote code execution.”

They’ve given Executive Agencies until 9/25 to “apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable.”

Fortunately, there is strong guidance provided by the vendor on how to mitigate this threat, which hinge around exploited ASP.NET machine keys.

Media coverage indicates that attacks like this have been seen in the wild since February of this year. The core of this attack hinges on attackers being able to leverage a known value for this machine key to get the server to execute malicious code remotely. Known as a “ViewState Deserialization” vulnerability, it’s both clever and face-palmy at the same time.

A full and quite technical write-up of this attack path is available from the Mandiant team, and I’ve linked through to it below. In short, when attackers know the machine key, the can gain a foothold and work through a series of additional steps to enumerate running processes, services, user accounts, TCP/IP configurations, and active network connections on the server, ultimately pivoting to data exfiltration and beyond.

But how do they know the machine key?

In the case of the SiteCore vulnerability, they’re correctly guessing it because of the sheer number of companies who used the machine key value shown in the documentation as they built and deployed the servers for these tools.

Who would’ve thought that including an example key was going to lead to such a vulnerable position? And, really, it’s not an issue with the software, but with the configuration - and the fact that those people responsible for managing the environment on which the software runs were too literal in their following of the instructions.

I’ve found myself saying lately that every configuration is a misconfiguration opportunity, and I think this example slots right into that.

If we look at the broader defensive landscape that we talk about every week on this show, I’m really struggling to think about how we would expect this company to avoid this sort of risk. One way, of course, would be leave the Machine Key value out of the instructions, instead indicating to users how to setup a unique machine key on their own infrastructure (which, ironically, is what they had to do in the guidance they provided for mitigating this risk).

As with most things in security, this comes with a tradeoff - it adds extra steps and friction for customers deploying the tool, which sales and product teams are (for obvious reasons) not fans of. Plus, if you put in the templated machine key, the installation would technically “work,” just not very securely.

But, beyond that, there’s the traditional set of responsibilities for anyone running a public-facing web server in their environment. I’m talking about things that will deter, detect, and disrupt this type of malicious activity, such as deploying the server in a DMZ, limiting lateral movement with additional segmentation, running with roles in least privilege, run a modern EDR solution with 24/7 monitoring, be capturing both server and network logs in a way that you can threat hunt if you think you might’ve been impacted, etc.

Shared responsibility isn’t just a cloud thing, it extends to endpoints here, and overall - you may have given threat actors a foothold by following the instructions of this particular software product, but whatever else they do within your systems is on you.

Stay sharp out there, defenders. Like so many other things in life, it’s those basics, applied consistently over time, every time, that will make the difference between defended or breached.

Fundraising

From a fundraising perspective, announcements are picking up as we head into the sprint to year end. We saw $9.3B in newly committed capital, led by Great Hill Partners putting up $7b for its ninth flagship PE fund.

We’ve already seen that much in announcements today for the next week, so I’d expect things to pick up with a purpose here in September.

A reminder that you can find links to all the articles we covered below, find back issues of these videos and the written transcripts at intentionalcyber.com, and we’ll see you next week for another edition of the Intentional Brief.

Links

https://www.cisa.gov/known-exploited-vulnerabilities-catalog

https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003865

https://thehackernews.com/2025/09/cisa-orders-immediate-patch-of-critical.html

https://thehackernews.com/2025/02/microsoft-identifies-3000-publicly.html