Inside Cloud Attack Paths: End-to-End Adversary Simulation

Besides, I can't hear you. How are you going? All right, there you go. That's the energy we need. Um, yeah, this is actually my second Bites New York talk. I did uh the last one in 2018, so it's been a while. I feel kind of old, but it's okay. Good to be back. Um, today I want to talk about cloud attack pads, specifically within the Microsoft cloud ecosystem. Um I think that we are seeing an important trend in the past reaches where attackers are going after cloud environments. They're not they're not using malware. They're not touching endpoints. There's no EDR alerts. And I think that's interesting because in the past 10 years we focused so much on

deploying EDR on all our endpoints. But now attackers, they don't even care because now they're going directly after cloud APIs using tokens. And I think that's important. And I think we as security practitioners, both red teamers who are trying to find vulnerabilities for the customers and blue teamers who are trying to defend networks, we really need to understand cloud attack paths. We really need to understand how they're created, how we can create lab environments, how we simulate uh end to end attack simulations against them. What is the telemetry that when an attacker traverses an cloud attack path, it generates? So we can create detections, we can validate our security posture. So that's my goal today.

Actually, my goal is to enable you guys with practical tools. I only have a few theoretical slides, theory slides, but then I want to show you demos of two open source tools I've built that will allow you to create attack paths on your own and to simulate them um and you can generate telemetry and learn from there. So that's my goal today. Hopefully you will uh enjoy. Just a really quick introduction. I'm Orisio. Uh I'm originally from Peru. I've been in the in New York City for uh 13 years now. It's been a while. I work at Microsoft. I run a a security research team and I'm still on Twitter or X if you are still there. And on my

GitHub page, I have links to my talks uh tools and the slides for this um talk will also be out there if you want to get them. But that's it. Let's let's move on. I first wanted to start with a quick definition of what I what I think attack paths are at least from my perspective in in the context of this talk. Attack paths are for me the path um or the chain of steps an adversary takes um by abusing compromised identities and abusing legitimate permissions to reach a goal. An important piece here is that we're not I'm not talking about vulnerabilities or zero days or exploits. We're talking about legitimate identities, legitimate permissions and targets and resources

with this these identities and an attacker is able to identify those after compromising one and then navigating those attack paths to achieve a goal which could be excfiltrate emails or read a database or install ransomware. How are attack paths created? And I think the three main components for attack paths to be generated are the who which are the security principles, the identities. These are the users, the ad registrations, the service principles uh who are actually compromised by attackers one way or another. Then the what which are the permissions the entitlements and these could be you know within the cloud world we have enter ID roles we have ashure arbback roles we have graph API permissions

specific API permissions so these are the entitlements or privileges that these identities have and and finally the targets that's where attackers are going these are you know your tenants your mailboxes your your key volt services your databases your one drive files are all the targets that attackers by abusing those legitimate permissions by compromising those identities they're able to get to them. So let's let's look at a really simple example of what an attack path could look like um in the the Ashure world. Let's say we have a user Bob here. Bob um is a compromised user. An attacker has compromised their account either through password spring or adversary in the middle or token theft. Um yes whatever technique they

use let's say that this attacker has elevated their privileges to be able to compromise an app registration within entry ID right and of course this app registration really runs as a service principle within the entry ID uh world and if that service principle has an Azure arbback role perhaps let's say the VM contributor role this role actually allows you to manage VMs and execute code on them. So if an attacker is able to traverse this to this point of the attack path, now they're able to execute current VMs. And let's say there's a VM there which we'll call Gibson01. And this VM has a manage identity which is a way a way how in Azure resources

have identities and have uh the ability to connect to other resources. If you can execute code on a VM, you can actually steal the token of that managed identity and become that manage identity. So if that's the case and if that manage identity has access to a storage account that has sensitive files, we have now created an attack path where if this user Bob is compromised, an attacker is going to simply abuse the legitimate permissions and the connections within this cloud to be able to excfiltrate those sensitive files from the storage account. And of course, as you can see, we're not talking about vulnerabilities. We're not talking about exploits or zero days. We're talking about configurations that

are going to arise as an organization moves to the cloud. You know, as we have more users and more resources, we're creating more and more configurations that just happen. We forget about them and they're still there. And um another important uh concept to talk about is how are attackers traversing the attack paths, right? So how are they moving to this attack pad? I think we can call those attack primitives. Um those are the capabilities that could be a configuration, a credential, a permission that an adversary will abuse within an attack path to move from one step to another. And these are again just legitimate actions that can happen in a legitimate um um legitimate workflow within an

