Getting Started with Cloud Pentesting with Scott Weston

TLDR;

• gcpwn (modeled after Pacu) is a great tool for pentesting covering enumeration and lateral movement. There are many more capabilities coming up soon with support for more Services and APIs.
• Annual Pen Testing is a good start. But, pentesting should be as close to continuous as possible. It helps organizations stay up to date with their attack surface.
• When starting to pentest, start with IAM. It connects all other services together and the most impactful. For environments, create a seggregated cloud environment for pentesting and tear it down once it’s not used anymore.

Transcript

Host: Hi, everyone. This is Purusottam, and thanks for tuning into Scale To Zero podcast. Today's episode is with Scott Weston. Scott is a senior consultant at cybersecurity consulting company NetSpI. Originally from Southern California, Scott is currently based out of Minneapolis, where he has experience testing AWS CCP web applications, including GraphQL and external networks as well.

Under the Webenroot alias, he has spoken about AWS at Forward CloudSec 2023, and he has also released a tool this year's Forward CloudSec called GCP Pawn to assist in pen testing GCP environments. We'll talk about that during the podcast today.

And in his spare time, he enjoys showing bug bounties or pursuing other research paths or opportunities.

First of all, Scott, thank you so much for taking the time and joining with us today.

Scott: Yeah, thanks for having me.

Host: So before we start, do you want to briefly share about your journey? Like how did you get started? What interested you in security, even pen testing, if you want to share anything?

Scott: Sure, yeah. I grew up in Southern California and I went to college out at Arizona State. And so while I was at Arizona State, I studied computer science. And so that's how I kind of got into computers. Towards the end of my junior or senior year, I tried getting more involved in the hacking clubs on campus. know, shout out to like Shellfish and some of those other teams. And so I ended up finding that I really liked breaking things as opposed to making them.

That just… I had a better inclination towards that. that's kind of what I started pursuing. So out of college, I got hired by General Motors. So I worked for General Motors for a year doing application security, moved up to Michigan. And then I got hired by Netspy. Shortly after that, I've been at Netspy for about three years. I kind of like you said, I do web, AWS, GCP, external networks, a lot of different stuff.

Host: Okay, that's an interesting journey. Hopefully, we will be able to get into some of those today. Before we start, we generally ask this question to all of our guests and we get unique answers. And the question is, what does a day in your life look like?

Scott: Yeah, I think my day is probably pretty standard in terms of business. So it's usually nine to five business, but usually it's I wake up right in the morning, checking the, checking the email, all the different communications. like NetSpy has something called the platform, right? Which is kind of a software solution that, helps communicate with clients. So I always try to make myself available to clients. Right. So I'm like checking messages on platforms like that, seeing if there's any questions, any concerns during the test and having some back and forth there.

And then the actual testing is going to be usually dependent on what I'm testing. might be cloud or external network or web. And actually even day to day, what I'm doing kind of depends on where I am in the test. Maybe it's more configuration based that day or more manual based that day.

But that's pretty much it. You know, obviously the meetings that pop up as well in that eight hour day and then kind of finishing out the day and yeah, just trying to do research stuff usually after work. I'm GCPone, it's like a tool I've been chipping away at. And then just yeah, gaming and all the relaxing stuff after work.

Host: Nice, nice. So yeah, so let's get into it. So today we are going to focus on pen testing, how to get started, tools available for cloud pen testing as well. To kick off, like this year at Forward CloudSec, you open sourced a tool called GCPawn, right? The idea is that it helps security practitioners, especially like pen testers, to pen test GCP environments. And we want to know a little bit about it.

What does the tool do? And before you answer that, did I say the name correctly? If you want to correct me, please, please do that.

Scott: I think I pronounce it GCPawn.

Host: Okay.

Scott: Yeah. but yeah, the tool, really try to model it like pack you, which if you're familiar is a pen testing tool for AWS, which is very modular base. It's usually loading credentials and then you will launch a module to enumerate something or exploit something. I mean, it's really nice because all your credentials are in that platform. And so, I kept coming back to GCP over the years where I would find GCP creds, right. Or something like that. And I would always just Google GCP tools like pack you.

I can never really find anything. So I needed to learn GCP anyways this last year. So I just figured I'd try to make a tool like that. So the tool itself is kind of, I try to think of it like a Swiss army knife for GCP pen testing.

So it does enumeration and exploit stuff. So by enumerate, I mean it will enumerate resources in the GCP account and also download the data. So for example, it will enumerate all the GCP buckets and download all the data in the buckets right to a local file.

If you want to sift through all the data that's in those buckets. It also does like exploit stuff. rather than having to make three or four separate API calls, it kind of bundles those all together in a module that you can just launch and then it runs. And then the coolest thing I think about it is like the credentials management. So you can have, you know, four service account creds, two OAuth creds, and an email password, and you can load them all into the tool at once and then kind of swap between them as needed to run the modules.

And the permissions, because usually when you're doing pen testing and you find credentials, your first question is like, what permissions do these credentials have and what can they access? Yeah.

So the tool is really meant for if you find credentials in the wild or during a pen test, right, as part of a responsible disclosure policy or whatever, and you want to decide what permissions these credentials have, you can load them into the tool and start firing off some modules. And in the background, it will passively basically passively track what permissions those credentials have, and then kind of give you a summary.

