Video Transcript

Welcome, everyone. I'm glad that you were able to join the the session. Indeed, it's a follow-up from a session I did at RSAC talking about, you know, chasing ghosts, indeed, in the Microsoft cloud. Just for those of you that haven't seen my presentation yet, the, the full one, which I would recommend anyone to, to go and and watch, it's it's basically...

It it was started with, you know, this observation, across all my years in instant response that identity was one of those topics that really isn't well understood by the majority of people that are working in incident response even in security operation centers. And when they're responding to certain incidents and containing even eradicating identities, they're not always fully aware of, you know, the consequences of, you know, when they trigger these actions, what actions to trigger, and when do we consider, you know, an identity to be fully remediated. Yeah. And so this was kind of the idea, on starting the talk.

And so I wanted to share some awareness on the shenanigans that happened in, you know, intra idea in the Microsoft clouds when, you know, adversaries are more and more, you know, trying to steal what happens after authentication and not before the authentication. So this is what the focus was of the talk. And so for today, you know, I could talk about this for hours and hours, but I only have 15, and then there's a fifteen minute q and a. So I'll try to keep it short and concise.

But if you have any questions, keep them for the q and a, and then we'll we'll try to answer them as quickly as possible. So, know, disclaimer, obviously. Right? So as you, know that this is all, educational purposes and so on, I'll let you read all of this yourself.

The presentation will be shared later. Maybe one already massive update since the last time that I presented since, you know, my presentation on RSAC was the pass keys are not becoming a default thing in Intro ID. So beginning of September of this year, this means that the pass keys will be the default authentication experience. Yes?

So that means that is the the the the first option, I would say, that the majority of your users will get. Obviously, we can control this in our tenants. But this also means that it's replacing the old SMS and voice multifactor authentication options that we have in Entry ID. Now don't worry, SMS and voice, we shouldn't be using those anymore.

If you're still using it, it's not really disappearing. It's just that Microsoft, will stop offering the services themselves. So as you know, Microsoft is actually also a telecom provider, because they're sending SMS and these voice authentication calls from their own, yeah, well, gateways. Yeah.

And so they're gonna stop that service. So you can still do SMS and voice as of...

Think it will be February next year that they will completely retire it. But you can still use it, but you will need to use a third party voice provider or telecommunication provider to do this. Regardless, just so you're aware, pass keys, yeah, for those of you that are not completely in the know, these are... It's a replacement for passwords, but then using a device like, you know, a phone or using your your computer or using a certain hardware device like a password key.

And so those things are a lot better than the old multifactor authentication mechanisms we used because of one little thing, and it's that those pass keys are actually phishing resistant. Phishing resistant means that they cannot be leveraged anymore unknowingly by users, submitting their credentials to a fake, web app...

Or web application. And so this is a lot of adversaries were doing nowadays and in the past, trying to do an adversary in the middle type of attack where they're tricking a user to go to fake login page, you know the rest. Yeah. The user submits a password and so on.

And what they're really after is not really password or even the passwordless authentication. It's what IntraID sends the client afterwards, which are these tokens. And so with passkeys, passkeys can only be used against the registered site. So only if it is the valid site, the valid URL, it can be used against it.

So even users...

Even if they would want to submit their passwords to a, yeah, let's say, a a fake website, it wouldn't work because of the fact that, you know, it was...

There's no associated passkey towards it. So this is a really cool thing, and I'm happy that Microsoft is is kind of pushing this, more and more forward. We'll talk about this a bit more in detail coming up. But...

That's already a big change. Now one thing that we identified during, my talk was that, you know, the logging itself, which we have been getting much better at at protecting, is just the start of this identity space. Yeah. So it's authentication and authorization.

Authentication happens first.

An important distinction that I made during my presentation was the difference between password and password less. Yeah. So, password is literally a password in typing that in. Password less means any other authentication that doesn't require a password, like using a passkey, for example.

