Restless Guests: From Subscription to Backdoor Intruder

Thank you everybody uh for coming. Um very excited to be in Seattle. Uh got to bust out my my check flannel shirt. So, you know, it's excited to be in the Pacific Northwest. Um yeah, so today I'm going to be talking to you about some fun shenanigans in uh the world of Azure. Um so um my I I work at Beyond Trust. I'm a cyber security researcher. Um and today I want to talk to you about a mystery um that came across my desk. Um so um I was um sort of working working my my usual kind of a little bit more humrum research kind of thing and then um a partner of ours like reached

out very very confused um as to how a guest had like made a subscription. So I'm going to explain exactly what a guest is in the world of uh Azure Active Directory and what a subscription is. Um but um basically this partner was really confused because um this guest had no special permission um to be able to create this subscription as far as they could see. And as I'd published a bit of work on uh Azure before uh they they reached out to me and asked like hey what's what's going on here? And so basically the aim of today's talk is for any of you working in Azure um to un understand the true threat model of of

guests. Um as far as I can tell uh this has not been uh ever um properly documented. Two weeks ago, Microsoft did uh release some um documentation. I think it is still a little bit incomplete to really help people understand the true threat model of guests. Um so let's review a few facts about the case. So we the guest accounts credentials were leaked to the dark web. Um the account was a B2B uh guest user. Um, and for those people not familiar with the B2B guest user feature, basically it's a way that you can add users into your tenant into your directory um, and not have to pay for them is the is the the main thing. And

so basically rather than have to kind of, you know, onboard a user um, eat into your kind of licensing costs for like users, you can say that, hey, this this user is going to come from another directory. um they're like external collaborators and then you're not going to get like charged for for that which is which is cool from a money-saving point of view. Um the issue is is that then the um you don't you don't manage the account life cycle of of this user. Um so the other directory is responsible for potentially enforcing MFA and and all all fun stuff like that. So, while you get to save some money, uh there's potentially some things to really like

consider um about using these things uh about using the the B2B guest user feature. So, then I like confirmed like going through um what what permissions this guest had and as far as we could tell, the guest had no special permissions. So, it wasn't a member of a single group. Uh it hadn't been assigned a directory role and it had no arback roles. Um no other permissions granted. So, how was a guest able to make a subscription? Um, in order to answer that, we're going to go through like the basics. So, if you don't know what Azure Active Directory is, I'll go through that with you, like what what kind of Azure resources are. Then, we're going to get

into the weeds um to really understand like some of the kind of more difficult to understand uh features. And then we're going to get into undocumented uh behavior. Um, and while there is some now some documentation, um, as I say, I think, uh, it it it still is a little bit lacking. Um, then we'll get into what Microsoft thought about this and then some possible ways to abuse this and then finally how how you can actually defend against this. Um so I am a physicist uh in back is my background. Um was more in the kind of like developer kind of um software engineer world of things and a couple of years ago have um kind of transitioned into

cyber security and I love to talk about all things graph theory and uh I'm a big graph nerd guy so lots of the visualizations you'll see are all kind of graph visualizations. Um, okay. So, Azure basics. So, this is kind of how Microsoft wants you to think about uh what like Entra ID is. So, you can kind of see that like you can connect up to your like HR systems. Um, so you know that you know that could be like bamboo HR. Uh, you can like have like external identities like that's that's the kind of B2B guest users. Um, you can also connect it up to your like on premise um stuff, you know, active directory like

Entra ID was the cloud replacement for for the on-remise like active directory that existed a long time ago. And you can see there's also this devices thing that's like just hanging off of the visualization. Um, we'll get into devices and exactly what they are. Um, I'm going to try and like break it down just like a little bit more systematically. So, first of all, like Entra ID. So like at its heart you've got this idea of that like users and like guest users are going to be able to like authenticate against the directory. You've also got service principles. These are like your kind of like machine identities. Um and then you've got devices. Those do also get authenticated

against the directory. They're not like true security principles. um but they're more kind of like an environment in which true security principles can like operate in and potentially used in um like trustbased decisions. Um so that's kind of like the absolute basics in terms of like privileges. Um you can give users like directory roles that means that they're going to be able to do do things against the Entra ID tenant itself. And then we've got like arback roles um which we're going to get into Azure resources and arbback roles. And then you can kind of give these these users um app roles. Service principles these machine identity is pretty much the same thing um except instead of app

