Risky Business - Soap Box: A deep dive on how Russia's SVR is hacking Microsoft 365 tenants

Episode Date: February 18, 2024

The need to properly secure Entra ID tenants has been made pretty obvious this year thanks to a large-scale attack on them by Russia’s SVR intelligence agency. In this interview Andy Robbins from SpecterOps, the maker of Bloodhound Enterprise, talks through how he thinks those attacks actually went down, about how if you’re an o365 customer you’re using Entra ID whether you like it or not, and about how you can lock down your Entra ID tenant.

Hey everyone and welcome to this special Soapbox edition of the Risky Business Podcast. I'm Patrick Gray. And as regular listeners know, these Soapbox editions of the show are wholly sponsored, which means everyone you hear in one of these episodes, these special Soapbox episodes, paid to be here. And today we are chatting with Andy Robbins from SpectorOps. SpectorOps is the company behind Bloodhound Enterprise. Bloodhound Enterprise is a tool that can hook into your Active Directory and enumerate attack paths. And it's great for spotting misconfigurations and risky configurations, permissions and so on. We actually recorded a demo of Bloodhound Enterprise a couple of weeks ago.

Adam Boileau and myself were both on that demo and I've included a link in the show notes for this podcast so you can check that out if you would like. That demo mostly focuses on the on-prem like old school Active Directory use case but Bloodhound is also pretty handy in Azure AD which these days is called somewhat confusing confusingly, Entra ID. Confusing because, yeah, they just renamed it. Now, the need to properly secure Entra ID tenants has been made pretty clear this year, thanks to a large-scale attack on them by Russia's SVR intelligence agency. In this interview, Andy talks through how he thinks

those attacks actually went down, about how if you're an 0365 customer, you're using Entra ID, whether you like it or not, and about how you can lock down your Entra ID tenant. So here's Andy starting off with a walkthrough of the SVR's attack. Enjoy. Yeah, so kind of what I refer to as like step zero is, or maybe even step negative one. Like step negative one is that there were configurations that existed before the Russians ever showed up. There were privileges that already existed, things that were already in place that were just waiting for someone to discover and just waiting to be taken advantage of.

I'm guessing you're not talking about good things. Let's say, yeah, not great things. Like things that somebody could abuse if they discover them and choose to do that. Yeah. So among those is what I call step zero, which is Russian intelligence, which Microsoft refers to as Midnight Blizzard. They were able to identify a user in a test tenant that had a weak password or an easily guessable password, and they used that to achieve initial access into this quote-unquote test tenant that Microsoft managed.

That's step zero. That's the initial access avenue. Now, the next statement, or what I refer to as step one, is the adversary used that initial access to quote-unquote compromise an app registration in that tenant. And so we don't know what that word compromise means necessarily. But what I think is the most likely is that this user had the ability to add a new credential to that existing app registration. And a lot of these terms, I think, are pretty new to a lot of

people. But an app registration is essentially like my coworker, Daniel Heinsohn, puts it pretty well. The app registration is the cookie cutter, whereas a service principal is like the cookie. And so an app registration has information about, you know, what are the URLs associated with the app? What are the privileges that the app is going to ask for when it's instantiated and things like that. But something that's really critical to understand is that, you know, an app registration can have credentials that are saved on it. Those credentials are valid for authenticating as that application into other tenants that have published that application. So an app registration is essentially like a manifest for the app,

but it also has credentials in it. That's precise. That's exactly right. Yeah, precisely. So, you know, taking everything into account, like taking the entire path into account, that's what I think probably happened is they added a new credential to this existing app registration. And there are many, many ways to do that. There are many different privileges or roles that enable that. And I have those listed out in that blog post. But would that be through some sort of security vulnerability in the app itself, or is this just something that depending on the way people have their environments configured, they can just add this credential through some sort of API call?

