BSidesSLC 2025 -- Restless Guests – Azure Exploit Exposed by Simon Maxwell-Stewart

All right, thanks everybody for coming. Um, as you can see, I was I was too cheap to pay for generative AI, so uh just just decided to indulge my own picks. Um, but yeah, just a quick intro of who I am. Um, I've like mostly worked in kind of like software engineering and kind of data engineering. Um, then kind of done some data sciency stuff. Um, like graduated from physics. Um, so kind of found my way into cyber security. Um, and I'm a bit newer to it. So, apologies if uh I don't know some some acronyms and things like that, but uh we should have a bit of fun today. So, um primarily we're going to be going

through a weird Azure mystery um how it happened um which kind of leads us to some fun undocumented behavior of kind of um of Entra ID and Azure. Um and to do that, we're going to be going through some basics. So, no worries if you don't know much about like Azure at all. Um, then we're going to be kind of getting into the weeds of some a few advanced concepts that like are relevant to to this mystery. And then finally, the undocumented behavior itself. We're going to learn a bit about Microsoft's position, what they thought of this, and possible ways we might be able to abuse this, as well as how we would like defend um this. So, I have lots to

present. So, I'm going to probably be going at breakneck speed. So, first of all, let's take a look at this mystery. We had a guest inside of Entra ID. um formerly known as Azure Active Directory. Don't worry if you don't know that too much. I am going to go over that. But they were somehow able to make a subscription. So I will also go over what a subscription is um and what it means. Um but basically a partner reached out um to us. Um I'm in the privileged position of getting to work with a lot of different um people that are trying to defend their Azure setups and they reached out and they were like,

"Hey, how come how come a guest has seemingly been able to make a subscription? That should be a fairly privileged thing to be able to do." Um when we dug into this, we realized that okay, the the guest account had had their like credentials linked leaked to the dark web. Okay, that kind of made some sense. um they were a B2B user in um in this Azure environment. But then when we dug into this, the the guest user had no group memberships, no directory roles, no arbback roles, and seemingly no permissions granted at all. And yet somehow they were able to make a subscription. Um and so this drove me into a a state like uh what you see on

the left there of trying to figure out and reverse engineer how any of this stuff works. Um okay so to understand this let's let's cover the basics. So first of all this is how like this is um Microsoft's homepage when you go to Entra ID this is the diagram that you see it kind of gives you a very high level like rough idea of what's going on in in Entra ID. And so to kind of bastardize a little bit what is a complicated um piece of software um it's like mostly an identity provider, right? It's it's it's about kind of enabling you to have things like users and machine identities and have those a like

be authenticated um by um like Entra ID. It's kind of the cloud replacement of what the on-prem active directory was. Um you can link that with your kind of on-prem active directory if you want. Um and then from that you can kind of hand out access to kind of like applications. Um and yeah you can have users and those users can also sometimes be external identities which is another name for guests. Um and then you also have this funny thing of devices. Um we're going to come to that a little bit later. Um, but yeah, this is this is kind of how Microsoft wants you to start thinking about Entra ID. Um, I'm going to go over just like some

some kind of basic basic concepts here and kind of build build things up. So, um, we we have um, Entra ID's directory, sometimes called a tenant. I'm going to be probably using those those two terms interchangeably. Um and yeah you can see that like a user or a guest is going to authenticate against the directory. That could also be a service principle. Service principle is what Entra ID call kind of machine identities. And then you can also have devices um that can authenticate against the directory. Those aren't kind of typical kind of principles. Um they're more like the environment that principles operate in. Um but they do have certificates that allows them to like authenticate against

the directory. Um so in terms of kind of basic privileges that you can have um users and guests can be given arbback roles. Um those are things that allow you to have like some kind of role over kind of Azure resources. We'll we'll come to that. Um then you've got directory roles. That's like going to allow you to do certain things to the directory itself. Um and then app roles. That's going to give you some level of access to some of the apps that are integrated in Azure. Um and then basically it's a very similar story with like service principles to like the the the kind of machine identities um except instead of like app roles we have like API

