Restless Guests: From Subscription to Backdoor Intruder by Simon Maxwell-Stewart

[Music] Uh I'm really excited to um share some fun research that I did in uh the world of Microsoft cloud services um and how uh we could get a lot more access than I initially thought from some guest access. Um a quick a quick bit of background about who I am. Um as the intro alluded to, my background's in physics. I sort of like have transitioned my way over into into cyber security. Um absolutely loving it. Um I think my uh my mischievous um background of doing things I probably shouldn't on computers is starting to serve me well. So um so I want to introduce this topic to you today in the same way that it got

introduced to me which was um as a mystery. So I am lucky enough to work with a number of partners um and one of those partners reached out to me and said hey um I have just had a guest in my Entra environment make a subscription. Um so this is what um they were seeing in their environment. This is a recreation. Um, and they were really confused. Um, and that was because when we looked at the facts about this case, um, things really weren't adding up. Um, if a user had made a subscription, we would expect be them to be able to see some kind of privilege that they had, but, um, when they looked and we looked, um, all of

the obvious signs of where they might be getting this privilege, um, there was there was there was nothing that had been assigned to the user. So they had no group memberships, they had no directory roles, they had no arbback roles um or any kind of um permissions granted. And yet this this subscription um was somehow created. If all of this is a bit new to you and that you're not quite sure about what all of these terms mean, don't worry. We're going to build everything up from kind of the basics. Um and yes, this is very much how I felt um trying to understand Azure Azure microservices. So on the agenda today, uh we're going to be getting into the

basics of how Azure works. Then getting into the weeds and some of the the weirder aspects of this. Um then getting into uh what was previously undocumented behavior and now is documented on the the Microsoft site. Um what was Microsoft's position on on this like uh threat? And then um whether we can abuse this and finally I'll go over some defense um for all you petrified defenders at the at the end. Um so okay very quickly um Azio basics this comes from the uh Microsoft website about Entra ID. This is how they kind of want you to think about Entra ID at a very high level. Um it is essentially a um identity provider. Um and you can see

that these are the kind of big high level things. So you can see we can like integrate apps. We can we can like on board our like different identities be those like kind of human identities or kind of like non-human um kind of workload identities. And you can see we can kind of like integrate things with with kind of like our on-prem environments. And then devices just sit over to the side. Uh I'm I'm going to hopefully help you understand devices a little bit better than this. Um this is all good. Um I prefer to build things up from the ground up being the physicist that I am. So this is my kind of crash

course of kind of how the basics of Entra ID. So um at the heart of things we have the Entra ID directory that is what you are going to like go authenticate um against the different kind of security principles that you can have in Entra ID is like users. Um those users can also be guests. We're going to get into the distinction between users and guests shortly. Um then you can have service principles. These are what our new non-human identities are. So think like applications. um it goes a little bit deeper than applications. Um you can also have like resources like infrastructure that can have an identity and then um devices which is probably the weirdest of all the security

principles um that's going to be like your actual like endpoints and like laptops and things like that that can have identities and can be secured um via those identities. So um in terms of like basic privileges that these security principles can have um as I mentioned before they can have like directory roles and arbback roles. Directory roles allow the security principle to do something to the directory itself. Arback roles allow them to do have like privilege over Azure resources. We're going to get to that in a second. And then finally you can kind of have like app roles or API permissions depending on whether you're a user or a security principle. um like really they're pretty much the same

thing under the hood. Um they're just like kind of permissions that we have when we go query like um like Microsoft controlled like um APIs. So um that is like the Entra ID kind of basic privileges. I mentioned Azure resources. These are the things that arbback roles kind of like typically affect. So let's let's try and understand the basics of Azure resources. So um when we're talking about like as your resources, we're really talking about like infrastructure that you're going to be deploying in your Microsoft cloud environment. So think like VMs, like databases, like networks, um generally like anything like that. Those then kind of get grouped together into resource groups. That's really like um kind of a

useful organizational tool more than anything. Then those resource groups um containing those resources will sit inside of subscriptions. Subscriptions are really your kind of logical container for different Azure resources. So separate separate separate subscriptions should be separate from one another in terms of kind of like any kind of cross cross access um from each other. Um the complexity doesn't quite end there though. In the above subscriptions we have management groups which as the name suggests are kind of like a useful construction for when we want to apply management policies across like all of our subscriptions. So we can have like an a a large amount of kind of nested management groups, but that there's always going to be one root