Now there's a big difference here on password and password less, and I'll I'll get to this in a minute. But so you authenticate. It's all successful, hazard, hazard plus multifactor authentication, and then, IntraID will basically issue these tokens. Now I will not get into the full review of those tokens because we don't have the time.

And if you want to, you can, watch my talk when I go extensively into this. But enter ID issue with certain tokens. So access tokens, refresh tokens, primary refresh tokens. In a nutshell, access tokens is what gets you access to a certain resource, let's say, Microsoft Graph API or something else, Outlook teams.

Refresh tokens is what is being used to request new access tokens for other resources. So an access token only is limited in time, typically between sixty and ninety minutes. If it expires, I need a refresh token to request a new access token or an access token for an other resource. They're scoped to a single resource.

Yeah? And then the last type of token is a primary refresh token, which is cryptographically bound to a specific device. We'll we'll get to this in a minute. But this is a really interesting type of token because it is trusted a bit more by Intra than the other ones.

And so the client, once they have these tokens, they will then use the access token that is scoped for the resource, like the graph API or Teams or SharePoint or whatever it is that they want to access using this access token. Right? Now the thing is, it's not because it was a secure sign in. It's not because you have, you know, the best passwordless implementation and the most secured multifactor authentication in the world that adversaries can't, you know, steal what happens after authentication, what happens after multifactor authentication, and that's what those tokens are about. So the whole point is it's not because there was a secure sign in that we should trust the session and and that session that cannot be stolen again.

So we had established just before that there is a difference between passwords based and non password based authentication. And so one of the differences here is that this actually carries over in your in your tokens. It's the access tokens I talked about. One of the claims in the tokens is basically whether this was password or password less, so nonpassword based.

And then you would actually have a difference here. Let me see if I can get my pointer up. So you have a password based token and a non password based token. Yeah?

And so with the password based token, if you do a password resets, you'll see that in the majority of the cases, it gets revoked, it gets revoked, it gets revoked. If you do a password reset for a nonhazard based token, yeah, this...

We're talking about the the refresh tokens here just to be a 100% technically correct.

So this means that actually, depending on where you are resetting the user's password, which can happen on three different levels, by the way, in the Azure portal, in the app...

Enter admin center, or the Microsoft three sixty five admin center, you'll see that there's a difference. The last two, it's revoked. And the first one, it stays alive, which, you know, is kinda like, But but why? It doesn't make any sense Microsoft that, you know, depending on where you would reset the password, that would be a different outcome.

It doesn't make any sense whatsoever. What's worse is that based on our testing, in a lot of the cases when the documentation of Microsoft says it's revoked, it wasn't always revoked. Oops. So this is why in the talk we talked about just the password reset alone is not enough.

Meaning, you also need to do a revoke sessions. Right? So this...

The majority of you are probably doing this, but there is an...

A compromised identity. Reset passwords, revoke sessions. Because what this does is this ensures that the refresh token is no longer valid. Yeah?

And so this means that the adversity can no longer use that refresh token. We know for a 100% sure this works well. Based on our testing as well, this works. Password reset alone is just, not enough.

Yeah. The problem is it doesn't stop here because a lot of the, secure...

A lot of the standard operating procedures that I know and all of security operations centers are exactly this, compromised identity or suspected compromised identity. We're gonna reset the password. We're going to revoke the sessions, and that's it, I guess.

Well, the problem is there could be more, and this is what I want to talk about a bit more today, which wasn't fully covered in my RSAC talk yet. And so an incident that has happened and was report... Well, we know these incidents, but it was reported by Huntress not that very long ago, was the following. So there was a, you know, stolen session. So, basically, those tokens were stolen by using device code phishing.

We're not gonna get too much into the details on device code phishing, but it is a...

But it's an authentication flow for devices that do not have an interactive keyboard thing. So think about, like, these little screens you have in your meeting groups. Yeah? They they typically have an an intra ID authentication and so on.

But, you know, how do I log in on those things? Because there's no keyboard. This is a flow that was created by Microsoft for those type of things. It's called device code.