permissions very similar thing um where those API permissions kind of allow you allow the machine identity to like go speak to another API um with kind of some like very like fine grain kind of permissions about what they're allowed to do on that like API. Um and then um we just have this idea of like groups which basically means that we can you know put users and service principles in groups and then hand out these kind of privileges um that we we just talked about. So um how this fits with Azure resources basically Azour resources are going to be like all of your like infrastructure like stuff. So this isn't your kind of identity provider stuff. This is like you know

I've made a VM I've say got a database and things that's all going to live in kind of Azure resources and the kind of key takeaway to think about all of this stuff is like subscriptions are the logical container for um Azure resources. So that's going to mean that primarily subscriptions are are meant to act as like um a security boundaries. Um, so if we've got our stuff in a subscription, you know, that's kind of going to be shielded away from kind of um other other subscriptions. And that's kind of primarily how we kind of like lock things down. And you can see how that kind of joins into um the directory is above the subscription. You can have

management groups. Um you can have those recursively, but it's always going to end in a root management group and that is going to be contained by the directory itself. Um, so this is actually going to become really important later as to how this all this stuff works. Um, and so just a quick note on arback roles. Um, you kind of can do your own custo custom ones, but typically kind of, you know, there's this idea of kind of the these ones out the box where you're going to be like an owner potentially of a resource or a contributor to a resource. Um, you might just be able to like read the resource. Um, so there's a whole bunch um of of

these arback roles. Um, okay, let's get into the weeds a little bit. Um, so first thing we've got to understand is how guests can get invited into a directory. So someone um say on the the in this case we've got two two directories, two tenants going on. So the resource tenant that's say where you as a defender are kind of like operating. You then decide that hey I want to invite someone into this directory. So you then send out an invite um to that user and then if that user's email address um is like tied to an existing Microsoft or Entra ID directory then they are going to authenticate actually to their own directory and then federate into the the

directory that you've invited them into. And so it's a little bit of a weird behavior, but this federation behavior becomes really important to understand kind of what's going on in this in this weird mystery of ours. Um, so once we do that, you end up with a user like this. Um, there's like just a couple of things to like point out. Just mostly this identities field um just beneath the user type you can see is set to Microsoft account. That means that this this user is federating in from their own Microsoft account. That could also say external Azure Active Directory and which would mean they were coming in from a um another directory kind of

thing. Um this mystery applies to both Microsoft accounts and um Entra ID directories that the guests federate in from. Okay. So one other weird thing that we've got to understand before we can really understand how a guest made a subscription without any any permissions. Um, we have billing agreements. So, billing agreements are like separate. Like when I was kind of digging into this, I assumed that our billing admins were the same as our global admins of the directory. They're not. Um, billing accounts exist as like a kind of third kind of major highle thing in this kind of recipe that we're looking at. Um, they come in kind of two flavors. Um you've got enterprise

agreements, that's the kind of legacy one, and then you've got Microsoft customer agreements, that's like the newer thing. Um you've just got this idea of kind of like hierarchy kind of at the top. You've got the actual kind of billing account for the EA enrollment. That's like kind of you know the actual kind of contract itself as it were. Um and then um for MCAs, the billing profile is where the like credit card is actually going to be like attached to your invoice section. just kind of is a way that you can organize like invoices. It's like really just kind of something that you can kind of split up um split up your kind of

billing. It's more of just a kind of organizational construct and then within those then subscriptions are housed um and will be will be built to those invoice sections. Um EA's very similar just a little bit of a different kind of hierarchy and organization. Um nothing too important to understand in the specifics of these of these hierarchies but it is important to understand that users can have billing roles. Um these are separate from directory roles. These are separate from arbback roles and um they can allow for subscription creation. Um so basically if I'm um a owner or contributor um at any of these levels for the MCA things then I will be have a permission to be able to create a

