← All talks

Hidden In Plain Sight: (Ab)Using Entra's AUs by Katie Knowles

BSides Toronto28:01212 viewsPublished 2024-10Watch on YouTube ↗
About this talk
Presented on Oct 19 2024 at BSides Toronto 2024 Entra ID's Administrative Units (AU) are great for defenders… and for attackers! AUs are a useful method for creating scoped Entra ID role assignments. However, this scoping also offers juicy new methods for anyone looking to persist quietly in an Azure tenant: Obscure parameters can hide AU membership, and restrictions can prevent removal of malicious accounts. AUs are a globally-enabled tenant feature. Are you prepared to keep an eye on them? No background necessary: We'll start by reviewing Azure permissions, Entra ID role assignment, and the advantages AUs can provide. Then, we'll demonstrate scenarios where an attacker can leverage them for invisible, privileged tenant persistence. We'll conclude with detection, remediation, and reflections on these double-edged features of user administration.
Show transcript [en]

um hello everyone thank you for coming back for lunch on time just for me I really appreciate it uh today obviously the talk hidden in plain site abusing ent's administrative units a little about me I'm a cloud security researcher at data dog I focus on Azure Cloud security um and I really love it yeah Applause for Azure [Laughter] or um today we're going to be talking about administrative units which are inside of entra ID forly Azure active directory if you're not familiar with azure I really encourage you to try to follow along we're going to start at the ground basics of what you need to know to understand what's going on we'll be talking about uh how administrative

units can be used for good why you might want to use them in your environment and then a couple attributes of them that are a little bit funny and in the wrong hands could be used for privileged persistence scenarios we'll walk through how to pull those off in Stratus red team so if you want to go back uh and you have a test environment you want to play with you can run these when you get home uh figure out what kind of detection would look like for this and we'll finish talking about that detection and Remediation of any potential abuse uh of administrative units just as a disclaimer uh this is a talk about using Au features as designed

it doesn't contain any vulnerability it's just that as we get more features to handle our environments our identity tools things like that attackers get access to those too and and in this kind of situation where somebody already has access to your environment there's going to be a lot of you know fancy knobs and bells and switches that they can use in order to stay in an environment which is getting more common uh seeing recent attacks where attackers maybe they have access and they just want to make sure they can keep it maybe you thought you kicked them out they're still in especially with Cloud environments so that's why we'll be talking about this today we'll start from the ground up you

may have heard a little bit about roles in Azure in general uh there's the general Azure arback roles which would be the permissions over resources so things like the ability to manage computes storage virtual machines contributor owner these kinds of things if you have that assignment of a scope over a subscription or a resource Group uh and the ability to manage Azure resources but there's another side to these roles that it's actually just permissions Management in an entirely different application which is an entra ID which again Azure active directory if anyone's still adjusting their ear uh and those are going to be permissions that include things like global administ Ator if you'd ever heard things like

domain administrator with active directory this is kind of that equivalent they get the ability to manage users reset passwords um change your MFA tokens all that good stuff that can be really juicy to an attacker as well and if you have control over the entra ID environment then you can escalate privileges to handle the Azure resources as well so both of them are very interesting but they're different the reason we're starting out by talking about both of them at once is that for an rback rooll assignment so that Azure arback the you know contributor stuff we just talked about they'll classically always be a scope of assignment that you can set so as an example a user might be

assigned a role like owner over a bunch of resources in Azure but they always have to have a subscription or a resource Group or a management group as the scope you have to explicitly set what scope does this permission have together those three things create an Azure rback rooll assignment and entra it hasn't always been that clear 's a scope but it's usually just the tenant everybody in the entra ID environment maybe I'm assigning uh you in the back the ability to reset passwords but now you can reset passwords for anybody in in the whole Azure or sorry the Entre tenant even I'm getting used to it um and that's not great right I don't really I don't know

if I trust you at that level maybe I trust you with a couple of users but not everyone administrative units give us the ability to scope that role assignment back down so by creating an administrative unit we can place users or group objects or devices and then do a scoped rooll assignment of an entra ID role to a user over that administrative unit meaning that they won't be able to reset everybody's passwords now it's just your team looking at this visually the classical role assignment that we see right now would be user administrator over the entire tenant uh but we can see we've got a couple users in pink and they happen to be in Canada we've had

