Casting Light on Shadow Cloud Deployments

Hello everybody. Good evening. Welcome, welcome uh welcome to Bsides Las Vegas ground floor. This talk is going to be about Luminina casting light on shadow cloud deployment and is given by our speakers Chapen and Britney. Uh a few quick announcements before we begin. We'd like to thank our sponsors, especially our diamond sponsors, Adobe and Aikido, and our gold sponsors, Formal and Profit. It's their support along with our other sponsors, donors, and volunteers that make this event possible. Uh these talks are being streamed live and as a courtesy to our speakers and audience, we ask that you check to make sure your cell phones are set to silent. If you have a question, please use the

audience microphone so YouTube can hear you. So, I'm holding the audience microphone. I'll bring it around if you have a question. As a reminder, the Bides Las Vegas photo policy prohibits taking pictures without explicit permission. These talks are all being recorded and will be available on YouTube in the future. So uh if you are coming in, if you just walked in, please move to the front so that we also have audience who are coming in can sit. Uh with that, let's get started. Please welcome our speakers. [applause] Awesome. To get started, any incident responders in the crowd here? Couple. All right. Anyone dealt with a cyber issue that resulted from an exposed cloud resource before? Of

course. All right. [laughter] If you have or have not, welcome. Hopefully we can shed some light on shadow cloud deployments. >> Yeah, thank you all for coming. Um, this is actually really great timing like with the the talk before was all all about shifting as far left as possible and looking at secure coding as a part of education. We're going to be talking about as far right as possible like when everything's already out and try and figure out like how to how to detect those resources and and start that investigation. Uh, I'm Chapen Bryce. Uh, I'm a instant response consultant turned developer. Uh these days I focus on cloud infrastructure and and threat data. >> And I'm Britney Ardus. Um I've hopped

around the consulting world a little bit. Did a little bit of private consulting, government consulting, and now I'm on an instant response team um at an enterprise. Um so one thing we've noticed uh through our combined years of experience um is that as cloud has become more popular um the same security issues leading to vulnerable exposures has also moved to the cloud. So it's no longer your, you know, web application that's hosted in a data center per se. That's your initial access vector. It is now living somewhere in the cloud and is easier than ever to deploy. Um, so as an instant responder, where do you actually start with dealing with some of these issues? Um, there's a ton of tools out

there. We did a lot of research when we initially had this idea. Um, a lot of brilliant people have built some great solutions with respect to perimeter scanning and network mapping. um that what we were seeing didn't really fit the bill for an instant response perspective. You know, there were some SAS tools out there. There were some that were more catered towards pentesting and red teaming, but nothing that was really instant response focused. Uh so we decided to build our own. So where are we actually seeing this? Uh we wanted to kind of generalize and categorize um different scenarios where we would probably be seeing these types of exposures. Um the first one being um

you know organizations that didn't necessarily have adequate logging or governance established which isn't necessarily unique to cloud per se but we did see that it was kind of a generalized trend. Um cloud technically is kind of a new concept um that's still being adopted by organizations and being rolled out. Um and as a result policy is still being written and adopted as well. So it's easy to cut corners um and not have adequate guidelines in place. to kind of adopt this just get it running mentality. >> The other place we frequently see it is the the shadow infrastructure, the shadow IT. Uh once again like shadow IT has just shifted to the cloud. What was

shadow IT that maybe was only internally accessible before is uh is now having public IP addresses. Um the barrier to entry for getting a public IP and putting resources online is a credit card free tier, right? uh folks were able to spin up in uh resources that um maybe were problematic when they were internal but now have a much higher exposure. >> Yep. So why and how is this actually happening? Um apologize for any of the introverts that are out there in the crowd right now. I'm going to ask for some audience participation. So buckle up. Um I'm going to go through some excuses that we have heard from resource owners in the past for why they have

exposed those resources. Um if you've heard this one, please raise your hand. This is just a proof of concept. >> So like I'd say most of the room uh raised their hands. Uh how many of those same folks, how many of those turned production? >> Yeah, I've seen it too. I saw it in this past week. [laughter] >> Next one. Don't worry, it's just test data. >> Yep. Uh about the same number. A little bit less maybe. Yeah. [laughter] >> Yep. Exactly. Yeah. It's a clone of prod, but it's in our dev account, David. [laughter] >> Yeah. So like what does that actually mean? Uh is it like what what is test data? Is it your just production data in