So there's some fun stuff in there. Like I talked about at DefCon briefly how you can put in credentials. And then because of this API called test IAM permissions, you can brute force like 99500 permissions on credentials through the tools. So you can like figure out exactly what permissions you have in some cases. So, It's definitely helpful from a pen testing perspective where it's you find credentials and you just need to know what the permissions are there.

Host: So you use the term passively once or twice. So I'm just curious, do you see this as an active pen testing tool or a passive pen testing tool or maybe for our audience, you highlight what's the difference between both of them?

Scott: yeah. Right. So passively, probably should have used different vocab there. So it's actively sending API calls. it's actively working with the cloud environment.

By passively, what I mean is as you're running modules, so as you're calling GCP APIs, it is in the background is probably a better term. Like in the background, it's collecting all the API calls you successfully called.

And then so if you call enum buckets and you're able to list all the buckets, then in the background it's saying, Scott can list all the buckets. Let me make a note of that. And so at a later time, you can check all your credentials and it'll be there. So that's kind of in the background as you're running all these modules, as things are successfully working, it's making notes of everything that's successfully working. So you kind of get a summary at the end. Yeah.

Host: OK, that makes sense. Because when it comes to pen testing, you have active and passive as well. So now the question is, how do you envision users using this open source tool?

Scott: Yeah. So when I, yeah. So when I made it, I try to make it more like a, I envision it more as a pen testing tool of like a starting point for enumeration and lateral movement, but not necessarily a configuration review of the entire account. Right. You can run it on the entire account. That's entirely possible. but you might see potentially some performance issues that account is really big. So the goal here is more the end again, the way I envision it is you're on a pen test WAPen, InPen, external network, whatever you're doing, you come across either an email password, GCP credentials, you get an OAuth token, something that gives you a foothold into that GCP environment, and then you load it into the tool, and then you fire off a bunch of modules to see what permissions you have and what data you can get to. And I'm hoping to add some configuration check stuff in the future, but at the moment, it's not meant to replace Scout Suite, for example, right, or something like that. It's not trying to check every configuration thing at the account level.

But I mean, it does handle different projects. like permissions wise, for example, if it can reach multiple projects, it will try to handle like inheritance and permissions, right? Things like that. So it can do multi -project stuff, just not really, I didn't really envision it as like a config checker for everything.

Host: Yeah, understandable. So you spoke about one scenario, right? Misconfig may not be the best use case for the tool. Are there any other scenarios where you don't see your tool being a good fit?

Scott: kind of, yeah, like what I saying, configuration based, other than that, most, well, okay. So configuration based and the thing about these pen testing tools is they don't cover every service, right? GCP has, has a services and there's also turnover in those services where some services will go away and some will show up. So, it's, you might run into a case where you get credentials and the permissions are for APIs that are not rolled into the tool. that, that being said,

What I will say though is because the tool allows you to brute force those permissions, right? And like I said, you can brute force 9,500 permissions in some cases. Even if the API isn't built into GCPone, you can still load the credentials in and try to enumerate the permissions at least. And so once you have the permissions, GCPone will usually give you back the OAuth2 token if you want. like the way I envision it happening is I find, I don't know, creds and they work for…

What's the GCP service that's not covered? Like memory cache, right? Or Redis or something. You find the creds they work for something like that. Memory cache and Redis and that type of stuff isn't built into GCPone at the moment, but you can still load the credentials in, fire off the permission enumeration, and at the end it will tell you, hey, these credentials work for memory cache and Redis. Here's an OAuth 2 token. And then you can take that info and go to the GCP documentation and call the APIs and all that.

I think that'd be the only other limitation, which is for most tools, right? Like there's so many cloud services, usually they can't cover all of them.

Host: Yeah, it's difficult to stay up to date, right? Like as you highlighted, like some services are going away, some are getting added. Especially with AI, are like new services getting rolled out every single day. yeah, totally understandable.

So we touched on what areas maybe should not be used today for any areas that you have in your roadmap that you do not support today, but you wish to support in future?

Scott: Yeah. So one of them is a wiki. One of the goals of making this tool is to make it community driven and allow people who want to get into GCPone or know about GCPone to add modules. So I'm trying to write a wiki article about how to make pull requests right and add your own modules and own services to the tool. And that is halfway written somewhere on this desktop. But it's in progress. And the goal is to roll that out this week or next week so that people can all see.

Also start making pull requests and add their own services. And then in terms of services, think next on the roadmap, had cloudrun, Firebase or yeah, fire. I always get the terminology mixed up. There's like Firebase and firestorage or the firewall ones. Yeah. And, adding those. And then I've been looking at Redis adding some of the Redis memory cache stuff recently. So that's, those are kind of the services and then a lot of bug fixes and just fine tuning things making it more streamlined and then yeah, wiki to help make it more community driven and help people be able to add pull requests and add their own code.

Host: Yeah, that would be amazing. Folks contributing and growing the tool, right? So we reached out to Daniel and he had a question which is somewhat related to what you're doing, right? Like there is a tool called AWS Pawn. And like if in my mind, both of these should do similar activity, right? How do you feel things have changed since 2016 when it comes to AWS?

