Total Identity Compromise: Microsoft's Incident Response Course on Securing Active Directory
When Microsoft Incident Response (formerly known as DART/CRSP) is involved in an incident, almost all environments include a local Active Directory component. In most of these campaigns, the cybercriminal took full control of Active Directory - that is, compromised the entire domain.
Compromising an entire domain usually starts with an ordinary unprivileged user, not a domain administrator. Risk actors can use this account to detect misconfigurations and attack paths in Active Directory that lead to full control of the domain. Typically, cybercriminals use free tools such as AdFind, AD Explorer or BloodHound to find attack paths in the Active Directory environment. Restoring trust in Active Directory after a domain-wide breach can take a lot of time and investment.
To aid our investigation, Microsoft Incident Response uses a custom Active Directory enumerator to retrieve metadata about users, groups, permissions, group policies, and more. Microsoft Incident Response uses this data not only to assist with investigations, but also toAttacker Removal and Compromise Recovery PlanIt also offers best practice recommendations for withdrawing and maintaining a positive identity check. In addition to the Microsoft Incident Response customization tool, there are other tools available such asidentity defenderand open source tools such ashoundIPingbao,you can useSecure Active Directory in your environment.
Across all industries, Microsoft Incident Response frequently finds similar issues in Active Directory environments. In this blog, we'll highlight some of the most common issues found in on-premises Active Directory environments and provide tips on how to protect against these vulnerabilities. They include:
initial access– Weak password policy, excessive permissions and poor credential hygiene, insecure account setup
credential access– Exposed privileged credentials, Kerberoasting, insecure delegation configurations, misconfiguration of local administrator password solution (LAPS), excessive privileges via built-in groups
privilege escalation– Access Control List (ACL) abuse, Exchange Privilege Escalation, Group Policy abuse, insecure trust configurations, breach of other Layer 0 resources
poor password policy
it's not uncommonMicrosoft Incident ResponseInteraction with clients whose account credentials are weak or easily guessed, including privileged users such as domain administrators. A simple password spraying attack can compromise these accounts. If these standard user accounts provide VPN or remote access without MFA, the risk increases: attackers can connect to the VPN from a device they control and start reconnaissance of the environment remotely. From there, cybercriminals can try to escalate to domain administrator privileges through vulnerabilities in Active Directory.
Where possible, Microsoft Incident Response recommends deploymentno password authenticationTechnology such as Windows Hello for Business (using biometrics such as facial recognition or fingerprints) or FIDO2 security keys.Full implementation of passwordless authentication allowsDisable password authentication, which eliminates password-based attack vectors (such as password spraying and phishing) for these users.If you're not ready to start implementing passwordless solutions, you can do soAccurate password policy.Current guidelines recommend longer (14 or more characters) but less complex passwords (no special characters, etc.), and users are much less likely to change their passwords. This prevents users from reusing easy-to-guess passwords to meet complexity and rotation requirements, such as changing passwords from "Monday 10' come 'Monday 11'.
If you have a license for Azure Active Directory P1 or later, you can also deployAzure Active Directory password protection, which prevents users from using easy-to-guess passwordsEven in local Active Directory.You can also block custom words that are unique to your business, such as your business name or the city you operate in.
In the absence of a password and stronger password policies, these solutions can take some time to implement if you work in a complex environment and target domain administrators and other privileged users first. Your Tier 0 accounts can and should meet higher security standards.
Excessive privileges and poor credential hygiene
One of the most common problems in Active Directory is assigning accounts (especially service accounts) too many permissions. It is not uncommon for multiple service accounts and named user accounts to be given domain administrator privileges during Microsoft's incident response efforts. Additionally, service accounts used for applications or scripts typically have local administrative access to all workstations and servers. While this is an easy way to run a product or script, these accounts can be a weak link in your security.
Service accounts are an attractive target because passwords are rarely exchanged. The security checks on them are usually weak and cannot be protected by MFA. Additionally, the passwords for these accounts are often stored in plain text, sent via email, stored in a text file on the device, or used as plain text in command line arguments. The combination of multiple domain administrator accounts and poor technical control over these accounts increases the risk of credential theft.
These excessive permissions also include too many users who have local administrative permissions on their devices. If the infected user does not have local administrative rights on their device, the cybercriminal will have great difficulty in continuing to navigate the environment from that device.
There's no specific guidance on how many domain admin accounts should exist in each environment because privileged account requirements are unique to each environment. That said, any request for additional domain admins should be carefully scrutinized, with a preference to always grant lower-level permissions, especially to service accounts. While adding service accounts to domain admins is an easy way to ensure that your applications work properly, most of these accounts can be assigned much less permissions and still function properly. They also typically only have access to a subset of devices, not all workstations and servers.
If you don't have strong controls to manage the security credentials practices of your most important accounts, the more domain admin-level accounts you add, the more risk you take. For service accounts, check thatA group-managed service account(gMSA), which provides automatic password management for workloads.
insecure account setup
In Active Directory, misconfigurations can cause individual user accounts to be less secure than expected. Some settings that you should double check to make sure they are set up correctly include:
- Kerberos pre-authentication is not required.
- Store passwords with reversible encryption.
- No password is required.
- Password stored with weak encryption.
Enabling any of these settings can significantly compromise the security of your account. It is relatively easy for adversaries to enumerate directories to find accounts with these flags. The credentials for these accounts can be more easily recovered by cybercriminals.
Defender for Identity provides a great summary of these risky account flags via the Secure Score portal. For each configuration item, it lists the affected accounts and how to resolve the issue. Other tools like BloodHound or PingCastle can also flag these account issues.
Disclosure of Privileged Credentials
During cyberattacks, adversaries often try to obtain privileged credentials. These credentials are considered "crown jewels" as they enable cybercriminals to achieve their goals. Once you have privileged credentials, you can use them to:
- Add additional persistence mechanisms such as scheduled tasks, installing services, or creating additional user accounts.
- Disable or bypass endpoint antivirus or other security.
- Deploy malware or ransomware.
- sensitive data leakage.
When administrators log directly into the device or connect to it remotely to perform daily tasks, they can leave privileged credentials. Threat actors can use tools such as Mimikatz or secretsdump (part of the Impacket framework) to retrieve these credentials. As privileged users log on to more and more computers, attackers have more and more opportunities to find and extract these credentials. For example, if members of the Domain Admins group regularly log on to end-user workstations for troubleshooting, the domain administrator's credentials could be exposed on every device, increasing the chances of cybercriminals locating and extracting them.
To help customers understand the propagation of privileged credentials,Microsoft Incident ResponseCollect sign-in telemetry from event logs on the device, signals from Microsoft Defender for the endpoint, or both. From this data, create mappings for Tier 0 accounts (such as domain admins) that log into devices that are not considered Tier 0, such as member servers and workstations.
Figure 1: Domain admin login path mapped to non-Tier 0 servers.
In this visualization, the green circle represents the domain administrator. The red dotted line represents the RDP login to the device, while the black dotted line represents the network login. In this example, we see two domain administrators logged into three different servers. If one of these three servers has been compromised by a cybercriminal, domain administrator credentials can be stolen. The larger the environment, the more pronounced this problem will be. If we add additional admins and other non-Tier 0 devices, we will see an immediate impact on our footprint.
Figure 2: Mapping domain admin login paths to non-Tier 0 servers and other devices.
Credential exposure has increased significantly as more and more domain admins and these admins have logged on to other non-tier 0 devices.
The purpose of these diagrams is to help customers visualize the location of privileged credentials on their network and start thinking the way a threat actor thinks. In large and complex Active Directory environments, these graphs can be very large, with the number of endpoints in the thousands.
The solution from Microsoft to reduce the exposure of privileged credentials is to implementEnterprise access model.This management model aims to limit the proliferation of privileged credentials by limiting the devices that domain administrators (and similar accounts) can log in to. In large and complex environments, it is safe to assume that some users and devices will be compromised. Your most privileged account should only have access to Level 0 resources from a hardened device called a Privileged Access Workstation (PAW). Access with the lowest privileges isZero trust clientBy reducing the likelihood of privileged credentials being extracted, we reduce the impact of a security breach on a single device or user.
Implementing an enterprise access model is a journey, and every organization is at a different stage of that journey. Regardless of your current status, you can always limit the proliferation of privileged credentials through technological controls and changing the way your employees work. ThistableIn the Microsoft Learn documentationLists the different login types and whether credentials are left on the target device.When managing remote systems, Microsoft Incident Response recommends using methods that leave as few credentials as possible.
Defender for Identity also maps these lateral traffic paths, showing the paths that collective user compromise can lead to a domain breach. all it isIntegrates directly with user and computer objects in the Microsoft 365 Defender portal.
Figure 3: Defender for Identity pageIt is used to map the lateral path of the user's movement.
The most at-risk users and computers are also shown insafety assessmentA portal that allows you to correct the most at-risk objects.
Kerberoasting is a technique used by cybercriminals to crack passwords on the accounts they usually maintainService principal name(SPN) associated with them. If regular users in Active Directory are compromised, they can request a ticket (which includes hashed passwords) using tools like RubeuseveryoneAn account with a configured SPN. Threat actors can then extract this hash from memory and attempt to crack the password offline. If they manage to crack the password, they can authenticate and gain permissions from that service account.
it's not rareMicrosoft Incident ResponseDetects SPNs registered to a privileged administrator account or a service account that has been added to a privileged group. Often, these SPNs are set up as tests and then never removed, making them vulnerable to Kerberoasting.
Microsoft Incident Response recommends reviewing all accounts with configured SPNs to ensure they are still required. For accounts that are in active use, make sure that the passwords associated with those accounts are very complex and changed whenever possible.
Defender for Identity includes logic to detect Kerberoasting activity in your environment. By receiving signals from domain controllers, Defender for Identity can help detect users enumerating your domain for Kerberoast-enabled accounts or actively trying to exploit them.
Unsafe delegation configuration
Kerberos unrestricted delegation provides entities with the ability to impersonate other users. This makes it easier to authenticate with multi-tier applications. For example, a Web server running IIS might be configured to delegate access to the SQL server that stores site data. When you log into the web server, the web server uses a proxy to authenticate to SQL on your behalf. For this purpose, a Kerberos Ticket Granting Ticket (TGT) is stored in the memory of the Web server. If cybercriminals compromise this web server, they can download these tickets and impersonate any logged in user. If the domain administrator is logged in, the attacker will gain access to the domain administrator's TGT and gain full control of Active Directory.
View all users and devices with delegation enabled. They are available at the addressDefender for Identity section in Secure Score.If delegation is required, it should be limited to the required services, not completely unlimited.
Administrative accounts should never be enabled for delegation. You can prevent these privileged accounts from being targeted by enabling the "Account is sensitive and cannot be delegated" flag on them. You can add these accounts to "protected user groupThe protection provided by this group goes beyond preventing posting and making them safer; however, it can cause operational issues, so it's worth testing it in your environment.
Local Administrator Password Solution (LAPS)
Microsoft Incident Response is frequently encounteredStanNumber of turnsNot yet deployed to the environment. LAPS is a Microsoft solution for automatically managing passwords for built-in administrator accounts on Windows devices. When building or mirroring machines, they usually have the same password as the built-in administrator account. If that never changes, a single password could give local administrative privileges to all machines and perhaps provide lateral movement capabilities. LAPS solves this problem by ensuring that each device has a unique local administrator password and changes it regularly.
In addition, even after implementing LAPS, sometimes enterprises do not fully implement it. Therefore, while LAPS manages local administrator accounts on these devices, there are groups of users who have local administrative rights to all workstations, all servers, or both. These groups can contain a large number of users, typically technical support or other operational personnel. These operators then use their own accounts instead of LAPS credentials to manage these devices. IT setups can also exist where non-LAPS secondary managed accounts with easy-to-guess passwords still exist, negating the benefits of implementing LAPS.
As mentioned earlier, groups with extensive administrative privileges provide cybercriminals with more opportunities to compromise privileged credentials. If an endpoint signed into one of these accounts is compromised, the attacker may have the credentials to compromise all devices on the network.
It is important not only to implement LAPS at endpoints, but also to ensure that IT standard operating procedures are updated to ensure the use of LAPS. This allows companies to remove permissions from administrative accounts and reduce the risk of credential theft across the enterpriseIn addition, it is very important to know which users can recover the LAPS password for use, as the ability to recover this password provides local administrative access to the device. Readability of LAPS passwords is controlled by the "ms-Mcs-AdmPwd" attribute and should be controlled to ensure that access is only granted to users who need it.
Too many permissions with built-in groups
When responding to incidents, companies often set up alerts and monitor changes in groups such as domain and enterprise administrators. These groups are known to have the highest level of permissions in Active Directory. However, there are other built-in permission groups that are attractive to cybercriminals and are often not subject to the same level of scrutiny. Groups such as Accounts and Server Operators have extensive permissions in Active Directory. For example, by default, server operators can log on to domain controllers, restart services, back up and restore files, etc.
It is recommended that built-in privileged groups contain no users, if possible. Instead, appropriate permissions should be granted specifically to users who need them. In addition, Microsoft Incident Response recommends that you review your current membership in these organizationsGroupAnd add additional alerts to their changes the same way domain or enterprise administrators change alerts.
Access control list abuse
Access control list (ACL) misconfiguration is one of the most common issues Microsoft Incident Response detects in Active Directory environments. Active Directory ACLs are very detailed, complex, and prone to misconfiguration. The security level of the Active Directory environment can be easily lowered without any operational impact on users. Attack paths start to form when ACLs are set up in your environment through regular actions. These attack paths create an escalation path from low-privileged users to full domain control. Threat actors can exploit paths created by an excessive combination of permissions and scopes in ACLs. Threat actors can exploit paths created by an excessive combination of permissions and scopes in ACLs.
Two common ACLs that Microsoft Incident Response often sees in Active Directory are:
- GenericAll - This permission is the same as Full Control access. If a user is compromised and that user has GenericAll in a high-privileged group, the threat actor can add additional members to that group.
- WriteDacl - This permission allows you to manipulate ACLs on objects. This permission allows an attacker to change the ACLs of objects such as groups. If a user is compromised and that user has a WriteDacl for a highly privileged group, the threat actor can add a new ACL to that group. The new ACL can then grant them permission to add other members to the group, such as themselves.
These permissions are typically set at the top of the Active Directory hierarchy. They are also often applied to users and groups that do not require these rights, effectively giving full domain control to members of those groups. Members of these groups are rarely as protected as domain and enterprise administrators.
Additionally, Microsoft Incident Response frequently detects unsecured ACLsAdminSdHolderThe object responsible for managing the permissions of protected users and groups. If an adversary can tamper with the ACL on the AdminSdHolder, it will be distributed to these protected users and groups while the SDProp process is running. The adversary would then have the authority to change the membership of protected groups, such as domain administrators, allowing them to add themselves. DocumentationhounddescribeThese and some other ACL "advantages" that can be used for privilege escalation.
Microsoft Incident Response recommends using tools such as Defender for Identity to audit permissions in your Active Directory environment, and use BloodHound to audit approved attack paths and remediate paths that could lead to domain security breaches.
Privilege escalation by Exchange
Prior to the adoption of enterprise cloud email services such as Office 365, customers used their own on-premises Exchange environments. Many customers still maintain full on-premises Exchange environments. On-premises Exchange and Active Directory have always been tightly coupled, and Exchange maintained high privileges through Active Directory. Even in environments where user mailboxes have been migrated to Office 365, Exchange's on-premises footprint often persists. It may exist to manage non-migrated users, legacy applications that cannot be integrated with Office 365, or to support non-internet-connected workloads.
These on-premises Exchange environments typically remain highly privileged by Active Directory, with groups such as "Trusted Exchange Subsystem" and "Exchange Servers" having direct access to overall domain control.
On-premises Exchange is usually available with the Internet to allow users to access resources such as Outlook Web Access. As with any service on the internet, this increases the attack surface. If an attacker can obtain SYSTEM privileges on the Exchange server and Exchange still retains excessive privileges in Active Directory, this could result in a complete takeover of the domain.
The separation of permissions in Active Directory is possible thanks to the implementation of ExchangeThe Exchange Shared Privileges ModelBy implementing this model, permissions for Active Directory and Exchange are separated.
After implementing the Exchange shared permissions model, they areoperational changesRequired for employees who manage both Exchange and Active Directory. If you don't want to implement the whole split permissions model, you can still reduce Exchange permissions in Active Directory by making changes to the following Microsoft softwareguide.
If you have fully migrated to Office 365 but maintain an on-premises Exchange server for ease of management, you can nowshut down these local servers.
ACL group policy abuse
Group Policy is often a tool used by cybercriminals to maintain persistence (by creating scheduled tasks), create additional accounts, or deploy malware. It also serves as a ransomware deployment mechanism. If cybercriminals haven't targeted domain administrators yet, they may have been able to compromise accounts that retain GPO permissions. For example, the ability to create, update, or even merge policies may have been delegated to other groups.
If an existing Group Policy is configured to run a startup script, an attacker can change the path to that script and force it to execute a malicious payload. If there is a group policy that disables endpoint security tools as an exception, cybercriminals can exploit the permissions of the related policy by applying it to all devices in the environment. This does not require the Threat Actor to update the policy, just change its scope.In addition, regular users can gain additional permissions throughAssignment of user rightsThese permissions are often not requested by the user but are granted accidentally.
The ability to manipulate Group Policy is a highly privileged operation, and users and groups delegated to manage it should be held to the same standards as domain administrators or similar. Ensure that permissions to create, update, and link Group Policy follow the principle of least privilege.
In large and complex environments, the number of Group Policies in use can be overwhelming, and it may not be clear which policies apply to which users and devices. Use tools such aspolicy results set(RSoP), you can model your GPOs to see the overall impact on users and devices.
Insecure trust configuration
SID History is an Active Directory feature that helps you migrate your domains. Allows domain administrators to simplify migrations by applying SID history (simplified, a list of permissions) from old accounts to new ones. This helps users maintain access to resources after resource migration. An attacker could exploit this feature by placing the SID of a group such as Domain Admins in the SID history of an account in a trusted forest and using that accountcontrol the forest of trust.to wmergers and acquisitionswhere trust between Active Directory environments is configured to allow migration.
Configure Active Directory trusts only when absolutely necessary. If they are part of an acquisition or migration, they must be decommissioned after the migration is complete. For trusts that must be preserved for operational reasons,SID filteringIoptional authenticationIt should be configured to restrict attack paths from other domains and forests.
Risks to other tier 0 assets
In the past, domain controllers were at the center of the Tier 0 infrastructure. While this is still true, Tier 0 has now expanded to include several interconnected systems. As the way we work evolves, so does the underlying technology required to power modern identity systems. Accordingly, your footprint at level 0 has also changed and may now include the following systems:
- Active Directory Federation Services
- Azure Active Directory connection
- Active Directory Certificate Services
This also includes any other services or infrastructure, including 3drugparty provider,They are part of the identity trust chain, such as Privileged Access and Identity Management systems.
Figure 4: Example of linking a Tier 0 resource to an identity chain of trust.
It is important that all systems that form part of the end-to-end identity chain are contained in Layer 0, and that security controls applied to domain controllers also apply to those systems. Due to the interconnected nature of these systems, a breach of any one of them could lead to a breach of the entire domain. Only level 0 accounts should maintain local administrative rights to these systems and, where possible, should be accessed through privileged access workstations.
In large and complex environments, the Microsoft Incident Response team often finds that the combination of the above issues significantly lowers the level of identity security. These misconfigurations allow cybercriminals to go from a single unprivileged user to a crown jewel domain administrator account.
Figure 5: Kill chain showing how a domain hack starts with a single infected user.
For example, in the kill chain above, the first user was compromised due to a weak password policy. The domain was compromised due to an initial bad password policy, additionally poor credential hygiene, and misconfigured ACLs. There are many possible paths to a domain administrator when you multiply all combinations of user accounts, group access, and permissions in Active Directory.
Active Directory attacks are constantly evolving, and this blog covers just some of the more common issues Microsoft Incident Response has observed in customer environments. Ultimately, any changes made to Active Directory increase or decrease the risk of an attacker taking control of your environment. To ensure continuous risk reduction, the Microsoft Incident Response team recommends the following continuous cycle:
- Limited Privilege - Assign all access rights according to the Principle of Least Privilege. Also, implement an enterprise access model to reduce the exposure of privileged credentials. Combined, this will reduce the likelihood that a single device or user breach will result in a domain-wide breach.
- Current State Audit - Use tools such as Defender for Identity and approved use of BloodHound and PingCastle to audit the current state of Active Directory security and troubleshoot issues that arise with these tools and are described in this blog.
- Monitor for changes - Monitor your Active Directory environment for changes that may compromise security or reveal additional attack paths to compromise domain security.
- Proactive detection - Alert you to potential signs of a security breach with Defender for Identity or custom detection rules.
Microsoft Incident Response often leaves customers with the message that Active Directory security requires ongoing management. You can't "deploy" Active Directory security and never look at it again. Active Directory security is all about continuous improvement and ensuring these misconfigurations and attack paths are mitigated before adversaries discover them.