test or is it actually sanitized? Is it generated from scratch? Like >> yeah, [laughter] >> a lot of questions. Uh >> dev accounts aren't safe just because they're dev. >> Yeah, >> exactly. And then finally, I didn't know it needed a security review. [laughter] >> Yeah, a little bit less on this one, but this goes back to the just get it running mentality. I see this one frequently with that. Um, so that's fun, but let's kind of dig into the scary part of this. Does anyone remember what happened with the AI company DeepSeek around January this year? See a couple noded. Yeah, I thought so. Yeah. So, if you're not familiar, um, the the security research company Whiz published

an article where they were able to identify a Click House database that was publicly exposed on two different ports. Um, they were just kind of enumerating the the internet. We're able to see that there were non-standard HTTP HTTPS ports out there. This ClickHouse client was fully unauthenticated. So as you can see from this screenshot, they were able to execute SQL queries directly from the browser. So you could see all the tables that they were able to dump and execute it directly from the browser. Um you know this is worst case scenario. Uh they were able to dump full chat history. um you know they also had full um backend issues and and um some sensitive datas that they were they were

also able to to dump as well such as log streams, API secrets um and other proprietary information. Um so this is uh obviously worst case scenario. Um but it's a prime example of how exposed endpoints could be exploited as an init initial attack vector. Um >> obligatory. [laughter] Yeah, that was our obligatory AI mention. Here's what we normally see. You know, that's what hits headlines. This is what we see probably more common. Uh, cryptojacking. So, it's not necessarily a full network takeover or PII database being dumped. It's probably just a really huge bill from CPU usage. Um, one thing that I did want to mention before I move on is, you know, I think we kind of associate web

applications and even cryptojacking with Linux systems. um as we were looking at different case studies, we were able to see that it wasn't necessarily uh focused on Linux systems fully. You know, there was um a CVE in 2017 affecting Oracle Web Logic servers that were running on Windows systems that thread actors were able to exploit and run Monero on. So, I don't want to hear anyone say that they're safe in this room because they were running Windows on their systems. [laughter] Just kidding, but not really. >> Yeah. So, uh there's a lot of great tools out there as we were talking about before and these [clears throat] are some of them. Um they they really have a

different focus than than Luminot on uh that continuous monitoring. Some of them are SAS focused. Um looking more at the pen testing side. Um Prowler is actually here this week at uh Defcon. So check them out at Defcon. Um but they they didn't quite scratch the itch of I'm rolling into an incident blind. I need to figure out what's exposed and start answering questions as soon as possible. And that's where Luminot is is really aiming. Um, so it's really for that quick triage piece. It's not meant for like a continuous scanning or it's it's really meant to answer those initial questions and help you get started in your investigation. So it's it's aiming for these questions here that you're

going to have to start answering very very quickly. It's also intended for environments where you don't really have the time to do a bunch of configuration. So the idea is the tool is as minimal configuration as possible. You can run Luminina without configuring it. We have some reasonable defaults in place. Um that way you can just hit the ground running in your investigation. You don't need to spend a lot of time setting it up and uh like safe listing or allow listing resources uh to to get going. So this is luminina. Um we kind of have a inside outside approach. So we start inside the cloud getting a list of all the public IP addresses. Um then we

gather context around what resources those uh IP addresses are associated with. So um including firewall rules, compute and and so on. There's many more resources we don't yet support. We'd love to support them. Um but once we have a sense of those resources, we then take it to uh sources like uh cloud trail or GCP um audit log in order to figure out more information about uh when that resource was created if it was ever suspended or you know resumed uh just so you can get a better sense of the exposure window time frame as well. And then there's also configuration resources available from uh both Google and AWS uh that give you more sense of