roles they have like API permissions. Um and then you can put those things in security groups and hand out like the privileges that way. So all all pretty basic stuff. Um, okay. So, Azure resources, this is where stuff gets a little a little bit weirder. Um, so subscriptions are really like the logical container for resources. So, resources being all of your like infrastructure, right? So, your VMs, potentially your databases, your blob storage, like any kind of like actual infrastructure that you're making is going to be contained inside of a subscription. It may optionally be inside of a like resource group. that can be a way to kind of further organize things. But the subscriptions is really

like your like kind of the the kind of like um security boundary between uh the different like um the different infrastructure. So it's going to kind of get get built under a different heading. Um and that we notice at the very top there is this thing that's going to come into play and is quite important. So above subscriptions we have management groups. So management groups are then a way that we can apply like management policies against like all of the subscriptions. And so um then the directory itself like ties to the management group and you can have you can have recursive um management groups but it's always going to tie up to one root level management group and that's

going to be quite important later. So hold on to that in your brains. for a second. Can you get the um clicker plugged in? Oh, yeah. So then we don't have to have Please, that would be amazing. Sorry about that. No, all good. I don't I don't have a USB. Um let's see. Does this one How do I micro USB? All right. Maybe I'll carry on while you're doing that. Sure. Okay. While we get this sorted, I'll just go over so Okay. So, like arbback roles. Um, so typically you can make your own arbback roles. Um, like the kind of like default kind of things is you know you're going to have like owners of resources. Um,

you know those are the those are the people who obviously like uh are the end owners kind of thing. But then you have kind of contributors. So those guys have like write access too. And then you can have kind of like things like reader um stuff. So all all pretty kind of like standard standard stuff and it's like a pattern um you see this pattern kind of like being rolled out like across a lot of like Azure. Um so so those are ourback roles um that you can have over infrastructure. Um so okay getting into the weeds that's like understand exactly how like these guest users are behaving. Um, so when someone decides to invite a guest user

into your directory, the invite's going to get sent out to them. So you're just going to enter the email of that person. But when they get into your directory, they're going to actually like federate in. So they're going to authenticate against their own home directory and then and then get federated in and then they're going to be authorized as a guest into into your directory. Um because um because obviously there's like room room for this to you know because they're kind of external collaborators. Um the idea is is that out of the box guest users have even less permissions than like typical users um do. So they're something close to zero trust users. I won't say they've

got no privileges out of the box, but they're very very limited in terms of like just just being a guest in a tenant really doesn't get you uh the ability to do very much at all. Um okay, so that's like after we've invited someone and you can see um just uh can I point with this thing? Anyway, you can see under user type there's this identities field and that says Microsoft account. That could either be Microsoft account or external AD external Azure AD and that just means that this person's coming from either a Microsoft account or another external Azure AD and then federating into the into the uh the directory. Okay, so this is a really not very well

understood feature, but is super critical to understand how we can pull off this this this weird behavior. So billing agreements, they're really just like a sidecar to directory like Azure directories and and uh Azure resources. So like this is just kind of like you know the domain of your kind of financial department as it were. Um there's like two ways that you can get build for stuff in in the world of Azure. There's like enterprise agreements. Those are the legacy stuff. And then the new the new model is um Microsoft customer agreements. Um they've got like both of them have got a similar kind of hierarchy. It's not too important the exact hierarchy here, but

you basically got something that kind of represents the actual like contract at the top. Um the department and the invoice section are kind of just like ways to kind of organize um your billing um into different like sections and like those got swapped. And then you've kind of got the billing profile which is like where the actual kind of credit card is going to like resign. Um and then in the old version that's kind of like the account and then then the subscriptions are then going to get build um like upwards through that through that direct through that hierarchy. Um the key thing to understand is you can have billing roles. So billing roles give you the

ability to make a subscription. So in MCA stuff, if you are an owner or a contributor at any of these levels, that gives you the ability to create a subscription. And then also you can just have a billing role that itself is just a subscription creator like role. EA stuff, it's like very similar um but uh just a little bit different. So this is this is from Microsoft documentation and it's kind of nice because you can see all the three kind of elements at play. So at the top we've got like Entra ID uh contained with that that we've got then got like the whole world of like Azure resources and then over to the side we've got the like the

