How to Define Tier-Zero Assets in Active Directory Security

Organizations trying to improve the security of their Active Directory environments face a simple problem: Attackers have too many options. The average enterprise AD environment has thousands or tens of thousands of attack paths, which are chains of misconfigurations that allow an attacker with initial access to a low-privileged user to escalate privilege, move laterally to a high privilege user, and then take over the domain. While fixing every misconfiguration may not be possible, security and identity and access management administrators can absolutely make meaningful progress towards securing AD. But they need a way to prioritize their work to do so successfully.

The first step in prioritizing attack paths is focusing on those that lead to any tier-zero asset. Tier-zero assets are the vital systems in AD or Azure AD that, if compromised, allow an attacker to give themselves access to any system they want. Whatever an attacker is trying to do, whether that's deploying malware, stealing sensitive information or establishing persistence, getting control of a tier-zero system will allow them to do that.

This raises the question of what systems are included in tier zero. The term comes from Microsoft's Enhanced Security Administration Environment (ESAE - Retired) model and means the set of objects with full control over the environment and any objects with control over those objects. The ESAE model has been retired and replaced with Microsoft's Enterprise Access Model, which recommends the same advice and now refers to this sensitive group as "control plane." However, neither model includes a list of systems considered to be part of tier zero.

Here's what my colleagues and I who research AD security consider tier zero assets. There are many AD objects and groups that should always be considered tier zero in every environment, but some will vary from organization to organization. The final tier zero group will be custom to each organization.

Group One: Domain Control Groups

First, we include objects that maintain full control of a domain or have the (effectively) irrevocable ability to gain access to those groups. Remember to inspect any privileged group membership in AD to identify any nested groups, since group permissions are inherited. For example, if one group is nested within a second group that is included in domain controllers, all members of both groups will have those privileges.

In Active Directory, these include the domain head object, built-in administrator accounts, domain admins; domain controllers; schema and enterprise admins; enterprise domain controllers; key and enterprise key admins; and administrators overall.

In Azure, tier zero includes the default roles that maintain full control of an Azure tenant or have the effectively irrevocable ability to gain access to those roles. These include tenant objects, global administrators, privileged role administrator, and privileged authentication administrators.

Group Two: Key Identity Systems

Next, tier zero should include the computers and service accounts associated with the following systems. These will almost always be tier zero, but the process for identifying them will vary depending on the environment.

First are the public key infrastructure/Active Directory certificate services, including root certificate authority (CA) server and subordinate CAs. Second is Active Directory federation services, but note that Web application proxy servers should be in a separate AD forest (DMZ or extranet network) and are not considered tier zero. Third are Azure AD Connect servers and accounts, including servers with pass-through authentication that is enabled. Privileged access management systems such as Thycotic or CyberArk, and group policy object administration tools such as Quest GPO admin or advanced group policy manager should be considered tier zero as well.

As we've said, tier zero should be customized for each organization. The computers and services accounts associated with anything else that a specific organization considers to be tier zero, such as privileged access workstations, should be included with the systems listed above. Enterprise read-only domain controllers and read-only domain controllers can be considered tier zero or tier one, depending on certain conditions.

Group Three: Systems With Code Execution Ability

Finally, tier zero should include systems that have code execution ability (or other privileged control) on the tier zero systems listed above. For example, if domain controllers are managed from Microsoft System Center Configuration Manager (SCCM), compromising SCCM allows the attacker to execute code on domain controllers. SCCM is, in this case, an indirect path to full control over the environment and, therefore, a tier-zero system. This attack requires more sophistication but is still a viable option for an adversary and organizations should be prepared for this possibility.

There are often many systems in this category and identifying them all can be a significant project. It's recommended that organizations work in phases; first identify all the objects and accounts listed above, draw the tier-zero boundary around them, and then move on to identify systems with code execution ability over them.

Once an organization has identified these assets, they can focus their security resources on protecting them and better assess which attack paths to focus on closing. It's practically impossible to close every possible avenue of attack in an enterprise network, but prioritizing their efforts allows defenders to eliminate the most dangerous ones that lead to tier-zero assets and reduce their overall exposure significantly.