Scott: Yeah. So I graduated, well, I was just starting college in 2016. So I didn't have a ton of experience in the cloud world. So it's hard for me to gauge how things have changed. I will say though, like, you know, even in recent years, you've seen a large number of services. would say cloud, to me, cloud environments grow big. They don't necessarily get more complex. They just get bigger, right?

It's usually more services being added, more things being added, more. And even if it's a different feature, it's just a different feature. And so it's more approachable to the average developer to build those things. think as cloud environments have grown, there's a greater need or there's usually a good idea to build a tool such that it's generalized enough it can handle that growth. So like for GCPone, kind of going back to that.

One of the things I did was that enumerating 9,500 permissions, because even though I don't have every service in that tool, I want to build it in such a way that you could still walk away with knowing what permissions give you access to what resources, even as GCP grows, I can just manually add those permissions.

So I would like, again, I started college in 2016 and I wasn't doing security at the time. So I can't give you a great roadmap for the last eight years in cloud, but. Just in recent years, seems like as services get added and you see these new trends like AI and that kind of stuff, it's not necessarily things are getting way more complex. It's just getting wider and there's more services and things are getting bigger. And so you have to build tools in such a way to accommodate that growth.

Host: Yeah, absolutely. That makes a lot of sense. So since we have been speaking about cloud, so if I want to start doing cloud pen testing, one of the things that I need to know is some of the basic concepts of cloud. And when you go into any cloud, whether it's AWS, GCP, or Azure, they all have a shared responsibility model, which is documented for everyone. Can you briefly describe? What that is and how does that work?

Scott: Yeah. So the shared responsibility model on cloud is basically like an agreement between you and the cloud provider that says the cloud provider will handle things that are outside of your control as a customer. So for example, if you were to deploy EC, well, if you were to run a Lambda function, right? If you, which in AWS, that's like, you read a bunch of code, you put it in a text box and you click the red button, right? You're not managing the server that's running that Lambda code. You're not managing the physical box that's sitting in some room somewhere, right? That's running your code. AWS has said they'll manage that. They'll manage the uptime and that kind of stuff. And then that's their kind of responsibility to make a functionality work.

But then on the flip side, you also have the customer responsibility of making functionality work where again, AWS, GCP Azure, they give you a lot of freedom in being able to set things up. It's kind of like a sandbox of how you want to build it.

And so with that freedom, inevitably you can set things up that just are inherently secure. And, you know, the cloud providers can't really do anything about that. That's kind of a bit on you because you're the one setting it up, right? You're the one building it. You're the one who, you make a Lambda function, you make a Lambda function that dumps all the secrets and you make it open to everyone and you expose it, right? Like the cloud provider can't really do much at that point. They can give you guidelines and suggestions per their documentation.

And so that's kind of the shared responsibility is the cloud provider has the responsibility to maintain the things you can't control and keep the uptime and manage the physical infrastructure and that kind of stuff.

But you also have the responsibility to build things in a secure way or architect things in a secure way in those sandboxes they give you depending on whatever service it is.

Host: Yeah, I like your example of Lambda, right? Often when it comes to Lambda, we think that, yeah, it's all, I just send the code and the cloud provider takes care of everything. But that also, that doesn't mean that if you write very insecure code, it's cloud provider's responsibility. It's your responsibility.

Scott: And you see interesting things in both part of that shared model, right? Where like when I was going through college, was like, okay, so the cloud provider, there's never going to be a fault there, right? It's always going to be the customer. And so you see there's faults on both sides of that shared model where obviously, like we said, a customer could set up things in an insecure way.

But if you also follow for cloud sec and some of these cloud blogs, you'll notice that cloud providers, those things also pop up. and securely, because again, at the end of the day, cloud providers are companies, companies are humans, right? Humans write things. all bugs pop up inevitably. you know, obviously a lot less frequently than like the customer portion, but security is an important part of that shared model. So not only do you have that aspect of setting things up securely, but from the cloud provider side, they also have to handle security.

Host: Right. Yeah. No, absolutely. I mean, even though the number of issues that we notice is less, but still it's not a perfect system, right? Like when it comes to the cloud providers.

Now, a follow -up question to that is, as a pen tester, each cloud provider provides very similar capabilities, right? With very different catchy names, like Azure calls it functions, AWS calls it Lambda, Google call set functions, similarly for different capabilities.

So as a pen tester, when I'm looking into these cloud providers, what are some key security considerations that I should be aware of?

Scott: Yeah, a lot of this it's interesting because cloud is usually a jumble or like a, what's the word, like a, just like a pot of different security skills, right? Like, because if you think about like EC2, you've got, IP management and then you could run a website on EC2. So now you have the website testing, or like Lambda, were talking about secure code review. So in terms of core security skills, There's usually different aspects depending on what you're testing from a core security perspective, probably networking is the most important because most of time when you're setting up a cloud environment, you want to make sure that what you're setting up is exposed as you expect, right?

If you set up an internal private website and the expectation is only internal employees are going to use that. And then you expose that to an external IP address and that kind of defeats the whole purpose and might be a risk.

