Exploiting N-Day Vulnerabilities at Scale with CPT

Preamble

You haven’t been living under a rock, have you?

Maybe you have. Or maybe you’re like us at Sprocket - you wish you could find a rock to hide under just for a tiny lull in what feels a like non-stop barrage of critical vulnerabilities popping up on your Twitter timeline.

If you fall into the latter camp, I’ve got a treat for you! Here at Sprocket, we specialize in Continuous Penetration Testing (CPT). The tl;dr is we throw the traditional, time-boxed penetration tests to the wind and instead pentest, well continuously. We are constantly scanning, testing, and exploiting new vulnerabilities hitting the internet daily. Sounds like a hackers dream, right?

So how in the world does a team like Sprocket manage the seemingly endless supply of Exchange privilege escalation vulnerabilities, or those deeply insidious VMware and Active Directory Certificate Services (ADCS) primitives? What about those SSRF and CSRF authentication bypasses? And you can’t forget the more exotic type-juggling and deserialization vulnerabilities either!

When you find yourself in the hot seat of CPT, how do you get a grip on all of this?
How do you dial in that signal to noise ratio?

Short answer: It’s hard!

Slightly-longer-answer: You and your team come up with a proven plan of action. And that’s what I’m going to walk through in this article. I’ll cover just some basic concepts and workflows we employ here at Sprocket that help us solve this challenge.

I can’t promise you’ll walk away from this article ready and willing to jump into the deep end of solving this challenge, but hopefully prove that cybersecurity is just hard to get right when real world attackers are doing what we do every day.

Introduction

When a new vulnerability becomes public, it’s imperative we at Sprocket begin to assess whether or not the vulnerability affects our existing clients. These vulnerability announcements and discoveries pop up all over the place.

This includes, but is not limited to, Twitter, argumentative GitHub issues, late night VirusTotal perusing, your favorite vendor disclosures, and more. It becomes even more critical to test our clients at scale when exploit code is floating around when a vulnerability is made public.

To keep this article somewhat brief and actionable, I want to focus on one of the most recent and critical vulnerabilities that we have directly and successfully exploited using this methodology: Microsoft Office 0-Day: “Follina”. That Office 0-Day vulnerability exploiting the Microsoft Support Diagnostic Tools (MSDT) protocol handler to execute arbitrary code.

Proof of Concept Building

This is where it all starts. This step can be performed individually, and perhaps preferably. Let’s say you see something like this come across your timeline:

”Vendor X has disclosed a critical, unauthenticated remote code execution vulnerability in Y”

Great, what do you do? Is it really a vulnerability? Is it overhyped? Has exploit code been published? Does the repository hosting the so-called exploit code provide a single, standalone binary that you should totally trust?

Our first course of action is to give the vulnerability details a cursory glance. At this stage, it’s crucial we don’t start thrashing around on exaggerated claims and click-bait headlines.

Activate Spidey Sense

If the details pass the sniff test, your spidey senses may start tingling. This step is where we start to rope in other team members. This can be accomplished a number of ways, but here at Sprocket we have a channel dedicated strictly to this subject. And yes, it’s aptly named “breaking-vulns”. This is where the initial source and our communications are collected. It gets the (if assigned) CVE and relevant details in front our eyes and into our working memory. This also has the benefit of focusing the conversation and moving distracting chatter from the main chat channel into it’s own category.

Remember what I mentioned at the beginning of the article about letting our clients know about the vulnerability before their newsletter?

As the vulnerability starts to pick up steam and more folks begin to validate, we also make use of a shared inbox for this exact purpose. We don’t claim to be a threat intelligence company, and there are plenty of folks who do fantastic work in that space. We went this route for two primary reasons:

• Provide a means to effectively communicate with our clients. They know if they receive an email from that address, exploitation is nigh!
• To ensure we don’t lose the initial conversation should our dedicated chat channel become flooded.

Recap

Okay, let’s see where we’re at.

• Confirmed there’s a new and exploitable vulnerability
• The overall feeling on the Sprocket CPT team is "We should act because this is serious"

Now comes the actual fun part!

Full disclosure: We have some secret sauce at Sprocket that let's us successfully perform the next steps at scale. The following steps are still perfectly doable without said sauce, of course.

Now that a vulnerability has been announced, we must identify which of our clients are running the vulnerable software/application/technology/etc.

Who’s Got What Where?

Let’s take a look at how we did this for the vulnerability I mentioned before. There are plenty of technical write-ups on Follina, so I will skip over the deep dive and root cause and jump right in.

Follina

nao_sec / @nao_sec

Interesting maldoc was submitted from Belarus. It uses Word's external link to load the HTML and then uses the "ms-msdt" scheme to execute PowerShell code.

icon-twitter: https://twitter.com/nao_sec/status/1530196847679401984