organization. For example, think about mailbox access, right? When an attacker uh compromise a cloud, let's say an M365 environment, one of the goals may be to exfiltrate emails. Well, how can they exfiltrate emails? There's multiple ways. For example, if they're going to use the graph API, there's a permission called mail read that allows you to read emails. If you're going to abuse the Exchange web services API, EWS, there's another permission that allows you to read emails, right? So all attackers have to do is find that right identity that has the right permission to then abuse this legitimate feature of the Microsoft cloud or 365 which is to read emails programmatically and then abuse that add that that add that step as part

of your attack chain. Right? So these are the attack primitives. We're not talking about vulnerabilities. We're just talking about legitimate features that can be abused by attackers given the right circumstances. How are we on time? Okay. All right. So now that we understand what attack pads are, now let's move to the fun part. How can we create these attack paths? So how can we use lab environments to create these attack paths? Uh so we can explore them. Well, of course going back to the mental model that I was sharing before, this is what we need. We need principles. We need permissions and entitlements and we need targets to go after. So let me introduce you Batcher. Batcher is a tool that I

wrote a couple of years ago that actually uh populates enter ID Ashure environments by creating identities, resources, entitlements, permissions and then it allows you to configure attack paths within those environments. So you can explore how attacks are created. You can simulate the attacks and you can learn from them. That's the main goal. Uh I'm actually going to release a new version today. After this, I'm going to merge that P pr PR request which has a lot of the features that we're going to share today. So, um, Bacher really has a really simple configuration file. So, you can define basically how you want your lab environment to be constructed. So, you can define how many users and

applications, service principles, groups, administrative units you want created. Ber is going to randomly generate new names every time, new group names and it's going to randomly assign them. So we can create try to create the idea of a fake environment. Right? Then it also supports creating actual resources. At the moment we support uh four which are or three really virtual machines, storage accounts and key. So you can define how many you want. It's going to randomly pick names, create them, put them in random resource groups. So that gives you that baseline of what looks to be a real environment with identities, resources, permissions. Then we move on to the attackpad area. This is where you can configure your

attack paths. And at the moment I support I think three privilege escalation techniques and multiple parameters and they're all described on the wiki. But essentially on this on this second part of the YAML file, you're essentially defining what are the attack paths that I want in this environment and batcher is going to inject them for you. So we're going to have a look at uh four attack paths and we're going to create four attack paths in our lab environment with batcher in the demo. This first attack path uh is a pre preset 411. Let's we have a user Bob. Again, I like the name Bob. I guess Bob is the owner of an app registration. And

that's the first attack primitive. If you're an owner of an app registration, you can actually manage it. You can actually create add credentials for that app registration. And if you're able to add credentials to it, then you can authenticate as it. So you effectively escalate privileges to a service principle. So this user Bob who doesn't really have any other permissions than being the owner of this app can effectively compromise the identity of that service principle. So through this attack path Bob escalate privileges to this acme service principle and if this app get service principle has this privilege role uh which is an entry id role. This role actually allows you to uh promote anyone to global admin. So

through this attack path you Bob could become a global admin or assign a global administrator role to any other user right so effectively escalating privileges and taking over the tenant that's one attack path second attack path has the pre pretty similar first steps but the only difference is that on the last step the compromised search principle doesn't have an inter ID role but rather has a Microsoft graph API or API role which is the app role assignment ment rewrite all this API permission actually allows you to assign yourself or any other principle any permission so you can promote yourself again give you another permission and then finally make it to global admin as well so that's our second attack but

that's pretty similar for to the first one the only thing that diff that changes is that last permission now let's move on to the third one which is a slightly different now we introduce a key volt into the mix so let's say that we user Paul has somehow a permission to read a key volt and if this key volt has a secret for an app registration that runs as a service principle then once again through that key volt you can escalate privileges to that app registration and in this case the mail read permission guess what allows you to read emails in an environment so you can actually read emails from that tenant and the most interesting and the most

complex attack path that bachelor supports at the moment is this one where we have a VM now um now we have a virtual machine if the user uh Tom can execute code on that VM and if that VM has a manage identity and if that manage identity has a special permission against another resource in this case like a ser uh storage account and in our simulated attack path if that storage account contains certificates for another app registration then our attacker can traverse this attack path by first running code in the VM stealing that manage identity token abusing that manage identity token to read a storage account, excfiltrate the certificates, use the certificates to authenticate as