management group that all of your organization subscriptions are going to be like nested within. And then finally, that management group then is tied to your directory. So we can have a bunch of different arbback roles that that affect um things. They are scoped either at the from anywhere from the top of the management group level all the way down to potential individual like resources and anywhere in between um is where these can can be. We can make our own arback roles. Um here's just an example of some of the different um out the box uh privileges. Okay, so this is where hopefully the talk gets a little bit more fun. Um now we've now we've got a

little bit of an understanding of the basics. Let's get into B2B guests. So, I guess one really quick thing I want to touch on, it's like why the hell would you have a a B2B guest versus a a user in a special kind of guest group kind of thing. Um I I had this question when I was like digging into this. The the real reason is uh cost savings. So um if you were to have um the say like vendors or like kind of people outside of your organization that you you who you needed to give access to quite often temporary access if you had to kind of use one of your actual user licenses for them you

know this could potentially get quite costly often these people are coming from environments where they have their own Entra ID associated with their own organization. So you can say, "Hey, I'm just going to invite you as a guest from your organization from your own Entra ID directory into mine." And then you don't have to pay um for like one of your one of your seats being occupied in terms of your licensing agreement. Um but then to understand how that's like working under the hood um our user is going to be authenticating against their home directory and then they are going to like get an ID token which they then use to like federate into your what I'm

calling the like resource tenant. Um it's not just my terminology. This is how Microsoft calls the two different tenants. So, uh, the home tenant, that's where they're coming from of the guest, and then the resource tenant, that's where they've been invited into. And then once that invite is sent to them, then they they reclaim the invite, and then they're going to be able to be authorized as a guest in in your resource tenant. Um, so because you don't control the authentication um, portion of this, guests are really meant to be like very very locked down users. So like they they really come with virtually no out ofthe-box privileges at all. Um so they they they really should

do less than an out of the box standard user even. Um there's a whole website that's um I've linked to here um describing exactly what the out the box privileges are for guests. Um and so once you've invited someone into your directory, they look like this. Um in the bottom right um there is something we can see where the B2B um invitations um status has has been set to accepted. So okay, we're we've gone a little bit into the weeds. Um but hopefully for some of you this isn't too too unfamiliar. This is where maybe maybe the wheels come off the bus a little bit. Um certainly it caused a lot of head scratching for us when we were in

this. Um so when we get into billing agreements um there is some a little bit weird behavior. So let's first of all touch on what a billing agreement is and why you need to know about this to understand weird guess behavior in Azure. So um billing agreements are the way that you get bills um in in Azure. Um there's two main real like common ones. There's like a whole bunch of more obscure ones, but the two big ones that you'll see is enterprise agreements and the Microsoft customer agreements, which is the kind of like new modern way to do things. Um, basically at the very top of the hierarchy, you've got your actual kind of contract with Microsoft. And then in

both models, there's like slightly different way of of kind of organizing things and like where you actually attach like the credit card. for the Microsoft customer agreement. Um, you kind of attach your credit card to a billing profile at the top and then you kind of have these these invoice sections which are kind of like useful organizational structures like inside of your billing profile. It's a little bit different with enterprise agreement but very similar thing. Um, and then ultimately anything that gets spun up inside of your subscription is then going to be going to be build to that attached um billing account. Um so so so that's how subscriptions start start linking with these these billing models.

Um so you can see that with certain kind of billing ro permissions um we actually get the ability to create subscriptions um so for Microsoft customer agreements we actually um just need um owner or contributor at any of one of these levels and then we get the ability to create subscriptions. And there's also a specific billing role of like subscription creator um that we can be assigned. Um and all of those lead to us being able to create subscriptions for enterprise agreements. Um again very similar um pretty much if you get have admin at any one of these levels, you can then create subscriptions. Um so this then to jump back to kind of Microsoft documentation. Um this this

comes from Microsoft's um websites website documentation and this kind of really shows you how to think about these three different worlds and how these different peri permissions and privileges are at like working together. So we've got the we've got the directory the tenant at the very top. You see that's linking to then from Entra ID to then the world of Azure resources with management groups and then the subscriptions all um beneath them and then off as a kind of weird sidecar we've got the the kind of um enterprise agreement um or m Microsoft customer agreement that that generally the billing account and you can see that the um how the subscriptions get inserted into the world of Azure resources. So