And the way it works, super easy, I go to a specific URL from Microsoft that will show me a code. And then basically, I need to enter this code in another session, and by supplying this code and authenticating, the first device that requested the code now basically has...

Is giving...

Is is now authenticated towards an intro ID. Now I see that...

I said here that passkeys do not stop this. It is because of the fact that, yeah, passkeys, as we know, authentic...

Can only authenticate against the the correct URL. Well, in device code flow, you're authenticating against the real Microsoft URL. So it doesn't stop here even if users aren't using passkeys. So it's a very important flow that we should be controlling as much as possible.

There are some controls. We can discuss this in the q and a if you want to. But...

In this incident, two device code phishing, those tokens were stolen, which then the adversary went to the next step. They enrolled a new device, their own device for this user, into Entra ID, and they created a new Windows Hello for Business. This WHFB, Windows Hello for Business key, which actually gave them a, a phishing resistance, password less authentication methods, which can then be leveraged to, circumvent some of your, conditional access policies. So this is a really interesting, incident, and I'm just wanna...

And the the next few minutes, just wanna go through this, quickly, because, again, I know that we only have a limited time. But so this was in the September 2, and this was reported by Huntress. It's a really interesting read. I have the link here, in the slides, so you can, you can go and read all of this.

But...

The way this works would be the following. So let's say the adversity now has these access token refresh token and so on. What they will try to do is they want to generate a primary refresh token, that last token I talked about, which is bound to the device, which is basically more trusted because, you know, it's bound to the...

A specific device, and it can request tokens for any type of resource. And more importantly, more and more, we're using device based conditional access policies. Only registered devices can access certain SharePoint sites, let's say. Yeah?

So in this scenario, the other city would use a stolen session to request a new device object to enter, and they don't need any specific permissions for this. They can basically just request it because the majority of tenants out there allow users to, well, enroll their own devices. So they can enroll up to 50 devices towards their...

Towards Entra for a specific user. Entra will then create identity and... So device identity and returns that device ID with that certificate to the attacker. And then the attacker will use that stolen session plus the device object to then request primary refresh tokens, which then can be leveraged later on. So this is problem number one, which, by the way, shows up in the intra audit logs event as an app device. This is the first thing that we would want to detect.

The second thing then then then that happens is Windows Hello for Business. And, basically, Windows Hello for Business is the... Majority of organizations are using this today. It is the most practical implementation of phishing resistant authentication. It's basically a passkey, yeah, but using your own computer as the passkey.

And so this negates password. You just log in with biometrics or with the PIN codes, and this is phishing resistant authentication. So again, once the adversary has a device object, they register Windows Hello for Business, which then, if they authenticate now, once this is registered with Windows Hello for Business, they could then pass through some of the conditional access policies you've put in place on, I'm gonna require phishing resistant authentication to access certain websites or certain resources like SharePoints, which, you know, then allows them to access this. We can actually see this if Windows Hello for Business has been registered in the intra audit logs, again, as an at Windows Hello for Business credential.

Again, a very high value event that we should be checking. I talked about response procedures as well. This is from my RSAC talk where, you know, an active directory and intro ID, there's a couple of things we need to do. There's one addition that I want to talk about, and then we'll go into the q and a.

It's basically...

I set disable the user revoke. We refresh token, so basically, evoke sessions. And then I said disable the user's device, and this has to do with what I just talked about. Right?

So we need to be able to stop the, use of those rogue devices and, associated primary refresh token. So we're gonna delete and disable those rogue device identities. This is really often forgotten. I haven't seen that many organizations actually check this after an identity has been compromised.

And the second thing is we then need to delete all of the attacker added authentication methods like Windows for Business to make sure that they cannot leverage this anymore. And then as a last part, just so you know, Microsoft released a new intro role, intro ID role called SOC identity responder, which scopes, the permissions for a SOC analyst to be able to reset credentials without needing to grant an overly broad identity, permissions.