That's a great question. So I believe that this had nothing to do with any kind of actual web app that was running anywhere. The app registration object in Intra, I think it only has to do with that particular object. And I don't think there's any kind of like, you know, local, like remote file include or local file include or any kind of like OWASP top 10 bug, you know, involved here. I think this is most likely a legitimate API in MS Graph probably was used by that initial access user to add a credential to that app registration. And this is something that happens all the time. And I think this goes back to kind of like that

step negative one thing. It's like this user always had the ability to do this. And that configuration, that privilege has just been sitting there for days, months, years. I'm going to go with years there, Andy. Probably years. It's been sitting there for years waiting for someone to discover and abuse. Okay. So, so attacker has added credentials. What, yeah. Why add credentials to this registration in the first place? What would be the point of that? Yeah, so, you know, control of the app registration actually doesn't guarantee control of the actual application, like a web app or a daemon application or anything like that. And I also don't think you really need to take control of the actual application that is running and is the manifestation of that app registrations manifest, let's say.

Because you can just pretend to be that app, I'm guessing. Exactly. Yeah. So the app, it has an identity. And that identity is what is able to access information that is in other tenants. And that kind of leads into the next step, which is all about the service principle that is associated with the app registration. Okay, go there. Explain. Right.

I'll try to stay with you because already I'm melting down just a little. But yeah, go on. I don't blame you because the vernacular here is confusing and it's opaque. And it's also, you know, what we're talking about really is OAuth. What we're really talking about is Microsoft's implementation of OAuth. And they have changed some of the vocabulary from, you know, the original spec and what every other vendor uses when they're talking about OAuth. So we're talking specifically about like the Microsoft flavor of OAuth. Like we could talk about the Microsoft flavor of Kerberos, for example. So yeah, that second step, the step two is the attacker has added a credential to this app registration and an

app registration is a class of object in intra now going back to kind of step negative one is like what already existed that app registration i believe had been published or consented or instantiated into the Microsoft production intra tenant. And when that happens, there is a different kind of object that is created in the target tenant or the production tenant. And that different kind of object is called a service principle. And these things are also called enterprise applications. So not only is the vernacular different, the vernacular is also like varied depending on context of what exactly it is you're talking about. It gets back to like what we are talking about here is in fact OAuth.

And so the fact that the app registration resides in one tenant and that vendor or that admin or that environment has control of that, and then it has been published into another tenant where that app then gets access. The olden days of on-prem active directory trust boundaries being very rarely ever pierced. Those days are over. Those days don't exist in the cloud. And, and OAuth, you know, as great as it is, the, the end result of OAuth is that these trust boundaries are pierced all the time, whether admins are aware of that or not. And this is, this is just one way that that happens. So going back to this kind of like step two step. So the app registration, it is published into the prod tenant as a service principle.

And the statement from Microsoft is that this app had quote unquote elevated access into the production tenant and this is where things get really uh spicy i would say because the the privileged actions that are taken later in like step eight or nine or i forget exactly what it is imply a level of privilege that requires the highest amounts of permissions that exist in intra, either global admin or the equivalent of global global admin. But at this point, the only statement we have is that it had quote unquote, elevated access. Now, I said earlier that like, you know, these apps, they have identities, the service principle is the identity. And so, you know, my user could have an identity. I have an identity like in our SpectreOps, you know, environment. And an app can work the exact same way.

It has an identity that it can do things with. And privileges and permissions can be granted to a service principle similar to how they can be granted to a user. I see where you're going with this, which is that, you know, the line between, you know, an app and a user is not entirely distinct here. I don't know. Am I making sense? Am I making sense? Or am I gone off the rails? Okay, cool, cool, cool. You're totally making sense. It's very complicated, but in fact, knowing the like minute differences between what an app identity and a user identity can and cannot do, knowing that difference is what you kind of have to understand as an Azure admin to really understand the real amounts of privilege that were held by the adversary. Well, and the real risk, right? And I'm guessing from what you're saying that understanding these subtle differences is more like PhD level than something you get from reading the readme.txt, right? Yeah, unfortunately it is today. It requires pretty deep expertise in these systems to understand that difference and