EA account. Um the crucial thing you can see is that the account owners can create subscriptions and between the two different like versions like these are these are the different roles that can create subscriptions. Um so this is the fun stuff. This this is this is as far as I could tell completely undocumented. Um and uh this is pretty pretty new content. Um so there's a really weird behavior where um my billing role in my home tenant can be used to create a subscription in the resource tenant and I've like deliberately drawn the diagram this way where it doesn't come from having like federated in and authorized in I have to be in my home directory but

then when I create a subscription under advanced there's the option to create the directory in the resource directory. So if I just try and create the subscription as a guest in the resource directory, it doesn't work. But in my home directory, I have the option to create a subscription in the resource directory. Very confusing. I'll just show you show you what it looks like. So in that home home directory I go to create a subscription and then under advanced I can then choose the resource directory which you can see like at the top left it says default directory. That's the that's the directory I'm in in my home directory and then I'm choosing a different subscription

directory. Um so this is this is kind of unexpected like um this is like the end result that we get that when when we do then go back and federate in as a guest now we're an owner of this subscription after we created it. So we had to create it in the home tenant but now when we actually go in and federate in we're an owner. So uh everyone I spoke to uh after we kind of like narrowed down like that this was how this guest had made a subscription couldn't couldn't find a single practitioner who expected this behavior. Um, so we we did the natural thing, which is to go go talk to Microsoft um and like find out what what

they thought of this like um they confirmed that this is um intended behavior. Um it's like meant as a feature. Um at the time that we met with them, they said there was no controls to prevent um like you as the resource directory from preventing um this. and they said it's not a vulnerability because um subscriptions are a security boundary in Azure. Um they have since recently updated their documentation and proposed some controls and we will like cover those at the end. Okay, so how can we abuse this? So before we like get into the different like things that I tried to try and abuse this, um it's probably worth just touching on the very weird privilege

model that we find ourselves in. So we're kind of like a king of the castle, but our castle is like empty, right? Like so like subscription owner role is like typically normally like a very like high privileged role. Um but this subscription that we're owner of has nothing in, right? We just created it. So, um, all the interesting stuff has, you know, been is like owned by like admins and is in a different subscription. So, Oh, was it? Yay. Okay. No. All good. All right. Okay. Clicker. Oh, does this What happened? Okay. Okay. Sorry. Techn Okay. Can I just [Music] uh Does this work? No. Uh okay. Sorry. Bear with me. What happened? Continue. Uh, okay. Sorry.

Okay. All right. I think I might abandon this and let's just go back to Sorry. Okay. So, yeah. So, we are we are king king of the castle, but our castle is like empty. Um, so the question is like does this hold does this hold up? Um so in terms of like trying to abuse this, the first um abuse that I tried was just like seeing like okay do do subscriptions act as security boundaries? And in terms of going from subscription to subscription like yeah they they kind they do right this is like their their intended feature. So good good if anyone here is from Microsoft like this is good good news that like you can't just kind of use

directly use your own owner privileges to get at another subscription. you can like request that the um subscription be like transferred to you. Um but you know that's going to require someone to approve it. So doesn't really work as like a way to abuse this. Um then um another idea I had was like okay can you can you use this to try and kind of offload billing costs and like again like no that doesn't work because like it relies on your billing role and so because the subscription that you create is tied to your billing role like all of the everything that gets made inside that subscription is going to be going to be tied to you as the guest. So

there's there's no way to like use this to offload costs. Um but after a little bit of digging I did find find this beauty um which is then if you go to the access control of the of the subscription um all this stuff popped up. So um if you remember we were talking about the um the root management group. So because that exists higher than the subscription itself, if there are any administrators of that root management group or really anything that has a role at that level, it's going to get enumerated here. So I'm not sure if you can see at the very very bottom of this screen like here I tried to just list

out like users and you can see it said insufficient privileges to complete the operation. Right? This is how I think most people are going to be thinking about guests in their environment if they haven't given them any special permissions, right? Like they're not a member of any group, so they shouldn't be able to see the other members of groups, right? They don't have any like any like role to like list users or things like that. And yet like we've managed to list out a bunch of users here. And these aren't just any users. These are like really really like high highly privileged targets, right? So in terms of like an enumeration attack like we've now like identified like who a

bunch of really privileged like users are. Um so you can see there was some like service principle stuff. These were like reader accounts that were like connected up to to like different software that was like going through and like feeding that data into like different products. Then you had a bunch of the user access administrators. Those are like for your global admins of the directory. There's a setting that you can switch on where you can say that you want to get visibility into like all of the subscriptions and like get get some level of of privilege over them because no one else has privilege over these guest subscriptions, right? So you can, but it's a bit of a double-edged