our team grow a lot in Canada we need our own it guy and he needs to manage our accounts so we hire our Canadian user administrator but we don't want him to be able to reset uh executive accounts in France and Switzerland and the US so in this case we can create an administrative unit place our Canadian users in that administrative unit and then create a scoped Ro assignment over uh for that role the user admin role to that it admin in Canada over those two users and they can only manage the accounts that they're allowed to now this doesn't change the assignment of our original user administrator that's still scoped at the tenant level that still includes

our Canadian users so they can continue doing their job our new guy can continue doing his job everything's good something else that can really help with this is when you go to create administrative units you have the ability to set What's called the dynamic membership rule so in this theoretical scenario we could say any user where their country is set to camp put them in that administrative unit and then we can create the scope Ro assignment at the same time uh up here we can see someone very important uh myself we'll be able to reset passwords for those users and it's a great day uh also just to show you can do this in the

Azure portal it's quite easy to set up uh reading the documentation a little bit further into administrative units from a security research perspective there were two features that really caught our attention one was restricted management which has been in preview for a little while so preview features usually they're still under development uh they're growing a little bit they'll be you know fully developed soon but there might be something interesting there uh the other aspect that we saw was a parameter called hidden membership and this wasn't documented anywhere outside of this example for creating administrative units it mentions something about the fact that the Seattle District technical schools might want a hidden membership Au I don't know why it it didn't say

anywhere in plain English so we get to explore this a little bit more on the research side uh I'm the lucky person who gets to do the digging and share it with you for restricted management administrative units they are going to change the logic of how administrative units are processed you know how I mentioned when we create our Canadian users administrative unit we put our users in it and then the tenant level admin he can still manage or she can still manage those accounts with a restricted management Au that would no longer be the case so the user administrator with permissions scoped at the tenant level cannot manage those users anybody placed in a restricted

management Au would require an administrator with a specifically scoped role assignment over that Au in order to manage those users why on Earth would we want this um documentation mentions and I I honestly think it's a pretty good use case that protecting VIP accounts can be really a good idea uh with these administrative units so let's say we've got somebody else we trust them to manage pretty much everyone in the company but there's still the fact that anyone can reset the CEO password when they have the ability to reset user passwords and that's not great in this case we can take our VIP users place them in a restricted management administrative unit and then Grant a

scoped rooll assignment to just the three admins we trust the most to be able to reset those passwords now those three people will have to wake up in the middle of the night anytime that account Management's needed but we can at least kind of know okay the account's a little bit more protected than the average user once a account has been placed in a restricted membership restricted management uh Au uh you can see that this warning shows up that says hey uh you can't manage this account like other ones and this view that we've taken screenshots as is as a global administrator as a global administrator you'd expect to do anything manage any user do whatever you want uh be mad with

power but in this case we can't edit that user's profile details we can't delete them we can't reset their password we can't revoke their sessions we can't do anything we just get this warning that says hey they're in this restricted uh management Au and you need a scoped Ro assignment in order to manage that user so we'd either have to give ourselves a scoped Ro assignment in order to handle this or delete the administrative unit but still pretty cool right we've protected the user um I think I might have blown past the slide yes so just a note creating these in the Azure portal is pretty easy you just need a little switch uh this

creates the following post request so this is just a screenshot of burp Suite you can see the parameter that we set uh is member management restricted true and then we get that back just showing that we successfully created it so now let's talk a little bit about hidden membership administrative units the hidden membership ones I mentioned there's not a lot of documentation available on these so we had to do a little bit more digging the basics are that unless you have one of nine specific privileged roles or you're a member of that administrative unit your user account is in there you won't be able to see the membership of it so something that's really interesting

about this is while these roles above can view the membership of an administrative unit uh the ones at the bottom cannot so things like Security administrator security operator don't necessarily have the associated permissions to see the members of an administrative unit so if you're investigating it and it's this type ah you you might get a little confused the role assignments so over that administrative user are viewable so we can see the Canada it administrator has a scoped Ro assignment over the Canada users au but when we click it if we don't have the right role the Au looks empty there's no warning to show us anything about this in the Azure portal if we start digging around in the API at