to be able to read between those lines. Should it be that way? No, it should be simple to understand all these things and it should be simple to control all these things. But right now it's not. It's not easy to understand or control these things. So moving on in like this kind of attack path that the adversary executed, it gets to step three,

which is where Microsoft says that the adversary executed, it gets to step three, which is where Microsoft says that the adversary created additional app registrations. And this starts to get into the point of the attack path where we kind of have to make some conjecture or some guesses as to why the adversary is doing certain things. Yeah. It's because they're doing more than what is strictly necessary. And I think that's why a bunch of people have looked at that and they're going oh look they're doing more than it is than is necessary to actually get information out of that tenant that doesn't make sense but i mean when i looked at that the first thing i thought is they're doing this because it will make it less likely that the organization that they're rummaging around in is going to detect them and their actions that's what i think i think it's like um you know like strangers on a

train it's like you know if the less each individual piece is associated with each other you know the longer a path you can create the harder it is for a defender or a responder to kind of unravel that you know like the harder it is for a defender or a responder to kind of unravel that you know like the harder it is for them to follow this but that that that breadcrumb trail that is being created so i agree there's the you know if you if you have a look in a log and you see some app that you know well doing stuff that it shouldn't be doing you know you're going to know that something is suspicious whereas if it's some app you've never heard of you know what i mean like that should be suspicious but in many ways it's like app you've never heard of, you know what I mean? Like that should be suspicious,

but in many ways it's like, oh, well that's not the one that I admin. That's not my problem. Exactly. Whatever. That's probably Bob's app. You know,

that's kind of what I thought they might be doing there. Exactly. Yeah. I, I think at this point there are steps being taken to obscure, you know, for future forensics purposes, what exactly happened.

Kudos to Microsoft for unraveling exactly what happened because it's not easy to do this. Lucky they did it just in time. Oh, wait. So yeah, so the adversary- Let's just take it easy on the Microsoft kudos is what I'm getting at. So the adversary,

they create these additional app registrations and we don't know if this happened in the tenant that was initially compromised. We don't know if those are created somewhere else. In my opinion, it doesn't really matter where those are created. Then the fourth step that Microsoft states is that the adversary created a new user in the corporate tenant. And again, I think I'm probably with you, Patrick. I think this is probably an obfuscation technique because they already had all the power they could have ever wanted or needed.

Yeah, they had everything they needed. They created a new user. So yeah, I mean, that's just what it struck me as because then they could use that new user to drive the apps. You know, like none of this is going to be foolproof evasion, but I get it. I get it.

When I first saw that too, I did a double take. I'm like, why would they do? Oh, okay, right. I get it. Yeah. Yeah. If you're the adversary and you know that certain actions are going to leave

forensic artifacts and you want to evade detection, you will try to blend in as well as you can. So I bet you that user they created, I bet you it had a lot of the same features that a normal, you know, new person joining Microsoft would have, you know, maybe even a address or an office they're working out of, an email address, etc cetera, so that it looks normal outside the fact that it's being done by an application that maybe doesn't usually do that. Yeah. So going on to step number five, this new user they created, this new user that the adversary created, they used it to consent to these newly created app registrations. And that

action results in the creation of these new service principles in the target tenant, in the Microsoft production tenant. And again, I think this is a persistence and obfuscation technique, not a privilege escalation technique. And the next step, step six, this is the most important step to really understand. And this is where we get to the difference between what a user can do and what a service principal can do and when and where. Yeah, because it's like everything's all set up at this point. So how do you actually do the thing? Yeah. Which I guess this is this bit. Yeah. Cause it's like, everything's all set up at this point. So how do you actually, how do you actually do the thing? Right. Um, which I guess this is, this is this bit.

Exactly. So, so the step six is the adversary used the original, you know, trust boundary crossing app from step two. They used that app to grant these new apps a particular app role called full access as app against the exchange web services service or API. So is this like a, like a, like a OAuth grant essentially? Precisely. Yeah, precisely. And this is where understanding the distinction between what a user can do and what a service principal can do gets really important and deep, I would say, technically. And it's because... Because I'm guessing users can't get that permission, but apps can. Well, there's a couple of things. So one is that a user cannot grant