subscription and then also in the world of MCA accounts you can also have a specific subs subscription creator role um and this is just comes from your your billing role. um EA very similar um it's just that yeah you you don't get anything from the from having um an administrator at the at the department level um but kind of similarly if you've got administrator um or owner of the account kind of thing or administrator of the EA enrollment then you get this subscription creation um like uh uh permission that you can do. So um this is how Microsoft um kind of visualized these these kind of three things sitting together. So you've got your kind of

Azure resources, the Azure Arbback stuff that's like tied and glued into your your um actual directory, your tenant, and then on the side you've got your your your um EA account. Um so very similar for kind of MCA stuff. All right. So yeah, just quickly these these are the different roles that allow for sub uh sub subscription creation. Um okay, so let's get into some some properly undocumented behavior. Um so billing roles are very weird as as we discovered. So it turns out that these billing roles can work across um tenants. Um which is something that when um flagged this to different people who were really big experts in Azure, have been kind of defending Azure for a long

time, none of them um none of them expected this or knew about this. Um so I I think this is this is something that that most people wouldn't be aware of at all. Um I haven't managed to find um any of Microsoft's documentation kind of explicitly pointing that this is possible but basically um we can kind of glue together this billing role idea that we learned about with kind of guest federation um where basically we can use our billing role in the home tenant um that we came from to create a subscription into the tenant that we're invited into. Um, and weirdly we don't do that by like logging in and going into the tenant kind of thing. We we

stay in our home tenant, but we get this option when we create the subscription to be created in this tenant that we've just been invited into. So you can see here we're in this like in the home tenant. This is a directory called default directory. And yet when we go when we're making the subscription and we go under the advanced tab, the subscription directory can go live in a different directory. So you can see that doesn't say default directory. I've had to fosticate some some parts of this, but uh hopefully you can see that that's that's not the same. Um so the end end result is is that then after we've done this subscription creation then when we do go federate

into the resource tenant then we are now um an owner of this subscription and that's done through like an arbback role. So somehow we have now managed to become um an owner of a subscription. Um, and this the the person in the resource tenant like no admin in the resource tenant gave out the billing role. Like this is just the billing role that we had from our home tenant. Um, when I recreated this in the lab, like in just a lab environment, this was just something that I got from signing up with a credit card and making a Microsoft account kind of thing. And the resource tenant that I was invited in did nothing to to give me permission to

to do this. Um definitely a little bit um a little bit shocking. Um so when we look at this then from now having logged into the resource tenant this is what we can see. We can see that we have a subscription and that we are now the owner of it. Um so when we talked to Microsoft about this um they they said the following um that this was this was um confirmed behavior. they knew about it because they had intended this as a feature. Um we our our partner um that we were working with didn't necessarily want this behavior. So um we asked whether there was any controls that existed to um prevent this. Um and we're told that

no at the time of the meeting there wasn't any any way to prevent this. Um we have since had an updated position from from Microsoft. that I'm going to cover what they now recommend um and what I understand it to mean um and that they said that this isn't really a vulnerability as subscriptions are meant as a security boundary. Um so basically their position was like sure you can make one of these subscriptions. Um but nothing's in it and so um it's going to be kind of shielded away from the the other stuff in the directory. Um so as far as they were concerned it was it was all all um fine. Um it did bring up some

questions for me of kind of like okay um can you really abuse this um like are there are there interesting ways that we can kind of use use this kind of weird privilege model that we have. So um just a quick note on that kind of privilege model. Um, the kind of weird thing, the weird situation we find ourselves in after we've made a subscription as a guest user is that we're kind of like king of the castle of this subscription. That's not like being a subscription owner is normally a pretty privileged um like role, but it's an empty subscription and all the interesting stuff that is potential targets that we want to go attack are

