Incident Response Foundations – Identity

Andrew Posted on 7:12 am

Incident Response Foundations – Identity

In today’s post I talk about responding to a compromised identity in Microsoft Entra ID. There is a lot of advice floating around on what to do and how to respond; I’m bringing experiences and existing guidelines together to provide a solid foundational starting point for identity based incident response in this post.

This post is written somewhat ‘informally’ in it’s format to allow you to easily copy the content into your own formats needed so that you can expand on the points throughout.

Let’s jump right in! There are 5 steps used to build incident response foundations:

  1. Identify
  2. Contain
  3. Remove the threat
  4. Recover
  5. Follow-up

Each of these steps has a number of sub-processes that can be added in to make this recipe your own; and you should make this your own!

I’ll begin by walking through each of these steps, and I would encourage you to consider that this is a foundations post….not a ‘one stop shop’ that has every single detail you’ll ever need for identity incident response. Your organization likely has specific systems, integrations, and maybe even custom solutions that will require specific response steps to be added (or removed) from this post.

Something that many organizations wait to develop is an incident response SOP or standard operating procedure. Why wait? For the remainder of this post, I will approach this with the mindset that we are getting prepared in advance; and that you will review this with your team, make changes and additions, and make this your own starting point.

1. Identify

If an identity has been flagged as compromised, has a high confidence flag for compromise, or a user reports their identity is having indicators of compromise (My password is different and I didn’t set it, logins from unknown places, etc); then lock the user account and clear all active sessions currently logged in. This is the first step.

This response measure is often described as ‘shoot first and ask questions later’. I prefer to think of this as ‘minimize risk and investigate now’. Next, begin identifying more information about what may have happened:

  • Identify the problem & begin exploring logs.
  • Look at least through the following logs:
    • Azure AD / Microsoft Entra ID
    • Endpoints logs such as Windows security logs
    • Endpoint protection logs such as firewall and XDR when available
    • Look for other identities used on the same IP addresses and endpoints
      • Consider if one identity is compromised via an endpoint that other identities on the same endpoint are likely to be targeted or compromised as well
      • Look for the same IP address being used for multiple other identities using the same baseline
    • Look for traffic patterns that don’t belong such as going to unusual systems or geo locations

Gain an understanding of the problem and the scope of the compromise.

Begin making a list of the identities and systems that those identities touched, this will help with the next steps when stopping the spread, and removing the threat.

2. Contain

If not done already, lock the user account, reset the password and thank your user for letting the team know about a potential problem!

Seriously, thank your user. It is critical that you do not blame your user or users, and that you support everyone involved. Remember what we learned at a young age here “Treat others how you would like to be treated”. I think this is very under-rated today and we can all put in the effort to just say ‘thank you’. Enough said.

Next, consider any systems that have been logged into from the impacted identities.

  • Lock the user account, reset the password, clear all active sessions from Microsoft Entra ID or other identity systems.
  • Through examination of your traffic and sign-in logs, identify any other systems the identities have touched.
  • Lock down-stream system identities:
    • CRM and sales systems
    • Private messaging systems
    • Any non-federated / non single sign-on systems that may use a repeated password*
    • VPNs and other connectivity tools

Ensure that you isolate the threat and evaluate those logs for commonalities.

Look in the log data for correlated events that may not appear to be a compromise right away:

  • The same computer or IP address used to try and elevate permissions
  • Software was installed locally or on a server > identify that software!
  • Emails sent from the account since the compromise time-period began should be evaluated via e-discovery or other review mechanism.

E-Discovery Side Trip

Here are some follow-up links on assigning the e-discovery roles in Microsoft Entra ID, and on completing an e-discovery in M365 portal:

  1. Assigning the roles:
    1. https://learn.microsoft.com/en-us/purview/ediscovery-assign-permissions
  2. Doing an e-discovery:
    1. The bigger picture: https://learn.microsoft.com/en-us/purview/ediscovery
    2. Getting Started: https://learn.microsoft.com/en-us/purview/ediscovery-standard-get-started
    3. Create an e-discovery case: https://learn.microsoft.com/en-us/purview/ediscovery-standard-get-started#step-4-create-a-ediscovery-standard-case

There is some licensing requirements listed in the documentation for you above and hopefully that will fit in with what you currently have already in place. Take a look at the license breakdown specifically here.

3. Remove the threat

Once you have identified all of the involved identities and systems, it is critical to remove the threat and reduce the risks now.

I prefer to re-run my KQL queries at this stage to confirm that there is no new information or entries within the logs already examined for our evidence.

Things to do for our identities:

  • Reset the password on each account and monitor the sign-in logs for any login attempts.
    • Investigate each unexpected logged attempt as an individual incident to ensure integrity of each account
  • Validate strong MFA is used such as Microsoft Authenticator or a FIDO2 key
  • If SMS is used for verification/MFA codes, disable it!
    • SIM Swap compromise may be in play. Confirm SIM swap is not an issue through your existing process and providers.
    • Strongly consider removing SMS capability for MFA in your environment.
      • Consider that some specific use cases for industrial, field workers or other identity use cases may be using flip phones or simply not capable of using Microsoft Authenticator.
      • In those cases, exceptions may have to be made, or use phone calls, but again a FID02 key would be preferable.
      • Use well configured conditional access with a security group to allow an exception for SMS usage in your cloud environment.

4. Recover