sword. like you can as a global admin get some visibility over these guest made subscriptions, but it's a bit of a double-edged sword because then you end up as a user access administrator at the root management like group and that then you're going to like also be visible to the attacker. Um so that that's a cool one. Um Oh, sure. Yeah. Thank you. Okay. Um all right, next slide. Thank you. Okay. So, um there is a control to prevent this. Um so, it's not by default, but you can you can say that like the if you go into the external collaboration settings, you can say that the user is restricted um to only um directory objects that they

like own kind of thing. And then that's going to like make it so that you can't do this enumeration thing. But again, not not default behavior. Um okay, next slide. Okay, so Azure policy. Azure policy is a fun one. Um so um Azure policy like this is like a whole bunch of policy stuff around the infrastructure that we make. So for instance, we could say that hey we don't want it so that you're allowed to install on a bunch of like red team tools onto like VMs, you know, uh that would be quite a sensible policy to have. But uh because we own the subscription um we can also change all the policies. where we can then make it

completely silent um for and turn off all the policies that would otherwise come on for any red team tools that we uh are going to going to switch on. So that's going to become useful later. Another thing that I thought was hang on the subscriptions are acting as as security boundaries against other subscriptions but like is there a way that we can can affect the directory itself and managed identities are a way that we can do this so um for those unfamiliar managed identities are a way that we can give an identity to a resource right so say we've got a VM that VM needs to go do something. We can give it a machine identity um that can

either follow the life cycle of the the the VM um or we can have a user managed one in which case we just make the managed identity ourself and then we're going to assign it to whatever whatever resource that we we create. Um so yeah so when when we do this that inserts like a service principle into the directory. So this is like a pretty cool thing because like we've actually managed to pivot right like we're starting to we're starting to gain some persistence into this system. Um because like we as our guest we you know we make the subscription we then make a VM we also make a managed identity we give the VM that managed identity and now that VM

is going to get represented as a service principle and the cool thing is is that we can assign it um the like we can assign it the owner of the subscription that we made. So we haven't lost any any privilege in this process and in fact we've actually done something really cool here because um there are privilege escalation protections against users but there's no privilege escalation protections against service principles. Um so for instance like a user can't if they've got the change password um permission they can't change the password of someone who's more privileged than themselves. But guess what? Service principles can. So we are now starting to like evade um things. Um so we can deepen this persistence even

further. Um this is a technique um by the very wonderful and accomplished um researcher of Dirt Jam. Um definitely look him up if you're not familiar. Published tons of cool things. He he published this cool red team tool uh where you can um basically like spin up just like a lightweight um OIDC uh provider and that's becomes really useful because um we can add federated credentials to our managed identity. Um and so now as as an attacker we like fully control this like service principle and it's like credentials. Um so um that like helps us to just get like full full full persistence like from this kind of like abuse um vector. So yeah cool cool cool way um to like use

use this. Um so that got me like thinking about like some other um other ways that we can affect the directory. Um so like we have this concept of like dynamic devices in in Azure. So um I was like hang on would our VM kind of like show up as a device in Entra ID? Um and what kind of abuses could we have from that? So for anyone who's not familiar in in Entra ID um both users and devices can be members of groups just based on dynamic properties of the groups. So um you can see in this example at the bottom it's like user principle name equals this um means that we end up in

this in this group. Um I I have the the the good fortune of having a lot of data at my fingertips that I can go see the prevalence of these kinds of things in the wild. So I was kind of curious like okay like how are people using these dynamic device groups and this is like a real world example that I found which is just like hey if the device display name starts with AVD then it's going to end up in this in this group. So obviously if you're like handing out privileges permissions based on this this group that starts becoming a problem. Um this is kind of like a variant of like a known um abuse for users. Um and is like

as far as I can tell a little bit of a a noveler approach like a novel approach for kind of devices which is that the as an attacker because I can create this because I can create the VM and I can call it whatever I like. I can potentially guess some of these rules um and just kind of probe to see if I can get a a device to end up in one of these like groups. Um so for instance, AVD is um Azure virtual desktop. And so that's like just someone thinking that's a good way like if everyone just calls their VMs with like AVD as a start, then we can organize that um organize them like