living inside of a different subscription that we don't own. So um that's that's kind of like the the problem that we we face as as trying to kind of like abuse this. Um so just taking through some completely failed attempts that I went um through to try and try and abuse this. First thing was um a billing attack. Can you kind of use this to offload cost? make a subscription then like you know do a whole like make a bunch of VMs do some crypto mining whatever kind of stuff and then get like the person who's like um you know paying for the the directory to to kind of offload the costs and unfortunately not because like

everything gets linked back to our billing account um so um because it was our billing role that like allowed as the attacker that allowed for for this and so everything's kind of tied back so we can't use it to offload costs. That was like a very obvious first thing to kind of rule out. Um, another thing was just to kind of like try and get another subscription kind of thing using our subscription owner and like you know Microsoft have done their job well like you know um subscriptions do broadly act as security boundaries. So you can't just kind of go ask for one. You can try and get them transferred but that's like something that's going to have like have

to have approval on the other end. So, this doesn't doesn't really work. Um, but after an embarrassingly long amount of time looking at this, um, I did notice this. So, when I went to my guest main subscription, we can go to the access control, um, I am settings and then suddenly I noticed that, hey, a whole bunch of stuff has popped up here. Um this is something that there are controls for um but that's not by default. Um and so what is happening here? Well, if you remember before um there's that idea of that root management group. Um so root management groups can have arbback roles um like um set on them. Um and so we that that's

often the case for things like user access administrators. Um, so it could be that we want to have someone that can administer the root management group and so they can do things across like all of the subscriptions. The trouble is is that that that gets inherited into the subscription that we've just made. And so because of that, we can then enumerate out those user access administrators. Here you can see there was also some other fun stuff that um like happened. There was a key volt reader um and that was like set like the root management group. Um there was some service principles um that were just kind of given permission to all of the subscriptions and so that permission

basis was like given out at the the root management group. Um and so there is a way to prevent this but I think the the key takeaway I want like folks to understand from this is that like this really isn't behaving in the way that you would like. And if you notice at the very very bottom of the screen um I'm like trying to list out like users um and it says like insufficient privileges to complete this operation. That that is I think how most people are going to be thinking about this is that hey I have a guest I haven't given them any permission to list any users. They're not in a part of a a group where say

they can list the group members. And so you may well look at the controls I'm about to show. um and say, "Well, that kind of doesn't apply to me because like they they don't have any kind of relationship to an object um that they've like either like a member of or like own. So, they shouldn't be able to see anything. But unfortunately, um they can via this via this weird weird and wonderful way. And just as another thing to kind of point out, these are all like pretty high value targets, right? These are these are your like these are often your kind of global admins that may well have ended up as like user access

administrators. Um so this gives the attacker some some like you know their their email addresses um their user primary names um that they can go start like trying to target. Um so this is quite a cool cool thing that you can do. Um as I say there is a there are controls that like can prevent this like specifically um but you've got to go from not from the default into the most like restrictive um settings. Um and so um yeah kind of typically kind of guests can only read objects of say like um you know say you make them a member of a group. Well then okay they can then go see the group that they're a member of

and then they can potentially see other other group members. Um and that would kind of be for the for the middle setting. um if you put them on the bottom then it's just like um it's like yeah that only only stuff that they own in the directory um are they able to view and so this does does stop the behavior um so if you're a defender out there you might want to you might want to think about this setting um a bit more bit more closely um okay Azure policy this is another fun thing that we can abuse a little bit um so Azure policies that's like policies that we can set um on like Azure resource um

side of things. Um so often these are policies that say like hey you're not allowed to download uh red team tools to um to VMs or if you do there's going to be um some security center alerts that that pop up. Um and so um by while this isn't enough to kind of carry out an attack by itself, it is very nice in that some of the other stuff I'm show showing you. We can really massively quieten down the um security center alerts that are going going to pop up. Um and so yeah, this is this is a cool thing that we we as the owner of the subscription get to say what the policy

