by Contributed | Jun 11, 2024 | Technology
This article is contributed. See the original author and article here.
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.
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.
by Contributed | Jun 10, 2024 | Technology
This article is contributed. See the original author and article here.
The National Institute of Standards and Technology (NIST) published the first version of its Cybersecurity Framework (CSF) in 2014. Ten years later NIST released the second iteration of CSF, entitled NIST CSF 2.0. Microsoft and its partners have supported organizations in implementing the original CSF guidance, going as far as building and enhancing an assessment in Microsoft Purview Compliance Manager since 2018. This blog and series will look to apply NIST CSF 2.0 to Microsoft 365 and discuss changes from the previous publication.
It is somewhat improper to look at any particular CSF Functions in a vacuum or singular vantage point. NIST CSWP 29 (the primary document) illustrates and describes CSF Functions as “a wheel because all of the Functions relate to one another. For example, an organization will categorize assets under IDENTIFY and take steps to secure those assets under PROTECT. Investments in planning and testing in the GOVERN and IDENTIFY Functions will support timely detection of unexpected events in the DETECT Function, as well as enabling incident response and recovery actions for cybersecurity incidents in the RESPOND and RECOVER Functions. GOVERN is in the center of the wheel because it informs how an organization will implement the other five Functions.”
NIST CSF 2.0 Wheel
Therefore, despite the blog title, there will be occasional references to other CSF Functions and Categories, as well as future blogs covering other Functions. This discussion will also endeavor to focus primarily on Microsoft 365 but venture into Azure topics periodically by the nature of each solution. This blog or any subsequent blogs in the series will not be an exhaustive review of all possible applications of NIST CSF 2.0, nor exhaustive of the technologies mentioned and their abilities to manage cybersecurity risks.
As a final caveat, Amy Adams in Talladega Nights once spoke of one of the most talented individuals behind a wheel this way, “Ricky Bobby is not a thinker. Ricky Bobby is a driver.” I want to believe I might be the latter.
NIST CSF 2.0 – Protect (PR)
PR as a function is intended to cover “safeguards to manage the organization’s cybersecurity risks” and contains five Categories. The prior CSF publication included six categories, but two were significantly edited and renamed. PR.MA: Maintenance for example was mostly removed with remnants found elsewhere. Let’s first dive into PR.AA. NOTE: Text in green are excerpts from CSF documentation.
Identity Management, Authentication, and Access Control (PR.AA): Access to physical and logical assets is limited to authorized users, services, and hardware and managed commensurate with the assessed risk of unauthorized access
Identity and access are not just about directories and networks. Organizations of all sizes and industries are challenged with controlling access to digital estates that are often complex and boundaryless because of accelerated technology adoption. Microsoft Entra’s family of solutions shown below employs a variety of measures to manage access to resources limited to authorized users, services, and hardware.
To meet the spirit of NIST CSF 2.0 PR.AA and a multitude of organizational scenarios, access decisions will need to be based upon periodic and real-time risk assessment. Automated and agile solutions are also necessitated for IT and security teams to avoid the manual processes traditionally associated with granting and managing access rights. Lastly, organizations will need to begin implementing some of the latest phishing-resistant multifactor authentication approaches using FIDO2 security keys, passkey technology, and/or certificate-based authentication to meet the barrage of sophisticated identity threats.
PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization
Microsoft Entra ID (fka Azure Active Directory) can serve firstly as the management solution of identities and credentials for “authorized users” in Microsoft 365, along with other infrastructure and platforms. In the Entra ID admin center, you can create and manage user accounts, different types of groups (e.g., security groups, distribution groups), and memberships to groups for enhanced access permissions and group-based policies.
Additionally, Microsoft Entra ID Governance comes with Microsoft Entra ID P2 and enables entitlement management, a feature for managing identity and access lifecycle at scale, automating workflows, assignments, reviews, and expirations. Entitlement management is able to bundle together an “access package” consisting of resources like groups, applications, and SharePoint Online site access that users need to perform their tasks or projects. These access packages can be bound to a department, role type, internal vs external user, newly onboarded employees, etc. Lastly, organizations can automate the creation and removal of identities based on employment status, integrating with HCM or HR systems for efficient governance.
Management of “credentials of authorized users” can also include the management of a self-service password reset (SSPR) process for users. Microsoft Entra’s SSPR allows users to change or reset their password without administrator intervention but reliant on thoughtful policy. This feature is designed to reduce help desk calls and improve productivity by enabling users to unblock themselves if they forget their password or get locked out of their account. Administrators can configure the number of methods required for password reset or unlock, and users are prompted to confirm their registered information periodically.
Microsoft Entra External ID also enables internal users to collaborate with external users (guests) by inviting them to your organization, managing guest accounts in the Microsoft Entra admin center or by PowerShell, and ensuring they have appropriate access while maintaining control over your resources. External ID B2B collaboration is particularly useful for inviting external business partners to access apps and resources using their own credentials. This eliminates the need for managing new credentials, as guests authenticate with their home organization or identity provider. However, it is important to document and enforce least privilege per PR.AA-05 below for these users.
Lastly, Microsoft Entra ID allows for central management of device identities and monitoring, with features like viewing total, stale, noncompliant, and unmanaged devices. By registering and joining devices to Entra ID, organizations can enable Seamless Sign-on to both cloud-based and on-premises resources.
Cross-Function Tip: PR.AA-01 could be included in your organization’s plan for the Detect (DE) Function and Continuous Monitoring (DE.CM) Category. Changes and actions taken by administrators in the management process can be “adverse events” resulting from malicious lateral movement or compromised identities.
PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions
Microsoft Entra ID Conditional Access policies can further prove the authenticity of an authorized user and their access activity, and dynamically adjust the bounds of that identity based upon various conditions. A Conditional Access policy can analyze details of a session or authentication attempt based upon conditions such as the network or location of the session, and the current identity risk of a user (leaked credentials, signs of a password spray attack, etc.) Microsoft Entra also uses industry standard continuous access evaluation (CAE) with token protection features to verify identities and assess based upon context.
During the device registration process in your organization, the user’s identity is also bound to the device based upon Microsoft Entra ID policies. Enrolled Windows devices, for example, will have an encrypted session key issued by Microsoft Entra that ensures token requests are not tampered with when a device is accessed, and subsequently Microsoft 365 applications. Other Microsoft Entra ID mechanisms are in place to prove and bound identities within device interactions, as well as prevent various types of credential theft. You can read more about them here.
For high-risk actions, organizations can require a step up proof of identity in real-time using Microsoft Entra Verified ID.
PR.AA-03: Users, services, and hardware are authenticated
Starting in 2019, Microsoft provides on-by-default multifactor authentication in all new Microsoft 365 tenants. This can be reviewed and controlled in the Microsoft Entra admin center. In addition, Microsoft started automatically rolling out “Microsoft-managed” Conditional Access policies that force an MFA action when an admin signs into the Microsoft 365 admin portal, and when any user attempts a high-risk sign-in.
You can view the policies and their impact using the new policy view user experience in Microsoft Entra. Within the portal, administrators can also review a policy summary, alerts, recommended actions, and an impact summary. Administrators can also create their own custom policies focused on certain users, groups, or roles if scenarios are not covered by the default policies automatically deployed. It is possible to clone a policy and then make changes to an existing templated policy as well to suit these needs.
Cross-Function Tip: PR.AA-03 can be included in your organization’s plan for the Detect (DE) Function and Continuous Monitoring (DE.CM) Category. Security teams can monitor authentication events using sign-in and audit logs with Microsoft Sentinel and reason over them with support from Microsoft Copilot for Security.
PR.AA-04: Identity assertions are protected, conveyed, and verified
For those less familiar with the term “identity assertion(s)”, NIST 800-63C Digital Identity Guidelines gives an explanation of this requirement in greater detail. You can define Microsoft Entra ID as an Identity Provider or IdP that can convey an assertion to a Relying Party (RP), and these “assertions are statements that contain information about a subscriber”. The RP “uses the information in the assertion to identify the subscriber and make authorization decisions about their access to resources controlled by the RP.” In other instances, Microsoft Entra ID could be considered an RP when receiving assertions from an external IdP to grant guest access to Microsoft 365.
Organizations can, as a part of Microsoft Entra ID P1 and P2, configure Microsoft Entra SAML token encryption with RP apps that support SAML assertions. This encryption ensures that the content of the token cannot be intercepted easily, and personal or corporate data remains secure. OpenID Connect (OIDC) alternatively is another method to enable single sign-on with an OAuth-enabled RP app by exchanging ID tokens issued by Microsoft Entra authentication servers. An organization can register an app in the Microsoft Entra admin center to configure both federated SSO scenarios (and others) for conveying, protecting and verifying identity assertions. It’s important to note that even without token encryption, Microsoft Entra ID already requires encrypted HTTPS/TLS channels for token exchanges, adding a layer of security.
As mentioned in PR.AA-01, eternal IdPs or external Microsoft 365 tenants can convey identity assertions to an organization through External ID. A simple invitation and redemption process lets an external party use their own credentials (via their own IdP) to access your company’s resources as the RP. Once the guest redeems their invitation or completes sign-up, they’re represented in your directory as a user object. Below is a sample flow aligned to B2B collaboration guidance, and gates 1-4 & 6 can be configured as allowable or not.
Cross-Function Tip: PR.AA-04 can be included in your organization’s plan for the Govern (GV) Function and Cybersecurity Supply Chain Risk Management (GV.SC) Category. As an organization works with various partners and suppliers, it’s important to ensure “supply chain risk management is integrated into cybersecurity and enterprise risk management”. Compromised identities from a supplier can directly impact external access and identity assertions for example.
PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties
Beyond identity, credential and authentication management covered in other AA subcategories, this subcategory can necessitate more robust written and technical policies. A solution to consider first is role-based access control (RBAC) enabled by Microsoft Intune and Microsoft Entra, which helps your organization manage who has access to internal resources and what they can do with those resources. By assigning roles to your users, you can limit what they can see and change. A built-In or custom role defines the set of permissions granted to users assigned to that role. Organizations can manage role assignments following least privilege principles to define which users are assigned to the role, resources they can see, and resources they can change.
With Microsoft Entra ID P2, Microsoft Privileged Identity Management (PIM) also allows an organization to manage, enforce, review, and incorporate least privilege and separation of duties for important administrative roles and entitlements. PIM supports a similar degree of control with groups and the associated entitlements and authorizations in Microsoft 365. From a management perspective, an approval process can be enforced to justify an elevation of a user/identity to a more privileged role and documented within PIM for later review if necessary.
Access to critical assets like sensitive data or information in Microsoft 365 may be authorize to users that do not have elevated administrative roles discussed in the previous paragraph. A user may be an analyst within a financial department, a human resources coordinator, or a junior engineer for a research and development project. Users in these roles may not have entitlements to export large quantities of data or grant entitlements to other users but are equally governed by defined written policies and technical policies administered in Microsoft Purview and Microsoft Entra.
An organization can develop Microsoft Purview sensitivity labels to manage and enforce access authorizations for files, emails, and meetings across Microsoft 365: SharePoint, Teams, PowerBI, OneDrive and more. Label policies can then restrict which users or groups of users have authorization to access the labeled content.
PR.AA-06: Physical access to assets is managed, monitored, and enforced commensurate with risk
From a Microsoft 365 perspective, there is physical access to two different types of assets:
- Physical compute resources (such as servers) and networking components at Azure datacenters across the globe
- Endpoints (laptop, mobile device, etc.)
According to the shared responsibility model in the cloud, a PaaS and SaaS offering like Microsoft 365 and it’s comprised solutions alleviate the responsibility of managing monitoring or enforcing access control to physical assets hosted in the Azure data center.
Azure datacenters deploy several safeguards to project physical assets, such as: video surveillance, perimeter fencing, 24×7 security officer postings with background checked personnel, locked server racks and server floors, integrated alarm systems, time and area-bound access granted through a protected ticketing system, and multi-factor access control including biometric scanning. As mentioned in the Category description of PR.AA, “logical access” to Microsoft 365 infrastructure, including customer data, is prohibited from within Microsoft datacenters. For more information about physical access security or to geek out on granular details like the material used to construct perimeter fences (spoiler – it’s steel and concrete), here is your muse.
Beyond the datacenter – laptops, mobile devices, and other endpoints can be considered a physical asset in the sense that unfettered physical access to them could create risk for an organization. The Protect (PR) Function at the highest level is defined as “safeguards to manage the organization’s cybersecurity risks”. Safeguarding endpoints as a physical asset, however, cannot be protected by fences and video surveillance realistically as you would a data center physical asset. Therefore, it is important to evoke other Categories, like Awareness and Training (PR.AT) and Data Security (PR.DS), within the PR Function to train employees to safeguard their endpoints and avoid negative impacts of a lost or stolen device. Organizations can also document this risk in your Organizational Profile and/or System Security plan.
Cross-Function Tip: The Identify (ID) Function contains a Category for Asset Management (ID.AM) that pertains to an organization’s strategy for inventorying and managing physical assets like endpoints. The lifecycle of a hardware component can include wiping and recommissioning/decommissioning previously used devices, as well as a process of remote wiping a lost or stolen machine using Microsoft Intune. Much of ID.AM pertaining to servers and network-related physical assets are managed at the Microsoft datacenter for Microsoft 365 tenants.
“You gotta learn to drive with the fear”
In this blog we covered all of the PR.AA Subcategories, where they apply to Microsoft 365, and how Microsoft solutions address each applicable element. This coverage is not comprehensive of all risk or all strategies; yet, the intent is to prime your organization’s approach. Subsequent blogs will explore other Categories within the Protect Function shown below.
NIST CSF 2.0 Protect (PR) Categories
Organizations establishing or reviewing their risk management practices can appreciate the importance of awareness. A proper identity and access control strategy starts by being risk informed, even if the risks presently outweigh the mitigations. Let’s press into the risk to grow as organizations and security practitioners.
Reese Bobby offered sage wisdom to his son Ricky in the theatrical number, Talladega Nights, “You gotta learn to drive with the fear. And there ain’t nothing more frightening than driving with a live cougar in the car.” Drive with the fear. Drive with a live cougar in the car.
Recent Comments