like how the resource changed over time. There's also the outside piece, right? So inside's great source of truth, right? It's it's what's actually running. It's how it's configured, but we don't actually know like is it routable? Like can someone actually hit it? And so that's where end mapap comes in. We do an actual scan with luminot um using end mapap in order to like try to talk to those specific ports and answer the question like oh yes this is routable and responding back. Uh we also use what web. How many folks have used or seen what web before? Yeah, this is relatively new. There's just a couple of hands. It was new to me in this project

as we were doing research. um really wanted to have fingerprinting of HTTP services and when we came across this I was so happy because it fingerprints like 1,800 different web services and we didn't have to build that database or those detection rules or anything like that. So what web is great um and we'll show a little bit of that later and then of course uh quering showdown for uh context on uh the services it's found and also vulnerabilities that it's aware of. So uh as mentioned before it is configurable but configuration is not required. Uh it has support for allow listing only in AWS right now. We're working to bring it to GCP and then it

reports to the terminal. Um, that same information also goes to HTML because terminals are ephemeral and the line wpping gets weird. Uh, there's also a JSON payload so you can parse it to your heart's content and a CSV timeline so you can get started building out your timeline for your investigation. Here goes a demo. We'll see how Wi-Fi wants to play with me today. Uh, so here is the help information. Uh, no tools complete without askart. And uh, here we've got the uh, um, option to provide a configuration. I've got one pre-loaded here for Bides. Um, and I'm going to go ahead and hit go. See if the demo gods want to play nice. Hey, it's scanning. Great. So, it's

starting to scan uh AWS and starting to enumerate some of the public IPs. From there, it'll move on to Google Cloud. And similarly, we'll identify public IPs and associated resources. And then once it has a sense of all of the public IP addresses in the cloud environments, it'll switch over to start um running the the uh tools on the outside uh like end map, what web, and showdown in order to start answering questions about those and produce um output. Uh I'm going to switch over to our screenshots here just in the sake of time. So um here is uh what one of the entries looks like. I'm going to show you multiple screenshots from the terminal just hopefully this is

readable. Um so uh IP address is the first thing as well as the region it was found in. So you can scan multiple regions. Um we then see the network interface associated with it as long as along with the security group and the permissive rules. So here uh it's filtering out any of the internal rules. So that way you don't have to go through a massive list. You're just focusing on the rules that are uh exposed um to external IP ranges. Um so in this case we see 80 and 8501 exposed. We also see a load balancer attached, but it's only listening on port 80 and it's called honeypot ALB. I know it's kind of hard

to read in in the font here. Um, so interesting. Like we got a little bit of information. Someone called this a honeypot. Neat. Um, so here we have AWS config and cloud trail. Um, AWS config pulls back a lot of information and we haven't figured out how to nicely display that in the terminal, but it all goes into the JSON report. So it's all there if you want to parse it out. And honestly, it's easier to look at it there because in the web app it takes a little bit of time to load and query. So, we've we've pulled it out for you. Um, and then in Cloud Trail, uh, this is uh nice to see in the terminal, but the

line wrapping doesn't really work great, but you can see like what cloud uh cloud trails pulled out. So, security group rules changing uh resources being created and and so on. It's much easier to see as a timeline. I know this font's smaller for you guys, but like it's it's nicely structured for the uh timeline here and answers those same questions. >> Um, >> one thing Yes, go ahead. Yeah, one thing we wanted to call out too is while we were building out this timeline, you know, it's great to see that a security group was created, but what weight does it really have unless it was attached to your running resource? So, we made sure that that

information is is built into your timeline as well, so that you have a full, you know, exposure time frame. >> Yeah. Um, so here we have the outside tools. We have uh end mapap uh telling us for sure that it can reach port 80. We then have Showdown also confirming port 80 and here finding 62 vulnerabilities associated with the service running on port 80. Uh so that's uh that's a good stat to start with and uh gives us a chance to start running down what these are. Anyone recognize any of the CVS in this list? Some old ones. >> Yeah, some old ones in there. Um it also calls out 443 and a Splunk server.