is of all of the the the infrastructure and resources that get created inside of that subscription. Um, okay. Managed identities. This one's a fun one. Um, so managed identities are a way that we can have like Azure resources can actually like authenticate and become like a principle within like Azure. So, so say we want our our VM to um you know um have an actual like identity in the directory kind of thing um that we then can kind of hand out privileges and permissions um from. um this is kind of how we do it. And so there's um couple of different ways that you can do it. You can either have user managed or kind of like system managed

um identities. And those um like if it's user managed then we get to control the life cycle of that um which is really nice from an attacker point of view because it means that that managed identity is going to hang around um even if the VM shuts down that it's attached to um and gets deleted. Um, and so this this inserts a service principle into the directory. Um, and so we've kind of done something really fun where we've kind of used our guest like owner um, permissions over a subscription. We then are allowed to then create a VM inside of that subscription. We can then attach like a managed identity that we also create. And then um we have now actually

like put this this service principle into the directory. Why this is like significant is like one because like we've pivoted right like we we now have like we're starting to gain like persistence in this like system. Um and um that there's like we can then give give that service principle um the ownership over the subscription. So we haven't lost any any privileges in the process of doing this. And in fact, we've actually now evaded some um privilege escalation protections. So in Azure um users um have privilege es escalation protections against them. So if we have like change password um permissions, we can't go change the password of someone that's like more privileged than ourselves um to stop

ourselves kind of being able to like escalate like that. Um service principles have no such protection. So we have pivoted and also now evaded some some protections that we like had just from our guest um just from our guest account. Um and we can take this like a tiny bit further which is fun. Um like a whole bunch of these techniques um after the like this this isn't my work. This is now me just trying to kind of use different techniques out there like using this kind of novel kind of subscription creation thing. But this was there's a really cool researcher I'm sure many of you would know Doug Jan um and um he's he's got an article um

detailing how with um with managed identities we can give them federated credentials and he's in fact got a red team tool which like spins up an OIDC provider so that we can basically have completely attacker controlled credentials of this like service principle which is really nice because we just say that hey uh the credentials to the service principle are going to come um are going to kind of federate in from our own like OIDC provider and then we can spin up just like that OIDC provider using using this tool that Dougj presented and so now we've got like a separate identity that didn't exist before that we've inserted into the directory um and that we we control

these like federated credentials um so there you go like this is this is kind of a full full kind of Um yeah, the the kind of full thing that we can do with managed identities um to kind of like get get persistence in in this in this directory. Um so there are some other cool things that we we can do. Um conditional access policies. Um this is where the the device um side of things comes in um that we we were kind of speaking about before. So there's a bit to understand about devices in um in Azure world. Um so say when we're making our virtual machine um we can install in an extension like this um and what that

is going to do is after we have after we've made our our our VM is in the directory it's going to now pop up as an actual device. Um, and that is actually going to be joined to Entra ID. And that has some significance that it's now a joined device in Entra ID. You can see it gets this device ID. Um, and that like um there are some like other fun stuff that we can see here. This device has um TPM protection disabled. That's going to be important um later. Um, so there's a really cool researcher called um called Dr. Azure AD. Um he is the guy behind AAD internals. Um it is both a

red team tool and a blue team tool. Um used by tons and tons of people um for for trying to either attack or or defend Azure Active Directory. A very very smart man. Um he's done a ton of really good work on device um stuff. I would recommend go read this this post that I linked to. Um it really explains kind of devices but basically um devices are kind of yeah like this endpoints that are supposed to be kind of like trusted environments um for um like our principles to operate in. So um they only get that trusted um status um like you know they kind of operate from a kind of zero um potentially if they pass certain

conditional access policies they will then become trusted and what that means is that um potentially when a a real um identity a real principle um I think it has to be a user um logs into that device because that device is trusted. They'll be issued a primary refresh token. And for for those folks that don't know, primary refresh token is like the long live token that you use to go ask for access tokens. So they're like a really valuable thing to steal. Um very very nice things. I haven't yet managed to um pull off a primary refresh token stealing, but I did do a related concept um and I think it might still be possible. Um I just um ran out of time