the details we can kind of see it uh but not just if we pull the membership and in order to create one of these uh reason why I'm showing you one of these is you can't do it in the Azure portal so you would need to send that post request with visibility to set to Hidden membership directly and we'll just see that we're getting that back uh in the response from from the server saying yep I created your au it has hidden membership once it's been created that behavior that I mentioned before we can see that our extra special users uh are visible to a global administrator in that administrative unit but if we have

the security admin role there's nobody there it looks like it hasn't been set up yet it's like half configured right weird but how do we get that list of nine roles you know I mentioned those the I mentioned there's no documentation on this and then I mentioned nine specific roles can do a thing what what's going on there you might expect that when working with Microsoft it's pretty easy to understand you know there's 488 graph permissions as of you know a little while ago there's 109 assignable entra ID roll templates surely these things are going to line up to actual actions right like I can look up a list that says here's the RO here's the API

actions it can take uh and I went into with the bright you know Wonderful attit ude thinking this must be possible it is not um this was the best description that I could find somebody saying oh yeah I work at Microsoft I know that guy on Reddit mentioned hey we don't have a direct list of these uh your best bet is probably to look at the permission descriptions in English and line those up to the API calls that you want to make and see if the permissions line up like that that's okay I guess um there's a couple of articles that I've linked here below that go into more detail on how how permissions in

Microsoft graph and roles in entra ID might not do what you expect them to they're really good reads uh just on generally the background behind some of this and just what happens when you can't actually know the answer so we've got what 488 permissions 109 roll templates that doesn't sound like manual testing 597 service principles later uh allow me to explain I pulled out terraform terraform is really good for creating users like the ones we need to test these uh making the RO assignments that were required setting one permission or one role to each user and then a little bit of finagling getting a token for that role and using it to test the API call who can view hidden Au

members these were the results only nine the ones that I showed you before those nine ar your ID built-in roles can view the hidden Au members they get a 200 okay response when they make that API call and and it has our extra special members in it myself included uh the other ones that you're seeing here the 200 empty they got the response that said yeah you can see the members there are none uh so that was quite a lot of the roles that we were assigning the others a few of them got 403 Forbidden that's not atypical uh not every role has the ability to do everything what I also found really interesting here is that for Microsoft

graph permissions for those who aren't familiar Microsoft graph permissions exist to allow a lot of like applic permissions against Azure against the Microsoft graph uh so in this case only four permissions administrative unit read and read write all and directory read and read write all could view the administrative unit members they could get that call back that said 200 okay but it just said yeah it's empty so that was a little surprising just something to keep in mind uh the application permissions weren't able to see hidden membership Au members trying to trace this back uh to know why did this actually happen What permissions for our roles uh you know led to this we got a pretty clear answer

for our high privileged roles there were six others where we could look at what permissions were in those role assignments but because you can't assign every permission to a custom Mantra ID rooll template we couldn't test out actually what permission was causing this for each of these uh this is super technical stuff if anyone wants to talk about it more let me know happy to chat about it if you want to try it out good luck and I want to know how it goes but for now we've we've figured it out right surely this is enough we have an answer we know who can see the hidden Au membership let's recap so the administrative units allow scoped rooll

assignment of entra ID roles over subset of users our restricted management administrative units change that logic so that instead of if someone has the tenant role or the scoped rooll assignment instead it just says no you need that scoped rooll assignment in order to manage those users and the hidden membership Au unless you're in a member of that administrative unit or you have one of those nine roles uh you're not going to be able to see the membership at all and you you won't necessarily get a warning about it either let's talk about doing evil that's really what you're here for right no oh that's good I'm really happy we're GNA talk about two scenarios um

one involves using restricted management aus one involves the hidden membership the other is just talking about the chaos of a combined scenario just to mention again these scenarios require an attacker to already have Global administrator or privileged role administrator in your environment so they would have need to have already done a lot of damage they'd have to already have full control of your environment but it can provide a great way for them to protect and hide accounts that they might want to come back to in the future if you get them we'll be looking at how to execute these techniques in Stratus red team uh it's a tool that data dog provides it's free it's open source not a product uh that