a service principle and effectively become the service principle and then finally the permission file that reads all allows you to read anyone's file uh one drive or shareepoint files. So this is the fourth attack path. Um all right so let's move on to the first demo real quick and hopefully this works out here great. I was afraid this is not going to work and let's make sure we have the right quality. Uh but essentially what I'm sharing here is you know we have a live tenant uh hopefully this shows up uh it's pretty empty you know have we have no users no groups no resources and we have our tool here batch which is again open source

you can download this and do the same what we're going to do and then you have this configuration file which will define what we're creating in our lab environment in this case I'm going to create 50 users 50 20 applications you know you get the idea those are randomly generated identities and then we're going create 10 resource groups, 10 key volts, a few VMs, a few storage accounts and then on top of that we execute those four attack paths that I described on the slides. We are describing them here with YAML. And of course, each of these parameters mean something. And you can go back to the wiki to learn what they are. And all we have to do is simply

call the build command of batcher. And batcher is going to use terraform on the background to start creating these things. Uh creating attack bots. Um and of course we can see here what everything that's going to be created by looking at this terraform file here. Uh and you can see exactly you know here all the user that he they're ger is going to create all the the entitlements uh attackb permissions. So I'm going to fast forward a bit because uh we don't have uh a lot of time left and [snorts] bure finishes. It takes like from 5 to 15 minutes depending on how many things you're creating. If we inspect our tenant now we see it's populated with

you know these 50 users randomly created identities. He has groups he has entitlements. He has permissions, all the fun stuff. But now let's take a look. Let's take a look at uh a couple of those attack paths that were created uh with batcher. So we go back to the terraform file that described everything that was going to be created. We can go back and actually see that each attack path has an ID. So we can expect inspect those attack paths that we just created with batcher. So let me inspect one of them. So you kind of like see the idea of how the attackpad looks from an Azure perspective. So I'm going to pick randomly pick one here and this is the

one and I'm going to pick this app registration called cyber director. So this app registration cyber director if we look at it uh from the Azure portal we find it and we see that it's going to have a privilege permission 10 minutes. Okay. Um and that's it. That's the mail that read permission. So this permission allows you to read um anyone's emails with the tenant, right? Provided that it's it's consented, admin consented. This app registration doesn't have any owners. Okay. Um so how is it part of this attack path? Well, there's actually a key volt. If you look at the terapform file, you'll see that there's a key volt name. And if we inspect that key volt,

we're going to find that batcher has actually when it created the app registration with the permission, it created a secret for that app registration and then it created the uh key volt and then injected that secret into that key volt. This again we this way we are creating the attack paths right. So we are and then finally we are allowing a user and we're going to fast forward a little bit here. We're going to give a user a random user created from the previous steps. We're going to give a user read access to that keyboard. So that's how the attack path gets constructed. Now we have a user who has a permission on a key volt and this key has a secret for

an operation and this operistation has a high level permission and we can navigate the attack path. So with this setup now you can go ahead and test this attack path execute attack simulation perhaps run black hound against it or run your security tools like will your security tool detect this attack path. Um I have one more here but I don't think I will have time to show it but essentially this is the one where you know what let's do it real quick. So there's a VM and this VM has a manage identity that has a role assignment and this role assignment is surprise storage blob reader and guess what that storage account has certificate files and those

certificates allow you to authenticate as a service principle. So that's way batcher you know allows you that's how virtual allows you to create these different attacks. All right so let's go back to our slide. So now that we have the um attack path created thanks to batcher, how do we simulate those attacks end to end where we start as a compromised user, we abuse all these different legitimate permissions, entitlements and then we get to the goal. Well, I wrote another tool for that and that tool is called MS Invader. MS Invader is an adversary simulation tool that allows you to execute end to end attack simulation playbooks. Um, and guess what? It also leverages a really

simple YAML configuration file where you define a few things. Things like you first define what are your victims, your assume compromised victims. So you you have a user here and um and yeah two victim users here and then you define a playbook with all the techniques that you want executed and under the context of which user. I think I support 30 or 40 uh unique techniques now and those techniques are essentially the attack primitives things like read email add application secret etc etc and all of this is documented um on GitHub and thanks to Chad GBT I have pretty good documentation now so let's go back to that attack path remember that first attack path that we

