D
DenizSezer
You're in the middle of a cyber incident, and you know certain accounts have been compromised, but you are not certain of the full extent of the Threat Actor’s impact. What do you do? Oftentimes, Microsoft Incident Response will recommend a mass password reset. This helps you regain control of your identity plane, deny other avenues of access, and disrupt any persistence the attacker may have established in your environment. However, and especially for larger organizations, navigating mass password resets can be a complex task. In this blog post, we'll discuss the practical challenges of performing a mass password reset, how to prepare to carry one out, and best practices in performing them.
A mass password reset is not always required, but it is important to identify the circumstances under which it is. Some considerations for when a mass password reset is the best course of action include:
Almost all organizations have remote users: many have hybrid users, and some have entirely remote workforces. This means that every organization has unique requirements and considerations for when a mass password reset is required. In this section, we will consider some of those requirements and how organizations can best prepare and respond if the need arises. Scenarios to consider include:
This scenario is the least complicated one: if all users are primarily onsite with line of sight to a domain controller, then a simple flag on every user account to require the user to change password at next logon can be used to enforce the password change. Users can be given a deadline and informed they are required to change their passwords by the deadline, and, if they fail to do so, their accounts will be disabled. Several PowerShell scripts are available online that allow for enumeration of users in specific organizational units (OUs) and manipulating the “User must change password at next logon” flag to facilitate a gradual password reset rollout so an organization’s helpdesk is not inundated. When the users arrive in the office and attempt to log on, a message will prompt them to change their passwords.
Gradual, but expedited expiration of passwords using Fine Grained Password Policies (FGPP) and the progressive reduction of password age through domain policy modifications offer alternative methods for enforcing a mass password reset for domain users. However, a significant drawback to this approach is the potential for a threat actor to remain within an authenticated session until a logon event triggers the password reset. When considering this method, it's important to balance the urgency of credential changes with the need to provide users with a grace period. Since many organizations have a portion of their workforce operating remotely, this strategy is often employed as part of a broader series of steps designed to secure all user accounts across various scenarios.
This scenario is more common when most users are primarily remote, or there is a mix of remote and onsite users. In this scenario, users rely on authentication mechanisms separate from their domain password; for example, certificate-based authentication. Once the users are authenticated using the VPN solution, they can be treated like the previous scenario since they will have line of sight to a domain controller.
An important consideration for remote users is whether you will execute an administratively managed password reset (which is where an admin resets credentials for users and relies on users to use self-service password reset (SSPR) to regain access) or allow users to change their credentials gracefully on their own.
This scenario becomes more challenging when the VPN solution relies on the domain password as one (or the primary) factor for authentication and the VPN solution does not support a password reset during the sign-in flow. In such a scenario, if the organization has been set up for SSPR before the incident occurs, it makes the password reset process much easier to handle. If an organization does not have SSPR capabilities, a mass password reset will require some manual intervention. This could take the form of users having to call in to the help desk or attend a centralized location that has been set up for this purpose, provide verification of their identity over voice, video, or in person, and then have their password manually reset.
Alternatively, for VPN solutions that do not support a password reset during the authentication flow, you may wish to consider migrating the authentication source of your VPN solution to Microsoft Entra ID either temporarily to allow the session to be interrupted with a password reset, or permanently to gain the benefit of additional Microsoft Entra ID features like Conditional Access policies.
With hybrid identities, an organization’s identities (users and computers) are already synchronized to Microsoft Entra ID. In this scenario, line of sight to a domain controller is not a requirement to orchestrate a mass password reset. Microsoft Entra ID supports flagging users to reset their credentials at next sign-in, similar to on-premises Active Directory.
Admins can use Microsoft Graph to set the user attribute either to "forceChangePasswordNextSignIn" or "forceChangePasswordNextSignInWithMfa" on the desired users to interrupt their next sign-in and allow them to change their password gracefully. If the password writeback feature is enabled in Microsoft Entra ID and the organization’s users are enabled for SSPR, then a password reset via either the MyAccount portal or SSPR portal will ensure that the newly reset password is synchronized back on-premises. If password writeback and SSPR are already enabled, this is the scenario with the fastest route to threat actor removal and least amount of manual work. There are some scenarios where an organization may not want to use SSPR, which we will discuss later in this post.
Service accounts with their never-expiring passwords and traditionally overprivileged nature tend to be the bane of any Active Directory administrator’s existence. This is particularly problematic when a mass password reset must be performed and little-to-no inventory exists that maps applications to service accounts. An effort should be made to inventory all service accounts and their associated services and applications. Where possible, service accounts should be migrated to Group Managed Service Accounts (gMSA). This has the dual advantage of making service accounts more manageable and removing the manual overhead associated with service accounts. This is also a great opportunity to “right size” the service accounts that tend to be traditionally overprivileged.
All privileged cloud accounts should have phishing-resistant MFA enforced. Also, it is strongly advised to use Just in Time (JIT) administration methods, for example Microsoft Entra ID Privileged Identity Management (PIM). In addition, there should exist a clear separation of on-premises and cloud administration with separate identities for each realm. Identities belonging to the privileged on-premises AD DS groups should not be synchronized to Microsoft Entra ID. Conversely, all privileged cloud roles should be held by cloud native identities and must not be synchronized from AD DS. Most organizations will choose to manually reset any privileged credentials for a high level of assurance and control. It is important to verify when passwords were reset with PowerShell or Microsoft Graph; otherwise, it is very likely that some accounts may be missed.
As we’ve detailed, there are several different scenarios that necessitate a mass password reset. This means that there are different levels of control or assurance an organization might require while performing a mass password reset. When SSPR mechanisms can be reliably used to provide assurance, organizations can use that feature to accelerate a mass password reset.
However, there are situations where an organization may not want to use the existing SSPR solution. For example, when an advanced threat actor has abused the organization’s SSPR system, or where there is actual evidence of AD DS database exfiltration. In such a scenario the organization would likely not choose to use that mechanism to enforce the mass password reset because the threat actor could re-establish initial access or persistence via SSPR.
Where an organization seeks a high degree of control and assurance for a mass password reset there will, unfortunately, be an element of manual intervention. However, with preparedness ahead of time, Microsoft Entra ID features such as a Temporary Access Pass, when combined with Conditional Access policies, can be used to automate some aspects of assurance and control. In any event where a high degree of assurance and control is desired, some level of manual intervention to verify users’ physical identities and the issuance of such temporary access passes is inevitable. In a subsequent post we will examine different Microsoft Entra ID features that can be used to accomplish this.
There are several variables and considerations for a mass password reset, and there is no one-size-fits-all solution. However, we can, with adequate preparedness, make this process less onerous and more manageable for organizations.
We recommend exploring other blogs from Microsoft Incident Response for expert guidance and tailored solutions to improve your incident response capabilities. Additionally, consider the benefits of Microsoft Entra ID for advanced identity and access management, which can strengthen your defenses against identity-related breaches.
Continue reading...
Identifying the need for a mass password reset
A mass password reset is not always required, but it is important to identify the circumstances under which it is. Some considerations for when a mass password reset is the best course of action include:
- Active Directory database exfiltration: When there is evidence of Active Directory Domain Services (AD DS) database exfiltration by a suspected threat actor.
- Active Directory database staging: When there is evidence of AD DS database staging with intent to exfiltrate by a suspected threat actor.
- Compromised privileged identities: When a threat actor has compromised credentials belonging to one or more privileged groups such as Domain Admins, Enterprise Admins, or built-in Administrators.
- Attacker-in-the-Middle: When there is evidence of an Attacker-in-the-Middle (AiTM) attack or other threat-actor-introduced proxy services which may have gathered user credentials.
- Cloud or third-party identity platform compromise: When there is evidence of a compromise on an authoritative Identify platform such as Microsoft Entra Connect, AD FS, RADIUS (Remote Authentication Dial In User Service) Servers, or 3rd party identity solutions.
- Ransomware deployment: When a threat actor has been able to successfully deploy ransomware by compromising accounts belonging to privileged Active Directory (AD) groups.
- Privileged credentials exposed in Business Email Compromise (BEC): When a BEC has exposed privileged credentials in emails.
- Privileged credentials exposed in exfiltrated data: When data exfiltrated from productivity and collaboration tools (such as OneDrive or SharePoint) has exposed privileged credentials.
- Privileged credentials exposed in code: When privileged credentials have been exposed in an online code or source control repository.
- Attribution to nation state or Advanced Persistent Threat (APT): When an attack has been attributed to an APT or nation state.
Organizational challenges and scenarios
Almost all organizations have remote users: many have hybrid users, and some have entirely remote workforces. This means that every organization has unique requirements and considerations for when a mass password reset is required. In this section, we will consider some of those requirements and how organizations can best prepare and respond if the need arises. Scenarios to consider include:
- Local users: Users primarily onsite with line of sight to a domain controller.
- Remote users: Users who primarily use VPN (virtual private networks) or have hybrid identities.
- Administrative controls: Whether password resets are driven by administrators or end-users.
- Service account management: Considerations for service accounts, which often have never-expiring passwords.
- Privileged identities: Special considerations for managing privileged cloud and on-premises accounts.
Users onsite with direct access to domain controllers
This scenario is the least complicated one: if all users are primarily onsite with line of sight to a domain controller, then a simple flag on every user account to require the user to change password at next logon can be used to enforce the password change. Users can be given a deadline and informed they are required to change their passwords by the deadline, and, if they fail to do so, their accounts will be disabled. Several PowerShell scripts are available online that allow for enumeration of users in specific organizational units (OUs) and manipulating the “User must change password at next logon” flag to facilitate a gradual password reset rollout so an organization’s helpdesk is not inundated. When the users arrive in the office and attempt to log on, a message will prompt them to change their passwords.
Gradual, but expedited expiration of passwords using Fine Grained Password Policies (FGPP) and the progressive reduction of password age through domain policy modifications offer alternative methods for enforcing a mass password reset for domain users. However, a significant drawback to this approach is the potential for a threat actor to remain within an authenticated session until a logon event triggers the password reset. When considering this method, it's important to balance the urgency of credential changes with the need to provide users with a grace period. Since many organizations have a portion of their workforce operating remotely, this strategy is often employed as part of a broader series of steps designed to secure all user accounts across various scenarios.
Remote users who use VPN to access the environment
This scenario is more common when most users are primarily remote, or there is a mix of remote and onsite users. In this scenario, users rely on authentication mechanisms separate from their domain password; for example, certificate-based authentication. Once the users are authenticated using the VPN solution, they can be treated like the previous scenario since they will have line of sight to a domain controller.
An important consideration for remote users is whether you will execute an administratively managed password reset (which is where an admin resets credentials for users and relies on users to use self-service password reset (SSPR) to regain access) or allow users to change their credentials gracefully on their own.
This scenario becomes more challenging when the VPN solution relies on the domain password as one (or the primary) factor for authentication and the VPN solution does not support a password reset during the sign-in flow. In such a scenario, if the organization has been set up for SSPR before the incident occurs, it makes the password reset process much easier to handle. If an organization does not have SSPR capabilities, a mass password reset will require some manual intervention. This could take the form of users having to call in to the help desk or attend a centralized location that has been set up for this purpose, provide verification of their identity over voice, video, or in person, and then have their password manually reset.
Alternatively, for VPN solutions that do not support a password reset during the authentication flow, you may wish to consider migrating the authentication source of your VPN solution to Microsoft Entra ID either temporarily to allow the session to be interrupted with a password reset, or permanently to gain the benefit of additional Microsoft Entra ID features like Conditional Access policies.
Users primarily remote with hybrid (on-premises) identities
With hybrid identities, an organization’s identities (users and computers) are already synchronized to Microsoft Entra ID. In this scenario, line of sight to a domain controller is not a requirement to orchestrate a mass password reset. Microsoft Entra ID supports flagging users to reset their credentials at next sign-in, similar to on-premises Active Directory.
Admins can use Microsoft Graph to set the user attribute either to "forceChangePasswordNextSignIn" or "forceChangePasswordNextSignInWithMfa" on the desired users to interrupt their next sign-in and allow them to change their password gracefully. If the password writeback feature is enabled in Microsoft Entra ID and the organization’s users are enabled for SSPR, then a password reset via either the MyAccount portal or SSPR portal will ensure that the newly reset password is synchronized back on-premises. If password writeback and SSPR are already enabled, this is the scenario with the fastest route to threat actor removal and least amount of manual work. There are some scenarios where an organization may not want to use SSPR, which we will discuss later in this post.
Considerations for service accounts
Service accounts with their never-expiring passwords and traditionally overprivileged nature tend to be the bane of any Active Directory administrator’s existence. This is particularly problematic when a mass password reset must be performed and little-to-no inventory exists that maps applications to service accounts. An effort should be made to inventory all service accounts and their associated services and applications. Where possible, service accounts should be migrated to Group Managed Service Accounts (gMSA). This has the dual advantage of making service accounts more manageable and removing the manual overhead associated with service accounts. This is also a great opportunity to “right size” the service accounts that tend to be traditionally overprivileged.
Considerations for privileged identities
All privileged cloud accounts should have phishing-resistant MFA enforced. Also, it is strongly advised to use Just in Time (JIT) administration methods, for example Microsoft Entra ID Privileged Identity Management (PIM). In addition, there should exist a clear separation of on-premises and cloud administration with separate identities for each realm. Identities belonging to the privileged on-premises AD DS groups should not be synchronized to Microsoft Entra ID. Conversely, all privileged cloud roles should be held by cloud native identities and must not be synchronized from AD DS. Most organizations will choose to manually reset any privileged credentials for a high level of assurance and control. It is important to verify when passwords were reset with PowerShell or Microsoft Graph; otherwise, it is very likely that some accounts may be missed.
Assurance and control considerations for a mass password reset
As we’ve detailed, there are several different scenarios that necessitate a mass password reset. This means that there are different levels of control or assurance an organization might require while performing a mass password reset. When SSPR mechanisms can be reliably used to provide assurance, organizations can use that feature to accelerate a mass password reset.
However, there are situations where an organization may not want to use the existing SSPR solution. For example, when an advanced threat actor has abused the organization’s SSPR system, or where there is actual evidence of AD DS database exfiltration. In such a scenario the organization would likely not choose to use that mechanism to enforce the mass password reset because the threat actor could re-establish initial access or persistence via SSPR.
Where an organization seeks a high degree of control and assurance for a mass password reset there will, unfortunately, be an element of manual intervention. However, with preparedness ahead of time, Microsoft Entra ID features such as a Temporary Access Pass, when combined with Conditional Access policies, can be used to automate some aspects of assurance and control. In any event where a high degree of assurance and control is desired, some level of manual intervention to verify users’ physical identities and the issuance of such temporary access passes is inevitable. In a subsequent post we will examine different Microsoft Entra ID features that can be used to accomplish this.
Conclusion and next steps
There are several variables and considerations for a mass password reset, and there is no one-size-fits-all solution. However, we can, with adequate preparedness, make this process less onerous and more manageable for organizations.
We recommend exploring other blogs from Microsoft Incident Response for expert guidance and tailored solutions to improve your incident response capabilities. Additionally, consider the benefits of Microsoft Entra ID for advanced identity and access management, which can strengthen your defenses against identity-related breaches.
Continue reading...