So, I think networking, especially as you're setting up networks and EC2 instances and doing all these IPs and that kind of stuff is probably the most important. But then, like I said, there's the other aspects of like websites, for example. If you have an EC2 instance and you've got a website exposed and someone can get SSRF on that website, right, and get into your cloud environment. So you also have to consider the web aspect. And we're ignoring kind of the networking portion and just focusing on the cloud layer.

Don't, I think access control is a big one. I am, which I think we'll touch on later. So that's like a big one, but that's kind of cloud specific. And so usually it's going to be dependent on whatever cloud provider. So that would be a core security skill. I would say to learn, but a lot of security skills I find for the different services are usually dependent on the service. And it's less about learning the core security skill before the test and being able to learn it on the job or pick it up as you go. Right. So Like if you've never seen Lambda before and you, you know, and you have a lot of core security skills learned before that, if you're on a C-Pen and you start looking at Lambda and you pull up the AWS documentation, right, you can see, okay, I put code in here and hit run. there's an external URL. You can start kind of putting the pieces together and start seeing, okay, there's, there's some things that could go wrong here. And so it's really the misconfig service by service and you, less of a, a technical skill and more of that soft skill of being able to pick things up, being able to Google things, being able to, you know, write connected dots and kind of pick it up as you go.

Host: Yeah, yeah, makes sense. now when it comes to pen test, I have one more question around it, which is many organizations perform annually or quarterly like internal or external pen testing. And they get certifications like SOC2s or HIPAAs or PCIs in order to stay compliant. Now based on your experience, is that enough?

Scott: Yeah. So my experience is usually doing just a general pen test, right? That's cause a lot of the certifications might say you need to do a pen test per year, something like that. So that's kind of where my experience why. So I think the short answer would be no, but it's a good start just because personally, I think that the minimum for your security practice or the minimum that you consider to be good enough for security should be higher than that that's dictated by external regulations, right?

So if there's a certification that says you need to hit these minimums, that's great. And that's, again, a great start if you're just starting a security program or you're just kind of ramping that up. But I think your minimum in terms of standards should be a bit higher than that just to ensure that you're both protecting your assets and kind of serving your customers at the same time. That being said, like I said, I don't want to discourage a company or organization that's just getting a security grant program off the ground either, right? I don't want to say it's like bad if you're doing the certification test. Again, it's great. It's better than nothing than doing nothing. And I'm not trying to like sell you pentests for the sake of doing pentests, but yeah, there's this also that like fiscal, I'm not a finance person. So I understand there's usually budget constraints, right? As well as you have to kind of prioritize what you test.

Obviously I'm a security guy, so I would love to test everything. But in terms of like what areas should an org pay attention to, or let's say you're doing those annual pen tests and like, where do I go from there? Right? Like how do I grow my security program from that?

I think one of the big things is if you're only doing a pen test once per year, it might be worth considering more of a continuous pen testing model throughout the year just because if you do that snapshot pen test, right, if you do a snapshot pen test in June, and then you're all signed off, everything's great. And then in July, one of your developers accidentally, you know, publishes an API key, right. To an exposed file on their website. have to wait a whole another year, potentially, to figure that out or, or sooner if someone else finds it. Right. So.

In those cases, it's usually good to have more of a continuous model. There's things that are like attack surface management. So like, for example, Netspy, the company I work for offers attack surface management, ASM. Or there's other solutions too that are provided by other vendors. And, you know, they can like hook into the cloud environments as well. So having some type of continuous model, I think for cloud at CSPM, right? Cloud security posture management. Having those types of continuous models, I think is almost a next natural stepping stone from those certifications, because you're basically taking that snapshot and applying it over the whole year. And that helps both you because you're not getting flooded with vulnerabilities all at once potentially, right? And it helps just make your overall network more secure.

And then once you build out that continuous model, you can start looking at more granular tests. So for example, maybe you need to test certain websites as dictated by HIPAA or, you know, SOC or some of these other certifications.

Well, if you can build your security program up enough, you can start including some other websites, So like websites, mobile apps, some of these other things you can start including into the overall, your overall pen testing strategy. And I think that helps and C pens, right? So C pens is another one where probably you want to focus on externally facing assets, right? First with web applications, but kind of the next step there, at least in, again, my opinion is Once you're looking at those external assets and you've kind of cleared all of those, then you want to look at the cloud environment because usually it's a good idea from a web perspective. The web is good to look at if you're worried about someone from an external perspective, right? Messing with your website and cloud pentests are really good for that perspective of well, what if someone compromises a website or mobile or whatever and gets into my cloud environment?

So it's kind of like the next layer naturally. It also helps find kind of publicly identifiable resources and that stuff. And then kind of at the very end of this, I think that the final step is just kind of red teaming, right? If you have security controls in place and you have continuous model and you're doing these granular tests, the next question is not necessarily do you have vulnerabilities, but can you catch someone trying to exploit your vulnerabilities in real time? And so that's when I think you get into the red team. So that's kind of my long answer for that question is.

Yes, think it's no, I don't think it's enough. I think we should be striving for kind of a higher standard in term of minimum. I understand there's budget constraints as well though. So kind of in your own time, whatever works best for your organization, I think it's worth kind of looking at better opportunities or more opportunities for testing your assets and kind of just building your team overall.