When this vulnerability was first announced, the thing that caught our eye was the protocol handler in use:

window.location.href = "ms-msdt:/id PCWDiagnostic /skip force /param

And the Tweet: “It uses Word’s external link to load the HTML and then uses the”ms-msdt” scheme to execute PowerShell code”

The screenshot below perfectly captures that spidey sense.

The fun thing about seeing a Tweet pick up so much steam is recognizing so many elements that have historically provided avenues of exploitation. The scary thing about seeing a Tweet pick up so much steam is recognizing an element that is unknown to you which provides an avenue of exploitation.

The vast majority of organizations are going to be using Office products. Combine that with a bit of institutional knowledge of our clients, and this is starting to smell more and more like something worth investigating.

Remember our steps:

1. PoC||GTFO - The tweet appears to satisfy this requirement
2. Activate spidey senses - The uncommon protocol handler, the obfuscated PowerShell, and the seemingly random inclusion of “mpsigstub.exe”? Definitely activated!
3. This tweet immediately gets sent to the shared “breaking-vulns” channel. We’ve now gotten this in front of the eyes of our CPT team.
4. Let our clients know we’re on it. Between putting out end user induced fires, wrangling pesky GPO deployments, and updating firewall rules, most organizations and their IT staff aren’t monitoring cyberspace for 0-days and remote code execution vulnerabilities. What are they doing? Waiting for that newsletter!

So now that we’ve got what acts, walks, and talks like an exploitable vulnerability that directly affects our clients, let’s dive in!

The first thing we did at Sprocket was replicate the vulnerability using the disclosed details. After quickly spinning up a test environment, some modifications to the few PoC’s floating around at the time, we finally landed on something that was working.

The only problem was the exploit wasn’t firing. After digging around and sifting through GitHub issues, it turns out the version of Word I was using just wasn’t vulnerable to both .docx and .rtf exploits. So I walk through the steps of manually downgrading Word and boom, exploit is firing!

Now that we have successfully replicated the vulnerability and have a reliable exploit, there’s just one more question: how do we get this to all our clients right now.
Typically, if a vulnerability affecting Active Directory or VMware is released, we take full advantage of the open-door policy we have with our clients. We can immediately start testing externally or hop right into client internal networks.

But this is different - it’s easy enough to test one or two clients manually, but we are talking about testing numerous client-side vulnerabilities at scale. While I was busy verifying and testing the exploit, another CPT team member was busy at work solving this exact challenge.

Our lead penetration tester quickly spun up a Python Flask app to host our malicious Follina document via our CPT platform. This allowed our clients (and only our clients) to download the document, verify if they are vulnerable or not, and provide feedback to us from a single location. Pretty slick!

So let’s put this plan into action!
An email notification like the one below quickly goes out to our clients:

We instruct our clients how to access their document, download, and verify successful execution. In this case, we chose to simply display a message box indicating their version of Word was vulnerable.

An example of successful execution might look like something below:

Clients can then let us know how their test went:
We can then monitor client access, and view their feedback in real-time!

Rapid Engagement

From tweet to client-side assessment and client engagement, we are roughly in the 24-hour ballpark. Which, to be honest, could have been faster. After about the 6 hour mark, rudimentary (yet effective) detections had started shipping and we noticed the success rate of execution rapidly dwindle. We were fast, but we need to be faster.

Getting Proactive

There’s probably a strong case you could make for Twitter to formally supplement an organizations vulnerability management platform. The commentary surrounding recently disclosed vulnerabilities and defensive measures become available in real-time.

But what if you don’t want to wait on viral Tweets to determine if and when you should patch your domain controller against the newest authentication coercion technique?

Two of my favorite applications for tracking and staying ahead of the curve on vulnerabilities like Follina are cvetrends.com and bugalert.org. Both of these sites aggregate and gather crowdsourced intel from places like Twitter, Reddit, and GitHub.

Remember that secret sauce I mentioned earlier? When you combine that with crowdsourced intel and an effective plan of action - you’ve got a solid recipe for managing, rapidly scanning, and exploiting vulnerabilities at scale.

Lessons Learned

If there’s one thing to take away from all of this, it’s just how insanely fast things move, and you have to move even faster. As infosec practitioners, pentesters, bug hunters, analysts, and all of the above - we all know everyone has their own workflow and way of doing things.

We are constantly refining our workflow, making it faster, more accurate, and more scalable.
Speed really is the number one way we stay ahead of the game.

Wrap Up

So, are you ready to dive into the deep end and solve this challenge? Maybe, maybe not. I wanted to briefly highlight and outline a few ways we perform our continuous penetration testing accurately, rapidly, and at scale. Hopefully after reading this post, you now have a few new things to consider!

Do you have a workflow you’d like to share?
How do you and your team stay up to date?

We’d love to hear from you!