saw um on how to become escalated prives to global admin well now we're going to execute it and uh this is our playbook. This is our MS invader per playbook, right? So let's say we have a compromised user. As that compromised user, we're going to store what is the attacker do the first team time they get in? They do enumeration. So we're going to enumerate users, enumerate groups, enumerate applications. The cool thing is that all these enumerations through the graph are going to create logs. So as we execute this attack path, we can validate if our security posture would have detected this type of enumeration. Right? That's the main goal of nimator to generate telemetry that allow you to

validate your detection or to identify those blind spots you have in your uh logging coverage. So once we finish with enumeration we want to um to escalate the privileges. We're going to add an application secret because this user is the owner of the app. So we can add a secret to it. Then we authenticate that as that app registration or service principle. we do uh we assign um we assign ourselves a new role that will allow us to become um to be able to assign any entry ID role. We're going to create a new user going to be Lex Luthther and then we then promote that user to to um to global administrator. And then this

is this the third attack path which involves a key volt right and if you remember um the attack path the attacker can read the key volt read the secret authenticate as principle and abuse the search principle and this is the playbook that MC is going to run for this. So we're not going to go through that because we only have 5 minutes. I'd rather stick to the demo. So which is cooler and you'll find it more interesting. I think I hope at least I had fun doing it. All right. So this is the same play that we just created with batcher, right? The same attack pad, right? So we have this user here um who is the owner of an app

and this app has this app role assignment or this graph API permission. And as you can see there's no user called Lex Luthther or Lex in this environment yet. So we have our MC mater playbook and of and I'm not going to go through the details and we have our yeah MC materi art you must have it and the playbook here I'm not going to go through the details of what the playbook does but documentation once again thanks to Chazb is pretty well good uh documented there on GitHub of all the different features and the techniques that it supports but essentially you just describe the playbook that the end to end simul ulation uh tax simulation that you want

against this environment. Um and then you just start running. Um in this case, we're going to assume that this user is compromised, that we have their password already, and there's no MFA. Um so it starts running. Uh takes a few minutes, but we're going to just fast forward here interest time. U by the way all these videos are also going to be on my GitHub. So if you want to watch them later um you can for each step it's going to give you details of what you know what it did and the results of each step. As you can see here it added a secret it basically using the graph API and the ARM API to

do a bunch of stuff. But if we go back to the to our to our app registration, we now see that this appreciation instead of one now has three roles which were part of the attack path where it abused this permission to grant itself all the roles. And if we see here, we refresh the the um certificates and and secrets, we see that there's a new one that wasn't there before because as part of the attack path, we added a new one using the API programmatically. And finally, we do find a user Lex Luthor here. And now, guess what? He's a global administrator. So now this tenant has been compromised thanks to this attack path and thanks to Invader

allowing us to do this in in an automated way. Let's move on to the next uh playbook where there's a key volt involved. Um yeah, so this is the uh key volt that has a secret and as you can see this secret uh this key volt um has uh a user has a permission against this key volt and that's the user we're going to use as our assume compromised user with our MS invader uh playbook. So we have 2 minutes left so I'll just fast forward. Here's the second playbook where we describe which are the identities that we're going to use. What are all the steps that we want to take on this simulation playbook like things like

list key volts, add access key volt, uh add an access policy, read secret, authenticate, etc., etc. And finally, our last step here is actually we're going to excfiltrate emails uh from the tenant. So uh we run the second playbook um starts doing its thing and we see towards the end that it it actually excfiltrated emails. you'll see towards the end um the email see those emails that you read from those two mailboxes. It actually you know use the graph API and abuse those permissions to excfiltrate emails just like real attackers do and as you can see here there's a new access policy that was added by MC invader and that's how the attacker is able to read secrets from

this key volt. Um, and I think yes, I have like 30 seconds, so we'll just wrap this up. [snorts] And yeah, those are the tools, guys. You can use them open source and my goal is for enable you guys to learn about tax plots, create them, simulate them, look at the telemetry. Uh, you can get a national subscription um with a credit card. So, just don't go crazy on the resources. as long as you delete them um then you should be fine. Uh but yeah, go out go out and try them and thank you very much. These are some resources from like researchers that post a lot of HID and Ashure and and so just if you're

interested about this topic, I recommend hitting those. They're going to be on my slides. But thanks a lot. I hope you liked it. THANK [applause] YOU GUYS.