that. Um the issue is is that that these can um get used in conditional access policies. So conditional access policies are are like ways that like it's it's used in Azure's zero trust model. So for ways of handing out access to users, it may well be that we use the criteria of like are they on a trusted device to be able to hand out like permissions and like privileges to them. And so often one of those criteria is is the device joined to the the directory. And so this got me thinking, is there a way that we can get our device to actually like join um to the directory? And it turns out when we're making our VM, we can just

ask it to have this extension um this Windows login um and that then if we do that uh then what? Yeah, that thank you. Um but you can see we've we've got this VM to now be Microsoft Entra joined. Um, and this this does have some fun significance. Like I want to explore the full the full impact and meaning of this. Um, there's a lot of different workflows and things that exist in the world of Azure in terms of devices. Um, in terms of Active Directory, the on-prem version, like computers, which is kind of like the predecessor of devices, those those really are just full-blown like security principles. Um, so having the for the workflows that are

potentially going with on-prem um integrations like hybrid integrations, this could be potentially really bad. I have not have not um explored this um in terms of the hybrid approaches. Um it's a bit of a a call to arms for fellow researchers out there. If you are intrigued um by by this behavior um then this is potentially a way that you can you can get a computer um that's like joined. There's like Intune which is like um a an a service offered in the kind of Azure ecosystem for like enrolling devices. You can potentially have like automatically enrolled devices um that then if they pass certain like conditions and things are going to get certain accesses. Um something I had to

draw the line unfortunately of like going deeper in. So I have not I have not researched um whether this could be abused in the world of like Intune. Um but it's definitely an interesting starting point. Um so yeah after after we do this we like give this extension we can then go like take a look and you can see that hey like we've got this device to have like um joined um and um when trying to like understand the significance of this um I was uh reading um the awesome awesome blog of Dr. Azure AD absolute absolute powerhouse of a researcher. Um he's the guy that published AAD internals. Um which is a really amazing blue team tool and red

team tool. Um he's like one of those those clever people who can can kind of bridge both worlds. And he kind of summed it up that like accesses um can be one of the criter decision criteria to allow or block access to services. um and he he also um published a blog where he um showed how you could steal device identities. And so this was something I thought like okay let's let's give this a go. Let's let's see if I could recreate this attack um using the privilege model that we've got from this guestbased subscription. So the key things to understand is because because I am the owner of this VM, I get like local administrator rights and then

because I can decide the policy of what kind of resources get get spun up. Um, I can then choose V1 generation um, images. And that's really important because V1 generation images don't have secure boot and they don't have like TPM protection. So I can basically shut off a bunch of protection that um, prevents people from exporting certificates from the place where certificates are supposed to be stored securely and are not supposed to be exported. And what we can get here is the device identity certificate. So this is really cool um because the device identity certificate as it kind of suggests is what is used to authenticate to the directory to prove that hey I am this device. Um so

we can potentially use this and then and then fake fake the identity. So we could then go take this um from a legitimately joined uh device and then use it say on a Linux machine and still make it appear like we are on a Windows-based machine. And you can see again Dr. Azure AD um saying uh this may allow evading device-based control access policies as the compliance of the device is accessed against the original device. Um so some more fun fun shenanigans that we can have. Um I really want to explore the device stuff further. So if anybody is particularly interested um in in doing some nerdy research together um very happily reach out afterwards um and we

can we can probe further. Okay. So um there is some stuff that you can do to defend against this. Um I don't want to kind of make this all all scary kind of stuff. So in terms of things that we can do, okay, the first the first and most important thing I'm going to bring your attention to is the root cause. Um so um this was was something that um I found before Microsoft kind of pointed direction um me in the direction of this policy. Um originally they said there was no controls or policies to prevent um this from happening. Um I'm still unclear as to exactly how it behaves. Um but that there is under subscription policies

there is this idea of subscriptions entering the the tenant. Um it's not completely clear that this policy applies to what I've just described. I think the reason why it applies is because under the hood the when how the kind of guest is able to make the subscription in in the resource tenant is is that they it first of all gets made in their home directory and then gets transferred into your resource tenant. Um, and so you can see unfortunately by default it like allows anyone to um to put a subscription into your tenant um including including guests. So you can you can change that to to permit to no one and you can like add in like exempted users um from that.

