Welcome to the deep dive. Today. We're really getting into the weeds of cloud penetration testing.
Yeah, we're using Kim Crawley's book Cloud Penetration Testing for Red Teamers as our guide.
Right, and the idea is to pull out the key stuff. You know how security pros actually test places like Aws, Azure, GCP, find the holes.
Make things stronger, and we want to get you the core insights those sort of aha moments about cloud security.
Testing exactly Crawley's book. It's pretty thorough good for experienced folks moving to cloud, but also if you're just starting out.
It really maps out the tools the methods for each big cloud player because they are different.
And for you listening, maybe you're prepping for a meeting, trying to get your head around this, or just curious. We're aiming to cut through the noise.
We'll focus on like the big shift from old school pen testing to.
Cloud, that shared responsibility thing. Definitely need to cover that.
Oh yeah, and the kinds of attacks you see, the defenses that work.
Without drowning you in Jurgen, just the actionable stuff. Okay, let's get started.
So foundational point cloud platforms are well basically everywhere. Now. AWS kicked it off, what two thousand and six.
Yeah, and then Azure GCP around two thousand and eight. Now most big companies use at least one, often more.
It's easy to see why. Right. The scalability is huge.
Oh, absolutely, spin up resources, spin them down, No need to build your own massive data centers.
Think about services like Netflix or Dropbox. They couldn't exist like they do without the clouds flexibility.
It really enables that kind of business agility.
And it's not just using the cloud, it's how they're using it. You've got companies that are all in everything's.
Cloud, right, the all cloud approach.
Then there's hybrid mix of their own servers in cloud, maybe for compliance reasons or old systems they can't move easily.
Makes sense. And then the other one you mentioned multi cloud, Yeah.
Using services from say both AWS and Azure, maybe GCP too.
Okay, that sounds complicated. Why add that layer?
Good question. Sometimes one provider just has a killer service the others don't like. Maybe one's way ahead on AI tools.
Ah, okay, best of breed for specific tasks exactly, Or maybe it's about not being locked into one vendor gives you more leverage, redundancy too.
Right, avoiding that vendor lock in. Okay, so that maps out the landscape. Let's switch gears to security. This shared responsibility model feels like ground zero for understanding cloud security.
It absolutely is. It's the framework defining who handles what. The basic idea the cloud provider Amazon, Microsoft, Google. They secure the underlying infrastructure.
The physical buildings, the core network, that sort of thing.
Yeah, security of the cloud itself, but this is non negotiable the customer.
So your company, you're always responsible for your data period.
Always, no matter what service you use. Where it gets nuanced is the other stuff, the apps, the network settings, inside your cloud environment, the operating systems, and.
That changes based on whether it's iass, poly ass or sauce right infrastructure platform or software as a service.
Precisely, the lines shift depending on that model.
Okay, let's get specific, Like the book does, how does Azure break it down? People might assume it's the same everywhere. Well, with Azure, you're responsible for your info, your data obviously, also the devices people use to connecting the user accounts. Okay, Azure handles the physical hosts, the network, the data center security, but things like identity applications, network controls OS. That depends if it's PANS, we ouris.
Got it and GCP. How do they draw the lines.
GCP says you're always responsible for your content and your access policies. That's true across size pans.
IGAs okay, consistent there.
If you use PANS on GCP, you also take on responsibility for how you use it, deploy it and secure your web apps running on it. Go to ISS and you add even more identity management your operational stuff, access control, network security can fig the actual guest os and the data itself.
So you're managing a lot more at the level what's left for GCP.
Then GCP handles things like audit logging for their infrastructure, their network security, data encryption, the hard and NOS kernels they use secure boot the physical hardware.
It really highlights that you need to know the specifics for your provider and your serf ball. You can't just.
Guess absolutely not, and that leads right into actually testing the security. You can't just go wild ah the.
Pen testing policies right. Each provider has rules and you.
Have to follow them. It doesn't matter what your boss wants, you play by their rules. It's their playground essentially.
Okay, so give us the rundown. What are the big dos and don'ts for AWS?
With AWS, generally, you can pentist most services without asking first.
Okay, that's fairly open.
But big restrictions. No missing with root fifty three DNS, zone walking, hijacking, no DUFTA or DDOST attacks, mostly no protocol flooding.
Right, don't break things for other customers.
Exactly, And if you want to use things like command and control servers or network stress tools like IPER, or run phishing simulations or test malware, you need to get explicit permission first.
Gotcha approval needed for the more aggressive stuff. What about Azure and the Microsoft Cloud?
Microsoft's also pretty open. Most pen testing is okay without prior notice.
But again there are lines.
Oh yeah, Crucially, don't test anyone else's stuff. Only your own assets and data. No massive floods of automated traffic, no dusty dass standard stuff. Network fuzzing is okay, but only against your own vms. And if you find an infrastructure issue, just show a proof of concept, don't exploit it further, and definitely no trying to social engineer or Microsoft staff.
Right, common sense really and g.
GCP allows pen testing without notification, but you have to stick to their acceptable use policy and terms of service, which means no disrupting other customers, So no d doo ass, no malware spreading, no trying to access other people's projects, and obviously nothing illegal. You can do vulnerability scanning within your own projects, but you need your company's written permission first.
So the takeaway is know the rules for the specific cloud you're testing. You're a guest in their house in a way.
A guest with responsibilities. Now understanding those boundaries, let's talk about how attackers actually come after these cloud setups.
Right where did the attacks usually start?
You can broadly think about external versus internal attacks. External gets the headlines, you know, the hacker and a hoodie stereotype, but internal attacks leveraging someone already inside, someone trusted, those can be really damaging and harder to spot.
The book had that kind of chilling example, the janitor with a USB stick.
Yeah, it illustrates the insider risk perfectly. Imagine a janitor has legitimate access to the server room, not an impostor a real employee doing their job. Because they have that trusted physical access, they could theoretically plug in a USB drive with malware into a.
Server bypassing all the external firewalls defenses.
Completely, and suddenly that server could infect all the client machines it manages. Shows how exploiting trust can be a powerful attack vector.
That's a really stark reminder. So besides physical access like that, what are the more common digital entry points the attack vectors.
Often it's vulnerabilities and web applications facing the Internet or open ports that.
Shouldn't be misconfigurations exactly.
Or attackers might go after accounts trying to crack passwords or fish credentials, especially for accounts with high privileges.
Gain a legitimate log in from their perspective right.
And sometimes, though maybe less common, it's bribing or coercing an actual insider to help them get access or plant something.
Okay, so they get in, what are they trying to do once they're inside? What's the goal?
Most attacks boiled down to hitting one or more aspects of the CIA triad Confidentiality, integrity, availability.
Right, the classic security principles, So confidentiality first, keeping secret secret.
Pretty much preventing unauthorized access to sense in seative data. A data breach is a direct hit on confidentiality.
The book mentioned the DC health Link breach from March twenty twenty three. What happened there?
Yeah, DC health Link handles insurance for government folks. They reported that data for like fifty six thousand customers was exposed names, social security numbers, health plan info, really sensitive.
Stuff, ouch and the likely cause. In a cloud.
Context, the book suggests data from cloud storage based on the IATT and CK framework, which we should talk more about later. Basically, data stored in the cloud wasn't properly secured.
A major confidentiality failure with real consequences. Okay, what about integrity?
Integrity is about preventing unauthorized changes to data, making sure data is accurate and trustworthy.
So a tax might involve what.
Things like injecting malicious code into a website or database, or man in the middle attacks where they intercept and alter data as it travels. Stealing TLS certificates could also let them impersonate a legit service sing within integrity.
Right, corrupting the data or the process. And the last one availability, Availability.
Is just making sure authorized users can actually access the data and services when they need to.
So denial of service attacks fit here exactly.
DTOs distributed denial of service is the classic example, overwhelm the server with so much junk traffic that legitimate users can't get through.
The book mentioned a huge one against a Google Cloud customer.
Yeah, August twenty twenty two peaked at something crazy like forty six million requests per second an HTTPS d DOOS attack.
Wow did it work?
Fortunately, Google Cloud Armor, their protection service, managed to block it. But it shows the scale of threats trying to knock services offline.
So attackers are constantly probing for ways to break confidentiality, integrity, or availability. Now, say they succeed in getting that initial foothold, what happens next? They don't just sit.
There, No, rarely, that's where lateral movement comes in. Once they're inside, the goal is usually to move deeper, find more valvaluable targets.
How does that work in the cloud?
They might try to jump from one compromise service to another within the same cloud account, say from a web server to a database, or in a multi cloud setup, maybe pivot from Aws to Azure if there's a.
Connection, trying to escalate privileges or find sensitive data stores exactly.
Find accounts with more power access, more systems spread their control.
That sounds really dangerous moving silently inside the perimeter. How do you defend against that kind of internal spread?
This is really where the zero trust model shines. The old way was perimeter security, build a strong wall, assume everything inside is safe.
The castle and mote approach right.
Zero trust throws that out. It assumes no user or device is inherently trustworthy, even if it's already inside the.
Network, So you verify everything all the time.
Pretty much every request to access a resource gets checked for authentication and authorization continuously. It doesn't matter if you're coming from outside or supposedly inside.
That must make it much harder for an attacker to just wander around after getting in.
It does. They might compromise one thing, maybe steal some initial credentials, but to move laterally they have to keep passing these checks, keep reauthenticating and proving their allowed access to the next thing.
More hurdles, more chances to get caught significantly more.
It prevents a small breach from easily becoming a full network compromise.
Okay, that makes sense, so we understand the threats the defenses like zero trust. Let's get back to the testing part. What are the core concepts pen testers need for the cloud?
Well, first things first, before you launch any tools, you need a solid vulnerability assessment.
Understanding the target.
Yeah, mapping out what's there, what services are running, what's exposed, defining the scope, what are you actually testing and what's off limits? You need that clear picture.
The book emphasizes the ININTI att and SK framework. You mentioned it briefly. Why is it so important for pen testers, especially red teams?
Minor? ATT and CK is basically a massive, organized library of attacker tactics and techniques. It breaks down how real world cyber attacks happen, step by step.
Like a playbook of bad guy moves.
Kind of yeah. It gives everyone a common language. For red teams trying to simulate real attackers. Its gold. They can use ATT and CK to model their tests after specific threat groups or known attack patterns. Makes the simulation much more realistic.
Very useful resource. What about cloud integrations systems talking to each other?
Huge area. Most organizations connect different cloud services or link their on prem stuff to the cloud, and.
The connections themselves can be weak points.
Absolutely Often these connections use API's application programming interfaces. If those APIs aren't secured properly, they become a major vulnerability. They can be vulnerable to injection attacks like feeding the malicious commands, or they might have weak access controls, letting an attack, or do things they shouldn't. Testing these APIs is.
Critical, so don't just test the services, test how they talk to each other. The book also talks about vulnerability databases like CVE right.
CVE stands for Common Vulnerabilities and Exposures. It's a public list of known security flaws in software and hardware, so.
If you find something, you can check if it's already known exactly.
Each known vulnerability gets a unique ID like CVE twenty twenty three something something helps everyone track the same issue.
And those CVSS.
Scores CVSS Common Vulnerability scoring System. It's a way to rate how severe vulnerability is. Goes from point zero to ten. Point zero, higher is worse, much worse. Yeah, gives you a quick idea of how critical it is to fix. You often find CVE details and CVSS scores on the NIST National Vulnerability Database the NVD.
Okay, so CVE identifies it, CVSS ranks its severity. Helpful context for a pen tester what about purple teaming? That sounds colorful.
Huh Yeah, So usually have a red team the attackers the pen testers, and a blue team that defenders the security operations center.
Folks, offensive ver's defensive.
Right teaming is when they work together. Instead of the red team trying to be sneaky and the blue team trying to catch them, they collaborate during the test.
How does that help?
The red team finds vulnerability, they immediately share it with the blue team. The blue team can then test their detection and response in real time. It speeds up the feedback loop improves both offense and defense much faster.
More collaborative, less adversarial. Makes sense. Yeah, And finally, the pentist report. Why is that so important?
The report is the whole point. Really, it's the formal ride up of everything The pendester found.
A list of problems.
Oh no, much more. It details the vulnerabilities, explains the impact what could actually happen if an attack or exploited this, and crucially, it gives clear recommendations on how to fix things.
So it's the roadmap for improvement exactly.
It needs to be clear enough for managers to understand the risk and technical enough for the security team to actually implement the fixes. It's a critical communication tool.
Okay, concepts covered, let's talk tools. The book lists quite a few. Can you give us some examples for say, AWS Sure On.
The AWS side, there's AWS Security Hub. It's not exactly a pen testing tool, but it pulls together findings from aus's own security services i AM Access Analyzer, Guard Duty inspector MACY.
Still like a dashboard for AWS security posture.
Yeah, a good starting point to see what AWS itself is flagging. For more active scanning, Prowler is really popular. Prowler Yeah, open source. It scans AWS but also Azure and GCP looking for misconfigurations, hardening checks, following benchmarks like CIS. You can run it easily, install via pip or Docker.
Multi cloud capable, nice, any others for AWS.
Puku is another well known open source framework specifically for AWS pen testing. Again, installable via pip.
So Prowler for broader checks, Pakuo for more focused AWS exploitation.
Kind of yeah. Then you have simpler tools like cred scanner, just a Python script to hunt for exposed credentials line around.
In files oooh finding those accidental secrets.
Exactly, and cloud Front, which focuses specifically on finding misconfigurations in AWS cloud Front their CDN service.
Okay, good examples for AWS. What about Azure or GCP For Azure?
The book mentions MFA swoop it checks if multi factor authentication is enabled to cross different Azure services. Basic but really important.
Can't stress MFA enough right.
Scout Suite is another multi cloud tool like prowler. It audits AWS, Azure, and GCP, pulling config data and highlighting risks.
Good forgetting that cross cloud view. What about containers? Docker Kubernetes are huge now?
Definitely Trevia has mentioned it's a scanner for container images looking for known vulnerabilities. Works for Docker, Kubernetes images and other things.
Too important for supply chain security.
Absolutely for Kubernetes specifically, there's tools like cube hunter and Digger designed to probe Kubernetes clusters for security weaknesses.
And GCP specific tools.
Yeah, things like GCP bucket Brute for checking Google Cloud Storage bucket permissions and GCP Scanner for looking at credential access levels within a GCP project.
Wow. Quite the toolkit seems like there's a tool for almost everything.
There often is, but knowing how and when to use them effectively and how to interpret the results.
That's the key skill right now, Let's quickly loop back to those service models, ISS, PASSSAS and how security differs. We touched on it with shared responsibility.
Yeah, it's worth recapping. With SAS, think Gmail salesforce. The provider handles almost all the security. Your main job is managing your data within the app and user access. Pen testing SAS is often very restricted by the provider.
Makes sense. You don't own the underlying app or infra. What about PASS.
Platform is a service Here, the provider gives you the platform, maybe a database service or a Kubernetes environment like aws EKS. You build your apps on.
It, so you secure your app. They secure the platform mostly.
Yeah, you're responsible for your application code, it's configuration, how it uses the platform services. They handle the OA patching underneath the platform, resilience, etc. Pen testing focuses on your application and its interaction with the PASS Okay and I infrastructure as a service. That's where you have the most control and therefore the most responsibility. You get virtual machines, storage networking.
Like renting the hardware.
Essentially pretty much, you manage the operating system, patching it installing software, configuring firewalls within your virtual network, securing your data on those vms. The provider just secures the physical data center and the virtualization layer.
So is pen testing looks more like traditional network pen testing closer?
Yes, but you still need to understand the cloud provider specific services and control plane because that's part of your attack surface too, got it?
And across all these zero trust remains.
The best approach, definitely, because that perimeter is so blurry or non existent in the cloud. Assuming zero trust and verifying everything is the way to go, regardless of IAS, pass or sauce elements.
And the book also brought up RBAC again, role based access control. Why is that fundamental?
RBAC is how you manage who can do what in the cloud. Instead of giving permissions to individual users, you create roles like database admin or.
Web developer and assigned permissions to.
The roles exactly. Then you assign users to those roles. It's much cleaner, easier to manage, especially at scale, and it enforces the principle of least privilege poll LP. Giving users only the minimum permissions they absolutely need to do their job nothing more. Reduces the potential damage if an account gets compromised. RBAC is also native to Kubernetes, making it vital there too.
Okay, this has been a really comprehensive look at cloud pen testing. If you had to boil it down, what are the absolute key takeaways for our listener?
I'd say one, cloud pen testing is different and essential. Two, you must understand the shared responsibility model for your specific services.
It's not just someone else's computer, not at all.
Three the threats are real and varied, so continuous learning and using the right tools like those mentioned is crucial. And four always follow the cloud provider's rules of engagement for testing.
And maybe the big aha moment is that the cloud shift doesn't mean less security work for your organization, just different security work and proactive testing is key.
Precisely you have significant responsibilities. Effective pen testing helps you meet.
Them, and as people listen, maybe they should think about their own setup, Like if they're multi cloud, yeah.
Consider how does that complexity impact your security visibility? Can you manage zero trust effectively across different clouds or in a hybrid setup? These are tough but important questions.
Absolutely well. That brings us towards the end of this deep dive. We've gone from the basics of cloud platforms to shared responsibilities, attack methods, core pen testing concepts, tools and models.
Wellpe, it's given you the listener a much clearer picture of what cloud security testing involves, hopefully a solid base to build on, and an idea of what's critical for organizations using the cloud.
Definitely, and we encourage you to dig deeper. Check out the umber eat t TCK framework online. Look up the security docs for AWS, Azure GCP. They have tons of information.
Think about your company's cloud services, how does this apply? Which tools might be worth exploring for your specific needs?
And may be a final thought to leave you with.
With things like serverlests and containers becoming even more dominant, how is cloud pintesting going to change next? What new skills new tools will security pros need and say the next five years?
Hmm, always evolving, something to definitely keep an eye on. Thanks for joining us on this deep dive.
Yeah, thanks for listening. Until next time,