Host: The takeaway at least for me is the closer you are to doing continuous pen testing, the better. That doesn't mean that if you are not able to do, it's completely wrong. You need to have at least those annual or quarterly pen tests if you can do those. At least those give you a snapshot at that point. And then you have to think about how do you handle the deltas after that. But yeah, it makes sense.

One of the things that you highlighted is misconfigurations, right? is often the root of security mishaps. It can be an internal or an external configuration challenge. So as a pen tester, what are some of the common cloud misconfigurations that you typically look at?

Scott: Yes. There's a couple different areas usually. So I mean, there are certain things that are very configuration based per service. And what I mean by that is it's usually a setting or a flag or a check box, right? That, know, you need to make sure your data is encrypted, that kind of stuff. And so tools like Scout Suite, those types of tools that do kind of those organization wide checks are usually good at checking for those kinds of things.

Again, another example, like you have IMDS version two enabled and IMDS version one disabled, right? Those are the kind of config checks that kind of fit into that category. As part of the configuration view, I'm also looking for secrets in publicly available resources or clear text creds that are stored where they should be placed in the cloud provider's corresponding secrets manager. Some of those are pretty fun.

Some of these are self -explanatory, like, you know, don't put your secrets in Lambda source code, right? That's a pretty static thing. But there's also other ones that I find kind of interesting. And one, like for example, I look at that might not get as much attention as CloudWatch, right? So thinking about secrets and like static files, you know, Lambda source code, you upload it, it's probably going to stay that way for several months. So it's a pretty static thing to check for, but your CloudWatch logs, depending on what you're building, what services you're using, those are always changing. They can evolve over time. They're totally at discretion of the developer, whatever they want to pronounce.

So I always have fun looking at CloudWatch logs as part of C pens. In fact, Pacu, example, that tool that does pen testing for AWS has a module specifically for just downloading CloudWatch logs. So I think it's 24 hours worth. It'll just try to download all the logs. So that's definitely like an avenue I check for.

And then obviously you can't talk about misconfigurations without IAM. So misconfigured permissive IAM permissions are something I always look for. I always look for things that have star or wildcard in any permissions. If you're not familiar with that in cloud, that usually means either you can access every resource and every action. They have their uses based off their business use case. So just because you have a star in your policy doesn't automatically mean I'm going to write something up, right?

But usually, at least what I personally recommend is even if you have stars, it's better to list out, like let's say you do S3 star, right? So basically you're allowed to do every S3 action. Usually I personally recommend it's better to just list out every S3 action because what you'll find is that when you're listing out every action that the user is allowed to use, inevitably you'll run into an action that doesn't make sense for the user to have, right? If there's like 20 S3 APIs, there's probably one or two that the user doesn't really need. And so even just that granular change of one or two actions still decreases your overall attack surface area.

So. I usually recommend if you ever see a star on your policy, just see if you can swap that out with literally, even if it's like 20 APIs, literally the specific actions. And that gives you a much better, more granular look at how everything's working. And then obviously config checks, have like your network specific checks, kind of like what we were talking to earlier. So are you exposing things that you are only meant for internal to the external, just your network security overall. If you have like external assets that are vulnerable versions of things, right, or deprecated OSs or deprecated versions of things, things of that nature.

And then finally, I usually kind of at the very end of all this, I like to do a manual, kind of what I talked about earlier, I do a manual check on the individual services and really try to deep dive to find the specific edge cases or unique things about those services.

And that's, that's usually important because from a config check perspective, configuration checks are great, but they lack that human element. And so they'll miss things sometimes.

So like, you know, I'm trying to think of an example off the top of my head, but like, example, Cognito, right? Cognito, there was a talk at black hat in 2019, I believe about Cognito, identities. And these researchers went out and found a bunch of Cognito endpoints that were able to authenticate to the unauthenticated role that you can set up in Cognito, right? At like a mass scale, internet scale. So I don't know off the top of my head if something like Scout Suite would check or some of these other tools, but like if you have an unauthenticated role, right, that's exposed, then if the permission or the role attached to that unauthenticated perspective is scoped down enough,

It might still be dangerous, right? Like if you attach a role that says, Hey, any anonymous user can pull all my Lambda code from a scout suite perspective. And from a config perspective, that might make sense. And that might be fine because it's very granular. But from like the human element, looking at it, you might be like, why are you allowing everyone to download your Lambda code? Right? So usually that's kind of the stuff I look for in that human element is just if things don't make sense.

Host: Yeah. imagine, like I love the example that you gave, right? Like instead of giving star permissions, reducing it to just writing it down, whatever permissions you want to allow, whatever APIs you want to allow. It like, it sounds tedious, right? When you are setting it up for someone, I have to go look for all the permissions, which one is needed. Not like it might take more brain power than I want to spend, but in longer run, it certainly helps.

And again, the example that you gave, right, lambda, if you have scoped it down just to read, so even if someone got access to your code, they could download the code, but they cannot change your lambda functions and run their own code or something like that, right, like do lateral movements and things like that. So it's again, as you said, it's not the perfect solution, but at least it reduces the attack surface quite a bit. If you go through the API actions available and replace it with stars with specific API actions.

Scott: Yeah, same with resources too, right? If you have like, if you have actions for S3 and that S3 or Lambda or whatever, and your service is only accessing one S3 or one Lambda function, like you don't need to put star to give them access to everything. Just list that those two or three or whatever Lambda functions and buckets, and you've drastically reduced your attack service again. Yeah.

