The Blueprint for a Successful Cloud Penetration Test
Watch this to learn about how you can get the most out of your next cloud penetration test.
Watch this to learn about how you can get the most out of your next cloud penetration test.
Don’t just check a box, get the most out of your next cloud penetration test.
Watch Terrill Thorn (Director of Penetration Testing) and Eugene Butenko (Senior Penetration Tester) will discuss:
00:00 – Meet the Experts: Offensive Security in AWS and Azure
01:12 – The "Cloud Gap": Why Most Pentests Overlook Infrastructure
01:46 – Common Cloud Misconfigurations IT Teams Often Miss
02:42 – Case Study: Anatomy of the Capital One WAF & SSRF Breach
03:28 – 2025 Case Study: The Risks of Unsecured Legacy Firebase Buckets
04:43 – Technical Breakdown: How Attackers Pivot from App to Cloud Control
06:26 – Privilege Escalation via Cognito Pool IDs: A Source Code Theft Walkthrough
09:57 – Azure Logic App Exploit: Identifying Plain-Text Password Risks
11:45 – The Blueprint: 5 Critical Steps to Harden Your Cloud
11:58 – Step 1: Solving the Visibility Crisis with Asset Inventory
12:40 – Step 2: Enforcing the Principle of Least Privilege
13:32 – Step 3: Why Continuous Testing is Required for Cloud Stability
15:07 – SecurityMetrics 3-Phase Process: Automated, Manual, and Threat Modeling
16:47 – Beyond the App: Why Integrated Security Reviews are Vital
18:43 – The ROI of a Pentest: How to Prepare Your Team for Maximum Value
21:28 – Q&A: Scheduling, Team Involvement, and Testing Timelines
24:57 – Transparent Pricing: What Determines the Cost of a Cloud Pentest?
Hi, everyone, and welcome to another webinar for security metrics pen testing. Today we're gonna be talking about cloud penetration testing, but before we jump into that, let's do some introductions.
My name is Terrell Thorne and I'm the director over the penetration testing team. And with me today, I have our penetration testing cloud specialist, Eugene Butenko. Eugene, what qualifications or like certifications do you have as a penetration tester just in general and also for the cloud penetration testing specifically?
I do have a couple of certs from Hacktricks, I think. So this two of them, one called AWS Red Team Expert and another one Azure Red Team Expert, which are both for the, you know, the cloud specific certs. I also have bunch of other certifications in other areas, which I think translate they all translate into security space really well, what whatever this, you know, it's a cloud internal, external, it's like security mindset.
Awesome.
So today in talking about cloud penetration testing and cloud security, it's one of the things that often gets overlooked in penetration testing. A lot of customers are concerned about their internal and external profiles, but they neglect to consider the cloud security.
And Eugene, what else do you see on the cloud security side that customers often forget to check and consider when doing a penetration test?
Well, on the cloud side, I see a lot of minor misconfigurations that could lead to larger problems.
And as Yutaro mentioned, there's a massive industry focus on securing external systems and on prem systems, and application testing is super popular. But a lot of times those applications and systems are actually deployed on a cloud infrastructure. And that is being overlooked quite often as focus is not shifted to the cloud context just yet in the industry.
You mentioned industry consequences, things like that. Are there any specific examples you can give us where the cloud infrastructure was overlooked?
Yes, Carol. The big one is a Capital One twenty nineteen misconfiguration in AWS web application firewall was combined with SSRF, which is server side request forgery. The attackers were able to exfiltrate data from their clients, and over one hundred million customers records were exposed.
And that actually resulted in over, I think, eighty million dollars in fines to Capital One. So that was a classic cloud related issue that big companies, Capital One, overlooked and actually was, you know, was fined for it. And maybe they would have got, like, the the reputation damage there. Another example, in twenty twenty five, there was a TF exploit where an unsecured Firebase storage bucket was exposed with the user data, such as photos, government IDs, messages, locations, and that breach went viral on X. And I think, like, everybody in security space actually heard about it. And the problem was just a simple misconfiguration where the bucket the legacy bucket, actually, was left open at you know, attackers were able to actually trade data.
And that's another, I should say, pretty big example of how cloud misconfiguration, very trivial one, led to such a huge breach.
So Eugene, you've done several penetration tests with cloud environments at this point. What have you seen or been able to exploit or take advantage of personally?
Couple comes in mind, and Hurst one is not actually straight cloud penetration tabs, but that is related to cloud penetration testing because I was testing the application and found SSRF vulnerability. And combined with misconfiguration that they use metadata endpoint version one, which enables SSRF vulnerability to be used to actually create metadata for EC2 instance, I was able to pivot into cloud. And from there, I was able to escalate within the cloud environment by using that instances IAM role that I was able to actually create through SSRF. Basically, the impact of that is that the attacker exploiting the vulnerability in application was able to pivot into cloud environment and do some damage there.
And that's one of one story.
And this this is very, I would say, popular exploit sort of thing. It's it's very pop not popular, but broad misconfiguration that happens a lot. That's the use of legacy version one metadata endpoint.
The second one comes in mind. This is pretty cool one as well because that one is sorts does look like the t app exploit sort of thing because that exploit relied on legacy sys legacy configuration that the company used previously, and that was a Cognito identity pool ID that was forgotten inside the application. So basically, what Cognito is, is authentication service based on AWS.
And Cognito pool IDs allow you to request temporary credentials for the user. They not like soup like, they're not allowing you to access a lot, but in some mis some configurations, you can escalate your privileges as a user inside of AWS environment. In my case, I actually was able to gain access to s three bucket where the company hosted all of their source code.
The access was read only, and there's not much you can do right off the bat. You cannot rewrite the denial of service. And in the Pentas, we wouldn't actually do that anyway.
But what I was able to do, I was able to exfiltrate that source code and actually examine the application that we were testing, the source code, because it was a black box in the beginning. But once I got the, you know, the source code, it's a white box now. So I was able to find more vulnerabilities and stuff. But the actual vulnerability in on the cloud side is that Dosecup need a pool IDs. First of all, they should not be exposed if they're not in use and not properly monitored.
And that was a leftover of the legacy authentication system on that application. But, also, s three buckets with such a wide range of sort of data that I found, there was, like, hundreds of entries over there. They should not be open for even for read access for those users who just, you know, can get this temporary token, and that token grows in that huge, like, line of access, that should not be possible.
And with a, you know, cloud audit, security audit, and stuff, that's something we would definitely find during the pen test, during the actual cloud pen testing security review that this bucket is wide open to all users who has authentication, which is really bad, especially if you keep, you know, the source code code of your application and all different logs and all kinds of things. So that's the second example that comes to mind.
It sounds like Eugene, though, like, a lot of these have to do not just with, like, strictly exploiting only cloud options, but, like, pairing them or chaining them together with other vulnerabilities that the cloud testing helps you just get further, like you mentioned, like with source code or other different types of vulnerabilities, being able to exploit those and, and chain those together.
This one actually cloud specific that was found during the cloud security review. And so on Azure, you you have those Logic apps. Logic apps can, you know, automate your workflows and stuff. And for some of the workflows you perform, you need specific credentials.
And, basically, some user, some, you know, some people, some developers can find a short like, use a shortcut and add those credentials straight into Logic App workflow. And that's what I found. They were basically hard coded in the Logic App workflow, and they were high privileged credentials that granted pretty high access to the Azure tenant and plus Entra ID that nearly admin permissions. And anybody who had read access to that Azure logic workflow was a would be was able to actually get those credentials.
So those are not secret anymore, right, in the this environment because anybody could read it, then, know, it's like they never existed. You don't need that thirty character password if everybody knows it sort of thing. So yeah. So that's the latest one.
But as as you mentioned, a lot of findings actually happen when it's when the cloud testing is combined together with other sorts of testing.
Because that's how it works. You, you know, you deploy your infrastructure to your apps on the cloud, then that makes it interconnected with the application or the networks together. So yeah. So, basically, that's it just adds up another layer of security by testing your cloud environment in conjunction with other things you're testing at that point.
Nice. Thank you for sharing those examples.
From our side on the penetration testing side, that's a lot of fun when we're able to find stuff like that.
So now that we've talked about impact and kind of share some more stories about how these vulnerabilities and issues can affect customers.
Let's talk about ways that customers can secure their cloud environments, and kind of give them a few takeaways on things to watch out for common pitfalls, common misconfiguration things. So first thing I would definitely recommend is to perform asset inventory. It is very important to know exactly what you have in your environment.
Then it's important to regularly communicate bet between job like, people who is working in a cloud environment that that can be DevOps, that can be platform engineer, cloud architect, maintain good architecture dig diagrams and topology. So you always can check, where data the data flows, basically, like, how those components interconnected.
And, probably the most important one is follow defense in-depth and list privilege, principles. Just don't trust anything and just open access only when it's absolutely necessary.
Yeah, so a quick recap, then is, make sure you're conducting regular asset inventory, communicate with the different job roles and the different people involved with the technologies.
Make sure you have good up to date architecture and topology diagrams, things that help you understand how your cloud services are communicating.
Look at the job roles in your company and follow common industry best security practices of least privileged and different things like that.
And then also make sure you're going back and verifying and testing your rules in your account on a regular basis to make sure that nothing has changed since you last configured it.
Absolutely. I think that is actually very important to verify and test it because as things change all the time, especially in the cloud and you build more and more things, there's more interconnected systems that pop up from everywhere sort of thing. And then as I should say, those cloud environments are pretty complex just in general. So to add, like, one link between few services, you might need to add few different things around the console and stuff. So you always need to verify that all the protections that you put in place before are in place still and that whatever you added, is not breaking anything, is not wide open, and is as secure as it can be.
So let's say as a customer, I've kind of done those things, tried to secure it as best I can, and I'm looking to purchase a cloud security pen test through security What does that look like?
I know we talked about oftentimes, the cloud security comes with like attached to like an application or a network somewhere in your environment. So what does it look like on security metrics side when we're looking at these cloud penetration tests?
We provide the expert level overview of the security in your cloud environment. Our testing consists of few phases. So the first phase would be automated. We use different security tools to basically match the environment, get a feel of it, maybe find few misconfigurations or, like, not alignment with the best practices.
On the second phase, there will be manual review. So we'll be reviewing all of your policies, all of your access points, your firewalls, your different sort of endpoints. We will review, and everything is going to be reviewed by the analyst. So there's there's a huge well, I I should say there's a pretty big gap in what automated tools can do.
They basically for example, with with the roles. Right? Just a little example with the roles. They just look for very specific high privilege roles, but the analyst gets in and be like, well, this is not very specific, not a wide open role.
Right? It's not like admin privileges, but still you have, like, fifty different policies assigned to one user with, like, high privileges. You know, that's automated tool might not flag it because it's not necessarily, like, wildcard privilege. But then that's looking at this, You're like, hey.
What's going on? Why this user needs all those permissions? And the only thing he's supposed to do is to read from this bucket and get this one file, whatever. You know?
So, so the manual would be the second phase. And then we do the thread as a third phase. That would be a thread modeling for your specific environment based on what you have exposed. For example, for inter to the Internet, maybe you have, like, applications running or something like that.
Or if you have internal infrastructure, like, you run-in active directory, maybe some of those machines are more vulnerable or more privileged for no reason. And what would happen if, one of them got compromised or something like that? And security metrics offers this service as an add on to any another engagement. So if you do web application, external, internal, active directory, whatever it is, if it is deployed on the cloud, we do strongly advise you to also perform the cloud review test as well.
Because any of the vulnerabilities or possible future vulnerabilities in any of those other components as applications, external, internals, would affect your cloud. And your cloud is your infrastructure. Basically, somebody breaking in right, you know, in your back door, like, in your backyard sort of thing.
And you would you would now wanna have that. Right? So you would wanna make sure everything is secure. We treat it as a whole, sort of like as a whole system together.
Like, have an account. This is the whole system. If you test just application, you leave something behind as a cloud infrastructure. So yeah.
So that's why we advise to just have it as an add on to any of those engagements that actually have infrastructure in the cloud.
Let's switch gears a little bit and talk a little bit about how customers can get the most out of their penetration test. What advice would you give customers for that?
As those are white box tests for cloud, customers should provide us with the most information they have on hand. It's not always possible. Some you know, some sometimes documentation is not great, but we would like to have as much as we can get, like, network topology maps, maybe some high level overview of services or applications and high value targets. You know?
Maybe there's database that holds all the all of the the most important things, like credit cards and all of that stuff. We would like to know it because this way we can talk well, we we we can try to find the most impactful misconfigurations to just ensure that those systems are secure. The second one, provide us with the proper access. We do ask for very specific permissions to your the customer's environment, which is read only, but there's, like, few roles you have to add to that user that you provide, and that will help us just see everything in your environment, but don't change anything.
Yeah. And I think a couple other ones that are just common for all penetration tests.
If you come with some objective or a specific concern, then that helps guide us in what we want to accomplish and what we should be looking for to help you get the most out of your penetration test. And then also just in general, with penetration tests, kind of like a lot of things you get out of it what you put into it. So if the analyst has questions, have someone dedicated to be responsive to those questions, share context around things and make it so it's a little more than just a check the box option for you.
Let's talk about then just from like a high level for what it looks like when someone reaches out to security metrics, What is that process like?
And I can speak to this one a little bit, give Eugene's voice a little bit of a break.
So typically, when you reach out to security metrics for a penetration test after you've worked with the sales agents to sign contracts and stuff and it comes over to our team, then we're going to set up calls to gather like the specific information about your scope. So whether it be IP addresses, the cloud permissions, Eugene talked about, to making sure those get set up correctly, making sure that application access is correct. So if we need credentials to log into different roles within the application, so we can test it appropriately, things like that, we'll gather all of that information.
And then on the cloud side, as Eugene mentioned, we'll give the customer time to grant those access for read only and then we're going to check those on our end. So for example, like Eugene will make sure that he has access to the application credentials and that those are working correctly, as well as the cloud credentials and that they're set up correctly for what he needs to do for testing.
We also, at that time, are going to gather information about the cloud architecture. So like Eugene mentioned, the topology graphs, the diagrams for the network, anything that you can provide to help make things go a little more smoothly.
And as much information as you can provide will help you just get more out of that test.
And then a couple weeks out, we're going to actually start running some automated scans of like applications and things to give analysts like Eugene a starting point.
And then we're going to perform the actual assessment where Eugene's going to look at your cloud application, run some automated tools while he's reviewing the permissions manually as well.
And then once he's done reviewing those, and finding where the issues might lie, where things that might give you problems, and he's going to put together an issue the report that will have detailed findings on different attack paths that attackers could use to exploit your environment or gain access to things like Eugene mentioned in his examples where he was able to get access to some source code, different things like that.
And then finally the last step is we also offer retesting so that after you've had a chance to review the findings that we gave you and then you've had a chance to try to address the issues and fix them, then you can come back and we'll take a look at them and make sure that everything is working as intended.
Any final stories that you want to leave us with Eugene maybe where, you know, biases or different things led to customer wins?
Yeah. Absolutely. And I do have a few examples. I found the open s three bucket.
Right? And it was wide open. Just read access. You could list things in a bucket using AWS CLI.
But, essentially, that bucket was for the public access things, public assets, like logo and stuff like that. So not nothing super, you know, sensitive. And, also, as it had this listing option enabled, there's nothing really actionable for anybody to act on. And, also, there's instances of, as mentioned a lot, SSRF vulnerability.
That is, like, one of the main things that actually lead to cloud exploitation from the application.
But a lot of customers now, they're using they're actually using, Instance Metadata Service version two, which does not allow you to leverage a server side request forgery to just get those tokens because you need to issue two requests. And one of them is a put request, to actually get a token to access metadata endpoint. So, you know, they'd use that second version of metadata service. So there was, you know, there was SSRF, but theirs wasn't actually the practical way to exploit it. So I I would I would count that as a win, for sure.
And the last one, in Azure, you have this, like, storage. And I see it all the time when blob access actually is set to public, but the account access is set to private.
And that actually does not allow you to read straight from the blob because layer up above the blob actually is restricted.
And as it's not perfect, it is, you can say, good enough. I would definitely tell them to fix it and make sure every single level of access is, you know, is properly set to their needs, but, it's just not accessible. It's not like something critical.
Great. And that's also a good thing to point out in, having an actual, like, manual person review those is, like, sometimes, like you mentioned, there are things that on the surface may appear to be security issues. But then there's some other like control or something in place that as you actually jump in and review it, you find out that like, oh, an attacker couldn't actually exploit this, even though it may technically like be considered like a vulnerability. It's not actually a danger to the company, right.
And while it might be a best practice to like, oh, maybe you should update this or change the permissions around this, it doesn't actually present an issue or a risk for the company, having those things open.
Great, Eugene. Well, I appreciate you, sharing all the information with us. We have just a few questions to go over that people have sent in. So, we'll jump in and we'll move to the question portion at this time.
First off, how quickly can we get someone to perform a penetration test? Typically once we have the sales agent talk to the customer we can help get that scoped out to figure out what you need from penetration test once you sign that contract.
We typically get those over on the penetration testing team seven to ten days after those contracts have been signed.
And then depending on the timing, it could be anywhere from like two to three months out from when we're actually able to perform the penetration testing. But that doesn't mean you're idle for that time. Most of the time about seven weeks out from your start date from your actual manual testing date, we'll start asking you for information, the access for the cloud environments that Eugene mentioned previously, domain login information, the specific IP addresses you want us to go after, all of that information. So that's kind of the time for both us and you as the customer to prepare for the penetration test while you're waiting for that manual testing to tap. And so you're looking, you know, somewhere around like eight weeks, like I said, two months out, is typically where we're scheduling right now.
On the customer side, who should customers coordinate with internally to make sure that their cloud pentesting goes smoothly, Eugene?
They do have to coordinate with their cloud administrator. Right? Then they would have to coordinate with definitely DevOps team if they do have one. Because as we're gonna be probably making noise in there, like, just, like, running tools and stuff, so they would definitely, would have to be aware of it.
So if there's alerts pop up, they don't, like, you know, don't go into panic mode and stuff. And, also, they all should be aware that we are not gonna be disrupting, beyond, you know, maybe some alerts or logs. We're not gonna be disrupting any of their workflow. So we do have read only access, which prohibits us from changing anything for them.
So, it's all gonna be left in the same state as we found it. So but, yeah, DevOps, cloud environment administrators, and whoever else is involved with, actual infrastructure.
Yeah. And that's a a good thing to, remind people as well is that because this is a penetration test and not like a a red team engagement or something like that.
Penetration tests are generally very noisy. So definitely alerting your DevOps team, your cloud environment admins, those people that might be getting the alerts that something is happening, it's good to let them know so they don't cause them unnecessary panic.
And I also appreciate appreciate you answering kind of one of the next questions, which is how will a cloud pentest impact their environment?
Because we have, like you mentioned, because we have read only access, we can't really change anything or negatively impact the environment in any way other than, like Eugene said, just seeing some traffic, maybe some alerts would, be populated, but, otherwise it won't interrupt, your general workflow or anything like that.
How much does a penetration test cost? It really depends on the scope and complexity of the issue, but I would say on average, the average pen test is somewhere between five thousand dollars and fifteen thousand dollars But really you'd want to reach out to one of our sales agents here at SecurityMetrics to get a more specific quote for your specific environment and that'll help you kind of like dial in where that actually needs to be for you and what your environment looks like. Let's see what else do we have.
There's a question about the methodology in approaching a cloud pen test, I feel like we covered this pretty well in the presentation, but you know just to recap can you just give us a short summary of that, Eugene?
Absolutely.
So to summarize, it's a white box test. We have read only permissions in the environment. We can see everything, can change nothing. It starts with the automated tools, running, mapping the environment, giving us the starting point from where we shift towards manual, review of all our defenses, controls, configurations within the environment.
And the last phase would be threat modeling and reporting of the findings that we identify.
Great.
Thank you.
And that looks like all the questions we have right now. If you have additional questions, you can reach out through our website at securitymetrics dot com, schedule a meeting with one of our sales agents if you'd like more information and getting more specific information around like a quote or what the cost might be for your environment, and otherwise thank you for joining us today and we appreciate your time and have a great rest of your day.
.svg)