Incident Response in Microsoft Entra ID (formerly Azure AD)

Compromised user account edition.

So in this blog I will be testing and validating certain incident response actions in regards to a compromised user account scenario within Microsoft Entra ID.

The scenario and scope will be:

• Compromised user account;
• MFA enabled;
• Microsoft Entra ID tenant (formerly Azure AD);
• All manual response actions, automation for now is out of scope.
  
  

Why ?

Identity-based attacks are a top risk for organizations, numerous threat and incident reports highlight that adversaries appear to focus even more on stolen credentials via initial-access-broker (IAB) services identified in the criminal underground. Most initial access sales involve credentials purchased through dark web forums and marketplaces and may contain usernames, passwords, session cookies and security tokens.

It is therefore very likely that security teams will eventually deal with stolen credentials and compromised user accounts, so having clear and validated response procedures are essential.

NIST Incident Response framework

The response actions in this blogpost, in regards to the NIST IR framework, fall under Containment, Eradication and Recovery. The framework combines these into a single step for recovering from and mitigating cybersecurity incidents.

Testing & Validating

Looking at above framework, one of the Containment & Eradication goals would be that of preventing the incident from spreading, yet more technical actions are not always validated or tested, leaving room for assumptions. On the topic of an account compromise, I have spoken with people in the past across things like: “should an account disable and password reset be enough” ? Or “what happens with an access token when a user account gets re-enabled” ? And “what about the lifetime of security tokens, when a password reset is performed” ?

So imagine yourself, during a cyber incident, after certain response actions have been taken — are you, as a defender, truly confident that the response actions worked as expected, or does some doubt remain ?

Well, in this blog I aim to test and validate both the above and additional questions. Let’s draw a comparison to Mythbusters, in the sense that we’re aiming to take away any myths or assumptions.

 
#Scenario

During a weekend shift a security analyst observed a user with multiple risky sign-ins and was labeled as a “Risky user” within the corporate Tenant.

What and why is a user at risk?

A user becomes a risky user within Microsoft Entra ID when:

• They have one or more risky sign-ins;
• They have one or more risks detected on their account.
  
  

After initial triage by the analyst the user account appears compromised, in order to mitigate the risk — as soon as possible — let’s follow Microsoft’s documentation on how to investigate risk in Microsoft Entra ID protection:

How To: Investigate risk in Microsoft Entra ID

So the advised response actions from above documentation that I want to test and verify are:

• Reset password — This action revokes user’s current sessions.
• Block user — This action blocks a user from signing in if attacker has access to a password or ability to perform MFA.
  
  

Investigation and risk remediation framework — Microsoft

Entra ID Risky user view

Since beforehand you don’t always know what kind of access the attacker has, I will test above response actions together with the following credential access combinations. This way every response action will have multiple validation factors:

• Username + Password + MFA credentials;
• Access token;
• Refresh token.

If you’d like to read a bit more on Access & Refresh tokens, check out my previous blog:

Azure & Entra ID token manipulation
  

Action 1: Reset password

Assumption: This action will revoke user’s current sessions.

Performing the password reset

From the moment the action is processed by Azure (took ±50 seconds) as shown in the audit logs section the attacker is not able to open any new login session, as expected, good. But does this kill all current sessions as described in the documentation ?

Printscreen of Audit logs when the password reset is processed

I indeed get an error when trying to fetch resources from within the Azure/M365 portal. So the password reset action really does revoke current sessions.. it seems..

Two errors popping up in the Azure portal GUI

Amazing, there also is an error code to look into: AADSTS160021, although the description seems a bit over the top.

AADSTS160021: AppSessionSelectionInvalidSessionNotExist — Application requested a user session that doesn’t exist. This issue can be resolved by creating a new Azure account.

Now let’s have a look at what happens to security tokens, I’ve got tokens for both API endpoints still supported by Microsoft. There is the most current and actively developed API called the Microsoft Graph API, but there also still is the Azure AD Graph API.

Fun fact.. it took 8:47 minutes for my Access token for the Microsoft Graph API to get revoked. But again, yes, so far it does seem the action revokes current sessions:

Postman view: 401 Unauthorized

What about access to legacy API endpoints ?

Well.. The Azure AD Graph API security tokens stay alive.. That’s a fun finding. This means if an attacker obtained AAD Graph API tokens (s)he can continue to explore the environment by running tools like AAD Internals, ROADtools, query the tenant manually with HTTP requests, try to escalate privileges, you name it. All by interacting with the AAD Graph API, without anyone noticing it.

For example, with the following GET request you’re able to fetch all users in a tenant (dependent on token permissions):

GET https://graph.windows.net/"tenant_ID"/users?api-version=1.6
Host: graph.windows.net
Authorization: Bearer "access_token_value"
Content-Type: application/json

Alrighty, very interesting stuff and if you ask me, crucial to be aware of.

So Microsoft’s documentation is correct by stating that by performing the password reset action from the risky users view, it revokes sessions. For the most part..

Except if an attacker has access via a legacy API endpoint.

Like the Azure AD Graph API. Check out below docs if you’re interested to read a bit more about this API:

Azure AD Graph API reference

 
FYI

The thing with legacy or deprecated APIs is that they eventually.. retire.

Azure AD Graph will be fully retired after June 30, 2025, and no API requests will function at this point, regardless of the application’s configuration.

 
Action 2: Block user ⛔

Assumption: This action blocks a user from signing in if attacker has access to a password or ability to perform MFA.

Let’s continue where we left off.. what if we now block the same victim user account. The account should not be able to perform any querying or authentication right?

And that’s correct, the account is disabled and i now also lose my AAD Graph API access and any ability to perform authentication:

OK, so the security team responded by resetting the password, blocking/disabling the user account and thereby killing the ability to perform any authentication. The victim later receives his/her new set of credentials and gets re-enabled.

What about after re-enabling the account ? What happens then..

Tokens for the AAD Graph API get re-enabled with it, both Access and Refresh tokens can be utilized to enable persistence. This is where security and IT teams should be cautious since it’s dangerous to think you eradicated a threat while it’s not fully remediated and the cycle may start again..

 
Revoking sessions explicitly

So in order to respond to these incidents effectively, security teams and IT teams can revoke user sessions from the Azure or Entra ID portal:

And this also kills my AAD graph API session:

But.. what about refresh tokens ? Do these get killed by revoking sessions ?

Yes they indeed do.

It’s also possible to make use of the Microsoft Graph API to revoke sessions programmatically with the correct permissions, check out:

revokeSignInSessions

 
What have we tested and validated ?

When responding to a compromised user account, the reset password action as described in Microsoft’s Entra ID protection documentation appears to indeed revoke sessions.. except when it doesn’t entirely. The initial response actions should therefore be followed by the Revoke Sessions action in the Azure, Entra ID portal or programmatically.

What about automating response actions ? Well, that’s for another time.

And there is more to responding to a compromised user account incident, like investigating e-mail forwarding/inbox rules, app consent, additional account anomalies and more fun stuff. Any organization should develop their own Incident response playbooks but teams at Microsoft have developed a few as well. Refer to the resources below.

And of course, you test and validate described procedures in place

Microsoft learn: Incident response overview

Microsoft learn: Incident response playbooks

Microsoft learn: Responding to a Compromised Email Account

 
 
Thanks for making it this far !

Subscribe