Host: Yeah, absolutely. Absolutely. So you mentioned about Scout Suite, which is an amazing tool. Any other tools that comes to your mind, any specific to any particular cloud providers or you would recommend folks to start with maybe Scout Suite?

Scott: Yeah, it really depends. think Scout Suite is a good beginner tool when you're just starting to learn the cloud environments because you can, kind of, think I'll touch on this later, but you can, all these cloud providers let you make accounts for free, right? And so when you're, it's really nice when you're learning something, you can actually put it into practice in your own account.

So if you learn about, Hey, AWS IMDS version one versus version two, and you read all about that and you're like, I want to see what this looks like. And you make an AWS account, you actually set that up and delete the EC2 so you don't incur charges at the end of the month. But if you check that out and you run, then you can run Scout Suite on it and kind of see what that looks like from Scout Suite's perspective. So it's a good kind of like closing the loop of learning those things. In terms of like general tools, so Scout Suite's great for configuration. Paku and GCPawn are pretty good if you're doing...

Not necessarily maybe a cloud config check, but if you're on another service line, so web application or something like that nature, and you want to figure out how to pivot in the cloud, those are good tools where you start out with credentials that are unknown and you have to go from there.

Again, kind of like what I mentioned before, cloud automated tools sometimes will miss things and a lot of it is very context dependent. So I would probably focus less on tool itself and more about understanding the service kind of like the cognitive example I gave.

So yeah, it was blackhat USA 2019 where they just went out and found all these unauthenticated identities so Again, like a config check might not necessarily find that and so just understanding each service Because you have the UI right? It's not like you have to do this all from the API level Usually if you're doing a cloud config check, you usually have a web browser. You can just click all the buttons right and see everything so it's more about like understanding the service, in order to test it.

And then there's some other cool tools in terms of like learning the cloud providers. like there's a lot of different, open source projects about setting up a vulnerable cloud environment and kind of like testing it, like a Cloud Foxable. It's made by like Seth art, right. Or, some other contributors. that's like a great learning platform I've heard for kind of like learning AWS and I think I'll touch on some of those at the end as well, but there's definitely a large amount of tools.

I would say the most important thing at the end of the day though is understanding the service and the nuance of the service, because from a value perspective in doing testing, it's a lot more valuable in my opinion to present a finding that would not normally be caught by a configuration scanner, one of those tools, just based off that context in human development. Yeah, that's kind of my long -winded answer there.

Host: I love that. Like I love the details that you added, right? So a follow -up question to that is that now let's say I know I have a little bit of understanding of cloud. I have a little bit of understanding of tools like Scout Suite or Pacu or GCPone. Now I want to start. And there are these three major providers, AWS Azure and GCP.

Which platform do you recommend generally for beginners to focus or do you suggest going across all of them?

Scott: Yeah. I would probably focus on one instead of going across all of them. At least I think it also depends on how you learn. don't think it was like a one like plan fits all or solution fits all. It's, it kind of, so like for me personally, it's also the same with the cloud providers.

For me personally, I started on AWS. So to me, AWS is like the most intuitive, easy to learn, no problem. so jumping from that to GCP was like pretty pretty interesting. There's a lot of different ways I had to kind of rethink things.

But at the same time, I know people who started with Azure, right? And who have done Azure stuff for years and say Azure is way simpler than AWS. So it kind of depends for me personally. I will usually recommend AWS, but I'll also say it's usually a good idea or I usually advise learning the cloud provider your company is using because that helps a lot, right? If you If you just ask around at your company and you're using Azure, probably just learn Azure because at least for me, when you're learning those types of cloud providers and you learn features for that cloud provider, you can ask people at your work or just say, hey, I learned about this. What does that look like in practice?

And because your company is using it, your org is using it, you're able to kind of see that firsthand and see that in practice. And so again, for me, that's just a much better way to learn and a much better way for me to kind of connect the dots. I'm like for consulting, right. It's doing those tests over and over. It's, it's helps me kind of learn a concept and then actually see it on an engagement, right. And then kind of close that loop of reinforcing it. but so that'd be my advice is really, I don't think it matters which one you start with personally. I, I always lean towards AWS.

But whatever you do decide to go with, would just stick with that one and kind of like learn the core concepts and see if you can't align it with what you do in your day to day to kind of reinforce that concepts and pick things up.

Host: Yeah, I love your suggestion of learning or starting with the environment that your organization uses so that you have others who have been working in that same cloud environment. They can guide you if you are making some mistakes. And also, you are getting a sandbox. You would always have a dev or a QA where you can figure things out even from a pen testing perspective. So yeah, that's a very good suggestion.

So earlier we touched on this that you mentioned there are many areas like networking, IAM, your server setup, like many areas when it comes to pen testing. As a beginner, is there one area that I should pick?

Scott: Yeah, I always recommend IAM because almost everything in all the cloud providers is sitting on IAM. usually, and the reason for that is usually IAM, if you can really master IAM and how different users are defined, how you get the credentials, how you set up policies to dictate who can access what. Then you're in a really good place. And it's actually way easier, at least for me to learn the other services, because at the end of the day, like S3, Google cloud storage, right? These different services, they're usually just functionality, right? Like Google cloud storage, you upload things to a bucket. It's not that it's like, obviously there's complexity on top of that. You can put additional stuff on there, but at its base, it's pretty easy to understand.