now we kind of got a bit of a picture of how these things work, let's get into um what was previously undocumented behavior. So what I was very shocked and after a lot of fiddling around as to why this partner was seeing a guest that had managed to make a subscription, we finally figured out this which is that when you have um guest federation happening into your into your tenant um your billing permissions kind of work across tenants. And I've deliberately drawn the graph this way where the the billing role allows you to create a subscription in your home directory or in a resource directory and not that you get somehow the billing role when you're like federated as a

guest. So the weird thing is is that this doesn't work if I go log in as a guest into the resource tenant. I have to be in my home tenant, but then I'm in my home tenant and I'm allowed to make a subscription into the resource tenant that I can federate into. I can I can choose. So, if you're a little bit confused, it's it's just this simple thing. When I'm creating subscription, you just click the advanced tab and then there's a dropown and you can choose whichever directory that that you have access to, be that a home tenant or a a resource tenant. And so then once you've done it in your home tenant and then you

go back and federate in now you are like the owner of a subscription. So you can see we've got the arbback roll um and we're the owner of this this subscription that we made in the step prep. And then this ends up looking like this. So mystery solved. We figured out how the guest managed to make their subscription. Um so just to recap the steps involved. the attacker is assigned a billing role in their home tenant. The attacker is then invited into the resource tenant as a B2B guest and then the the exploit is that then the attacker can create a subscription in that resource tenant. And so in terms of like defenders and other people think about the threat

model, this really is that any B2B guest federating into your tenant is now a possible vector. So with this we were pretty excited. We went over um and spoke to Microsoft um and is um as is a a bit of a right of passage of being an Azure uh Microsoft security researcher. They told us it is it is a a feature and not a bug. Um at the time of the meeting they said that there was no no controls um to prevent this kind of behavior. They have since updated um that and I'm going to I'm going to be a responsible researcher and and um try and link you guys to to that. So, so you know what is

the Microsoft's um recommended best practice now. Um but they kind of were really really wanted to reassure us that don't worry subscriptions are a security boundary um in Azure. Um and so you know you don't need to worry about this very much. And so obviously I just went fair enough and left it at that and and didn't go any further. No, I I wanted to see whether we could abuse this because I I wasn't I wasn't so sure that that defenders can just kind of easily just dismiss this as a threat. Um so in terms of if we're going to really need to abuse this, we're going to have to step up our game a little bit. We're going to

first of all, we're going to need a reliable attack vector. So the first of all thing to overcome is like how do we get this like billing permission? How do we get this like billing ro that we need? So we can get it in about five minutes. We just sign up for an Azure free trial. Um, so once we sign up for a zerree trial, we are now the billing admin of this Entra ID tenant that gets like spun up associated with this trial. So we're now a billing admin. We've got these special special billing admin permissions that we need. U the next thing that we're going to need to to do to um make take advantage of this attack

is to figure out how we can be a guest in someone's environment. Um so the nice thing is is that we can take take advantage of some default settings. So by default um if you've done nothing to change this in your environment um any user including guests themselves can invite other guests um into the directory. So that means if we have access to any kind of account be a user or guest we can now just go invite in the billing admin that we just spun up in the previous step. So now we're a guest and we've got our billing admin permissions. So we've we can now create these subscriptions. But we now we like run

into our next problem, which is that uh our subscriptions are empty, right? Um and this is kind of like the the really weird unique privilege model that we're in within this attack. So we have managed to get like ourselves to be owner of the subscription, but it's empty. So we're like king of the castle, but the castle is like empty. and like all of the interesting targets like key vaults and things like that are all sitting off in like other subscriptions that like we we don't have any kind of our back roll over. Um and so kind of seems like game over. There's like different failed ways that I tried to kind of like leverage this. So first

thing was like do subscriptions really act as a security boundary? Um and like from a very kind of obvious thing like they they do, right? You can't just go from being the owner of a subscription and kind of try and get access to another subscription directly just by being in virtue of being an owner of a different subscription. The worst you can do is kind of request um like ownership being transferred. But you know that's a that that requires um someone to approve it on the other side. So it's not really an abuse of any kind of significance in my opinion. Um the other thing that doesn't work and is is very important to clarify about this um

