CPT in the wild: 3 real-world examples that prove its value

Overview

We get it, regular ol’ once-a-year penetration testing is the norm. It’s what your company has budgeted for, what you’re IT team is used to, and in many cases, what your expected to do. But that doesn’t mean it’s the best way to protect your network.

Think about this: Why would you test your network security from emerging cyber-security threats only once a year. That’s like picking a random day and turning on your home’s security system. Yea, you’re safe for a moment – but only for a point in time.

Like that home security system, continuous penetration testing lets you sleep easy (forgive the cliché), knowing professional cyber-security pros are looking for holes in your network year-round, monitoring for new threats that pop up seemingly daily and deliver real-time remediation plans and support.

Sound like a late-night infomercial pitch? Well, hold onto your ShamWow, this is the real deal. Take a look at three recent real-world scenarios in which our teams discovered and resolved significant cyber-security threats:

1. Heapdump Disaster. Avoided.

Critical Context

A Sprocket Security client constantly expands and shrinks its tech stack, using modern infrastructure management methodologies. What’s that mean? Well, it means they have A LOT of assets we have to monitor and test regularly. In a scenario like this, even one change to a configuration file and the redeployment of an existing application can result in a vulnerable system. What was safe three months ago, may no longer be secure.

The Situation And Solution

This client uses a software framework named Spring Boot. Spring Boot allows users to quickly and easily deploy applications that work efficiently and effectively. Included in the Spring Boot framework is the Spring Boot Actuator. This functionality makes it easier for IT pros to monitor and troubleshoot web applications.

Actuator exposes web application endpoints that, when requested, provide information such as real-time performance metrics and logs. One of these endpoints is aptly named “heapdump.” When the heapdump web endpoint is requested, the application produces a memory dump of a running Java application. Suffice it to say, this is bad.

Through continuous testing, we identified the exposure of this endpoint on web applications that had not previously been available to the public.

We issued a web request to this endpoint and received the contents of the memory associated with the running process. We were then able to parse the file and extract clear text credentials and proprietary company and customer information from it.

Because we test and monitor systems year-round, the vulnerability was quickly reported to the client and fixed. We saw this happen multiple times when new or redeployed applications were brought online but continuous penetration testing methodology allowed us to catch each vulnerability.

Had the organization only relied on a point-in-time penetration test, each vulnerability would have remained in place until an attacker exposed it. Such an attack could cost hundreds of thousands of dollars while hurting customer trust and brand reputation.

2. Telerik Terror. Tamed.

Critical Context

Many of our clients use Microsoft IIS for custom web applications. While these applications use a plethora of underlying technology to deliver products to customers, that same tech that’s so helpful can expose a client to risk when a vulnerability is released.

To manage such vulnerabilities, we monitor for them 24/7, quickly develop methodologies to test a network for the vulnerability, and then scan a client’s assets for the issue.

The Situation And Solution

In 2019, a vulnerability (CVE-2019-18935) was released for Telerik, a web application framework. Telerik is a .NET framework used to deliver a functional and pleasing look to the front-end of web applications.

The vulnerability released for this software suite resulted in code execution when exploited as an unauthenticated attacker. This means that if an attacker were to exploit the vulnerability as a random person on the internet, they would gain access to the internal network of a company. This is how ransomware happens, my friends.

We recognized the risk of this vulnerability and sprung into action, scanning all client web applications to ID vulnerable servers. Our team found a client with a Telerik endpoint exposed and jumped to exploit the vulnerability.

Now, you may expect us to assume the endpoint is vulnerable and report it to the client. This is where vulnerability scanners fall short. They guess that something can be exploited and report it. This introduces confusion and makes it hard for organizations to prioritize what they need to fix. Read More: What Vulnerability Scanners Don’t Catch – And How It Can Cost Your Business Millions.

Our testers made attempts to craft custom exploits and gain access to the client’s network using the vulnerability. The attack was successful and we had now gained access to the client’s internal network. Using native Windows and custom tooling we elevated privileges inside the network and took over the client’s domain.

Seeing how easy it was for us to access sensitive information, we quickly shared the finding with our clients using the Sprocket Security Portal. The client received a notification and we worked with their internal team to patch the vulnerable server.

But, that’s not where we left it. Instead – and this is a Sprocket best practice – we retested the issue to confirm the client’s network was no longer susceptible to the attack.

3. Microsoft product issues. Internal CPT for the save.

The context

Continuous penetration testing often is associated with external services and web applications but that’s only part of the story. We provide internal penetration testing by placing a secure dropbox on a client’s network. By doing that, we’re able to test networks as if we’re an insider or an attacker who has access. This gives us a unique opportunity to continuously monitor internal networks for vulnerabilities and misconfigurations.

This additional layer of protection allows us to unearth complex attack paths and help clients further harden their networks against attacks.

The Situation And Solution

At the beginning of most CPT partnerships we establish with clients, a testing dropbox is placed on the company’s internal network. This allows us to securely connect to the host and test client networks from the perspective of an insider threat or attacker that has already breached the perimeter.

Due to the nature of internal networks in the modern tech world, we often can quickly discover and disclose common internal misconfigurations and vulnerabilities. After these issues are fixed, however, it’s often fairly difficult for an attacker to get a foothold on internal networks and gain access to domain resources.

Here’s a good example of this playing out: Recently, researchers discovered issues related to “features” in Microsoft products. We’re going to call them vulnerabilities.

As an unauthenticated attacker on a network, it’s possible to leverage separate Microsoft products to take control of an entire active directory domain. Unfortunately, many companies are unaware of this issue. If they are aware, they’re likely having trouble remediating the vulnerabilities due to a lack of guidance.

We immediately made attempts across all clients to exploit this misconfiguration using a custom-built attack path. Our team successfully exploited the vulnerabilities on client networks long thought to be adequately protected. As unauthenticated attackers, we took over several clients’ internal domains and were able to gain privileged access to company resources. Immediately, we developed findings and contacted clients.

Unlike vulnerability scanners, we were able to ID the issues, demonstrate the risk, and develop a remediation plan. All of which our team did in real-time, helping our clients with custom documentation that made it easy for them to implement a fix.

The Common Thread

The key takeaway is pretty clear, here: In each scenario, these vulnerabilities never would’ve come to a client’s attention without continuous penetration testing. Well, at least until an attacker exposed them.

Fundamentally, the issue is that point-in-time penetration testing only would’ve caught these if they occurred within that short window. And the result of not catching these vulnerabilities can be catastrophic to your organization’s reputation and revenue.

And if you need further proof, just send us a note. We have plenty of other examples to share.