more power than what they already possess. So a newly created user that doesn't have any special privileges, they can't just grant consent to an application to have the equivalent of global admin. And that makes sense. Why would you architect a solution that people can give things more power than they themselves already have? That makes sense. Well, that's just Privesk, right? So that's like Privesk by design at that point. Yeah. It's like MSRC would be all over that. So the difference between what a user can do and what a service principal can do. When an application is asking for certain app roles or delegated permissions, there is a difference between permissions that can be

granted with admin consent and those that can be granted without admin consent. So for example, there is a pretty low privilege MS Graph app role called user.read. And that does not require admin consent. Any user can consent to an application, and then that application can read that user's profile, they can read their email address. And the user who does that, they don't need to wait for an admin of their environment to allow the app to do that. And those permissions that don't require admin consent are all just very low risk, low privilege, you know, actions or permissions. And it's basically the user, you can think of as a user

saying like, I already have access to all this stuff myself. I'm going to go ahead and say this application can have access to that stuff too. Now, permissions that do require admin consent are those that can present some kind of risk to the environment, like being able to add credentials to a service principal or to promote someone to global admin or to grant app roles. Now, these privileges that require admin consent, the mechanics of how an admin actually does that is there is a particular API endpoint that they have to hit. And the way they hit that is by going into the Azure portal GUI and clicking on a little button that says grant admin consent. When you're using the Azure portal GUI, you're actually kind of using a very fancy API client.

And it is accessing all these different APIs. The API that gets hit when you hit that button that says grant admin consent, that button, it makes a call to a particular API and that API cannot be accessed by a service principal. It can only be accessed by a user. And that is the mechanism that Microsoft uses to fulfill this kind of contract that says, if there is a permission... It says you can't have default Privesk as a service. Exactly. Yeah. And the contract is basically like, if an application is requesting really dangerous permissions, a human being has to click a button that says that's okay. But there's a bypass. I knew the next word out of your mouth was going to be but.

But go on. So there's a bypass for that. So there is a way to grant consent for these very high privilege roles that can be done programmatically. And that can only be done by hitting a different API endpoint. And in order to bypass that admin consent process and hit that other endpoint, an app has to have already an MS Graph app role called app role assignment dot read write dot all. And that is what I think is the most likely privilege that the initially compromised application most likely had. I mean, so a user can't do it, but an app with that permission can.

Yeah, a user could do it if they were a global admin or if they were like a privilege, if they were already in full control of everything. So if you've got control of one of these apps, then you what can control, you can grant access to other apps

from the app that you control because that privilege, oh my God. Exactly, yeah. I mean, I could see there being legitimate use for this privilege by some kind of business application or a third-party vendor that's managing privileges and permissions in Intra.

I think it's something that Azure admins need to be aware of. Because I think what's most critical is for admins to be auditing what applications have that privilege in my environment. And do they actually need it to do whatever it is that they're doing for me? Oh, you would need a really good reason. Like I would think, you know, the first thing anyone listening to this should do is a full audit of their Azure slash 365 environment for any app with that permission and really look at removing that permission? There is a chance that it could break some kind of business process if they reduce the privilege that that application has. But I think certainly it's an opportunity to kind of lean on

that vendor and tell the vendor, you need to justify the amount of privilege that I've granted you in this environment. And certainly some vendors do make legitimate use of these privileges. I can give you a good example. So Okta has an Azure application, which when it is published into a tenant, it has the ability to promote itself or anybody else to global admin. And it makes legitimate usage. I mean, that's its job. Exactly. That's its job, right? Yeah. That's exactly what it's supposed to do. And so it is a mechanism to provide kind of just-in-time access through an Okta, like you have to authenticate to Okta first,