kind of abuse is is that um as the guest we we are are charged back to like the our billing account from the like tied to our like home directory. Um this is like the whole point of the feature is is that you can have subscriptions that are living in one directory but build to a different um like directory. So we can't use this to offload costs as like we can't like spin up a whole bunch of crypto mining and hope that the the resource tenant is going to get charged for that. We we'll just get charged for that. So anything like on that like doesn't work. Um but that does sort of give us like a bit of a bit bit of an

advantage. Um and when I started doing some more digging, I did realize that there was there was some things that we could take advantage of. So, the first thing that took me an embarrassingly long amount of time to do was to click on the access control for the subscription um that the guest controls and then like up popped all of these different users and service principles. Um and I thought this was just an empty subscription. So, I was like where where the heck did did all of these security principles come from? And now hopefully you guys put a little pin in your head of that like detail I was giving you before of that management groups sit

above subscriptions and are used for for for management um of all of your of subscriptions. So if the any admin in the resource tenant has given an arbback role scoped to the root management group that's going to get inherited into every single subscription and this is a really common common practice right for for um any kind of inventory say um applications where they're going to just like constantly look at all the different SEO resources that you spin up they'll be given like say a reader arbback role at the root management group level. Um there's other reasons like we see in here there's like key volt readers. Um there's a whole plethora of reasons as to why you might

set up this. Um it is a very common um common practice. And so yeah, as you can see, this is how this works. Um we can we're we're we're getting a our role is being inherited of the actual admins that we're managing to enumerate out. Those are being inherited from the the root management groups. Interestingly, when I was like reverse engineering this, this like this the UI display comes from two API endpoints. Um, so it first of all does a lookup on the like Azure resource manager management endpoint. um and it gets the role assignments and then from that that gives gives um like principal ids and and the principal type and then it uses

that to go do lookups of those ids and like entra ID has got a bit of a funny thing in terms of like the the Microsoft graph where it's like by default like if you know the UU ID of an object you're allowed to like look it up because it's kind of like it's it sort of like uses the assumption that that's sort of a secret that you know the UU ID. So you're allowed to go get the details of it. And so actually, interestingly, for this um for this enumeration abuse um tactic, there's there's only a partial defense to this because there is a a setting that can um control this, but it only controls the lookup portion. So

those role assignments like you you can't change any controls to stop actually getting the principal ID only the lookup portion where you use the principal ID to get the actual name and the email address. Um but the principal ID is all we need to do our back roll assignments ourselves. So now we've got those those um principal IDs. We can start assigning um the users that we enumerated out our back roles onto our subscription. And why would we want to do that? Well, probably for camouflage, right? Now, instead of just having just a weird guest user um having an back roll of the subscription, now suddenly legitimate users have our our back rolls over the our subscription. So, any

defender looking at this might think, hey, this is this is kind of like a legitimate subscription. Um so, let's see if we can keep on taking this up a notch. Um so, that was kind of like as far as I got for a good while on this abuse. Um, and then, um, I went down a whole fun rabbit hole of devices. And so, this is where I get to explain to you a little bit about what devices are. So, um, devices are a key part of, um, Azure's idea of zero trust. So, basically, um, one of their primary roles is to be used as a key signal in conditional access policies. So the idea is is that like

a users may an organization is maybe going to trust me more if I'm on a joined and compliant device say my laptop they know about this device it has a device identity um it's also say say managed um in terms of compliance by a solution like in tune or other like MDM um solutions and so that then we can then use these conditional access policies to say, "Hey, don't give access to unjoined um uncompliant devices, but if if a user's on a a compliant managed device, then sure, give them access um to whatever uh we're wanting to target with that conditional access policy." Um and there are a few really important um security implications of of devices um

and things that have device identities. So, um join devices get issued primary refresh tokens. primary fresh tokens. Um, for those not in the world of Azure security research, these are big big targets um, for attackers. The reason why they're big targets is because they are tokens that we can use to mint refresh tokens and access tokens. They are longived um, and they're valid for up to like 90 days um, if we keep on using them. And once we have one, right, we we can get like we can mint refresh tokens and access tokens to all the different um like resources in in Azure. Um so there's a really great rate write write up by the um the the one and only

Dr. Azure ID. Um he he is um a bit of a genius when it comes to um HR ID um security. So definitely recommend his his write up. Um so um let's see if we can get one. So how how would we get one in our model of things? We can actually we can we can make virtual machines because those are just an Azure resource and when we make an Azure resource there is the option to give it the extension um of um basically entra ID based Windows logging. So rather than doing something horribly insecure like you know managing our own credentials and things like this we can say hey I want to give access to this VM

