Live Hack: Anatomy of A Cloud Attack

In this session, Jeff Moncrief, Field CTO at Sonrai Security, delved into the hidden vulnerabilities within cloud environments, while demonstrating the risks with a live hacking demo, unraveling a real-world identity-based breach scenario in the cloud. Jeff illustrated the alarming ease with which hackers can exploit even the smallest mistakes, such as accidentally sharing private keys. Because of that single error, he was able to transfer sensitive files from the cloud to his local machine, showcasing how hackers could effortlessly pilfer data if cloud environments lack proper security measures. Key Takeaways:

• Guard Against Small Errors: Even a minor oversight like sharing a private key can provide hackers entry into protected cloud domains.
• Vet Trust Relationships: Exploit vulnerabilities may lurk in trust relationships between environments, demanding meticulous examination and fortification of these links.
• Urgency of Secure Data Transfer: The effortless transfer of data from the cloud to a local machine highlights the imperative for stringent cloud security measures, safeguarding against the theft of sensitive information.

Jeff's eye-opening demonstration showcased the imperative to view cloud security through the lens of an adversary, urging CISOs to reevaluate their strategies in the face of evolving cyber threats. For a deeper dive into these insights, watch the full video!

Karen Levy (00:01): All right, we promised you hands on keyboard and here it comes. Our next session is titled Live Hack Anatomy of a Cloud Attack. And presenting today is Jeff. I happen to know he's a former repo man as well as a cloud security expert, and his title here at Sonrai Security is Field CTO. Jeff, let's see what you got. Jeff Moncrief (00:23): Thank you, Karen. So welcome everyone to this very exciting access session. My name is Jeff Moncrief. I am Sonrai's Field CTO, and I also run the sales engineering team. I've been here a little over three years, and today we're actually going to be doing a live hack, a live demonstration of how an identity based breach plays out in the real world when the network footprint is no longer there. And an adversary can sort of take advantage of the identity footprint the exact same way that they would if they were trying to exploit the network fabric. So without further ado, we're going to dig right into it. So I have a couple of quotes that I'm kind of famous for around these parts. The first is hackers don't attack, they just log in. And this is the truth, and I'm going to show you a GitHub repository here in a second that kind of backs this up. (01:12): But if you look at the statistics about how actual security incidents happen in the public cloud, AWS, Azure, GCP, Oracle, et cetera, they actually are very, very simple. They're not based on sophisticated vulnerability exploits. The vast majority, over three quarters of reported security incidents over the last six or seven years in the public cloud are all based on one thing, compromised credentials. Whether that's through repositories and GitHub, whether it's through compromised buckets, disgruntled employees, or we're hearing this more and more frequently, social engineering. So they just log in. And then what? Where can they go? What can they get to? And that's where a lot of folks really aren't thinking. They're not thinking of the identity fabric as a network conduit, a system of plumbing that you can take advantage of the same way that you could a network fabric, which leads me to the next quote. (02:04): That identity is the new network. I've heard this for years since I've gotten here. That identity is the new perimeter. That may have been the case four or five years ago, but now identity is the new network. A cloud native application lives, breathes, communicates, and functions through the identity fabric, not through the network. And so you have to start looking at that identity fabric, very, very similar to the way that you would look at a network fabric as it comes to securing it. And then another quote there, which is the statistics prove this, and I'm about to show you this, okay? This is a GitHub repository that actually tracks, and this is just focused on AWS, but it's very similar in the rest of the cloud service providers. It actually tracks security incidents that have been publicized. And note that these are just the ones that have been publicized, and you'll find a common pattern here, okay? (02:51): When you search this repository, you search for the word credential, you'll see that there's 66 instances of it in this screenshot that I took recently. Okay? Now I'm actually going to exit out of the presentation and I'm going to show you this repository, okay? It's a real repo. If I search for the word credential now. Now there's 68 and I took this screenshot just a few weeks ago. Okay? There's 68, so there's been two added since. And if you scroll through this repository, you're going to see a very, very common pattern, credentials committed to a public GitHub repo. Okay? Global exposed Kubernetes pod with AWS credentials, someone shared the root credentials, credentials stolen. You're going to see social engineering in here, okay? The statistics do not lie. This data does not lie. This is how folks get in. And this is what we're going to show you today. (03:43): We're actually going to walk you through one, and I just randomly chose this. We're going to walk you through what it looks like with credentials that have been exposed in GitHub. All right? So I'll bring back up the slideshow and you'll see that this was just earlier this year where of all people, GitHub actually accidentally published their private RSA encryption key. Now, it was only exposed for a matter of hours on a given day, but you can see that even they are susceptible to mistakes like this, and this is exactly what we're going to demonstrate today in this live hack. Okay. So we're going to go through a couple of things. Before my life at Sonrai, I was at Cisco and folks used to aggravate me. My nickname was Kill Chain Moncrief because all I did was talk about the kill chain because I always looked at the lens of your network security strategy through the lens of an attacker, not through have you done all these check boxes, right? (04:37): Well, we're going to talk about the exact same phases, okay? Recon, lateral movement, privileged escalation after pivoting, actually going to ransom some data, we're actually going to encrypt something that we find in S3, and then we're actually going to steal some additional data. So I want to make note that this is real, and so as a result, you never know what can happen in a live demo, but we'll pray to the demo gods. But before we dive into the actual hack, you're going to see that this overview, and I'll flip back and forth as I'm able to from this diagram, but we are going to grab a key out of GitHub. We're then going to leverage that key to see what it gives us access to. We discovered that it gives us access to an exposed AWS virtual machine in a sandbox environment. You're also going to see that we're going to expose that it has a role attached to it. (05:30): We're going to leverage that role to do some recon. We're going to see what we can find an S3 and in Dynamo DB in this environment, you're going to see we come up empty. We're going to get some permissions denied errors as well as we just come up empty. Okay? Next thing that we want to do is recon to pivot and laterally move and possibly privilege escalate, which is where we discover that there's a role from production that trusts this sandbox environment. We are then going to exploit that configuration, assume that role, jump into prod, and then as this new persona, we're going to continue our hack. We're going to do more, enumeration of S3 and of Dynamo DB. We're going to find a file. We're going to encrypt it so that we can ransom it. Later on down the road, we're going to find some data in S3 that we want to steal. (06:17): We're going to find some data in Dynamo DB that we want to steal, and then as a last step, we will back channel and exfiltrate several different files to my local machine to actually just play out the entire kill chain, all the way to data exfiltration. And then we'll talk a little bit about how you can prevent this in the end. So let's jump into it. Okay? (06:39): You'll see here that we've got a couple different things open on my screen here. Okay. We've got a primary command line interface terminal. We've got a secondary for command and control and for data exfiltration. And then we've got something else that's really, really exciting and that is an actual script that I've written that's going to actually help us play through this threat. But first things first, as the story goes, all right, we are playing around in GitHub. (07:12): We're looking for compromised credentials, and again, this just happens over and over and over again. This is not farfetched, it's frightening, but it's super, super frequent. This is my personal GitHub repo. If you're familiar with Hackerman in the shadows of hacking and kind of the cult that is hacking culture, this is Hackerman. He hacks himself into the future. Side story, but that's who this is. And we're poking around in this repo as an adversary and we see there's a couple of different repositories, but one is called Sonrai, okay? The moment I go into this repo, as I'm just looking around, out of curiosity, I see a PIM file. I know that a PIM file is an RSA encryption key. All right? So what do I do? I take a look at it and I'm going to determine whether or not this looks like something juicy. It does, okay? (08:04): This is a real key. I'm going to warn you, it's not the one I use when I actually access the workload. So it's a dead end if you try and copy it. All right? But I know, okay, this is exactly what that story about GitHub exposing their key looks like. Someone could come across the private key. But a key is useless if you don't know what to combine it with, that endpoint. I also see that there's a miscellaneous app info file here, okay? I open it up and sure enough it says that it's a Linux, AWS AMI. It's got an IP address. This is not the real IP address. And it has a function that's misspelled. Go figure. That's how you know I did this. Retrieve deb web input and write to S3 in prod via Lambda. So I know that this key is connected with an AWS workload, has something to do with S3 and doing something with a Lambda and prod. Okay. (09:00): So what am I going to do? I'm going to download that key and I'm going to execute it. All right. So this is where we'll now start our attack. This is my local command line. Okay? It's real. And we are going to SSH using that key into that workload. It's that easy. We're in, okay? If I wanted to, you can see it's Amazon Linux. If I wanted to print working directory, I could. You can see that I'm in home EC2 user. Now I'm not going to waste time. We're going straight to this script that I wrote. This is real, okay? This is going to execute command on our behalf, thinking of it as a little attack example utility that I wrote in Python. All right? I'm going to select all of its contents and right here from this machine that I've now jumped into, I'm going to VI attack.pi And we're going to paste all of this code in. (09:53): You can see the skull there. And we're going to save this file and we're going to exit out and now we are going to execute this and it is going to run us through an attack leveraging this real AWS environment. Okay? You can see the banner that created here just for fun because I could. I do want to stress though, warning for demonstration purposes only. This is meant for demonstration purposes, even though we're essentially leveraging the IAM fabric here to exploit the kill chain. Okay. Do you want to proceed with the attack? Yes, we do. So this is the first phase of the attack. This is reconnaissance. This will verify the current assigned identity and we're going to issue the command. AWS STS get caller identity. So we are logged in. It is now shown us that we are who? We are tableau tester. If we go back to the diagram, you'll see that this is where we are in the phase. We grabbed from our local machine and GitHub that credential, we're on the sandbox VM. (10:58): We've now asked that sandbox VM, who are we? Okay? Many people are not thinking about roles attached to VMs, but without roles and permissions a VM in the public cloud is useless from a platform standpoint. Right? Think of it as an invisible umbilical cord. Now that I am this role, what am I going to do? Okay. I want to try and list S3. Let's see if there's something easy in this sandbox environment that I can grab. Okay, there's two buckets. My health sandbox, my health app sandbox, and Sally's secret stuff. Let's see what's in them. Do you want to list the contents of the first one? Sure, why not? Error occurred, access denied. So I don't have permissions, but let's just try the next one. Same thing. I don't have permissions. All right. Okay. Well I also love grabbing things out of DynamoDB just because it's easy. It's a clear text table that you can usually just print data out of. (11:56): I have access, but there's nothing there. Okay, so that's fine. Let's see what other IAM roles are in this account that I could potentially try and assume. This is going to issue the command AWS IAM list roles with the proper syntax to give it in the output that I want here. And here you'll see these are all the roles that I can assume. Cory scanner role, deploy infrastructure, the list goes on. However, I know from that GitHub repo note that there's something here about a Lambda and something in prod and all of these roles are actually, or the majority of them are in this sandbox environment. Okay. So I want to see if there's maybe something on this machine that would let me know where I need to start. Okay. So I'm just going to list the contents of the home directory and look at that. Lambda bucket policy do JSON. (12:51): Now there's a bunch of other files because we use this demo system for a bunch of stuff, but that Lambda bucket policy JSON file is super interesting. So I want to list the contents of it. Okay. So S3, get object, example bucket and look at that. There's a roll ARN to another account called Medical Results Reader. Okay. So what I'm going to do now is I'm going to assume that, all right. I'm going to generate the credential, I'm going to set the environment variables and then I'm going to ask the system who am I? Look at that. Medical results reader, Jeff is MMR. That's just what I called it. But you have to understand how to generate the credential, set the environment variables for the secret access key, the session token and the AWS access key, all right here. When you do that, you are now this identity right here, okay? (13:45): When you're this identity, you have now privileged escalated, you have now done lateral movement, you are now a whole other persona that you have to worry about. I think the most interesting thing about this is that this trust relationship actually starts from the role and goes backwards. So I'm actually in that account right now in AWS taking a look at this identity and you'll see that the trust relationship on this identity allows the sandbox right there to privilege escalate because of that cross account trust relationship. You would've never known about this if you were just looking at those roles that I listed or if you were just looking at that particular sandbox account, AWS. You need some sort of technology that's able to put the pieces of the puzzle together from the inside out. So that's key here. Okay. So we're going to continue. I'm now this particular identity. Now that I privilege escalated, as you can see from the attack phase here, I'm going to see if I can list buckets. (14:39): Well look at that. There's a whole new set of buckets that I can access and these are in prod. So I want to list the contents of the health app claims upload bucket, and there's all kinds of goodies, card type two, credit card data, a dental claim, CC billing. I love CC billing.text. I want to know what this is. Now, you can't just cat it directly across S3 using the AWS command line interface, you've got to grab the file. So that's the first thing we're going to do is we're going to grab it and bring it back to this compromised sandbox. I just downloaded it. Now I'm going to list the contents of the current directory to show that it is indeed there, CC.billing.txt and I want to see what's in it. Look at that. Fake credit card numbers of course, but this is actually showing you that we grabbed the file after enumerating it in S3 and brought it back across the wire. (15:31): We started right here and sucked it back through this roll back to this workstation and then catted it out. All right? And I'm going to keep rolling here just in the essence of time. The next thing that we're going to do is we're going to ransom that file, okay? It's one thing to just sell it on the dark web and I want to ransom it. Okay, so I'm going to actually use open SSL. I'm going to generate an encryption key here. All right? Now I'm going to use that encryption key to encrypt the CC.billing.txt file. We're going to take a look at it now and look at that. That's the same file that we just generated the output above. It's now fully encrypted. As you can see here, salted, et cetera. Okay. So what are we going to do now? We're going to replace the original with this encrypted one, upload to S3. If you wanted to verify, we can actually take a look at it in the bucket. Earlier it was clear text. Let me log back in real quick. And we'll take a look at it. (16:35): That's what I get for having that tab open earlier. All right, so we're logged back into prod, taking a look at S3. We go into health app claims upload. You see that file and it should be encrypted now, if I go to open it, and sure enough, if it was in clear text it would've opened it up in another browser, if I actually opened that text file there. We have officially ransomed that file now and we can do whatever we want at that point in time. Now the next thing, just because we can, we're going to download that file that we enumerated that says dentalclaim.dot.jpeg. Why not? Let's just see what it is. All right, we got it. Do I want to list the contents of the directory? I do. There's the dentalclaim.jpeg file, and now we're going to manually transfer some files using this second terminal that I've had open this whole time. All right. (17:18): And what we're going to do is I've got these commands right here. We're going to secure copy. I'm going to move this off to another screen. We're going to secure copy, the private key that we generated. We're going to secure copy the clear text billing file. We're going to secure copy the encrypted version. And the last thing that we're going to do is we're going to secure copy the dental claims file. We have now brought these down to our local machine. I'll show you what that looks like in my downloads folder. You'll see dental claim, the encrypted credit card billing file, the attacker key as well as the clear text one. So we have now officially done data exfiltration. It was not easy. Now we're going to clean up. Do I want to remove, do I want to remove? Do I want to remove? Do I want to remove? Yes. (18:07): And then just list the contents again, you'll see that all those files are now gone. So we've cleaned up, they're no longer on that workstation. Whoever finds this, they're in trouble, all right? Because all those contents that were just there that we use to stage on that machine are now gone. Okay? Just because we can, the last thing that we're going to do is see if we can enumerate DynamoDB. Remember we couldn't do that in the sandbox. Sure enough, leveraging privilege escalation in this new role we have, there's two DynamoDB tables that we can exploit. The one that we want to take a look at is medical results. Do you want to take a look at it? Sure enough, there you go. You've got names, birth dates, secrets, positive, which probably are test results, blood counts and contact information. Super easy to copy and paste this out and do whatever you want from an adversary perspective. (18:59): And then we're actually, I wrote this routine that replaces the encrypted credit card file with a plain text one just to clean up so to speak. But the exercise is complete. You may not exit the program. If you are able to exfiltrate any files, now's the time to take a look at your treasures. Okay, so having said that, the one thing I want to show you is I have no idea what this dental claim file is. I take a look at it. Sure enough, it is an actual Canadian dental claim file that I was able to exfiltrate. And let's not also forget that I was able to exfiltrate the contents of the encrypted file as well, which I can always decrypt with my key. So just a really great example there of executing the kill chain. You saw how quick that was and very, very painless. (19:48): You have to understand how the identity fabric works and you have to start thinking of it through the lens of an adversary, okay? And remember, this is kind of exactly what you just saw. I'm always happy to answer any questions about this at a later point in time. I'm available on LinkedIn as you'll see here at the end. But the last thing I want to talk about is what can you do? Obviously things are going to happen. Compromise credentials are going to get out there, but what can you do to prevent the kill chain and the exploit that I just showed you here? You have to monitor cross account trust relationships in AWS, you have to monitor your break glass identities, which are your admin level roles, service principles, service accounts, person and non-person identities, keys and secrets in the public cloud. More often than not, almost every single time, there are far more admin level accounts that are out there and identities than you are aware of. (20:49): So first you need to know what's out there, and B, you need to manage those. Make sure that they're under locking key. Same thing with trusts that are not necessary, right? You need to be able to certify those identities regularly, whether it's six months, every 12 months, you need to build a certification cycle with the identities because you need to be proactive about monitoring for this kind of risk. If there's dormant identities, get rid of them. There is a method to this madness that we've learned here and that I've learned here, consulting customers with identity security. When you get rid of dormant accounts and dormant identities, you remove so much unnecessary risk across lateral movement, privileged escalation, unnecessary permissions, but the accounts that are needed, maintain least privilege, monitor used and unused permissions and try and get those to least privilege to remove all that unnecessary risk. (21:40): I didn't show up, but those accounts that I just demonstrated, they had access to KMS, they had access to delete things. They probably don't need all of that. And then just continuously monitor those identities for changes and set those virtual trip wires around them to let you know if there's a new identity chain that can access something that means something to the business or if an identity is acting suspicious. But I think the real takeaway is to think of securing identity through the lens of a network and through the lens of a network attacker. And to understand that there is so much more to securing your public cloud than just focusing on vulnerabilities and misconfigurations, especially when you look at how this actually plays out from a bad day perspective with folks just logging in. (22:21): Okay, so I hope that you learned something from this session. I hope that you're able to take away just a few nuggets that are going to maybe make you think again about how you're securing identity in the public cloud. But with that being said, I know we're about out of time, so I want to thank everyone for joining. And Karen, I want to turn it over to you and see if there's been any inbound questions I can help with. Karen Levy (22:43): Hi Jeff. Thank you. That was excellent. I learned a lot and I know our audience did too, and there are a ton of questions, so let's dig in. First question, one of the things that you showed here was a trust relationship between sandbox and production. Do you see that often in your customer environments? Jeff Moncrief (23:02): Yes. So in AWS environments, Karen, absolutely. Trust relationships, I would say they're one of the most scary things from a security risk perspective, but they're also one of the things that allow so much amazing things to happen in AWS where one environment can interact with another one, can write something and retrieve something from another one. And they're very, very hard to understand and see, as I showed you there in the AWS web console, because trust relationships are usually granted from the inside out versus the outside in. So if you're looking at your public cloud, if you're looking at AWS and just taking a look at direct entitlements and whatnot, you're never going to see the majority of that risk, but it's very, very easy for an adversary to take advantage of it. But definitely Karen, we see a lot of that. Karen Levy (23:46): That seems tough, difficult to see, but high risk. Another question we have is I have a key management system. Would that help prevent this attack? I think referring to a key being used in the beginning of an attack. Jeff Moncrief (23:59): Yeah. So if we're talking about how the attack started, which was the GitHub repository, no, you can store a key in key management, it will protect it, but if you look at how this actually plays out, which is not FUD, as you can see that the data shows, people are going to accidentally publish keys in GitHub. They're going to accidentally, because it's easy for them, especially like an AWS secret key for an identity for me, and many times I do this hack in that manner. I don't even have to exploit a workload, I just have to log in from my machine right here, my laptop and I'm already in your cloud, with just one command. And those kinds of things, while it would be easy to keep them in KMS, there's so many ways that they get out of KMS because it's easier for developers to do their job. Karen Levy (24:43): Yeah, I think what you're saying is what we hear all the time is that security comes down to that human element in the end, and whether it's intentional or malicious, something goes wrong and you need to protect yourself against when it does. Jeff Moncrief (24:55): Yep. Karen Levy (24:55): Another question here, if someone does get in, could you track their movement and how can you be sure what exactly was accessed once they got in? Jeff Moncrief (25:04): Absolutely. Absolutely. You would need something that's able to first build out that relational footprint of all of those possible conduits, and then you would need something that was actually monitoring the audit and activity logs in each of the public cloud service providers, which they all provide, and actually setting trip wires and letting you know that all of a sudden someone's leveraging this conduit, someone's leveraging this particular lateral movement path and they're poking around in some places they shouldn't be. But absolutely, as long as you have the ability to ingest those logs, build a behavioral model of known good and then alert on changes, you can totally monitor for that level of activity, which would be a possible indicator of compromise. Karen Levy (25:43): Okay, thanks. And lots of questions. I think you've got people thinking about their own environments and what they can do. If I'm just going to do one thing, what's the one best thing I can do to stop this from happening in my cloud? Jeff Moncrief (25:56): One thing is I would implement a cloud infrastructure entitlement strategy. I would. If it's not part of your strategy, it should be, and you should be focusing on end-to-end visibility, that awareness, and then end-to-end capability to prioritize based on the blast radius across the identity fabric. That's the one thing is be thinking about the blast radius through the identity fabric and be able to prioritize based on that. Karen Levy (26:23): I think related to that question, people are still thinking about how do I solve this? I have a good practice of least privilege. Does that solve this problem? Jeff Moncrief (26:33): It does not solve this problem because it's not going to stop credentials being put out there. It's not going to stop folks just logging in. And then even with least privilege, I could totally take advantage of an identity doing exactly what it's supposed to be doing. And you'll also going to see that there's so many scenarios where you see developers bridging gaps between accounts, creating conduits between accounts, creating identities for testing. Least privilege is one phase of what I would say is a CIEM strategy. And the other thing is if you can't put the pieces of the puzzle together to see true end-to-end permissions all the way through the conduit where you can jump from one role into another one into another one, Karen, and just taking a look at direct entitlements, then least privilege is actually not giving you the full picture. It's a false sense of security. Karen Levy (27:21): All right. We're going to leave everybody with a false sense of security. We've run out of time, but Jeff has been gracious enough to offer to continue this conversation in the chat, so if you have questions, please put them in the chat. If we didn't answer it live, he's going to answer those questions and answer any other ones that come in. And please stay tuned for our next session, which is titled Mapping the Battlefields by Untangling Cloud IAM. Really going to war with those attackers in the next session. Thanks everyone. Thank you, Jeff, for a great session and we'll see you in the next one. Jeff Moncrief (27:51): Thank you.