on the research. Um but basically yeah and you can see this conditional access of the device information is used to kind of allow or block access to services. Um and so kind of how how we can start to abuse this from our like specific model is like one um there's a fun this is a bit of a again a bit of a a kind of a new approach to an old technique. Um it's been known for a while that you can potentially um use dynamic um device um dynamic groups you can abuse for like users. Um so dynamic groups are just groups where your membership is based on various different attributes of the object in question. Um

so for users um it could be your like name, it could be your like department or something like that and then you'll get put into a group. The problem comes when like attackers control those attributes. Then the attacker can potentially like guess some rules and end up in a group um that they they wouldn't necessarily um be able to get membership to otherwise. Um and so that that's like a known technique for kind of users. Um, I kind of realized like within this kind of like world we could like do something fun um for for this kind of like specific threat model where potentially when we're making our kind of guest made VM um we can then say like

oh I'm going to call it like Windows workstations and you know it could be that hey there's a a a a device group out there that has these dynamic rules that anything starting with Windows is going to mean that it's like a trusted Windows group. um you we um in the privilege position I'm in at Beyond Trust um we do have access to um some some interesting data and so I went went looking at how these are actually used in the wild and one of these uh like the example I give at the bottom was actually a real life um example of of one of these dynamic device groups where um AVD stands for Azure virtual desktop

um and so there was plenty of like easily guessable like things like this where hey the as a attacker we get to control the display name of what this device is called. So I just have to just try say um guessing a bunch of different uh uh you know plausible kind of prefixes to to kind of start off my device with and then it might be that we just you know hit hit the jackpot and end up in one of these groups. Um so yeah another fun that we can do um uh was um following this other post um by Dr. Azir AD um he kind of demonstrates how you can um steal um device

identities. So kind it's a it's pretty similar to a primary refresh token theft. Um, instead what we're going to be doing is like stealing the certificate that is used by the device um to authenticate against the directory. Normally you can't steal this. Um there's like protections like in place. Um but hey, guess what? We are we get local admin to this this VM because we are um the like the owner of the VM and then also we get to choose what kind of VM uh that we're spinning up. So um while the the they call it like gen two um VM um images have protections against this against this we can just say hey we want a a a v1

um image and what that's going to do is get rid of um like TPM um protection um and secure boot and that then means that we can then go actually um steal a device identity so we can export that certific certificate um like off of the system. Um and then uh as Dr. Azure ID kind of put in his post that like may allow evading device-based conditional access policies and the compliance of the device and we can kind of use use this like device identity on a different device completely. So we can say, hey, you know, impersonate that we're being like a Windows machine potentially on like a Linux machine and do kind of all

kinds of fun shenanigans. Um, okay. So, in terms of the defense and how to best defend defend against this, um, Microsoft have since updated their position. And so this is probably the most important important slide to to take a look at if you're trying to defend um any of this stuff. Um there is a a um setting of kind of the um subscription policies um where when we go into these subscription policies, you can see we can we've got these these two options of subscriptions entering Microsoft Entra ID and um subscriptions leaving. Um it's not immediately apparent that this like applies to our problem. Um I think what's going on here is that under the hood the way that that

it works from how we do managed to do this um subscription creation in a different tenant is I think what's happening is under the hood it's making that subscription within our home tenant and then transferring it over to the resource tenant. And so by changing it to um permit to no one um then we can we can block that um by by by changing that that policy of the subscription entering the the the tenant. So good news now is that there is there is some way to do this. Um the partner that reached out to us to begin with um did point out that they they believe they had this in place um and had some receipts to to show it. Um