of one of my Entra ID users and I'm just going to let them log in via their like Entra ID credentials. So I don't have to worry about like managing a bunch of credentials. So seems more secure which is great. How this works under the hood is is that this this VM is now going to get a device identity. Um, interestingly, by default, um, any users can can join devices into Entra ID, but there is the option to to um say none, and that that setting doesn't prevent um the in installing this extension and getting a device identity. Um, so while you might say like, haha, like I I'm I'm very cautious defender. I don't allow

users to join devices. um that's actually not going to not going to stop us getting this joint device anyway. Um and we don't even need uh like VMs that have these these compatible extensions. Um if you want to do the extension manually manually yourself, it's really just about setting a few um registry settings and then running this DS regge command with the right right um input and then we're going to get um we're going to get a uh a VM with a device identity. So here you can see we have we have a device it is joined to entra ID. Um so the reason why this is like significant is one because if we join this virtual

machine uh if we delete this virtual machine um it's its device identity is still is still going to persist. So when we do this as an attacker and we make this virtual machine, we've essentially inserted a device identity backd dooror. And why is having a device identity backd dooror important? Well, because devices can be used for fishing. Remember I said that devices will get issued be issued primary refresh tokens, but only join devices will get primary refresh tokens. Um, and so because I'm the owner of this VM, I can make my VM with no trusted platform module protections and I have as the creator of the VM, I get the local admin credentials to this

VM, which means that I can strip away all of the protections that would normally prevent device identities um from being harvested from the machine. And so that means I get the device identity hub and private key. And there's there I'm using AD internals to do that. And then from that I can this then opens up this attack path um where you can see here I'm the threat actor. I do my whole initial first thing of like signing up for a Microsoft account and then federating in as a guest, making my subscription, stealing the device identity, and then the only new part is is that um we go we go um we go um device code fishing for a specific kind

of refresh token. So um this um this does rely on a specific um technique that was um written by um Doug Jan MMA of absolute uh he he's he's the goat of um of blowing up Entra ID. Um and what he found is is that there's a very specific kind of refresh token that you can request which is used in the process of device registration which you can actually upgrade a refresh token to a primary refresh token. It's like the the um the the token that gets gets used when you're like initially on boarding the device. And so we can go fish for that specific kind of refresh token and then combine that with our device

identity. And that that is the the the method of upgrading requires us to have the device identity. And so that's why it's important that that from the previous step that we can insert in these device back doors. Um and so um obviously that does make it like a post compromise um uh like um attack. Um I do want to point out that this is this exact technique of the primary refresh token upgrade is being used in the wild um at the moment. Uh Microsoft did a whole write up about it. Um there's a lot of um Russian a um like actors using this at the moment as well as like ransomware folks. So this really isn't

like some some theoretical like abuse in terms of um that and everything else we got for free in terms of just being able to make make subscriptions as as a as a privileged kind of guest. Um and so this is this is how we would do it using um rotx. Um it's a popular python python library um for for doing these kinds of things. And you can see here once we've um done our device code fish and we've got like our spec our refresh token we can then use that to to upgrade to a PRT. And once we've got that if we've remember we were enumerating out admins of the management group. So those are

people who very likely are going to have global global admin level. One of the primary ways that admins end up at the m management group level is when they assign themselves subscription access to all subscriptions and they'll get inherited in. So we we do we are in the position of targeting these the mo most high-profile most privileged users. Um and then once we've got that primary fresh token we're in to any service. So that's cool. Um we can also do a couple of other um kind of related um um but different attacks. So, we could also spin up our VM and try and get like one of the admins that we enumerate out to log into the VM. So, maybe we we send

them a Teams message if our initial kind of user that we we managed to compromise um has Teams access and we try and get get our admin to log into a VM. Hey, I'm really sorry. I'm like I'm struggling to log into my VM. I don't know why it's working. It's supposed to work with Entra ID login. Can you get it to work? Kind of thing. people think well hey I'm logging in in a in a completely completely secure way using you know um their credentials um we grant the login access we can even do it the secure way which is using um a bastion which actually is the easiest way to do it from an attacker point of view um and

