
Um so introduction about what we're going to talk about today. So, we're going to talk about um uh fantastic caps, conditional access policies, and uh how to abuse them, how to find them. Um we're going to talk about how to go from cloud into internal. We're going to talk about how, you know, the initial foothold might be closer than a lot of people think. And um we're also going to go from inter onrem uh into the cloud and then talk about Microsoft processes and sort of the defender gotas. So, a little bit of blue teaming and red in between, right? And then we'll end it off with a Q&A. Um, so just a little bit of intro to uh
Azure and Entra Cloud. Just a show of hands. How many of you guys are familiar with Azure and Entra? Okay. I don't need to introduce it, right? Okay. So, yes, Azure a lot of people use them. I think um a lot of people will be uh have their identities, have their infrastructure, have a lot of things in them. Um I think based on shared services Canada right it's been I think the most used cloud been between 2019 and 2023 right and they have probably probably much more now about $24 million of cloud spend and if we really look at uh like cloud migration uh in the last uh decade or so right up until like 2022 it was like you
know a hyper speed train move everything to Azure I think it's slowed down a little bit in 2023 but uh it's uh you know it's it's picking back up again in 2024 and I think um for when we work with a lot of our customers I think I've noticed two major trends right we give them a report maybe 13 findings there's like five ways we get to domain administrator sometimes their leader manage their leadership would be okay forget active directory right let's move everything into the cloud and so they'll have the exact same uh on-prem infrastructure but within the you know Azure cloud and I think uh another sort of trend I've noticed this right and
that's really represented by the bottom diagram there right and another sort of uh trend I've noticed is instead of just having infrastructure they'll just have laptops and they'll have entra ID and they'll have no infrastructure so people will just work on their laptops access teams for collaboration one drive etc so those are the two sort of major trends I've seen and I don't know that that is the correct way to fix things right so we're going to jump right in uh to caps uh fantastic cap app uses and where to find them. Um, and and really bear with us here. We have like 80 slides and every time we look at this thing, we just want to add more. I don't think
we're finishing today. Right. Um, right. If you guys have questions, uh, feel free to find this at lunch. Um, and and primer on sort of hybrid pentesting. I think this is where the pentest at least for the active directory side or the Windows side of pentesting is moving towards is really more of a hybrid model now, right? And for cost and budget wise, our approach is really an assume breach type of model in hybrid environments. Meaning um you take and then if you guys do like fishing training, this is what you should do, right? You take the department that fails the most or the group of users that fail the most. Give us one of those
accounts because you want to see what happens if that group or that user gets compromised. Where they where can they touch in your environment? What crown jewels can they access? Right? And for almost all of our all all of our assumed breach assessments, right, we start with really for for most of them, at least the on-prem side, we start with evading the target EDR, meaning we start with an evasion first. Then we actually are able to test your defenses uh about what you're a like what part of your stack is able to catch us, right? So doesn't matter if you're using Sentinel One, Crowd Rag, MD, whatever. We have a bypass for it, right? And that's the
real starting point, right? Uh, bypasses, by the way, sell for anywhere between $50 to $1,000 on the dark web, and you can get a hold of them pretty easily now. Um, and I think, you know, there's a real difference to uh assume breach pentesting rather than the traditional fire up a VA scan or fire up CIS benchmarks. Uh, because a threat actor will never ever do this, right? And a lot of our engagements will start with a more realistic sort of starting point, right? A traditional pentesting has been I I fire up my NAS, my qualis, my CIS and then I try to validate those things, right? Attackers aren't doing that, right? And we try to approach this
from what a real attacker would do. And this is sort of the attack diagram or attack model that I sort of want to go through with you guys. This is actually a lot of how customers in Canada and the US gets compromised. This is just a one of many attack paths that we have. Uh and we're probably going to start with a fished account, right? Um yeah uh and you'll know that we use like pasta names for for users just because they're fictitious. Okay. Um going to set the stage first with caps, right? Uh fishing will happen in every environment. And I was talking to a couple of folks uh yesterday. Uh the fishing that you know
is very different from how threat actors fish, right? You have your know before or whatever product Microsoft that does your fishing training, they fail, you get a report. Real fishing doesn't occur like that. Real fishing occurs. And this is a story I typically share with customers is that there's a you know there's a financial institution that we uh sort of did it with right and you know you guys maybe do assessments maybe every quarter. It'll take a day or two days of effort. Our fishing engagements last anywhere from 15 to 30 days. Why do we do that? Because we need to go on LinkedIn you know scope out who you are start a conversation with you maybe talk
about something you're interested in. And there's going to come a time when you're expecting something from us. that's when we'll deliver that link. That takes time, right? And so this fishing campaign that we did for an organization, right? We got all the way to the interview stage for, you know, attacking the hiring process, right? And they were calling us into for an interview and then that's when we mass as it and we were like, hey, you know, what have you, you know, you've been interviewing people and we notice that there's a couple of resumes that's, you know, smells a little off, right? Is this one of the names? I was like, yeah. She's like, oh yeah. Then you know
that's when we deliver our payload and this financial organization have never been breached that way. So it was a very interesting uh time during debrief when we had to walk through what happened. I think we scared this this lady like forever. She was only there for like nine months right. Yeah. Um yeah so thread actors do not fish like pentesters like really right. And most of the times right a lot of the fishing that occurs uh they're you know they can use tokens or MFA enriched uh tokens or cookies to gain access right a lot of people feel like multiffactor authentication is going to stop an attacker not necessarily and when you're logging in with credentials right MFA is
used to be one of the biggest hurdles I I remember in 20 like 2014 like if you had MFA on your thing people would just move on right it's not the same anymore because there's open source tools that's going to be able to help Right. And um and and a lot of actually a lot of defenders underestimate device code O and that's a really quick way to gain access to a person's environment and and really why am I spending some time here talking about this is because uh there's really like after like once it pop why why does a entra sort of platform pop MFA it's controlled by something called conditional access. you're making conditions where you know
there's you know you going to when when it causes MFA and I think the biggest difficulty to understanding this space is that there's zero training on how to build good conditional access policies like and the way Microsoft has designed it makes it really is not very intuitive for you to understand that we'll go through a few examples yeah all righty so just a quick show of hand who here has heard of or seen a conditional access policy before. >> Okay, perfect. So then I don't have to spend much time on it. Who has ever been told or thinks because I have conditional access I'm fine? Anyone has ever heard that before? No. >> Okay, heard it. Yes, a lot of executives
think that way unfortunately. Uh so here we just have a conditional access policy and it just says require multiffactor authentication for all users and we have it selected for device platform or Windows. Just by a show of uh hands, who here thinks that if you were to try to log in on your Windows device, it will prompt the user for MFA. >> Okay. >> Yeah, this policy is particularly >> no. >> All right. So, in this case, if a normal user, not an attacker, were on a Windows device and they try to log in, it should prompt a request for MFA if they go to any other resources. What if they try to go in from like a
Linux device? Is this going to prompt anything or is this going to allow them in? >> Exactly. And so even though these conditional access policies have selecting a device, if you only select one device on here, it's not going to check anything on the other end, it's basically going to ignore it. Even though there's an exclude tab, Microsoft doesn't tell you this. You just kind of have to figure it out. Now, does anyone know how these policies are checked for devices? Anyone take a guess? It's okay if you don't want to. >> It's exactly that. It's user agents. So, yeah. So, anyone who has this type of policy where you're checking just on devices, an attacker can just change the
user agent and they're going to get in. It's very common, but this is the way we do it. Uh, so the next screenshot here is just showing how we normally do a fish. So, this is external to cloud. Effectively, we use a tool called evil gen X. We've uh created our own custom version of it and we can fish users and effectively we usually get their username and password and we will also get their cookie. Their cookie will allow us to effectively do whatever those users do and your only protection here is going to be conditional access policies where if you deny that user or their specific resources, that's your only protection here on this.
Additionally, another method that we can do is if we fish a user, we gain access. We can use device code fishing or if we have access, we can just put in the device code and we can get access to other resources this way. By default, Microsoft allows this. I think they're starting to roll out a new Microsoft manage policy that blocks this, but right now you do have to turn this on if you want to block device code authentication flows. Highly recommend turning it off if you are using it, unless you have a very specific reason for it. So, as an attacker, you might be thinking, well, how do you enumerate conditional access? you can't really see
it. So, right now, uh there's a tool called a road recon. It's a very popular tool that a lot of attackers use that was created by a gentleman named Derk Dirkjan. Uh and effectively, if you have a username and a password and as long as you can get access through conditional access or through device code fishing, you can enumerate policies for any user from any account. There is no way to block this on Microsoft's end because this is using legacy APIs, which we'll talk about a little bit more later. Uh but essentially you'll get an HTML output of every single policy, the trusted locations, everything that effectively you need to know to build your attack path as an attacker into the
environment. Uh so who here has ever set up a conditional access policy where you require compliant device before? Okay. Does anyone here realize that that basically means nothing in Microsoft? You can bypass this hopefully. If not, you can. Uh so here we just show uh a lot of the times by default you can register a device as a user because a lot of people will use BYOD bring their own device or log into some type of resource and you need a way to authenticate into the entrance system. So here we just show effectively that you know when you try to register a device you can quickly enroll it through device registration. It'll usually allow it even if there's conditional access
because unless you specifically create a special conditional access policy for it you're going to allow this. And then you can authorize that user with their device. You can create tokens. There was a talk here yesterday. A guy kind of talked about devices a bit if you saw it. If not, same thing. You can create primary refresh tokens. You can do a lot of things with those. However, once you have a device, you can use the tool pie to enroll into intoune if you're using intoune. So in the first step here in our screenshot, we show how a user tries to enroll into intoune a lot of people's MDM and you'll get an enrollment restriction fail. A lot of
people go in and luckily tick the box that says, you know, don't allow personal devices. A lot of people change that default setting from allow to blocked. However, Microsoft has an issue where if you send a device token, the device is considered part of your organization already and it just bypassed that check. Anybody can do this with just- device token in the in this flag and this will register the device as compliant and you can run a check-in and make your device compliant. Microsoft says this is by design, by the way. So, they're not going to be fixing it. This is only one of four different methods. Another one is if you don't block everything from personal, but
let's say you allow Android to allow Android devices of personal, you can just enroll your device as Android even though it's Windows and then check in as your Windows and it'll allow it. And again, Microsoft says by design. So, here we just show we've effectively follow that policy. The device is now set as compliant. Well, the policy says, you know, we either require MFA or require compliant device. Cool. We no longer need MFA. As long as we have your username and password and you haven't changed your defaults and you have this setting, we're effectively we that user. So, if you're using compliance, highly recommend you don't, but if you are, you're going to want to put some safe
caps in, and we'll talk about that in the uh blue team side later. Okay. >> All right. So, this this time we're going to sort of talk about how to you know pivoting between uh entry and Azure. I think the first slide too though you know um and and also like entra ID role abuse and Azure privilege escalation. Um you want to take this? >> Okay. Uh so what is the cloud right? I think if you ask 10 different people what the cloud is you're going to get 10 different responses. Even in our own organization we're like what do we consider cloud? Is it Teams? Is it One Drive? Is it Azure? Is AWS? Honestly, it's personal opinion. In our
way, we just kind of assume anything that's a SASbased application or is accessed through those, those are what we consider cloud. Uh so, for example, the Azure portal cloud graph API if you're familiar with that or done anything through terminal that is also part of it. Uh and then there's also the legacy one. Windows graph.windows.net. This is legacy. And we have a screenshot here from Durk Jan where we talked about it. Uh Microsoft said they're deprecating this API multiple times. It's still working. They say it's going to be this month, but as you can see, everyone doesn't believe them. Uh and we use these attack paths all the time with this API because they're not detected and they're not
even you can't even create detection rules on those as we'll see in a bit here. Yeah, it's not logged. That's why. Uh okay. And I think one of the really quick uh sort of attack path I want to share is uh this is one major difference between sort of like on-prem active directory and like uh cloud-based organizations. Um you know in in in on-prem active directory I think people are used to fileshares right and for fileshares most of the time only administrator can sort of control the ACL's on like who can access what folder what groups can access that folder. Do you know that in SharePoint like for cloud only organizations there's so many things that a user can do like one of
the things here that you know that I actually just learned about like four weeks ago is you can have everyone except external users for a particular file right like cloud allows you to do that and and I think what what is going on in their mind is like oh if if only my organization's users is accessing it it's fine right but when attackers try to come in to the network right they're converting external access into internal access meaning all it takes is one compromised account for them to touch that file right so file shares in the cloud are really really bad uh and they make things very accessible uh and and this type of access is very very abused
right and and oversharing is often one of the ways we look for for privilege escalation I think of like the 10 organizations that we've tested in the past three months alone I think seven of them seven of them had their uh global administrator plain text password in SharePoint right yeah why Why? Why? Because one drive is very connected to sharepoint, right? They think it's just mine, right? Um yeah. So that's one of the first things, right? Uh and just continuing on that attack path. This is something I I don't think this one is very rare, but it happens. And especially it happens with this particular setting, right? they would have a file and it would be a you know
organization of all developers and they kind of need access to maybe the SPN the service principles uh within Azure when they're all you know collaborating and developing on it and so they'll sometimes store the entire Terraform file in one drive right and the really cool thing about SharePoint is you can search for extensions and it'll look through the zip files too right so it's really really cool right so um you know and this happens a lot there's a file called secrets or whatever zip file is is in the folder uh and they'll has it'll have access to secrets credentials right and this will actually link to a service principle that we'll later abuse right so a lot of
the times or you know when organizations get compromised the first place to look at is shareepoint um right and I think you know that secret you know on the left is when we authenticated to that service principle we we would get an access token back right and a lot of times you can decode that token because the tokens are just JWTs right you can decode that token look at what resource it has access to, look at what app it is, and also look at the scopes or the permissions, right? And so we're going to talk about a little bit about directory readrite all, right? And this is what makes Azure sort of pentesting really difficult. You it's
not like just like like active directory, yak go domain admin. Like there's so many things in Azure that you have to know before you actually get started to understand this entire like attack path, right? And what is directory rewrite all? It's um it's a it's a really garbage permission. But anyways, it's a third party and and I think a lot of like uh like if you hire thirdparty people to come make apps in your Azure environment, you got to be really really careful because they don't understand scopes and permissions. They all they care about is making sure that application runs, right? They don't really care about anything else, right? So that's how a lot of like smaller SMBs
uh happens. they they get someone to develop apps and they have leftover permissions that are overprivileged, right? And so before December 3rd, 2020, when you make an application, right, you actually get an additional role called directory writers. And when you revoke that application in Azure, uh that permission doesn't go away. Microsoft didn't tell people that until until someone said it, right? and and for our attack path that we're trying to sort of demonstrate here directory read write read write all it basically grants access uh to like groups administrators like you could do non-assignable roles and intra and azure there's Azure roles which is like owner contributor is it also reader I only know owner and
contributor because those are the two things we target right um and then there's also entra roles which is your like global administrator security administrator things like that right and basically What this allows you to do, it allows you to add a member that you control, right? So if you're assumed breach, you control an account already, right, to a non-assignable security group. You can also add a new owner to a non-roll assignable security uh security group there. I don't know why I repeated it. Okay. Right. Oh, sorry, a new owner. Sorry, one's member and one's owner. And the third one is you can add new users to the tenant. Right. Um, and there's also a lot of other like privilege
escalation vectors out there, scopes that are like overprivileged, you kind of have to know what they are. Um, right. And I think before, right, when I was like testing organizations like back in 2018, uh, once you fish into an organization and you have access to their emails, like one of the first things you got to do is you have to find a way into your internal network. Just because you have access to their email inbox doesn't mean you have access to organization. the most you can do is probably like BEC, business email compromise. Um, but for us, because our goal is access into your internal network, what this forced us to do is we have to search your emails for
potential, you know, locating where your VPN endpoint is, locating potentially credentials for the VPN endpoint or a certificate that they use because for certific certificate based authentication for the VPN. So, you have to walk through that process and with sort of the migration into the cloud that's kind of changed a little bit. you're actually initial your initial foothold is probably closer uh on the cloud than you know um than people who just ran straight Active Directory with you know traditional VPN. Right. Um Right. Yeah. Just continuing on our attack path here. Right. For example, once we got access to that user, we'll call him what is it? Larry. Larry Lasagna. Yeah. Yeah. Yeah. Right. Larry Lasagna. We I got got access to
Larry Lasagna. Uh Larry Lasagna had access to SharePoint. That SharePoint had access to a service principle. We authenticate that service principle uh allows us access over uh the pasta makers group. So what we're doing is we're now using that token adding Larry Lasagna into uh the pasta makers group, right? And the pasta makers group has owner and contributor over a subscription as you can see here, right? Um, do you take this part or me? Oh, okay. No, I'll take this part actually. Right. And and you can see with owner or contributor access over a subscription, what can you do? One of the easiest ways to get in from here is just run commands on VMs, right? And you know how we set
up our lab diagram or lab network is we have one Azure VM uh on-prem domain controller and on-prem workstation and an on-prem enterconnect server. Right? So right now we only see one VM here right and what can you do on that VM? You can run PowerShell commands right as system right and this is this is one of the biggest things that this was known to people since 2018 actually right so this is one of the easiest ways for thread actors to get into an organization run commands on your VM and then tunnel back into your on-prem environment so actually if you have VMs that's connected to the domain on your Azure right this is a potential path
that you want to make sure you're watching right these logs are not like I run anything here it's not getting logged unless you actually built that yourself, right? And what am I doing here? Um, I think a couple years ago in 2020 or 2019, uh, Subt Casey Smith, right, he, you know, called out, hey, you can actually execute stuff with MS build and it'll call back as the MS build process, right? And I think in 2022ish, this is where like all the EDR vendors are like, oh, we're going to block this, right? But really, the detection that they build for people is only if MS build, right? uh launches a HTTP request outbound, right? That's the
logic of the detection. And what we did here is okay, let's not do that then. Let's use MS build to write a binary, two binaries onto the host, right? So the first command is writing the binary file. The second command is writing the DL file. And what is the third and fourth command? The third and fourth command is using MS build to build those two files. So now we've completely downloaded our binaries onto our VM. And what is the third thing? We're just executing our silo. For anyone that doesn't know, atmgr.exe is Cisco Webex. Right. Right. Okay. Um by default there is zero detections. Uh and you only get this if you have uh def Microsoft Defender for cloud. So you
don't even get this for with MDE, right? Microsoft has different products. There's identity cloud office endpoint and XDR, right? And then they also have Microsoft Sentinel >> and Microsoft >> and and that one, right? So you don't know like honestly Microsoft like they should be winning the game, but they're losing because they they like they separated out all of these things, right? So this is us demonstrating, huh, now we have a call back to our command and control server, right? on that you know file server in Azure right um and this is how the lateral movement works a lot of the times right so I have access to an Azure VM code access to an
Azure VM right it's a file server who's going to be on that maintaining it probably the domain administrator or some someone privileged right so because Azure VMs when people move and migrate their infrastructure into the cloud it doesn't mean they they're not domain joined anymore right and sometimes they don't shoot down all their on-rem stuff. So their on-rem stuff still talks to their Azure VMs through a domain join or you know a sight to sightVightVPN, right? So a lot of times Azure hosts still have access back into the domain controller or other sort of servers within uh active directory, right? Um and honestly I think this problem still exists, right? The lack of tiering for
domain administrators often lead to token abuse. And what token abuse is is that in traditional pentesting, right? pentesters would be able to access a host and then they would run something stupid like NXC or impact to dump credentials, right? People like smarter adversaries don't do that anymore, right? What do they do? They usually use some type of command and control framework and they'll impersonate the token that a domain administrator has. So right now I'm system on Azure FS. I'm taking the token of domain admin on the FS server and then I'm you know uh impersonating that and then doing an ls on the domain controller which is on on prem right so what was on the cloud is
also now in your on-rem environment right and what do I do here right after I do that I because I can list the C drive for the domain controller I'm just cding in there you know change directory and then uploading my sideload again through that um out of box also almost all EDRs do not do not detect uh remote upload of this type right um yeah I have to write rules for our clients to make sure this is not that abuse right and assuming your you know binary this is only assuming your binary implant isn't detected by these EDRs after I do that I call whatever remote protocol I want RM SMB you know your
yeah whatever you can imagine then this is now my call back to my domain controller, right, over AWS APIs. You're not allowed to do that, by the way. They changed it last week. Um, okay. And so now we're going to talk about uh sort of, you know, if you were on prem, right? How do you get back into the cloud, right? A lot of times when customers come to us, they want us to access and pop their AD, but they also want to pop their Azure, right? So if you're on the AD side, what do you do? Right? All right. So, we're going to talk about the sync link exploiting onrem to gain entra trust, right? Uh
this is sort of the model that we're going to sort of demonstrate the attack path, right? Let's say you have, you know, the the whole model is let's say you have workstation access. You have to find a way to privilege escalates. So, we're going to take a little bit of a shortcut because I think we're low on time. We're going to start from the domain controller, right? Uh and then this is what you can do, right? And I think one of the biggest pieces to uh Azure pent uh to to just like hybrid pentesting is if you look at all the cloud training out there, right? They will teach you about Azure services. That's it. They almost no training talk
about how to do this together, right? So when you want to pentest hybrid environments right now, you're going to be going into certain courses and they're only going to be teaching you about about like Azure pentest and Azure services. they're not teaching you about uh how to look at it together. So this is sort of the meme we have going on in our company that oh I want to do hybrid engagements I know Azure but I don't know active directory. You actually still need to know active directory. That's that's not ever going to go away right. So that's why active directory is what we tell tell people like our juniors like this is kind of a
gatekeeper until you learn this is really difficult for you to understand how the attack paths flow from top to bottom bottom to top like 80 to Azure Azure to 80 right um don't do that in red teams but uh a lot of the times when you're doing um when you're doing sort of enumeration in Azure you would run a tool called Azure right um if you want to ask me about that later we can talk about that but I'm going to leave it alone for now right and you want to run this because you want to understand your Azure identities um and why do you want to understand your identities who here knows what blood hound is lots of people
great right um blood hound is basically an active directory enumeration tool that allows you to map like attack paths in your active directory identities for example um Bob from accounting uh what actual permissions does he have in active directory this is a nice tool for you to run as a graph. Uh don't use this for red teams either, right? You're going to get caught. Um and what when you run both of these tools together, what you have is in the green you have your active directory identities and in the blue you have your Azure identities, right? And you can see in the middle there's something called uh sync to Entra, right? That's a problem. And why
is that a problem? is because when you set this up first in your intra uh connect that first thing where it says sync all domains and organizational units that's default right so what what do we see most of the time so in active directory you have your normal users and you have your service accounts right what gets synced all of them right so let's say you have a 14 character password policy uh but your service accounts might not adhere to that right that gets synced into Azure so a lot of the a lot of the ways we you know compromise Azure is because a service account has a weak password um that we found and we just hey login
right so this is a default setting you actually have to go to the second setting and you know sync selected domains and OUS in order to exclude them you actually have to create an exclusion first yeah so this is Microsoft yeah okay right and um a lot of organizations nowadays like in in in the cloud there's three forms of hybrid sort of models that we see it's seamless SSO and it's uh active directory fed fed like ADFS there's a third one >> yeah yeah password hash syn yeah yeah yeah that that's right you're right password hash synchronization phs right I think most organization have move to the seamless SSO model um and why do people like SSO is because you don't
want to log in 14 times and enter your MFA 14 times that's actually more secure but no one does that right So people love SSO, users love SSO because it's better than you know um you know uh you know forgetting 12 passwords an hour, right? So seamless SSO is in play and um you know and really there is a number of ways to privilege escalate for active directory. I think in my eight years of pentesting I've not gotten domain admin like twice, right? So and you know so almost every organization as long as you spend enough time in there you will always get privileged AD, right? There's a whole bunch of stuff you can exploit
now. There's ADCS, there SECM, there is like vulnerabilities that like gives you direct access to, you know, uh the domain controller, zero log on, proxy log on, uh noac bad successor, right? And you have passwords, right? Passwords are everywhere. They're in description fields, they're in notepads, they're in spreadsheets, they're in one drive, right? Um you know, they're in, you know, notepads that you stick on your computer, right? Um there's also like ACL's and DACL misconfigurations. There's so much and many many more. We published multiple vulnerabilities on thirdparty tools that actually caches you know that caches uh domain uh domain admin credentials. Okay. Okay. So uh how do you exploit seamless SSO and what seamless SSO is? you're able to sort of
compromise an identity in your active directory is the a no Azure AD SSO account dollar sign dollar sign means it's a computer identity and when if you have access to this account you can uh grab the NLM of this account you can DC sync now if your organization thinks you have DC sync covered um the attackers are probably not running in the right places there's a place you can run it where there you can't detect it right domain controller, right? Yeah. You can't detect that. Yeah. Um when you do do that, right, you'll get the hash, right? And you can use that hash, right? And you use a tool called seamless pass. What it does is
you can specify the domain controller, you can specify the user you want to target, and you also specify the resource uh and also the client app, right? And once you do do that right, you're able to convert uh that hash request any user in active directory to get a access token in the cloud. So a compromise of your on-prem sort of line is also kind of a compromise of your entra line as well. And here we have the role management readr directory role. That means we can add ourselves to any entry id role i.e. global administrator. Right? So you can see here we get you know tokens access tokens um and you want to talk about this part.
>> All right. So as you saw in the uh previous one we did seamless pass on a user called Ralph Gaton. However here it says global administrators are protected by conditional access policy. >> Ralph's a G by >> Yeah. So he's a he's a global admin. So, does anyone here have an idea of why this may not have protected him when we did our seamless pass? All right. So, the reason is they use something called PIM. So, Microsoft I I report as a vulnerability to Microsoft where basically if you have a user in your organization and you assign them a PIM role, they are not protected by a conditional access policy if you use directory roles unless that person has
that directory role currently active. But when it's not active, they are not protected by your conditional access policy. Microsoft said it's by design. They updated their blog to say why it's by design and I disagree with it, but we don't have time to get into that. Uh but so yeah, so here as this user because we have tokens as them, we can usually just request PIM oursel because a lot of people do self-activated PIM because you don't have the time to approve people. There are defaults where MFA is required. A lot of people will turn those off. However, you don't even need to do this. you can just wait in the environment, request a token every hour
until a person activates it themselves and then you'll get eventually a token that can be used because again they also didn't consider this a vulnerability but when you do pin it doesn't expire old access tokens you can just use the access token as your uh that privileged user so here we just show that once we activate a pin if we try to run seamless path now Microsoft finally then says oh no you're actually a global admin now even though technically you are before now we're going to block you So if you are using pim definitely don't be using directory roles for protections because this is a flaw they're not going to fix. Uh from there we can easily just add
ourselves to uh any role. So we just use another curl command here and effectively we just pass our principal ID which is our uh Larry lasagna priv unprivileged account with the global administrator role and now we can effectively become glob administrator. A lot of times we don't do this because uh we get detected. However, the detection for this is not out of the box by Microsoft. Again, you have to detect this. So, and then here we just show that we are now effectively global administrator because we have the seamless paths enabled. >> So, we don't have a lot of time to go through this. So we'll do it really talk but uh really quick but effectively uh
if you use a Windows device you're probably using Microsoft products, Teams, One Drive, SharePoint, any of those tools. Uh you're probably using on your laptop. So one thing we sometimes will do is we'll go into a workstation of a global administrator or someone with a privileged role and we'll just sit there until we see a process running as that user and we'll just dump the process. Uh the reason we do this is this also contains our tokens that we can use as long as we do it within a time. So I think one one thing to clarify is um the EDR space right they spent a lot of time preventing and detecting and blocking the LSAs you know uh LSAs the Elsas
process right and both basically if the if the EDR vendor is capable they would you know prevent handles going to the Elsas process from another process right but they this is not the same with Microsoft processes and just like what Chance said right you can access uh JW WT tokens from Outlook, One Drive, Microsoft Office, Excel, Sharepoint, every single Microsoft process because it's using it's using the APIs to authenticate into Azure right into intra right and it's uh and and it will h it will need to do that right so there's been many tools created to grab these things right and I think um yeah one researcher also you know talked about where these tokens are cached on
laptops, they're in the token uh they're called a token broker cache and it's in a user's app data local Microsoft token broker cache directory and what these files are these files are protected by DP API so you can touch these files guess what you can touch JTLBT tokens of global administrators right so now your administrator laptops then your gas right they are tier tier zero assets too right which many people don't consider Right. Um, and you know, you know, this is just one of the tokens that we've gathered. Um, you know, there's privileged uh scopes within these tokens that allow you to do things, right? It's not exploitable in our environment. What this does is allows us to add ourselves
to a group that has an intra IE role. Uh, but we didn't have that set up, right? So, you know, office processes dumping is sort of the game right now, right? Okay. So, we have a bit of time left. We're going to run through speedrun the defender gotchas. Okay. Um, all right. This is going to be one a little bit hard to to speedrun. Uh, when I first wrote this slide, it was about 70 steps that you should do to make an actual conditional access policy. Unfortunately, we just don't we're not able to do that as blue team people. It's you're going to your life's going to be miserable. Uh, so in this case, I
recommend some that will make you moderately secure. Uh so in this case you should require MFA on all resources uh as your baseline and exclude any resources or users after that because this way you have a catch all basically MFA on all resources. This is going to block a lot of things. They're going to need to have a certain account for any of those excluded resources. You then need to create a policy uh for whatever access that user has. This is where you can use like trusted locations, device joined uh domain join devices, compliant devices. Again, yes, we just talked about how they're insecure, but it's about layering and and uh you know, compensating controls versus being able
to do everything. Uh so that's what we recommend on those. Uh additionally, however, when you onboard new users, a lot of people are still somewhat remote kind ofish. Uh and you probably ship out a device, they register their MFA at home. Uh this is also a flaw where you can register MFA devices for new users from anywhere. So, we recommend having a conditional access policy to block registering MFA unless from a trusted location for the first time and using like dynamic groups to put them in and out of those uh because that will also help where if a user gets compromised or a service account gets compromised, you'll still require MFA enrollment on the first login, but it'll block that
user when they get access. Finally, you also should block device registration through conditional access. It's also another thing you have to click a checkbox through to go through and require MFA for all users and only have exclusion on for all uh the users that you require or if possible set device registration to zero which is unfortunately really difficult to do with how Entra is set up. Okay, logging. So if you ever use uh Entra for uh logs or Microsoft, sorry, Microsoft products for logs, you see out of the box, if you just buy E5, you're going to see that none of these are enabled, right? You actually have to go and enable them, right? So out of the
this is why like Microsoft technically should win the detection space. They have the most telemetry of any company, but they do not make their products easy to use, right? So you you you buy an E5, you think, oh, you're good. No, you got to like understand where this is and toggle them, right? Yeah. And the more you toggle, the more it costs. Yeah. Right. Yeah. And look at this. This is uh Defender for Cloud. This thing's insane. This is why no one uses it, right? They charge by resource, right? If you have one server, that's $15 a month per server. Yeah, it's expensive. Like, right. Like, and it doesn't it doesn't really do that much, right? And
they they don't just charge for servers. They charge for every single resource you can possibly imagine in your Azure. Right. This is this is defender for cloud right. Um right uh by default also right you if someone were to add themselves to a global administrator you would not know unless you write a rule or you hunt for it. Uh you should definitely write rules and hunt for it right. Um okay and for I think I think one of the best technologies is uh within the Microsoft suite it is Microsoft Defender for identity. Um because one of the things that I start teaching customers is if you want to detect us at the encryption stage of the
attack where I encrypt some of your files, test files, test files, right? Um too late, right? What you want to do is you target us on the discovery phase, right? So if you know that I'm going after your domain admins, you want to make sure your domain admins at least has a honey token. So when I run an LDAP query to look for domain admins, I'll get popped, right? So defenders have to go on the offensive. You have to think like an attacker. It's like where what do they have to do to get that information, create detections there, right? Um and I think this is one of the better Microsoft defaults, right? By default, if you have an E5 and you have
Defender for XDR, you have automated response turned on. Pen pentesters hate this, right? because you they can lock out systems or users that are actually really important for the organization and this is actually where to find it. We actually have to in our kickoff we're like do you have this you have this all right go to this place you know we got to write exclusions otherwise we don't want to lock out your important users right by default right there's automated lockouts for users that they deem risky right so you're going to hit like if you're a pentester in the industry you're going to lock out stuff really quickly if you do not know what you're
doing right this is yours >> all right well we don't have a lot of time so Uh yeah, why Microsoft sucks. As you can see here, this is five different testers, including my own case, where they basically said, "We determine this behavior is due by design. It's a valid concern, however, but due due to design." Uh, and they say this for basically every person submitting a vulnerability right now. They'll just say it's by design unless it's very critical. They won't fix it and they'll just update their documentations. And Microsoft sucks for doing it. But yeah, the why Microsoft really sucks though, if if you ever have ever set up a Azure tenant, they charge you a nickel and
dime you for everything. You want defender, you got to pay for it. You want, you know, cloud, you got to pay for it. You can get E5 licenses and combine some of things. But we'll also notice a lot of uh customers will have basically everything from an E5 license, but paying for it individually where Microsoft should just upgrade them. Uh, I think it's crazy that they say conditional access and PIM are security requirements that you have to pay for. I think security should be by default free to everybody. Uh, and I think that's a really shame that vendors like Microsoft are doing it because it's just going to convince more vendors to to get away
with doing this unfortunately. >> Um, I think yeah, that's that's sort of all we listed some references here. Um, some tools of the trade. Um, there's also a lot we didn't cover. Yeah, >> look at look like we there's things about SharePoint image. There's like there's taps. There's like abusing the intraconnect connector. There's like tenant hopping. There's like you know abusing you know bastion. Yeah, exactly right. There's too many we can't cover. This is all the time we have. Um and yeah, any questions? Cool. >> Yes.
>> No, unless you want our slides to be 200 slides. I don't I don't even think 200 slides would cover like two of the points. Yeah. >> Yeah. We'll we'll write about it and public uh publicize blocks. Yeah. >> Anyone else? >> Yes.
uh so if you actually look at how they're doing the continuous uh token protection right now it's only on very specific resources and if you look at the specific resources they cover it's not the resources attackers want first of all other than SharePoint uh so basically it's pretty useless in my opinion Uh, but the other fact is that if I steal your token, I'm already on your device anyways. Probably I can just use your device to bypass the continuous access depending on how you have it set up. Uh, it needs a lot of work. It is still in preview though, so it will hopefully eventually get to that pair of detections where it's actually useful.
>> If anyone has any questions, we'll be around.