has various techniques that you can execute against your test Cloud environments um to easily you know create and destroy everything that you would need to test out various techniques we added entra ID support as a part of this research so we have a few other techniques not related to administrative units related to I think like ooth apps uh and if you're ever interested in contributing I just put up a post this week on my experience writing new techniques uh for it so if you're new to contributing to open source I highly recommend recommend working with that project it's a really fun place to start in our first scenario an attacker might be looking to protect an account

under their control maybe they think they're going to get nabbed I need to figure out how I'm going to get back into this environment so they'd create a restricted administrative unit they'd add the user under their control into that restricted administrative unit that's their setup and remember if you don't have a scoped role assignment over that restricted administrative unit you don't have the ability to do anything to that user so let's say the attacker gets caught they come back in through this account under their control they can log in as their user do their nefarious Deeds but any administrator coming to try and clean up this account even a global admin wouldn't be able to disable the

user under their control they'd get that warning that says hey this user you know is in a restricted management administrative unit in order to do anything you need to have a scoped rooll assignment they'd have to figure out what does that mean uh assign themselves a scoped rooll assignment or delete the administrative first before they could even think about containing this user in an incident that's a lot of time uh to spend with a global administrator I don't know about you uh your time with global admins they're usually pretty busy let's look at this in Stratus so on the left we're looking at the stratus console on the right we're looking at the Azure portal um Stratus

will use terraform to create our user and then the technique will detonate which is to protect that user by placing them in a restricted administrative unit we can see that the user was created the administrative unit when we click into it we can see the user was at as a member if we go back and refresh this user you can see that now that warning is showing up now we're not able to modify them uh now we can't reset their password and this is as a global admin account we can't revoke their sessions so nothing we'd expect to do is possible anymore until we undo that configuration all right let's keep going on this we've

got our hidden membership scenario now so in this case once they've Protected Their account they might think okay well I want to set up some sneaky situations that might be difficult to investigate on permissions assignment the attacker would create a hidden membership administrative unit they could add a couple of Target users so maybe some juicy administrators I don't know if I care about our you know local Canada administrator but maybe the tenant level admin I want to put that account in there uh into that hidden administrative unit and then Grant the account that they have control over the one they've protected the privileged authentication admin role over that hidden membership administrative unit so remember our

admin we're targeting is in there uh but not everybody can see that so we'll come back in to the user under their control the back door or sorry the account under their control would then with privileged authentication admin have the ability to reset that admin's password and also reset their MFA methods so this is something really important to note uh you might think that account has MFA a password reset won't do anything uh the password reset will update the account's password but if you clear the accounts MFA methods as well the next time that that account logs in with the attacker generated password it'll just say hey you don't have any MFA methods set up would you

like to do that and of course inacker is goingon to say yeah I would love to do that register straight away and now they've got both methods to log in they can perform their actions objective but any security analysts coming to investigate this incident will probably get a little confused right they might see the logs that somebody was added to this administrative unit but then they click it and it's empty but there's no warnings did are they done with it did they like clean it up what's going on here looking at this in Stratus in this case a couple of different users will be created we've got our user under our control so our backd door account but then we've also

got our Target user uh and you can notice Stratus is doing a lot of things here to support that scenario and if we look at our Target user we can see that they have Global administrator scoped to the directory so that's the tenant level that means they're they're an admin of everything we'd love to Target that account if we look at our backd door user we can see our attack technique has granted the scoped role of a privileged authentication administrator over the scope of that hidden administrative unit just showing you to the you know hit home the understand standing of Scopes here um and we can see that as a global admin the membership is clear to us but

as a different account it looks empty our Security administrator role is not able to see the membership of this administrative unit just to show I'm not tricking you just refreshing a few times so again Global admin can see the membership Security administrator

cannot combining these techniques might lead to some pretty interesting impact we could create a a restricted and why not a hidden membership administrative unit as well as attackers place that backd door account in there it's not clear uh you know why this account is restricted at this point if I'm an analyst coming in to investigate this and I don't have one of those nine privileged roles I'm going to click this user they'll have the banner that says hey this user is in a restricted management administrative unit you can't do anything to them and I might say what and then click administrative units under their account and it'll be empty it's like what's What's Happening Here