Prior to re-enabling identities, I prefer to place additional monitoring rules using Microsoft Sentinel to closely watch the impacted accounts.

  1. I use my investigation KQL to build statements that capture the impacted account sign-ins, look closely at location and IP, and frequency of logins.
  2. When I create new Analytics rules for this, I also set a calendar reminder to come back after a couple of weeks and clean them up as this is a temporary measure for peace of mind, not a permanent solution. See the Follow-up section in this post to read more about how to improve security posture as part of post-incident procedures to bring yourself more restful nights!

Once you and your team are satisfied that there is no longer a threat present, and the identity has been cleaned up, and you have your additional alerting in place:

  • Validate each identity is properly protected and then re-enable the accounts one at a time.
  • Place additional monitoring rules such as Azure Monitor or Analytics Rules in Sentinel.
  • Set a reminder in your team calendar to come back and clean-up those extra alerting rules. They are temporary to automatically add granular monitoring on top of those impacted identities, not a solution to the problem.

5. Follow-up

Now that your users are back to work, the dust is starting to settle.

Let’s think about how we can improve our security posture and reduce our risk to help prevent this from happening again.

There are 2 main things that I’ve seen over and over:

  1. MFA was not enabled, had an exception, or just not turned on at all; and
  2. The user behind the identity did not have preventative education such as:
    • Phishing prevention education
    • Identity compromise education
    • Malware prevention education
    • Information security education

See a common factor here? Education and MFA folks! Let’s dive into some deeper details on how we can really improve our security posture together:

Where to Start with Improvements to Security Identity?

There are a number of quick-wins that should be explored to help secure identities in a cloud environment. Let’s begin with the core 5 tasks and build out some additional steps to help secure the environment going forwards:

  • Strengthen credentials
    • MFA, MFA, and also MFA
    • Configure lockout thresholds
    • Use password ban lists
    • Use password hash sync if you are using Entra ID Connect (Azure AD Connect in it’s past life)
    • Educate your administrators and users for the strongest type of phishing defense
  • Reduce the attack surface area
    • Could we mention MFA here too? Yes, MFA again is on the list!
    • Consider passwordless authentication
    • FIDO keys, Microsoft Authenticator App
    • Block legacy authentication
    • Use Conditional Access policies to restrict login locations, types, devices, networks, and more.
    • Use Entra PIM to only activate elevated roles when actually needed
    • Ensure your admin team is using ‘admin usernames’ only to perform approved tasks. Restrict email to only the absolutely required admins when required.
  • Automate threat response
    • Use Identity Protection
    • Configure Sign-in risk policy to force MFA or block
    • Utilize user risk policy to force password changes on users with confirmed high-risk signals. This policy can force MFA and have the user reset their own password with no additional helpdesk calls.
    • Integrate your security logs from Microsoft Defender XDR and Entra ID: correlate threats using logs from Office 365, Defender for Identity, Defender for Cloud Apps, and Defender for Endpoint.
    • Use Microsoft Sentinel SIEM/SOAR to create incidents automatically for suspicious identity behaviours.
      • Pro Tip: Build playbooks and automations to respond to these events automatically!
  • Utilize cloud intelligence
    • Log into the Entra ID Dashboard and observe the events and alerts.
    • Take advantage of recommendations and Secure Score fixes
    • Utilize CoPilot automatic fixes to speed your work along!
    • Monitor your hybrid environments via Microsoft Entra Connect Health agent
    • Review the Risky sign-in AND Risky users reports
    • Audit app consent and permissions in your environment
  • Enable end-user self-service
    • Use self service password reset
    • Use Microsoft Entra access reviews
    • Automate provisioning and de-provisioning process as much as possible in your organization

Have I mentioned MFA? Protect all privileged accounts with MFA. If you are not using Conditional Access policies to protect privileged roles, my only question is why not!

According to Microsoft: In Microsoft Entra we observe 50 million password attacks daily, yet only 20% of users and 30% of global admins are using strong authentications such as multifactor authentication (MFA). These statistics are based on data as of August 2021. In Microsoft Entra ID, users who have privileged roles, such as administrators, are the root of trust to build and manage the rest of the environment. Implement the following practices to minimize the effects of a compromise.

Protect the core privileged roles:

  • Global Administrator
  • Application Administrator
  • Authentication Administrator
  • Billing Administrator
  • Cloud Application Administrator
  • Conditional Access Administrator
  • Exchange Administrator
  • Helpdesk Administrator
  • Password Administrator
  • Privileged Authentication Administrator
  • Privileged Role Administrator
  • Security Administrator
  • SharePoint Administrator
  • User Administrator

Remember to add exclusions for your:

  • Break Glass / emergency access accounts
  • Service accounts
  • Service Principals
  • Your own admin user while testing the policy

Every best practice guide and all Microsoft documentation have told us for many years to enable MFA on accounts that hold, or can be elevated to hold, any privileged role. Need to know how to deploy this policy? Check it out right here: https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-admin-mfa. Please go and enable the template in Conditional Access for Privileged Role Access and MFA. I’ll wait here….

CLOSING

Remember that responding to an identity event is a very dynamic situation. Take all indicators and reports of compromise seriously, investigate, and respond accordingly. There are often no easy answers when it comes to the ‘how-to’ of incident response; so work together with your team, enjoy the benefits of everyone’s experiences, and always be open to asking your peers for support.

Good luck with your future investigations & hardening activities! Thanks again for joining me on the adventures of SecOps and SOC teams across the globe, I’m having a great time sharing my experiences with every one of you!

Additional Sources:
https://learn.microsoft.com/en-Us/azure/security/fundamentals/recover-from-identity-compromise
https://learn.microsoft.com/en-us/azure/security/fundamentals/ransomware-detect-respond
https://learn.microsoft.com/en-us/azure/security/fundamentals/steps-secure-identity