it's nice because um any admin um would think that someone's being quite responsible in how they've set up they haven't opened up any RDP ports to the internet but that we can do it the the kind of old fashion way. There's a few annoying problems to overcome, but there's a great write up by this guy who who kind of showed how we can um we can set up VMs to do on ID login. Um so, okay, so all of this is really good. Hopefully some of the defenders are getting a little bit worried. I'm just going to worry you just a little bit more. Um, so some of you might be thinking, okay, it's not not too bad

because everything's just gonna everything's going to look like it's like there's, you know, there's going to be this this this weird user that a little bit of of um research instant response is going to show us that like, hey, there's like a guest owner and that kind of inherently looks suspicious, right? Like a guest owner of the subscription. Um, that's like a bit weird. So there's a few things we can do about that as an attacker. So the the first which I found this really ironic and quite kind of fun um is that there is um the are defender alerts that go off um saying that hey guest accounts with owner permissions are on Azure

resources and this is on the subscription so the highest level of like a a kind of as your resource. Um, but because I'm the subscription owner, I get to switch this off because all of the Defender alerts are tied to the subscription. So, I just say like, "Yeah, it's all good. I know that I am the subject of this this alert, but I'm just going to I'm just going to switch this off." Um, so that's that's really useful. Um, but like for for you skeptics out there, you'd be right to point out some of these things, which is that like hang on, like it could well be that Defenders aren't just relying on on on Defender, right?

Like they've probably got a whole bunch of other SIM tools and other things um that say looking for guests being owners of as your resources. So, how could we have a a kind of a full foolproof method of of silencing alerts? So to kind of really do this properly, we want to kind of persist as a different security principle. We want to like retain all of the same like privileges that we had um and then ideally kind of disappear as a guest and we can do that. So um we can use managed identities. So managed identities are a special kind of um service principle. Um and so basically um that a service principle when we have

Azure resources and we want to give them an identity. So um say we we want to give like our virtual machine an identity. So we want to um give any kind of as your resource can can um potentially have have this this service principle identity kind of glued onto it. Um works in an interesting way with fabric but I won't won't get into that right now. Um and so you can see like the basic idea is like okay as my guest I'm I'm the owner of the subscription I can create VMs I can then attach a managed identity to that and now that managed identity is going to be represented as this like service principle. Um, so we're starting to

pivot away, right? Like we've now insert like inserted a proper security principle, not a weird one like a device, um, but like a proper security principle. Also, service principles don't have MFA um, safeguards, right? Um, so that's nice. Um, so we we've pivoted away to a security principle that doesn't have MFA protection. And we can make this even worse because we can actually give um federated credentials um to um managed identities. And what that's going to mean is is that we actually spin up a little attacker controlled OIDC provider. Um so something that speaks OIDC uh there is red team tools in order to do this where it's just an OIDC provider um that doesn't really do any actual checks and

it just says yep this person's person's good to go. you can log them in. And what that's doing like behind the scenes is it's like it's offloading to the OIDC provider the responsibility of doing the authentication patch. And so now we've got a proper backdoor um setup because we can just access the system directly now from this like service principle. Um we just go to that service principle. it goes and speaks to our attacker controlled or IDC provider that says yeah hey that's that's that service principle is authenticated and then we get an ID token that we can then go use to be authorized in in the directory. So we we we've got our persistence um we

can then give this service principle our arback role of owner. So, we can now keep all of the privileges that we had before, but we we've got this one one last little touch. Um, and so one last little fun. This was this was the final thing that of of of research I did on this and I was happy because it it felt like a little bit of a cherry on top. Um, which is that we can actually make make use of one last default setting which is guests are allowed to uninvite themselves from the directory. And so basically we can do all of the shenanigans. Set up our device back door, our managed identity backd dooror,

give our managed identity the access of like the subscription owner, and then we can just like piece from the directory as the the the guest themselves. And I tried this to see if there would be any any kind of um like artifacts left over. And no, like as a as a defender, when I try and look up that user, it just says no user exists. Um, so all of the alerts, anything that was like scoped to, hey, this guest has some weird access that they shouldn't will now just be silenced because that guest doesn't exist anymore. Um, but as an attacker, we have managed to persist and we still have a bunch of access to this. And this