And so where a lot of the confusion comes from, and where I think people sometimes get tripped up is once you put something in that bucket, trying to figure out, who's allowed to access that? And like, is my bucket public, right? Or how are my permissions set up? So in my, my mind, learning IAM and learning all those permissions makes it really easy to pick up the other services because once you get to those other services, you really just have to understand the core functionality and everything else kind of just clicks into place because it's all just the same IAM.

Or like Lambda, right? If you set up a Lambda, and you don't know IAM, it's probably a lot more daunting. Whereas if you do know IAM, it's like, okay, Lambda, you like put code in a box and you click run, right? And now the IAM part is, okay, who's allowed to access Lambda and what permissions does the Lambda have when it's running? And if you understand IAM, you can answer those two questions pretty easily in your set. So, excuse me, Eric.

Host: And often folks who move from like traditional data centers to cloud, that's one of the biggest change, right? Because earlier in case of running an on-prem data center, it's all driven through AD or something like that, which has limited sort of blast radius. You focus more on the network side. But the moment when you move to cloud, I am like, it hits you, right? You have to understand how it works throughout the cloud provider services, how the services authenticate and things like that. So yeah, that's a very good suggestion that we should start with IAM.

So let's say I understand the value of pen testing, I understand the cloud a little bit and I want to get started. So there are tons of resources available online. Do you have any suggestions like any free or affordable online courses or something like that so that I can learn from it there and then get my hands dirty?

Scott: Yeah, there's some I personally use, right? And can like, personally point to, right? I don't have any, I don't think I have any that are, quote, like recommended by NetSPI, right? But there are some that I can point to. so like PwnedLabs is one of them, for example, that I think has popped up recently. I know I, I did a couple of the free labs for when I was working on GCPwn. so Pone Labs is really cool because it's kind of like, like it.

A lot of people are probably familiar with hack the box, which is basically like a sandbox where you'll deploy a web server and IP something, and then you try to hack it in kind of a controlled environment. Right. So it simulates that. But I don't think there's a ton for like cloud resources in terms of launching those boxes. So prone labs is nice because it's like hack, it seems like hack the box, but specifically for cloud.

So you like launch a room, right? And it launches a cloud environment for you. And then, you found exposed creds. What do you do with these? And so it kind of walks you through that. So that's pretty good. Cloud Foxable is definitely something I would check out. I've heard a lot about it. It's definitely on my to -do list to go through it because it looks really fun. It's like a Jeopardy CTF style learning. So if you really like the challenges and like you know, reaching the end of an obstacle and getting a flag. That seems really cool. know that's Seth artist contributed to that and spoke on that over at Datadog. He spoke on that at DEF CON and that's also just open source, right? And I think they have a whole blog article somewhere that kind of details how to set that up and walk through that hacking the cloud by Nick. So once there's a kind of like tools to learn it. And then a lot, a big part of cloud learning, I think it's just reading blog articles, reading blog articles and replicating it in your own environment. like hacking the cloud by Nick Frichette again over at Datadog is a great resource that has kind of a bunch of different articles on different exploits and that kind of stuff.

So usually what I recommend when learning the cloud provider, like what I did to learn GCP is again, a lot of these cloud providers just let you make a free account. So. I just made like a free account and then I might learn about GCP cloud storage, right? Like I'll read a bunch of stuff about it. And then I can go to my cloud environment and actually make a bucket and like physically click those buttons and kind of connect the dots.

So that's what I usually recommend is learning the cloud, kind of going service by service and having your own test environment to just learn things. that, that being said, it's probably a good idea if you're making a test environment, you'll like maybe segment it from your, right? Like primary email and all that. Maybe do a little work to set up a cloud environment such that it's segmented from your other stuff, right?

Because you don't want to like be playing around in a cloud environment and testing things. And then that actually does get compromised. So usually I make a cloud environment to test things and I make it segmented enough that it's not really attached to any of my stuff. And then I'll kind of play around in that and test specific things.

And also if you have your own cloud environment, you can start learning the APIs, right? If you have your own cloud environment, you can look at Boto 3 for AWS or like the GCP Python SDKs. And you could just like write a simple function to list all the buckets in your own account. And it's kind of doing things like that that help pick things up. Cause cloud is very much like, if you can understand the core concepts, then a lot of it translates service by service. So I think you'll find like as you're learning cloud, As you pick things up, you kind of almost go faster and faster because you kind of have a better template or a foundation to build on.

Host: Yeah, so I wanted to ask you about how to set up a secure lab and things like that. One key thing that you highlighted is if you are setting up a cloud environment, make sure that is not connected to maybe your production workload. It's very segregated so that even if you get compromised, that is very limited to maybe your test cloud environment.

Any other recommendations you have from a lab setup for my pen testing?

Scott: Yeah. Yeah, lab setup. I usually do lab setup, like just a personal account, right? I'm not trying to tie it into any organization. So like I wouldn't like deploy like a development account and then just start deploying a bunch of random stuff, right? In my actual production or company con environment, I would probably do a, again, this is just for personal learning.