in addition we'll create a hidden membership administrative unit add the administrators we want to Target so that we can come back and reset their accounts later and you know get into there um and assign that privileged authentication administrator role to the account that we have control over uh over that administrative unit creating the hidden administrative permissions that we just talked about so the combination of these for somebody who's not familiar with administrative units might be pretty strange to investigate and require a lot of escalation to clean up what can we do about this there's a couple of points I want to make here uh the administrative unit logs on the left side uh are really good

for any Creations or modifications of administrative units uh if you want to use administrative units you may want to keep an eye on things like updating them the other thing I want to mention is if you have existing detections for role assignments you need to make sure that they include the scoped uh member word basically so if you're currently flagging on event names that say Ad member to rooll that detection won't catch ad scoped member to rooll so it's really important to pay attention to word changes like this uh where your current detections might be missing something in order to remediate this kind of scenario once you have the right people right Global admin privileged Ro

admin it's pretty easy to clean up delete the administrative unit there'll be a little bit of a weight uh but then the users will go back to normal and you can go on with containing evil and getting on with your day as a final recap administrative units allow scoped Ro assign assment of entra ID roles over a subset of entra objects restricted management Aus allow only the admins with scoped assignment to manage those objects uh but they can protect our sensitive accounts but they can protect attacker's sensitive accounts too uh and hidden membership administrative units will allow only Au members and certain admins to view that membership which can lead to some strange you know concealed

permissions assignments so you should monitor your au activities if you're not already prepare playbooks so so that you don't walk into your Global admin's office virtually or literally uh for the first time on a Friday saying hey about this thing you don't understand um yeah that's not a fun one uh and just be prepared to handle the cleanup of these scenarios you may also want to use them for your own scoped permissions assignment right there's a lot of really good uses for administrative units out there we have a post on this uh that was published about a month on ago on the data dog security lab's blog uh you can try the techniques in Stratus red team the cont rtion

guides on my site so that's not on this slide but I can share it with you if you're curious uh and the other links that I mentioned are there I believe I'm out of time but thank you so much uh for joining me thank you Katie and give Katie an extra special Round of Applause because I think I had this music going on in the background or I heard something I noticed it partway through I felt so energized but relaxed anyways I think we have time for a couple of questions but before we get started in on the question is e tahun here no okay is the next speaker in the room is the time to set up this is what

we're trying to figure out I'm not seeing any takers so we do have a pinch hitter um who's going to come down while we while you ask Katie questions about our talks so any questions I'm seeing a question over here okay let's say you have an attacker who's like persist so they created a back door account they they use the techniques that you talked about you still is it true that you can still see

that yeah so you're right that the user is not hidden at all like the user account is still there um the part that's going to be aisc and the administrative unit you can still see that object you can still see the scope roll assignments for the hidden membership administrative unit uh the issue is that you can't see that they're in there so it's not clear what the scoped Ro assignment impacts uh for a restricted management if it's also concealed it's not clear why that account has restricted management if you can't see that they're in the Au okay yeah so just very specific sneakiness thank you uh yes have you seen it exploited in a while yeah uh so the question is if

I've seen it exploited in the wild uh to my knowledge I've not seen any exploitation of in the wild uh which is good but also good for updating

detections yeah so the question is do you need a high level of privilege you absolutely do you need to have Global admin as an attacker already to execute these scenarios um there's a lot of attacks against identity platforms becoming popular as ways to persist once you have that access though so things that you might have heard of this is not quite quite as flashy as something like golden samle but just backdooring authentication um taking authentication Keys figuring out how you can persist in that environment uh is becoming more of a topic uh one last question I think yes does a restricted Au always need an admin because if can you like remove the admin and then no one can control that

Au yeah that's a really good question so uh question asker men mentioned uh does a restricted management Au always need an admin I think they would have a Creator uh I hadn't actually looked into that to specifically I think it is a good thing to look into more uh but to my knowledge especially if I was like the attacker and I created the Au and then maybe that's the only person who can modify it uh to my knowledge there's yeah it's a blend of I should look into that more and I don't know that it would impact the scenarios we just talked about too too much but really great question thank you