You'll notice that 443 wasn't in the list in the cloud environment, right? So um looking at the date here, this as of we can actually see this comes from an older scan from Showdown. Showdown's not live data. And so in this case, uh, you know, it's showing us something that's slightly inaccurate. So always validate output from tools, right? Make sure all your sources are reporting things accurately. Um, so the Splunk cloud is probably also unrelated here. Here's a what web. It's not the best example of what web, but uh, it's showing that it's detected Apache. Notice that there was actually a redirect. Followed the redirect and is now saying, "Oh, this is actually a Synology disc station." I mean it's it's

not because it's a honeypot but it's pretending pretending to be. Uh I just wanted to show off briefly uh the Google cloud output very similar shows the compute resource firewall rules and these are events from the audit log. Um this is the Google cloud uh run service which is uh the container run service that they have and uh what you'll notice is instead of the IP address it actually just shows the URL and then uh under ingress it says ingress traffic all so the the firewall rules are a little bit different there but luminance supports the URLs and we'll also scan those against uh or scan those with uh end map showdown and what web so that way you get information on

those URLs as well. This is what the uh uh config looks like. Um, and this is what we were just running in the demo. Um, uh, so you'll notice you'll be able to set up which reports you want to output as well as configure your tools. Um, I did redact the API key. I I trust you all, but not that much. [laughter] And, uh, we have the AWS, uh, and GCP configurations off to the side as well. Uh, these are the policies that are needed. This is also documented on our GitHub. Um, and as you'll notice, they're all just read policies and rather short lists that hopefully are uh easy to share with the administrator of the cloud environment

for them to set up a role for you to run the tool. And that's it. Let's see actually if the demo finished. Hey, it finished. Great. Uh, [laughter] so uh yeah, any questions? Uh, they're coming with the mic. Yep. >> Is Azure on the road map? >> Azure is on the road map. There is. [laughter] >> Yep. If you have Azure expertise, we'd love to check because that's an area that we don't uh [laughter] other questions. Oh, one over here.

>> We had uh thank you for the for the talk. Uh the question is not really related to the tool by itself but more about uh attacker on cloud. Are you seeing a difference today with attacker trying to use the cloud as a pivot point to compromise the onremise or they usually just stay at the first layer of resources trying to deploy crypto miner or things like that? Do you want to take? >> Yeah, sure. So generally what I've been seeing um you know it's kind of staying at that cloud level. Um I haven't seen an instance where they're using cloud as a pivot point to get to on-rem infrastructure only because I just haven't seen that exist um in my line of

work. I'm not saying it doesn't happen because it's very possible to do. Um but generally like the day-to-day the comp compromises that we're actually seeing are some of the you know commodity malares or the crypto miners that's what we're generally seeing unless it's something that's more of a highv value target. So, you know, if it's critical infrastructure, if it's something that's like more of a weighted value, that's when we're going to see the more sophisticated attacks where potentially AP type attacks, maybe a little bit more sophisticated where it's targeted. Um, but generally it's going to be more of those commodity malware, crypto mining that stays in the cloud, tries to look for pivot points, but it's probably

going to be at the cloud for the most part. Um, but to answer your question, I haven't seen it doesn't not saying that it doesn't exist because I'm sure it does. >> I can actually give an example. So I work very few cases these days as I'm mostly on the developer side but uh got called into a case in the past year or so where we did see them pivot uh not necessarily on prem but multicloud um through our our favorite service Jenkins and so uh that was a that was an interesting one I can't talk more about it but [laughter] >> and uh does your tool detect any Eim EM exploitation or EM uh weakness that can

allow an attacker to raise it's privileged on the cloud environment or detect some access persistences for example um back during a specific role uh opening the AWS account on another account or it's not something implemented yet >> so uh the question was about uh IM and using that for uh uh persistence and such am I getting that right okay for persistence or attackers that are using EM to escalate privileges things like that. >> Do you want to speak to that part? >> Yeah, that's not something that the tool currently supports, but I think that's a pretty valuable resource to start enumerating into. You know, like we have the infrastructure like the actual, you know, networking component and that's

the privilege escalation part that we aren't necessarily looking at. So, I think that's a good pivot point for future movement of the tool. >> Yeah. >> Yeah. >> Thank you. >> Thank you. >> Yeah. Thank you.

I think we're at time. So, yeah. Thank you all. Appreciate it. >> We'll be around if you have any other Yes. [applause]