and then Okta is what gives you access into Azure as an administrator. And so this is the mechanism that that uses and it makes legitimate use of it all the time. Now, does every application that has that power need it? I would argue not, but it's a tough question to answer and it has to be done on a case-by-case basis.

No, no, no, fair enough, fair enough. I mean, I was thinking about stuff that clearly doesn't need it. I mean, obviously your auth, you know, your SSO app is going to need that, right? So yes, point taken. It's going to need something. Maybe not that, it's going to need something, yeah.

The last step, step seven of that attack path, which is kind of like the action on objective step, the impact step. What did they do after they did all these configurations? And it's, they used those permissions to access Microsoft employee email inboxes. And what I've read is that, you know,

cybersecurity people or personnel at Microsoft were targeted, executives at Microsoft were targeted. And I read somewhere that this was possibly motivated by trying to figure out what Microsoft cybersecurity people knew about SVR's tactics, maybe in particular related to the war in Ukraine. But I don't really know. I don't really know that for sure. It makes sense. Yeah. It's just occurred to me too, like Microsoft has said that it's gone out and notified a bunch of people where these TTPs have impacted them or whatever. And again, very careful language, but word on the street is that an awful lot of people got popped by SVR through this. And we were talking before we got recording about how finding that through logs would be pretty hard because Microsoft's logging around this stuff isn't real great.

But then what I've realized is their kind of stealth step here might've brought them undone because if you searched for something unique to these app registrations that they were doing as part of this step to try to be stealthy, you would just pop out every single tenant where this had happened, if they had something common between those app registrations. Yeah, that's definitely possible. Yeah. I wish I knew more about SVR's tactics, you know, to kind of say one way or the other. If it were me, you know, if it was me being the adversary in the situation, I would make sure that every app that I create falls in line so well with what already exists to not allow for a kind of like one-off, you know, hey, this property is the same. Let's find that everywhere. That's certainly what I would do. Yeah. Who can say what the adversary actually did?

Now, it's probably worth it at this point to point out that, you know, Azure is the platform. And 365 is like the productivity suite that runs on top of the platform. So we can kind of think of Azure as Windows and, you know, O365 as Office. Sure. That's the way I feel like it's, you know, the most helpful to think about it. So for people out there who are like, well,

we're just 365 customers. We don't run Azure. Well, you kind of do, right? And so I would think this is something that anyone who's using 365, you know, needs to think about from the point of view of, well, no, you know, there is a platform under all of this stuff that either you can be manipulating and adjusting permissions or attackers are going to do it for you. You know, do you think people realize that they're, that all 365 customers are essentially Azure customers? Do they know? No, I think this

is actually a really common misconception that people have that, you know, if I'm only running Microsoft 365, that I don't need to worry about these things. But the truth is that with the productivity suite with Microsoft 365, that requires the existence of an intra-ID tenant or what used to be called an Azure AD tenant. The rebranding of these things causes a lot more confusion, I think as well. But yeah, I hadn't even heard of entra until like a couple of weeks ago. I'm like, what the hell is a, you know, Googled it. I'm like, oh, okay. They renamed it. Thanks. Yeah. As you say, that's helpful and confusing. Yeah. Yeah. These systems,

they are, they're confusing, they're opaque and they're dynamic. They change all the time. So it's really hard to keep up with all these changes. But yeah, certainly, somebody who's using Microsoft 365, whether they know it or not, they are using intra-ID as well. And so these kinds of attack paths can impact those users as well. So look, taking a step back, if you're a 365 customer, which like, you know, a gajillion people listening to this are,

what is it that you should be doing about this? Because the situation you described there, you know, I think I described these, the Microsoft test tenant, and I'm guessing a lot of other equivalent tenants that got owned as kind of like tinderboxes, right? Like they are just sitting there ready for a spark to hit them and they'll go up. So how do you actually go about paring back some of the accesses that made these steps possible?