they were on an enterprise account. Um when I was recreating this in the lab um I only had access to a an MCA because the EA billing accounts are legacy. It's it's pretty difficult to get hold of one. Um so At this point, I'm unable to say exactly whether this policy stops that for for the legacy um enterprise accounts. Um but it does seem like this now um this this this prevents things from for the MCA accounts. Um so definitely if you're on a a um MCA um account, then I recommend switching this on. In terms of other controls, uh you'll see in um the directory um we can go to kind of like the settings. Um and

then we can go to to this external collaboration settings. Um there's like a bunch of different settings for guests here. Um I would recommend probably switching all of them on to most restrictive unless you have a rule like an a reason not to. Um there's some fun stuff that we can do like of allowing kind of guests to invite other guests and only kind of compounding the problem worse. So probably most of these things you want to kind of set to their most most restrictive um settings. Um and yeah um the um the guest user access one at the top that's that's the one I already spoke about in terms of like stopping the enumeration attacks. Um, so that that

one seems especially important. Um, and then just one one kind of specific attack that I think all of this like opens up that I think like defenders should be aware of is when we've done this kind of pivot to use to make a a a managed identity and that's like inserting a service principle into the directory. Um, it's kind of worth pointing out that we're we're really just one API permission away from being global admin. um we don't have it but if we managed to get a way to get um a certain um API permission we would then effectively be be global admin of the the whole of this Azure setup. Um so for instance the role management readwrite

directory that's going to give us that service principle the ability to to assign um to assign directory roles and so we could then assign our original user the global admin or we could assign the service principle itself global admin. Um, so we we don't want to be in a situation where that gets granted. And like I think in in lots of setups that that exist, you know, it may well be that your guests do actually have some kind of like teams access, say, so they can a guest can say, you know, has been granted the ability to to kind of shoot your team a message via like teams. And so they could kind of use that to be

like, hey, I'm kind of blocked on a project. like do you mind just like do you mind just kind of adding this this this application that I'm using says that it needs this API permission. Um I'm hoping that your like Azure admins wouldn't wouldn't fall for this. Um but it would probably fall a bit outside of their kind of expected threat model. um because you wouldn't necessarily be expecting that the guest would be controlling the the service principle itself if you haven't handed them any explicit um explicit permissions to to have um you know be owner of any any service principles. And so um you know um you could kind of plausibly make this look like quite an innocent kind of

request just to kind of get like unblocked on a project um and that then actually like you're you're just kind of giving them the the one the one API permission they need to start start doing something really nasty. So I think while this is a bit more improbable because of its disastrous consequences, it is worth just making sure that your like admins like definitely know not to just go handing out API permissions willy-nilly because hey, we control all of the the applications on our side. Um, okay. And then finally just some like wrapping up um notes like um uh we we can we can monitor like guest main subscriptions a little bit by just kind of like taking a look at the owners

um like maybe just polling the API kind of coming up with like um just like a little a little tool or just kind of regularly regularly checking it but just checking who actually owns the subscriptions on a fairly frequent basis could be an important thing to do. um probably reviewing the usage of kind of broad d like dynamic device groups um and your kind of conditional access policies that that may have these these dynamic um device rules in them. Um you know if they're very easily guessable um it could be and you have guests in your system. Um it could be that you're kind of exposed to this. Um and then finally um some alerts can pop up in the

security center. Um, it's a can be a little bit of a double-edged sword with this in that you can try and gain more visibility, say as a global admin, um, by getting access to all of the subscriptions, but hey, guess what? It's going to give you a role at the root management group. And so, you've also then just given more visibility to the attacker themselves. Um but if they do that then the global admins can see some of these alerts that pop up in the security center. Um again not foolproof though because we can also like do some stuff with the policies things. So um normally at least they'll be like hey that there seems to be I think they've

now released a um guest has made a subscription um alert. So hopefully hopefully that one will be be visible. Um, awesome. I think I've managed to end a little bit ahead of time. Does anyone have any questions? All right. Well, you know where to find me. Um, and I can very happily nerd out about this stuff anytime. Um, but thank you for your attention and uh hopefully your Azure setups are a little bit safer. Thanks.