Why you need to protect DA (Domain Admin)

Active Directory (AD) is ubiquitous across enterprise estates and even with more and more migration to the cloud, AD on premise solutions are still very common. At a high-level AD provides a way of organising users and computers into manageable collections, for example all the HR computers in an organizational unit (OU -like a folder basically) that you can then manage with policies. The benefit here is you apply policies to the OU, and all the computers inside this get that policy. Maybe you want certain features to be enabled or disabled, policies, known as Group Policy Objects, can help you achieve that. The same can be applied to users, all the HR users are placed into a group called "HR_users" for example, and then access to network shares and resources can be granted or denied to that group. You can also apply policies to these user groups to control the end user experience. Time needs to be spent in defining what these management group looks like, but once the planning and implementation are completed, these strategies make common management tasks more flexible. This is not to say that AD management becomes easy at this point, AD can be complex, and this complexity can lead to a range of security issues.

Forests and Domains

An important piece to understand is that AD has a concept of a Forest, which can contain several domains. These domains can be configured in a parent child relationship. AD uses the domain name system (DNS) as a method of identifying resource locations and resources such as computers and user accounts are associated with a domain. The domains are created for replication reasons and servers called Domain Controllers are responsible for managing their respective domain objects (users, computers, policies). In the following example, 'internal.ad.com' is the forest and root domain (the first entity at installation) and 'emea' and 'asia' are child domains. The forest boundary in this case becomes 'internal.ad.com'.

One important point to note is that in an on-premises deployment, the forest is the only security boundary. Forests implement a trust model whereby the direction of trust can be used to secure access to resources.

Consider two companies, Company A and Company B. Company A trusts Company B, but Company B does not trust Company A.

This is known as a one-way trust. What this means is that when a user in Company B requests resources situated in Company A, this is allowed because the domain controllers within the Company B domain, verify to the Company A domain controllers that the user is valid and has an active, verified authenticated session. So Company A trusts Company B, which really means that Company A’s domain controllers will respect the authentication session details of a user in Company B and provide access accordingly. In the opposite direction this fails because Company B does not trust Company A’s domain controllers when they are stating that a user is successfully authenticated. Even writing that was complicated to try and explain, so imagine the challenges that AD system administrators must consider when implementing trust models and the impact of such decisions.

Domains are not security boundaries because you cannot say that 'emea.internal.ad.com' does not trust 'internal.ad.com'. Active Directory uses transitive trusts, therefore all children of 'internal.ad.com' ('emea' and 'asia' in this case) are trusted.

All roads to privilege

All that background was really to get to the point of discussing the main theme. Privilege. In any network there should be a concept of privilege. Administrative users are needed, and these rights should be based on roles where not every admin needs to hold full rights to the environment. The least privilege model is a method of implementing such controls.  The principal being that a scale of privilege should be implemented, and the number of users that hold high levels of privileges reduces based on the requirements of the role.

The diagram below is like an operating system kernel representation. The idea is that the least amount of privilege required for daily user activity is both the broadest user group (the outer ring) and the least privilege. Service privileges could be either be dedicated accounts or resources that "service" the network such as file shares etc. Then we have common administrative tasks, where specific administrative permissions are required.

The most powerful user group within a domain is “Domain Admins”. In a forest it is "Enterprise Admins." These users generally hold rights to configure critical infrastructure.

Domain Admins (DA) are the gatekeepers of the domain they are responsible for. To quote Microsoft directly:

"Domain Admins are, by default, members of the local Administrators groups on all member servers and workstations in their respective domains."

What that means is that a member of the "Domain Admins" group, a user account, can access everything by default. That critical server, the finance department server or the CEO’s desktop. All assets are accessible and, even if they are not, gaining "DA" would allow an attacker to manipulate their rights to access these resources anyway.

Within a large AD deployment with multiple regional domains, membership of the “Enterprise Admins” (EA) group gives you even more control:

"Enterprise Admins are, by default, members of the Administrators group in each domain in the forest"

This is access to any resource in the entire forest by default. These permissions are not to be considered lightly and the impact of an attacker gaining access to either of these groups can be considerable. It could render the network, and the business unrecoverable. Imagine compromising the AD environment of a global company that has a forest, with regional domains (EMEA, AMS, APJ). EA has access to everything. Globally. For the rest of this post, I will consider DA, but bear in mind, DA can lead to EA.

Attaining DA Status

During my career I know of many testers who have compromised domains as part of a scope requirement in order to achieve their objectives. I have compromised many myself. Often this is a necessity to be able to fulfil an objective, for example to demonstrate access to a sensitive system. Testers know that achieving this level of privilege will allow them to move unhindered towards whatever goal has been defined in the scope. Therefore, it tends to be a focus.