Yeah, I think about something else you mentioned earlier, Patrick, which is like throughout the narrative of this attack path, there's no vulnerability really being exploited. These are all configurations and system mechanics. But that's a semantic debate. That's a semantic debate at the point where a lot of this is down to when it's so easy to misconfigure things like that, like, I think you're splitting hairs at that point as to what is and what is not a vulnerability. I mean, it's very, you know, it suits Microsoft's PR team very well to say that, but I don't, you know, it's a distinction without a difference.

Let's put it that way. Yeah, I guess like the reason I mentioned it is because, you know, these configurations, they were there for Microsoft for a long time, probably years. You know, they were just sitting there waiting. And any one of those particular configurations seen in isolation, step three, step four, you know, to turn something, you know, immaterial into something very impactful. It's important to be aware of what those configurations are, and to reduce the risk by making reductions to power that already has been granted to these different identities. So that's why I think it's critical to go back to that kind of like step negative one.

You know, what does the environment look like right now? What does it look like for years? And for Azure admins, for intra ID admins, I think the most critical thing first is to identify what are those foreign applications that have any kind of privilege in my environment. And then after identifying what those are, like cull those permissions as much as possible to get rid of that kind of, you know, super impactful piercing of trust. You know, something else I think that kind of goes on said is these tenants, they have foreign apps and foreign apps and foreign apps. It's not just one tenant to another. It's the fact that, you know, these things can chain and hop from one tenant to another, to another, to another. So even if I trust this vendor to have a good security posture, what if they get popped?

And then like, what if Okta's Azure, or what if Okta's intra ID tenant gets compromised, all of a sudden, there is this super powerful application that has access into my tenant that I could be impacted by. So I think reducing the privilege that already exists, I think is the most critical point. And setting up some kind of periodic audit process to easily figure out, you know, here's a brand new application that somebody published a week ago. And now guess what?

It's a global admin, basically. So what happened? Why does it have that? Does it need it? You know, let's criticize that. Let's put pressure on the vendor. I'm sorry, Microsoft should be doing this. Microsoft should be giving its customers a way to control this.

I mean, this is the latest in a long line of Microsoft doing really dumb stuff when it comes to things like OAuth apps. We were at them about this for years in that the only way that you could choose to allow or deny or really have granular control over OAuth apps that your users were using in a 365 tenant. Until recently, you had to do that via PowerShell. Even in your blog post now, you were talking about config changes that you were making and you were instructing people, well, if you're using Chrome, you need to go to developer tools and then search it for this special good, then you can take that and then you can do it.

Like, why is it so hard? Why have they just, you know, and for them to say, oh, well, there's no vulnerabilities, you know, there's no, you know, butter wouldn't melt in our mouth. Everything's perfect. But it's like the way that they run this stuff is f***ing insane. Yeah, I got to tell you, the truth is I find myself pulling my hair out a lot when I use the Azure portal with trying to accomplish what it is I'm trying to accomplish. And there are people at Microsoft who I think may have a similar experience to me who put out resources or tools to help with that. Like Meryl Fernando puts out

great resources to help make these things easier without people needing to get some kind of premium license from Microsoft to access some kind of special suite of tools. It's not a great GUI for doing auditing of permissions, I'm sorry to say. Yeah, I mean, I don't think it's just about the GUI, personally. I think it runs a little bit deeper than any sort of one interface, which is they've just allowed their stuff to get misconfigured this like this was waiting to happen i guess is my point they should have bloody seen it coming but

anyway bloodhound is most associated with being able to do attack path uh you know enumeration for active directory installations you do play in azure but i mean what it sounds like what you really need most in az Azure is just simple permissions auditing as opposed to attack path enumeration. I'm guessing that's where you focused your product efforts on this. You're right. So I think at the very fundamental level of what a product like ours has to do, it has to get permissions auditing right.

And we've tried hard to get that right. And so we make it a lot easier to understand what are the super impactful permissions that exist in my IntraTenant or in my Azure RM environment. And what exactly is the danger posed by those particular configurations. So we put a lot of effort into making that permissions auditing experience way easier so that, you know, for any given object, I can see with one click, who has control of this particular app registration, let's say, for example, and you know, who has control of that through an intra ID role, who has who has control of it, because they've been added as an owner, who has control of it, because it's a service