So that is the way to stop this. I reached back out to the partner that had been affected by this and they told me that they had this policy already in place and had screenshots to prove it. They were on a um enterprise agreement account. Uh my lab testing was a um MCA account. It's very very difficult to get an EA account these days because it's the legacy one. Um by default everything is now on MCA. So, it's unclear to me at this stage whether what quite what has happened like was this always the case and that when I met with Microsoft that they they simply kind of weren't quite aware at that point of of this control.

Um, is this something that they've added in and that does work uh for both EA accounts and MCA accounts? um or does this only work for MCA stuff and that the reason why the partner that this didn't work? So, I'm I'm unclear. I'm trying to get answers as to whether this is a recent addition or just something that like only only works for MCA uh billing accounts, but if you are in an MCA account, I would definitely recommend going and uh changing changing this. So, um this is the the new page they have published. Um, and at the very top it says the default behavior of these two policies is to allow everyone. Note that

the setting of allow everyone allows all authorized users including authorized guest users on a subscription to be able to transfer them. It does not mean all users of a directory. I guess I do have some issues with this with this wording. I think it's great that Microsoft are starting to try and address this. Um, I do think the word like they still haven't fully documented that guests can do this this weird subscription um creation behavior in kind of just plain plain English as it were. Um, it's kind of the wording is around this kind of subscription transferring. Um, which is it's not immediately clear that that's how how things work for guests. Um, and then the

the the main thing I've got just a little bit of issue with is just this including authorized guest users. Um, if you'll guys have been paying attention, you'll have noticed that at no point did we authorize the guest to be able to do any of this. Um, so um, I I I think this is a great step in the right direction, but I would I would implore Microsoft just to to potentially just tighten up the wording just to make it a little bit easier for for users to really understand their like their true threat model. Um there's some more important controls that you probably want to take a look at while you're you're reviewing kind of um guest access. So um guests

can potentially invite other guests. So that's like something that we we maybe want to not allow to kind of stop the spread of that like um further. Um and yeah, there's there there's some other stuff. So do do pay attention to this external collaboration settings. Um, and just like generally we're going to want to make sure that that guests have like the least least amount of privileges possible like all all quite standard security stuff. Um, one thing that I want to just like draw attention to if like for folks trying to kind of defend against this stuff um it's probably worth your admins like just understanding this attack. So when I talked about the service principles um

you know being able to in insert a service principle and then we've evaded um privilege escalation those service principles are just one API permission away from being global admins in your in your setup and your your admins who are defending your your Azure setup may well kind of have an assumption that they control all of the service principles, right? they control all of the apps. Um, and we might be able to kind of try and pull off a bit of a daring attack where we we kind of we we use our original guest user account and appear like we're kind of just like a B2B collaborator and say, "Hey, I'm I'm kind of stuck on a

project." Maybe you have set it up so that B2B users have got some Teams access so they can can kind of contact you on Teams and things and then you could say, "Hey, like I'm blocked. um do you mind just giving this this like service principle just a bit more permission? And you would think, well, okay, you know, maybe there's nothing too bad about this because, you know, we control the credentials to all the service principles and not not realize that there is actually a way that those guests themselves could could be controlling one of these like service principles. Um and so you know um if we if we get say like the role management

readr directory that's going to mean that that service principle is now going to be able to assign directory roles and that then we can then use our federated credentials um to then um authenticate as that service principle and then assign our guest user that started off all of this say global admin um and then boom we are we are now global admin in the system. So, um definitely I think this like weird guest API permission fishing um is like pro probably something that an attacker would only do as a last resort kind of like to kind of roll the dice to just like see if they can can uh can can use their foothold in

your system to to kind of do this. Um, but definitely probably worth worth uh knowing about, especially if this kind of like collaboration with your B2B guests is something that is like quite common of like working on on kind of um projects that involve like service principles. Um, and then generally um you you're probably going to just want to like review um subscriptions, who made them. um you don't get full visibility um but there is now something in um the security center that is an alert that says that um a guest has made a um has made a subscription. Um so while you can as an attacker evade a lot of the security center alerts by changing

the Azure policy to to quieten down a lot of them um there are still some things that like it's kind of impossible not to to set off in the security center. So, um yeah. Um and then the other thing I would just um say is um if you're using dynamic device groups um that have easy to guess rules um you might you might want to kind of change change that um because obviously attackers may well be able to guess those rules and then end up getting devices into that and that that's going to have implications to conditional access policies. So um that is the end of my talk and very happily give give room for questions.

[Applause]