is all we have to do. We just have to go to this portal to like uninvite ourselves. Um, so, um, as Microsoft didn't want to fix this, um, I thought it would be a little bit fun to, um, release this as an offensive toolkit. So, for any folks that are interested, um, go to this, um, GitHub, um, and you can see all the API calls. If you're just interested in all the API calls, um, it does a few fun things for you. I will do a quick demo of just one of them. Um here it's like creating a subscription. Um and then um you're asked what kind of invoice section. It goes and looks up your invoice sections,

ask which one you want to like create it inside of and then um I think shortly. Yeah, there you go. It created the subscription. Here's an example of it. Um making a VM. Um I think yeah, here we go. So, um it is a bit of an involved process to getting everything right to do the uh VM setup. So, that the nice thing is the offensive toolkit does all of that for you. And so, you can see us going through getting all of the settings right and and doing everything um on on the user's behalf so that they they can get one of these what I like to call an evil VM um for the device back

door and boom, there you go. So in terms of all the commands that you can run with this like offensive toolkit um these these are the different um things that you can do um I think from having successfully scared Microsoft a little bit with some of these shenanigans um they have now started to update their documentation which I'm really happy about because ultimately um I I do I do just want people to be secure in their Azure um in their Azure environments. So they now say say this authorized users including guest users in your directory can create uh as your subscriptions in another directory where they have billing permissions and then transfer those subscriptions into your

entra ID directory. If you don't want to allow this you should set one or both of the following policies. So I think this is like a lot better that they're like acknowledging this behavior still exists. I still do have a few qualms in just that like use of the authorized users. I like I do hope that if you've got one thing from this talk, it's is that we we didn't authorize the user to do any of this in our resource directory. They just used their authorization from their home directory. So, while it's maybe technically correct, I do think that's that part's still a little bit misleading, but I'm happy to see that they're they're they're starting to acknowledge the the

threat of this. Um, in terms of defense, um, really prevention is key. There's like three big policies that I want to just quickly take you through. um that is going to um going to be um key here. This is part of the offensive toolkit. Um attackers won't be able to run this command, but you can just figure out these command like the the these policies as an attacker by just trying the attacks and see what see see what works. Um so um the first thing that we're going to do is um the root cause which is um stopping these subscriptions being transferred into the directory. So actually what's happening under the hood is these subscriptions are being made in

the home directory and they're being transferred into the resource directory. And so this setting here um that Microsoft's now linking people to stops that. Um so I would definitely recommend you changing that from the default which is allow anybody to to to um transfer subscriptions into directory to to no one and then just permit specific users if you do have that use case. That is really the single best thing you can do as a defender. Um other things that you can do is just generally go to these ex external collaboration settings and just harden everything as best as you can. Um as I as I said before um there's not a full protection for the enum thing, but

the um changing um what like the user access restrictions sending that to the most restrictive means that like at least they can't do the lookup um part of that. And then I probably wouldn't recommend um not allowing people to uninvite themselves. That's kind of nice because people clean up um as they go, but it is just worth knowing from your kind of instant response kind of point of view that if you had like a weird alert flash up and then disappear like it could be because that's what's like happened. So yeah, maybe maybe just keep that in mind. Um and then in terms of like other just kind of general um things to to be aware of um MFA via

conditional access is always a good thing for guests um just generally monitoring guest main subscriptions um you might see these things um fly up um like broad dynamic device groups um that those can be important um because um we can we can brute force getting into these device groups if it's just like hey all devices that have like the name like Madrid something something um that's like a common thing I've seen in defenders environments um where they're using like office locations um and like they're actually using device groups um kind of based on just simplistic rules. So you might want to just think about that. Um and then um hardening root management group um policies is probably

a sensible thing to do like not not having it so that um that people can make generation one um virtual machines that have got the TPM um protections disabled. So so that that that stops people being able to export um device identity certificates and also primary refresh tokens off of off of the virtual machines. Um, and generally like audit devices, which I don't think is something any defender that I've spoken to does very well. And I think most people find that they've just got thousands and thousands of devices in their environment and with no understanding of which ones have actually been used. So it might be something I blog about um later. Um, so in conclusion,

the BB guest threat model I don't think is well understood. Um, the defaults are very very insecure. Um, by default all of this behavior is is allowed. All of the all of the settings um that I took advantage of were all the default settings um for all the attacks. So um there there was no special configuration to allow any of this stuff. Um but if you then go and change those hardening does work. Um and with that I will turn over to any questions if we have time. [Applause]