Make no mistake, achieving DA is a serious outcome. The impact of such an achievement, especially if this were to represent a real world attack route, would mean an attacker would have complete control of the assets within your domain, and as AD tends to facilitate your company, an attack can take your company offline. With the rise of ransomware, this means that holding DA would allow an attacker to deploy ransomware to every asset. 

Reducing the Surface

We often find that when customers are asked what the "worst case" scenario could be, inevitably this is to gain DA. Some customers understand that this will have significant impact to the environment. This understanding is not always the case though, and customers can often miss the importance of controlling administrative membership. There are examples of tested domains whereby every user has been granted DA. Not deliberately, but through a series of group permissions that collectively end up inside a privileged group.

Tools such as Bloodhound allow you to analyse such attack routes within on-premise AD solutions and these approaches are valuable. Regular auditing of Active Directory users, groups and passwords can help to maintain a manageable baseline. Security policies will only get you so far though. With the default password policy in place that requires 3 of 4 categories (i.e., Uppercase, Lowercase, special character and number), "Password123" is still a valid password that meets these criteria. Users can and will choose weak credentials and therefore education is equally as important as policy controls.

An attacker would be focused on routes where these credentials could lead to privilege. Whether these credentials are tied to services, or just long standing administrative credentials getting an understanding of the credential posture is an important step in governing on-premise AD deployments.

Actionable Strategies

So far we have discussed the impact but what can be done to reduce the attack surface. Auditing Active Directory is an effective start. Understanding some core aspects of the state of the directory can assist in devising a plan of remediation. Key areas of potential weakness to look for would be the following high level list:

• Accounts with excessive group membership
• Last logon times
• Last password set dates
• Service Principal Name associations
• Delegation rights
• AdminSDHolder attribute values
• Service account privileges

Complementing these should be a password audit. We have information on our blog about how to perform a password audit of the current domain. Password control is critical, and now with the integration of cloud environments as discussed in our post on "cloud-centric models", new working models can inadvertently place weak credentials within an attackers' reach. Often when assessing the current security posture, starting with weak credentials can be an effective first step in reducing the attack surface. Running the collated password hashes through a brute force attack process can show how easily and quickly credentials can be recovered.  

Your biggest exposure related to accounts in Active Directory is those passwords that are known to be compromised, or which can be guessed or brute-forced over the network. Rather than opting to use a powerful system with dedicated graphics cards that can crunch through large volumes of passwords, much of the risk can be identified using a simple virtual machine with moderate resources using CPU based power. Running collated password hashes through a brute force program with an appropriate publicly accessible word list will identify known-compromised passwords and those which are especially susceptible to password guessing attacks. Whilst this is not an exhaustive review of the susceptibility of each credential within the domain should an attacker have access to high performance resources, it does demonstrate where weak credentials reside in the domain. The low resource approach to password recovery often identifies credentials that are trivial to recover. These would be susceptible to password spraying attacks and often these are the immediate weak points. 

Analysis of Active Directory databases can also identify weaknesses such as common shared credentials, default passwords that are used during account setup, accounts that never logon, and accounts that are never forced to change their passwords - as well as combinations of these. 

Credentials that are weak can easily become embedded into an environment whether this is a result of administrative processes or end user behaviour. Attackers looking to identify routes to privilege will always consider credentials as one viable route. As previously mentioned, Bloodhound is an effective tool at providing a visual overview of routes available from a specific starting point, a compromised user account. Active Directory permissions can become complex very quickly, and it is hard to understand where implied permissions can reside. Visually mapping these routes can help to identify hidden pathways.

However, often the solutions to these challenges relate to design and process. For example, a common logon credential desirable to make helpdesk processes easier to onboard new users. This inevitably embeds common, weaker long standing credentials into the directory. A process change may be that a helpdesk user is required to generated a random initial password that is shared with the user. This removes the common credential and makes the account much more resilient to a password brute force attack should it remain dormant.

Summary

In any organisation where an attacker has elevated privileges to Domain or Enterprise admin this is a significant outcome. Once this level is obtained, no assets that reside within the environment are beyond reach. The business impact from such attacks can be considerable and in many of the public breaches related to ransomware, elevation of privileges is a key part of the attack chain. Domain Controllers and the groups that facilitate access need to be considered as critical infrastructure - the Active Directory domain itself should be subject to regular auditing of rights granted, privileged access and the use of weak credentials. Whilst there can be some planning required in building out internal models that follow the least privilege approach, overall, the company network will be more secure as a result.