So there shouldn't be any company data in there. So I would, usually I'll just set up my own environment, like a personal environment. So like Google, need like a Gmail, AWS needed Gmail.

But again, I try to set those up as pretty standalone, pretty segmented. And then usually if you're setting up your own lab environment to test things, just make sure to tear things down at the end, right? Don't leave stuff up. you, and also just like, you know, common sense, if you want to test public S3 buckets that are open to the world, I mean, that's something you can test, but like, don't put your social security number in there, right? Or like, don't put actual passwords in there.

Just like expect some, expect someone will exploit whatever you're setting up in your cloud environment. And so it's just set it up in such a way that, you know, if you do expose an S3 bucket to the world, just to see what that looks like, maybe it's just a document that says test in it, right? Like it's like nothing, nothing that's actually could result in vulnerabilities. And especially the cloud, if you're going to do, learn cloud and set up your own lab environment. It's usually a good idea to just, again, do a personal lab environment. Don't put company resources in there. Just keep it totally segmented just for your own personal learning.

Host: Yeah, that's a great advice. Just to stay safe, right? Like, since you are learning, you may not have figured out many things. It's better to have a segregated environment so that it doesn't impact your production. Make sure you tear it down once your testing is done. If you leave things around, then you will get hacked eventually. Yeah. yeah. True, true.

Scott: Or yeah, or you'll get a bill, which I've done. You'll get a bill at the end of the month. So yeah.

Host: So this is slightly off topic, but one of the things that comes with all of this is that you have to learn a lot to stay up to date. You have to experiment with many services that comes from cloud providers, which constantly keeps growing. That could add a lot of stress or burnout.

One of the key statistics which was presented in Gartner Security Conference this year, was that around 73 % of CISOs and security leaders feel burnout at some level in their work life. What's your take on this and how do you handle stress and burnout?

Scott: Yeah, it's, yeah, it's definitely something that pops up or getting consulting. Cause usually, usually what I try to do is just like work, work is work, right? need that work life balance. So usually I'll try to, the general rule of thumb I do is I will try to cut off my work day, right? right at eight hours or whatever it is, because whatever you're looking at can usually wait till tomorrow. or if there's something that I'm looking at after business hours, it's usually because I want to look at it, right. Or I it's interesting.

So, you know, I do WAP pens. If I find an SQL injection or something like that, right. Maybe during that eight hours of my day, I'm making sure I get everything in there and get the minimum.

And then once that eight hours is done, right. Having that really defined work life balance. or if I want to kind of chase down that SQL injection and say, cause I find that fun, see like, Hey, where can I go from here? then that's something I'll look into, but that's kind of the general strategy I try to do, but it's definitely definitely a work in progress, right? That's definitely something you have to consciously work for and strive for because it's so easy, definitely security to get caught up in that security atmosphere. Right.

And one hour turns into two hours of looking at something and it just kind of exponentially grows. So I think the biggest thing is just being cognizant of it and kind of coming up with a plan or strategy to do what you need to do in the time required. And then kind of like what I said, my strategy is just, if I find something really interesting or I want to look at something, then I'm fine doing that after hours. But if that's the case, it's something I want to do and I'm actively choosing to do that.

Host: Yeah. So finding the balance and also finding what sort of motivates you. Right. And so that you can keep going in that area and you don't feel burnout because you are learning as part of that process. So you handle that way makes a lot of sense.

So yeah, that brings us to the end of the podcast.

Before I let you go, one last question. Do you have any reading recommendation? Like it could be a blog or a book or a podcast.

Scott: So a lot of the security companies will have blogs for different cloud providers. So not like one thing to check, but I would probably check a lot of those. for example, like Nestify, example, Thomas, Thomas Eiling just published something about Google groups, right? I've written stuff about AWS organizations. So, and then there's other companies like, Huntress, Permiso, right? Is another one. there's lot. Yeah.

Host: For me, so. I think. Yeah.

Scott: Yeah, there's a lot of different companies that have blog articles out about specific cloud things. And then there's a couple of books like I know Carl at Netspy who is kind of like a wizard in the Azure space, wrote a book about Azure pen testing. So I only know GCP and AWS. So I can't speak to Azure a whole ton, but I imagine it's a pretty great book since again, he's like a wizard in Azure stuff.

And so yes, it's, it's not really hacking the cloud is like one I mentioned, right. But it's, it's less about like just one book or one blog. And it's really just looking at a lot of different blogs across time and probably learning the service first.

So like, if you're learning, Cognito, right in AWS, learn Cognito. And then once you kind of have a good foundational understanding of Cognito. Then start looking up Cognito like hacking blogs and pen testing blogs. And you'll find a lot of information and that information will probably be way more valuable to you than if you just went there from the get go, right? So that's what I'd recommend. So not one thing, but many things.

Host: The way, like understand many things, but also be able to connect the dots so that you can do better pen testing, right? Better discovery of gaps in the security infrastructure.

So, yeah.. That brings us to the end of the podcast. Thank you so much, Scott. It was a fun conversation.

Scott: Thanks, yeah, likewise. Thank you for having me.

Host: Absolutely. And to our audience, thank you so much for watching. See you in the next episode. Thank you.