principle that has a particular, you know, MS graph app role. So with one click, you know, what I want to see, and what we have put into the product is being able to see the full picture of who has control of anything. So the permissions auditing, we try to make really simple, really, really easy. Doing that in the portal, in the Azure portal is not straightforward and it is not easy. It's a very frustrating process. But Microsoft will sell you a permissions auditing tool. Sure. They'll sell you one. They'll sell you one that makes it easy, but they make it for the average user. They make it nigh on impossible. Unfortunately, yeah yeah without a premium license of some kind it's it's very frustrating to to achieve that same kind of uh uh efficiency

of auditing it's it's it's really hard to do yeah yeah i mean you know alex starmos summed it up nicely in the in his linkedin post about all this, saying that Microsoft plugging their permissions auditing products when describing how their customers are getting wrecked is like cybersecurity chutzpah hall of fame kind of level stuff, right? Yeah, it's the kind of thing that kind of creates, you know, I think a lot of resentment and cynicism in our industry against marketing and PR professionals when we see things like that. And that's, it's a pretty egregious example, I think of, I think, you know, what I referred to, what I referred to as ambulance chasing. Yeah. I think practitioners in our industry. Ambulance chasing is one thing, but ambulance chasing when you're the one who caused the crash, like that's a whole other thing, you know, that's just, yeah, chutzpah. But look, I mean, you know, going beyond just a first level,

first line permissions audit, you know, what else are you doing in Azure? Because there is, you know, it feels like this stuff is really kicking off now. It's front of mind for a lot of people. Everyone's thinking about it. So I'd imagine you are too. It seems like there's beyond just simple permissions auditing there's probably a little bit of an opportunity to do some graph-based analysis here and enumerate certain attack paths and look at certain things that might be dangerous when you

string them together which is kind of you know the spectra ops bloodhounds uh bloodhound thing so you know what what else you're working? Like beyond just the permissions audit, which I'm guessing, funnily enough, you deploy as an app. I was going to make a joke and ask you what permissions it has, but anyway, we'll just, we'll just move on from that. Um, yeah. What, what else are you working on with the Azure stuff in particular? Yeah. So with the Azure stuff, you know, we are interested in doing the attack path analysis to understand what is the impact of, for example, a foreign app registration having the equivalent of global admin. And what we are hit by today are limitations on what we are able to see. So, for example, let's say I have that Okta app as a foreign app registration in one of my customer environments for BHE. What is the impact that Okta has, you know, global admin in

my environment? I don't really know because the best I can get is like, you know, an ISO 27001 or a SOC 2 attestation from Okta. But beyond that, I have no idea what their environment looks like. I have no idea what the environments that they have trusted look like, et cetera, et cetera, et cetera. So we're making efforts to get some more insight into what these foreign environments may look like. Beyond that, what we're more immediately looking at uh shipping this year is the connections that uh emerge from you know joining an on-prem active directory uh asset up into azure or up into intra id and vice versa um so these kind of like what i refer to as like a change of venue attack path where I'm going from one platform to another, to another, to another.

That's a big opportunity for us. I can't wait till some bad OAuth configuration lets you go from cloud to code exec on a domain controller. You know, like that's, it's so coming. We've seen it. I mean, it's here. Yeah, right. Okay. Yeah.

It's here. Yeah. There are in tune app rolls. So anyway, Andy Robbins, uh, thank you so much for joining us to walk us through all of that. Uh,

cause it's really great to get a comprehensive view on it. It's an important topic. Uh, and I appreciate your time. Thank you very much. It's been my pleasure. That was Andy Robbins there from Specter Ops. Big thanks to him for that.

And that is it for today's Soapbox. I do hope you enjoyed it. I'll be back in a couple of days with a regular edition of the weekly show. But until then, I've been Patrick Gray. Thanks for listening.