TierZeroTable.json

[
  {
    "Asset": "Account Operators",
    "Category": "DC group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-32-548",
    "Description": "The Account Operators group grants limited account creation privileges to a user. Members of this group can create and modify most types of accounts, including accounts for users, Local groups, and Global groups. Group members can log in locally to domain controllers.\r\n\r\nMembers of the Account Operators group can't manage the Administrator user account, the user accounts of administrators, or the Administrators, Server Operators, Account Operators, Backup Operators, or Print Operators groups. Members of this group can't modify user rights.\r\n\r\nThe Account Operators group applies to the Windows Server operating system in the Default Active Directory security groups list.\r\n\r\nNote: By default, this built-in group has no members. The group can create and manage users and groups in the domain, including its own membership and that of the Server Operators group. This group is considered a service administrator group because it can modify Server Operators, which in turn can modify domain controller settings. As a best practice, leave the membership of this group empty, and don't use it for any delegated administration. This group can't be renamed, deleted, or removed.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Account Operators group has GenericAll in the default security descriptor on the AD object classes: User, Group, and Computer. That means all objects of these types will be under full control of Account Operators unless they are protected with AdminSDHolder. Not all Tier Zero objects will be protected with AdminSDHolder typically, as not all Tier Zero objects will be included in Protected Accounts and Groups. This means Account Operators members have a path to compromise Tier Zero most often.\r\n\r\nIt is possible to delete all GenericAll ACEs for Account Operators on Tier Zero objects. To protect future Tier Zero objects, one would have to either remove the Account Operators ACE from the default security descriptors or implement a process of removing the ACEs as Tier Zero objects are being created. However, we recommend not using the group and classifying it as Tier Zero instead.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH 'S-1-5-32-548'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "YES",
    "Episode": "1",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#account-operators\r\nhttps://www.whiteoaksecurity.com/blog/account-operators-privilege-escalation/\r\nhttps://specterops.io/blog/2025/06/25/untrustworthy-trust-builders-account-operators-replicating-trust-attack-aorta/\r\nhttps://bloodhound.specterops.io/resources/edges/generic-all"
  },
  {
    "Asset": "Administrators",
    "Category": "DC group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-32-544",
    "Description": "Members of the Administrators group have complete and unrestricted access to the computer. If the computer is promoted to a domain controller, members of the Administrators group have unrestricted access to the domain.\r\n\r\nThe Administrators group applies to the Windows Server operating system in the Default Active Directory security groups list.\r\n\r\nNote: The Administrators group has built-in capabilities that give its members full control over the system. This group can't be renamed, deleted, or removed. This built-in group controls access to all the domain controllers in its domain, and it can change the membership of all administrative groups. Members of the following groups can modify the Administrators group membership: the default service Administrators, Domain Admins in the domain, and Enterprise Admins. This group has the special privilege to take ownership of any object in the directory or any resource on a domain controller. This account is considered a service administrator group because its members have full access to the domain controllers in the domain.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Administrators group has full control over most of AD's essential objects and are inarguably part of Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH 'S-1-5-32-544'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "YES",
    "Episode": "1",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#administrators"
  },
  {
    "Asset": "Backup Operators",
    "Category": "DC group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-32-551",
    "Description": "Members of the Backup Operators group can back up and restore all files on a computer, regardless of the permissions that protect those files. Backup Operators also can log on to and shut down the computer. This group can't be renamed, deleted, or removed. By default, this built-in group has no members, and it can perform backup and restore operations on domain controllers. Members of the following groups can modify Backup Operators group membership: default service Administrators, Domain Admins in the domain, and Enterprise Admins. Members of the Backup Operators group can't modify the membership of any administrative groups. Although members of this group can't change server settings or modify the configuration of the directory, they do have the permissions needed to replace files (including operating system files) on domain controllers. Because members of this group can replace files on domain controllers, they're considered service administrators.\r\n\r\nThe Backup Operators group applies to the Windows Server operating system in Default Active Directory security groups.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Backup Operators group has the SeBackupPrivilege and SeRestorePrivilege rights on the domain controllers by default. These privileges allow members to access all files on the domain controllers, regardless of their permission, through backup and restore operations. Additionally, Backup Operators have full remote access to the registry of domain controllers. To compromise the domain, members of Backup Operators can dump the registry hives of a domain controller remotely, extract the domain controller account credentials, and perform a DCSync attack. Alternative ways to compromise the domain exist as well. The group is considered Tier Zero because of these known abuse techniques.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH 'S-1-5-32-551'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "YES",
    "Episode": "1",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#backup-operators\r\nhttps://book.hacktricks.xyz/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges#backup-operators-1"
  },
  {
    "Asset": "Cryptographic Operators",
    "Category": "DC group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-32-569",
    "Description": "Members of this group are authorized to perform cryptographic operations. This security group was added in Windows Vista Service Pack 1 (SP1) to configure Windows Firewall for IPsec in Common Criteria mode.\r\n\r\nThe Cryptographic Operators group applies to the Windows Server operating system in Default Active Directory security groups.\r\n\r\nThis security group was introduced in Windows Vista SP1, and it hasn't changed in subsequent versions.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "NO",
    "Tier Zero": "YES",
    "Rationale": "The Cryptographic Operators group has the local privilege on domain controllers to perform cryptographic operations but no privilege to log in.\r\n\r\nThere are no known ways to abuse the membership of the group to compromise Tier Zero. The local privilege the group has on the domain controllers is considered security dependencies, and the group is therefore considered Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH 'S-1-5-32-569'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "NO",
    "Episode": "1",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#cryptographic-operators"
  },
  {
    "Asset": "DHCP Administrators",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "CN: DHCP Administrators",
    "Description": "Members of the DHCP Administrators group have administrative access to DHCP servers. This group is created when the DHCP Server role is installed on a Windows Server. Members can view and modify all aspects of DHCP server configuration.\r\n\r\nThe security impact of this group depends on where the DHCP service is running. According to Akamai research, 57% of organizations have a DHCP server installed on a domain controller.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "IT DEPENDS",
    "Rationale": "DHCP Administrators can escalate privileges to Tier Zero when DHCP runs on domain controllers or Tier Zero systems. Akamai research demonstrates privilege escalation via DHCP option abuse, enabling Kerberos coercion attacks followed by AD CS relay attacks. This can lead to compromise of the DHCP machine account and potentially the domain controller.\r\n\r\nWhen DHCP runs only on network appliances without access to domain infrastructure, the group is limited to Tier 1. However, with 57% of environments running DHCP on domain controllers, this represents a Tier Zero risk in common deployments.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.name STARTS WITH 'DHCP ADMINISTRATORS@'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "Community contribution",
    "References": "https://www.akamai.com/blog/security-research/abusing-dhcp-administrators-group-for-privilege-escalation-in-windows-domains"
  },
  {
    "Asset": "Distributed COM Users",
    "Category": "DC group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-32-562",
    "Description": "Members of the Distributed COM Users group can launch, activate, and use Distributed COM objects on the computer. Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. Distributed Component Object Model (DCOM) allows applications to be distributed across locations that make the most sense to you and to the application. This group appears as an SID until the domain controller is made the primary domain controller and it holds the operations master (also called the flexible single master operations or FSMO) role.\r\n\r\nThe Distributed COM Users group applies to the Windows Server operating system in Default Active Directory security groups.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "NO",
    "Tier Zero": "YES",
    "Rationale": "The Distributed COM Users group has local privileges on domain controllers to launch, activate, and use Distributed COM objects but no privilege to log in.\r\n\r\nThere are no known ways to abuse the membership of the group to compromise Tier Zero. The local privileges the group has on the DCs are considered security dependency, and the group is therefore considered Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH 'S-1-5-32-562'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "NO",
    "Episode": "1",
    "References": "https://decoder.cloud/2024/04/24/hello-im-your-domain-admin-and-i-want-to-authenticate-against-you/\r\nhttps://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#distributed-com-users"
  },
  {
    "Asset": "Domain Admins",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<domain>-512",
    "Description": "Members of the Domain Admins security group are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined a domain, including the domain controllers. The Domain Admins group is the default owner of any object that's created in Active Directory for the domain by any member of the group. If members of the group create other objects, such as files, the default owner is the Administrators group.\r\n\r\nThe Domain Admins group controls access to all domain controllers in a domain, and it can modify the membership of all administrative accounts in the domain. Members of the service administrator groups in its domain (Administrators and Domain Admins) and members of the Enterprise Admins group can modify Domain Admins membership. This group is considered a service administrator account because its members have full access to the domain controllers in a domain.\r\n\r\nThe Domain Admins group applies to the Windows Server operating system in Default Active Directory security groups.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Domain Admins group has full control over most of AD's essential objects and are inarguably part of Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH '-512'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "YES",
    "Episode": "1",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#domain-admins"
  },
  {
    "Asset": "Domain Controllers",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<domain>-516",
    "Description": "The Domain Controllers group can include all domain controllers in the domain. New domain controllers are automatically added to this group.\r\n\r\nThe Domain Controllers group applies to the Windows Server operating system in Default Active Directory security groups.",
    "Tier Zero Default Risk": "YES - Disruption",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Domain Controllers group has the GetChangesAll privilege on the domain. This is not enough to perform DCSync, where the GetChanges privilege is also required.\r\n\r\nThere are no known ways to abuse membership in this group to compromise Tier Zero. However, the GetChangesAll privilege is considered a security dependency that should only be held by Tier Zero principals. Additionally, control over the group allows one to impact the operability of Tier Zero by removing domain controllers from the group, which breaks AD replication. The group is therefore considered Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH '-516'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "YES",
    "Episode": "1",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#domain-controllers"
  },
  {
    "Asset": "Enterprise Admins",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<root domain>-519",
    "Description": "The Enterprise Admins group exists only in the root domain of an Active Directory forest of domains. The group is a Universal group if the domain is in native mode. The group is a Global group if the domain is in mixed mode. Members of this group are authorized to make forest-wide changes in Active Directory, like adding child domains.\r\n\r\nBy default, the only member of the group is the Administrator account for the forest root domain. This group is automatically added to the Administrators group in every domain in the forest, and it provides complete access to configuring all domain controllers. Members in this group can modify the membership of all administrative groups. Members of the default service administrator groups in the root domain can modify Enterprise Admins membership. This group is considered a service administrator account.\r\n\r\nThe Enterprise Admins group applies to the Windows Server operating system in Default Active Directory security groups.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Enterprise Admins group has full control over most of AD's essential objects and are inarguably part of Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH '-519'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "YES",
    "Episode": "1",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#enterprise-admins "
  },
  {
    "Asset": "Group Policy Creator Owners",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<domain>-520",
    "Description": "This group is authorized to create, edit, and delete Group Policy Objects in the domain. By default, the only member of the group is Administrator.\r\n\r\nFor information about other features you can use with this security group, see Group Policy overview.\r\n\r\nThe Group Policy Creator Owners group applies to the Windows Server operating system in Default Active Directory security groups.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "NO",
    "Tier Zero": "NO",
    "Rationale": "The Group Policy Creator Owners group has the privilege to create new GPOs. However, members of the group can only edit or delete GPOs that they have created themselves. The group has no privileges to link GPOs to an OU, a site, or the domain.\r\n\r\nThere are no known ways to abuse membership of the Group Policy Creator Owners group to compromise Tier Zero. The group is not a security dependency for Tier Zero and is therefore not considered Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH '-520'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "NO",
    "Episode": "1",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#group-policy-creator-owners"
  },
  {
    "Asset": "Print Operators",
    "Category": "DC group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-32-550",
    "Description": "Members of this group can manage, create, share, and delete printers that are connected to domain controllers in the domain. They also can manage Active Directory printer objects in the domain. Members of this group can locally sign in to and shut down domain controllers in the domain.\r\n\r\nThis group has no default members. Because members of this group can load and unload device drivers on all domain controllers in the domain, add users with caution. This group can't be renamed, deleted, or removed.\r\n\r\nThe Print Operators group applies to the Windows Server operating system in Default Active Directory security groups.\r\n\r\nFor more information, see Assign delegated print administrator and printer permission settings in Windows Server 2012.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Print Operators group has the local privilege on the domain controllers to load device drivers and can log on locally on domain controllers by default.\r\n\r\nIt is feasible to remove the logon privilege from the group on the domain controllers, such that the group has no known abusable path to Tier Zero. However, the local privilege to load device drivers is considered a security dependency for the domain controllers, and the group is therefore considered Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH 'S-1-5-32-550'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "YES",
    "Episode": "1",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#print-operators\r\nhttps://book.hacktricks.xyz/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges#print-operators"
  },
  {
    "Asset": "Read-only Domain Controllers",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<domain>-521",
    "Description": "This group is composed of the RODCs in the domain. An RODC makes it possible for organizations to easily deploy a domain controller in scenarios in which physical security can't be guaranteed, such as in branch office locations or when local storage of all domain passwords is considered a primary threat, like in an extranet or application-facing role.\r\n\r\nBecause you can delegate administration of an RODC to a domain user or security group, an RODC is well suited for a site that shouldn't have a user who is a member of the Domain Admins group. An RODC has the following functionality:\r\n\r\nContains read-only AD DS database\r\n\r\nUnidirectional replication\r\n\r\nCredential caching\r\n\r\nAdministrator role separation\r\n\r\nContains read-only Domain Name System (DNS)\r\n\r\nFor more information, see Understand planning and deployment for read-only domain controllers.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "NO",
    "Rationale": "The Read-only Domain Controllers group has no compromising privileges, and there are no known ways to abuse membership in the group to compromise Tier Zero.\r\n\r\nWhether the group is a security dependency for read-only domain controller servers is not clear, but read-only domain controller servers are not considered Tier Zero (only the read-only domain controller AD objects are). The Read-only Domain Controllers group is therefore not considered Tier Zero. We will dive deeper into how read-only domain controllers should be handled in one of the following blog posts.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH '-521'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "YES",
    "Episode": "1",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#read-only-domain-controllers"
  },
  {
    "Asset": "Schema Admins",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<root domain>-518",
    "Description": "Members of the Schema Admins group can modify the Active Directory schema. This group exists only in the root domain of an Active Directory forest of domains. This group is a Universal group if the domain is in native mode. This group is a Global group if the domain is in mixed mode.\r\n\r\nThe group is authorized to make schema changes in Active Directory. By default, the only member of the group is the Administrator account for the forest root domain. This group has full administrative access to the schema.\r\n\r\nAny of the service administrator groups in the root domain can modify the membership of this group. This group is considered a service administrator account because its members can modify the schema, which governs the structure and content of the entire directory.\r\n\r\nFor more information, see What is the Active Directory schema?\r\n\r\nThe Schema Admins group applies to the Windows Server operating system in Default Active Directory security groups.\r\n",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Schema Admins group has full control over the AD schema. This allows the group members to create or modify ACEs for future AD objects. An attacker could grant full control to a compromised principal on any object type and wait for the next Tier Zero asset to be created, to then have a path to Tier Zero. This attack could be remediated by removing any unwanted ACEs on objects before they are promoted to Tier Zero, but we recommend considering the group as Tier Zero instead.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH '-518'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "YES",
    "Episode": "1",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#schema-admins\r\nhttps://cube0x0.github.io/Pocing-Beyond-DA/#schema-admins"
  },
  {
    "Asset": "Server Operators",
    "Category": "DC group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-32-549",
    "Description": "Members of the Server Operators group can administer domain controllers. This group exists only on domain controllers. By default, the group has no members. Members of the Server Operators group can take the following actions: sign in to a server interactively, create and delete network shared resources, start and stop services, back up and restore files, format the hard disk drive of the computer, and shut down the computer. This group can't be renamed, deleted, or removed.\r\n\r\nBy default, this built-in group has no members. The group has access to server configuration options on domain controllers. Its membership is controlled by the service administrator groups Administrators and Domain Admins in the domain, and by the Enterprise Admins group in the forest root domain. Members in this group can't change any administrative group memberships. This group is considered a service administrator account because its members have physical access to domain controllers. Members of this group can perform maintenance tasks like backup and restore, and they can change binaries that are installed on the domain controllers. See the group's default user rights in the following table.\r\n\r\nThe Server Operators group applies to the Windows Server operating system in Default Active Directory security groups.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Server Operators group has local privileges on the domain controllers and perform administrative operations as creating backups of all files. The group can log on locally on domain controllers by default.\r\n\r\nIt is feasible to remove the logon privilege from the group on the domain controllers, such that the group has no known abusable path to Tier Zero. However, the local privileges are considered security dependencies for the domain controllers, and the groups are therefore considered Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH 'S-1-5-32-549'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "YES",
    "Episode": "1",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#server-operators\r\nhttps://cube0x0.github.io/Pocing-Beyond-DA/#server-operators"
  },
  {
    "Asset": "Administrator",
    "Category": "AD user",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<domain>-500",
    "Description": "The Administrator account is a default account that is used in all versions of the Windows operating system on every computer and device. The Administrator account is used by the system administrator for tasks that require administrative credentials. This account cannot be deleted or locked out, but the account can be renamed or disabled.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The built-in Administrator account has admin access to DCs by default and is therefore Tier Zero.",
    "Cypher": "MATCH (n:User)\r\nWHERE n.objectid ENDS WITH '-500'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "YES",
    "Episode": "2",
    "References": "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn745899(v=ws.11)?redirectedfrom=MSDN#administrator-account"
  },
  {
    "Asset": "AdminSDHolder",
    "Category": "AD container",
    "Platform": "Active Directory",
    "Identification": "DistinguishedName: CN=AdminSDHolder,CN=System,<Domain DN>",
    "Description": "The purpose of the AdminSDHolder object is to provide \"template\" permissions for the protected accounts and groups in the domain. AdminSDHolder is automatically created as an object in the System container of every Active Directory domain.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The permissions configured on AdminSDHolder is a template that will be applied on Protected Groups and Users, by default every hour. Control over AdminSDHolder means you have control over the Protected Groups (and their members) and Users, which include Tier Zero groups such as Domain Admins. The AdminSDHolder container is therefore a Tier Zero object.",
    "Cypher": "MATCH (n:Domain)\r\nMATCH (m:Container)\r\nWHERE m.distinguishedname = 'CN=ADMINSDHOLDER,CN=SYSTEM,' + n.distinguishedname\r\nRETURN m",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "YES",
    "Episode": "2",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory"
  },
  {
    "Asset": "Allowed RODC Password Replication Group",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<domain>-571",
    "Description": "The purpose of this security group is to manage a read-only domain controller (RODC) password replication policy. This group has no members by default, and it results in the condition that new RODCs don't cache user credentials. The Denied RODC Password Replication group contains various high-privilege accounts and security groups. The Denied RODC Password Replication group supersedes the Allowed RODC Password Replication group.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "NO",
    "Rationale": "The Allowed RODC Password Replication Group has no control by default. By default, this group is included in the msDS-RevealOnDemandGroup attribute of RODC computer objects, meaning that the RODC can retrieve the credentials of members of the group. Control over the group could potentially cause an attack path to Tier Zero if the attacker has administrative access to an RODC host and the RODC is misconfigured to not deny replication of Tier Zero principals. An attacker could add a targeted Tier Zero user to this group. With admin access to an RODC computer, the attacker can dump the RODC krbtgt account to create a Golden RODC TGT for the targeted Tier Zero user. This Golden RODC TGT can be exchanged with a real TGT when the targeted user is in the msDS-RevealOnDemandGroup attribute through the membership of Allowed RODC Password Replication Group, unless the target user is in the msDS-NeverRevealGroup attribute.\r\n\r\nAll Tier Zero users and computers should be in the msDS-NeverRevealGroup attribute to ensure they cannot be compromised by being added to the Allowed RODC Password Replication Group. When this practice is followed, this group can be treated as a non-Tier Zero group and non-Tier Zero admins can manage membership of the group.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH '-571'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "2",
    "References": "https://posts.specterops.io/at-the-edge-of-tier-zero-the-curious-case-of-the-rodc-ef5f1799ca06\r\nhttps://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#allowed-rodc-password-replication"
  },
  {
    "Asset": "Denied RODC Password Replication Group",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<domain>-572",
    "Description": "Passwords of members of the Denied RODC Password Replication group can't be replicated to any RODC.\r\n\r\nThe purpose of this security group is to manage a RODC password replication policy. This group contains various high-privilege accounts and security groups. The Denied RODC Password Replication group supersedes the Allowed RODC Password Replication group.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "NO",
    "Rationale": "The Denied RODC Password Replication Group has no control by default. By default, this group is included in the msDS-NeverRevealGroup attribute of RODC computer objects, meaning that the RODC cannot retrieve the credentials of members of the group. Control over the group could potentially cause an attack path to Tier Zero if the attacker has administrative access to the OS of an RODC and a target Tier Zero principal is in the msDS-RevealOnDemandGroup attribute by group membership. The attacker could remove the targeted Tier Zero principal from the Denied RODC Password Replication Group, and with admin access to the RODC computer, the attacker could dump the RODC krbtgt account to create a Golden RODC TGT for the targeted Tier Zero principal. This Golden RODC TGT can be exchanged with a real TGT now the targeted user is no longer in msDS-NeverRevealGroup.\r\n\r\nAll Tier Zero users and computers should be in the msDS-NeverRevealGroup attribute by dedicated Tier Zero groups to ensure they cannot be compromised through RODCs, rather than through membership of this group. When this practice is followed, this group can be treated as a non-Tier Zero group and non-Tier Zero admins can manage membership of this group.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH '-572'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "2",
    "References": "https://posts.specterops.io/at-the-edge-of-tier-zero-the-curious-case-of-the-rodc-ef5f1799ca06\r\nhttps://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#denied-rodc-password-replication"
  },
  {
    "Asset": "Domain Controllers (OU)",
    "Category": "AD OU",
    "Platform": "Active Directory",
    "Identification": "DistinguishedName: OU=Domain Controllers,<Domain DN>",
    "Description": "When domain controllers are added to the domain, their computer objects are automatically added to the Domain Controller OU. This OU has a default set of policies applied to it. To ensure that these policies are applied uniformly to all domain controllers, we recommend that you not move the computer objects of the domain controllers out of this OU. Failure to apply the default policies can cause a domain controller to fail to function properly.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "Inheritance is not disabled by default on DCs and RODCs, which means they can inherit permissions placed on the Domain Controllers OU. An attacker could thereby grant themselves GenericAll on DCs and RODCs, which enable the attacker to perform a domain compromise. If the attacker has the privilege to create or modify GPOs, the attacker could compromise DCs with a malicious GPO. For these reasons, the Domain Controllers OU is Tier Zero.",
    "Cypher": "MATCH (n:Domain)\r\nMATCH (m:OU)\r\nWHERE m.distinguishedname = 'OU=DOMAIN CONTROLLERS,' + n.distinguishedname\r\nRETURN m",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "2",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/delegating-administration-of-default-containers-and-ous#domain-controller-ou"
  },
  {
    "Asset": "Domain root object",
    "Category": "AD object",
    "Platform": "Active Directory",
    "Identification": "Top object in the Default Naming Context",
    "Description": "A Domain root object represents the AD domain. It contains all AD objects in the Default Naming Context.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "An attacker with control over the domain root object can compromise the domain in multiple ways, for example by a DCSync attack (see reference). The domain root object is therefore Tier Zero.",
    "Cypher": "MATCH (n:Domain)\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "2",
    "References": "https://adsecurity.org/?p=1729"
  },
  {
    "Asset": "Enterprise Read-only Domain Controllers",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<root domain>-498",
    "Description": "Members of this group are RODCs in the enterprise. Except for account passwords, an RODC holds all the Active Directory objects and attributes that a writable domain controller holds. However, changes can't be made to the database that's stored on the RODC. Changes must be made on a writable domain controller and then replicated to the RODC.\r\n\r\nRODCs address some of the issues that are commonly found in branch offices. These locations might not have a domain controller, or they might have a writable domain controller but not the physical security, network bandwidth, or local expertise to support it.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "NO",
    "Tier Zero": "NO",
    "Rationale": "The group has no Tier Zero privileges and is not a security dependency for Tier Zero. The Enterprise Read-only Domain Controllers group has the GetChanges privilege on all domains in the forest. This is not enough to perform DCSync, where the GetChangesAll privilege is also required.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH '-498'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "2",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#enterprise-read-only-domain-controllers"
  },
  {
    "Asset": "GPO linked to Tier Zero container",
    "Category": "AD object",
    "Platform": "Active Directory",
    "Identification": "ObjectClass: groupPolicyContainer",
    "Description": "A Group Policy Object (GPO) is a virtual collection of policy settings. A GPO has a unique name, such as a GUID.\r\n\r\nGroup Policy settings are contained in a GPO. A GPO can represent policy settings in the file system and in the Active Directory. GPO settings are evaluated by clients using the hierarchical nature of Active Directory.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "Control over a GPO allows you to compromise users and computers affected by the GPO (see references). If a GPO is linked to a Tier Zero container (Domain, OU, or Site), then the GPO is Tier Zero. ",
    "Cypher": "MATCH (n:GPO)-[:GPLink]->()-[:Contains]->(m:Base)\r\nWHERE 'admin_tier_0' IN split(m.system_tags, ' ')\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "2",
    "References": "https://learn.microsoft.com/en-us/previous-versions/windows/desktop/policy/group-policy-objects\r\nhttps://wald0.com/?p=179\r\nhttps://www.trustedsec.com/blog/weaponizing-group-policy-objects-access/"
  },
  {
    "Asset": "GPO NOT linked to Tier Zero container",
    "Category": "AD object",
    "Platform": "Active Directory",
    "Identification": "ObjectClass: groupPolicyContainer",
    "Description": "A Group Policy Object (GPO) is a virtual collection of policy settings. A GPO has a unique name, such as a GUID.\r\n\r\nGroup Policy settings are contained in a GPO. A GPO can represent policy settings in the file system and in the Active Directory. GPO settings are evaluated by clients using the hierarchical nature of Active Directory.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "NO",
    "Tier Zero": "NO",
    "Rationale": "Control over a GPO allows you to compromise users and computers affected by the GPO (see references). If a GPO is not linked to a Tier Zero container (Domain, OU, or Site), then the GPO does not effect Tier Zero principals and is therefore not Tier Zero. ",
    "Cypher": "MATCH (n:GPO)\r\nOPTIONAL MATCH p = (n)-[:GPLink]->()-[:Contains]->(m:Base)\r\nWHERE 'admin_tier_0' IN split(m.system_tags, ' ')\r\nWITH n,p\r\nWHERE p IS NULL\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "2",
    "References": "https://learn.microsoft.com/en-us/previous-versions/windows/desktop/policy/group-policy-objects\r\nhttps://wald0.com/?p=179\r\nhttps://www.trustedsec.com/blog/weaponizing-group-policy-objects-access/"
  },
  {
    "Asset": "krbtgt",
    "Category": "AD user",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<domain>-502",
    "Description": "The KRBTGT account is a local default account that acts as a service account for the Key Distribution Center (KDC) service. This account cannot be deleted, and the account name cannot be changed. The KRBTGT account cannot be enabled in Active Directory.\r\n\r\nKRBTGT is also the security principal name used by the KDC for a Windows Server domain, as specified by RFC 4120. The KRBTGT account is the entity for the KRBTGT security principal, and it is created automatically when a new domain is created.\r\n\r\nWindows Server Kerberos authentication is achieved by the use of a special Kerberos ticket-granting ticket (TGT) enciphered with a symmetric key. This key is derived from the password of the server or service to which access is requested. The TGT password of the KRBTGT account is known only by the Kerberos service. In order to request a session ticket, the TGT must be presented to the KDC. The TGT is issued to the Kerberos client from the KDC.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The krbtgt's credentials allow one to create golden ticket and compromise the domain. Therefore, if you obtain the credentials of this account, then you can authenticate as any Tier Zero user. However, there is currently no known privilege on the object to obtain the Kerberos keys or to compromise the account in any other way. When you reset the password of krbtgt, AD will ignore your password input and use a random string instead. So, the reset password privilege does not work for a compromise. An attacker could use the reset password privilege to harm Tier Zero, as a double password reset causes all Kerberos TGTs in the domain to become invalid. So, since control over the account can harm Tier Zero, and there is no reason for delegating control to non-Tier Zero, the krbtgt is Tier Zero.",
    "Cypher": "MATCH (n:User)\r\nWHERE n.objectid ENDS WITH '-502'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "YES",
    "Episode": "2",
    "References": "https://adsecurity.org/?p=483\r\nhttps://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn745899(v=ws.11)?redirectedfrom=MSDN#krbtgt-account"
  },
  {
    "Asset": "RODC computer object",
    "Category": "AD computer",
    "Platform": "Active Directory",
    "Identification": "AD attribute msDS-isRODC: True",
    "Description": "A read-only domain controller (RODC) is a new type of domain controller in the Windows Server 2008 operating system. With an RODC, organizations can easily deploy a domain controller in locations where physical security cannot be guaranteed. An RODC hosts read-only partitions of the Active Directory Domain Services (AD DS) database.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "An attacker with control over a RODC computer object can compromise Tier Zero principals. The attacker can modify the msDS-RevealOnDemandGroup and msDS-NeverRevealGroup attributes of the RODC computer object such that the RODC can retrieve the credentials of a targeted Tier Zero principal. The attacker can obtain admin access to the OS of the RODC through the managedBy attribute, from where they can obtain the credentials of the RODC krbtgt account. With that, the attacker can create a RODC golden ticket for the target principal. This ticket can be converted to a real golden ticket as the target has been added to the msDS-RevealOnDemandGroup attribute and is not protected by the msDS-NeverRevealGroup attribute. Therefore, the RODC computer object is Tier Zero.",
    "Cypher": "MATCH (n:Computer)-[:MemberOf]->(m:Group) \r\nWHERE m.objectid ENDS WITH '-521'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "2",
    "References": "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc732801(v=ws.10)\r\nhttps://posts.specterops.io/at-the-edge-of-tier-zero-the-curious-case-of-the-rodc-ef5f1799ca06"
  },
  {
    "Asset": "RODC host",
    "Category": "Computer host",
    "Platform": "Active Directory",
    "Identification": "Not applicable - Not represented as an object",
    "Description": "A read-only domain controller (RODC) is a new type of domain controller in the Windows Server 2008 operating system. With an RODC, organizations can easily deploy a domain controller in locations where physical security cannot be guaranteed. An RODC hosts read-only partitions of the Active Directory Domain Services (AD DS) database.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "NO",
    "Rationale": "An attacker with admin access to the OS of a RODC computer can compromise any principal which is in the msDS-RevealOnDemandGroup attribute of the RODC computer object if the principal is not in the msDS-NeverRevealGroup attribute of the RODC computer object. All Tier Zero principals should be protected in the msDS-NeverRevealGroup attribute, which will prevent a compromise of Tier Zero. The RODC computer OS is not Tier Zero if that practice is followed. That means non-Tier Zero users who belong to a remote office where the RODC computer is located are allowed to log in on the RODC computer with admin access.",
    "Cypher": "MATCH (n:Computer)-[:MemberOf]->(m:Group) \r\nWHERE m.objectid ENDS WITH '-521' \r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "N/A",
    "Episode": "2",
    "References": "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc732801(v=ws.10)\r\nhttps://posts.specterops.io/at-the-edge-of-tier-zero-the-curious-case-of-the-rodc-ef5f1799ca06"
  },
  {
    "Asset": "RODC krbtgt",
    "Category": "AD user",
    "Platform": "Active Directory",
    "Identification": "SAMAccountName: krbtgt_<x digits>, and msDS-SecondaryKrbTgtNumber attribute set to same <x digits>",
    "Description": "The RODC is advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a different KRBTGT account and password than the KDC on a writable domain controller when it signs or encrypts ticket-granting ticket (TGT) requests. After an account is successfully authenticated, the RODC determines whether a user's credentials or a computer's credentials can be replicated from the writable domain controller to the RODC by using the Password Replication Policy.\r\n\r\nAfter the credentials are cached on the RODC, the RODC can accept that user's sign-in requests until the credentials change. When a TGT is signed with the KRBTGT account of the RODC, the RODC recognizes that it has a cached copy of the credentials. If another domain controller signs the TGT, the RODC forwards requests to a writable domain controller.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "NO",
    "Rationale": "The RODC krbtgt's credentials allow one to obtain a golden ticket for any account in the msDS-RevealOnDemandGroup attribute of the RODC computer object if the account is not in the msDS-NeverRevealGroup attribute. All Tier Zero principals should be protected in the msDS-NeverRevealGroup attribute, which will prevent a compromise of Tier Zero. The RODC krbtgt account is not Tier Zero if that practice is followed.",
    "Cypher": "MATCH (n:User)\r\nWHERE n.name STARTS WITH 'KRBTGT_'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "2",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts#read-only-domain-controllers-and-the-krbtgt-account\r\nhttps://posts.specterops.io/at-the-edge-of-tier-zero-the-curious-case-of-the-rodc-ef5f1799ca06"
  },
  {
    "Asset": "Users (container)",
    "Category": "AD container",
    "Platform": "Active Directory",
    "Identification": "DistinguishedName: CN=Users,<Domain DN>",
    "Description": "The users and computers containers are the default locations for all new user accounts and non-domain-controller computer accounts in the domain.\r\n\r\nIf you need to delegate control over users or computers, do not modify the default settings on the users and computers containers. Instead, create new OUs (as needed) and move the user and computer objects from their default containers and into the new OUs. Delegate control over the new OUs, as needed. We recommend that you not modify who controls the default containers.",
    "Tier Zero Default Risk": "YES - Disruption",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Users container contains multiple default Tier Zero objects by default and is therefore considered Tier Zero. The most privileged ones like Domain Admins are protected with AdminSDHolder and have ACL inheritance disabled, so control over the Users container does not enable compromise of these objects. But some Tier Zero objects such as Cert Publishers and DnsAdmins are not protected with AdminSDHolder and do have inheritance disabled, which means they can be compromised by an attacker with control over the Users container. However, the Tier Zero objects that can be compromised can only disrupt Tier Zero operation but not takeover Tier Zero.\r\n\r\nWe recommend to move all Tier Zero objects from the Users container to dedicated Tier Zero OUs to make it clear what belongs to Tier Zero in the OU structure. The Users container is not Tier Zero when this practice is followed.",
    "Cypher": "MATCH (n:Domain)\r\nMATCH (m:Container)\r\nWHERE m.distinguishedname = 'CN=USERS,' + n.distinguishedname\r\nRETURN m",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "2",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/delegating-administration-of-default-containers-and-ous#users-and-computers-containers"
  },
  {
    "Asset": "Application Administrator",
    "Category": "Entra ID role",
    "Platform": "Entra ID",
    "Identification": "Template ID: 9b895d92-2cd3-44c7-9d02-a6ac2d5ea5c3",
    "Description": "This is a privileged role. Users in this role can create and manage all aspects of enterprise applications, application registrations, and application proxy settings. Note that users assigned to this role are not added as owners when creating new application registrations or enterprise applications.\r\n\r\nThis role also grants the ability to consent for delegated permissions and application permissions, with the exception of application permissions for Microsoft Graph.\r\n\r\nImportant: This exception means that you can still consent to application permissions for other apps (for example, non-Microsoft apps or apps that you have registered). You can still request these permissions as part of the app registration, but granting (that is, consenting to) these permissions requires a more privileged administrator, such as Global Administrator.\r\n\r\nThis role grants the ability to manage application credentials. Users assigned this role can add credentials to an application, and use those credentials to impersonate the application's identity. If the application's identity has been granted access to a resource, such as the ability to create or update User or other objects, then a user assigned to this role could perform those actions while impersonating the application. This ability to impersonate the application's identity may be an elevation of privilege over what the user can do via their role assignments. It is important to understand that assigning a user to the Application Administrator role gives them the ability to impersonate an application's identity.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "IT DEPENDS",
    "Rationale": "The Application Administrator role can control tenant-resident apps. This includes creating new credentials for apps, which can be used to authenticate the tenant as the app's service principal and abuse the service principal privileges. The role is therefore considered Tier Zero if the tenant contains any Tier Zero service principals.",
    "Cypher": "MATCH (n:AZRole) \r\nWHERE n.objectid STARTS WITH '9B895D92-2CD3-44C7-9D02-A6AC2D5EA5C3@'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "N/A",
    "Episode": "3",
    "References": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#application-administrator"
  },
  {
    "Asset": "Global Administrator",
    "Category": "Entra ID role",
    "Platform": "Entra ID",
    "Identification": "Template ID: 62e90394-69f5-4237-9190-012177145e10",
    "Description": "This is a privileged role. Users with this role have access to all administrative features in Microsoft Entra ID, as well as services that use Microsoft Entra identities like the Microsoft 365 Defender portal, the Microsoft Purview compliance portal, Exchange Online, SharePoint Online, and Skype for Business Online. Global Administrators can view Directory Activity logs. Furthermore, Global Administrators can elevate their access to manage all Azure subscriptions and management groups. This allows Global Administrators to get full access to all Azure resources using the respective Microsoft Entra tenant. The person who signs up for the Microsoft Entra organization becomes a Global Administrator. There can be more than one Global Administrator at your company. Global Administrators can reset the password for any user and all other administrators. A Global Administrator cannot remove their own Global Administrator assignment. This is to prevent a situation where an organization has zero Global Administrators.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Global Administrator role is the highest privilege role in Entra ID and inarguably part of Tier Zero. It can do almost anything, and grant permission to do the things it cannot do.",
    "Cypher": "MATCH (n:AZRole) \r\nWHERE n.objectid STARTS WITH '62E90394-69F5-4237-9190-012177145E10@'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "N/A",
    "Episode": "3",
    "References": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#global-administrator"
  },
  {
    "Asset": "Intune Administrator",
    "Category": "Entra ID role",
    "Platform": "Entra ID",
    "Identification": "Template ID: 3a2c62db-5318-420d-8d74-23affee5d9d5",
    "Description": "This is a privileged role. Users with this role have global permissions within Microsoft Intune Online, when the service is present. Additionally, this role contains the ability to manage users and devices in order to associate policy, as well as create and manage groups. For more information, see Role-based administration control (RBAC) with Microsoft Intune.\r\n\r\nThis role can create and manage all security groups. However, Intune Administrator does not have admin rights over Office groups. That means the admin cannot update owners or memberships of all Office groups in the organization. However, he/she can manage the Office group that he creates which comes as a part of his/her end-user privileges. So, any Office group (not security group) that he/she creates should be counted against his/her quota of 250.",
    "Tier Zero Default Risk": "YES - Disruption",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "YES",
    "Rationale": "The Intune Administrator role has permission to execute scripts locally on Entra-managed devices. The role has therefore a potential attack path to Tier Zero through Entra-managed devices used by Tier Zero principals. Furthermore, the Intune Administrator role can manage Conditional Access, which can be abused to lower the security of Tier Zero or prevent the operability of Tier Zero. The role is therefore considered Tier Zero.",
    "Cypher": "MATCH (n:AZRole) \r\nWHERE n.objectid STARTS WITH '3A2C62DB-5318-420D-8D74-23AFFEE5D9D5@'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "N/A",
    "Episode": "3",
    "References": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#intune-administrator"
  },
  {
    "Asset": "Knowledge Administrator",
    "Category": "Entra ID role",
    "Platform": "Entra ID",
    "Identification": "Template ID: b5a8dcf3-09d5-43a9-a639-8e29ef291470",
    "Description": "Users in this role have full access to all knowledge, learning and intelligent features settings in the Microsoft 365 admin center. They have a general understanding of the suite of products, licensing details and have responsibility to control access. Knowledge Administrator can create and manage content, like topics, acronyms and learning resources. Additionally, these users can create content centers, monitor service health, and create service requests.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "IT DEPENDS",
    "Rationale": "The Knowledge Administrator role can control non-role-assignable groups. If any non-role-assignable group has compromising permissions over a Tier Zero asset (e.g. Contributor on a domain controller Azure VM), then the Knowledge Administrator role can add arbitrary principals to the given group and compromise Tier Zero. If no non-role-assignable group has compromising permissions over a Tier Zero asset, then there is no attack path to Tier Zero from the Knowledge Administrator role. It therefore depends on the usage of non-role-assignable groups whether the role should be considered Tier Zero.",
    "Cypher": "MATCH (n:AZRole) \r\nWHERE n.objectid STARTS WITH 'B5A8DCF3-09D5-43A9-A639-8E29EF291470@'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "N/A",
    "Episode": "3",
    "References": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#knowledge-administrator"
  },
  {
    "Asset": "Partner Tier2 Support",
    "Category": "Entra ID role",
    "Platform": "Entra ID",
    "Identification": "Template ID: e00e864a-17c5-4a4b-9c06-f5b95a8d5bd8",
    "Description": "This is a privileged role. Do not use. This role has been deprecated and will be removed from Microsoft Entra ID in the future. This role is intended for use by a small number of Microsoft resale partners, and is not intended for general use.\r\n\r\nImportant: This role can reset passwords and invalidate refresh tokens for all non-administrators and administrators (including Global Administrators). This role should not be used because it is deprecated.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Partner Tier2 Support role can reset the password for any principal, including principals with the Global Administrator role. The role is therefore considered Tier Zero.",
    "Cypher": "MATCH (n:AZRole) \r\nWHERE n.objectid STARTS WITH 'E00E864A-17C5-4A4B-9C06-F5B95A8D5BD8@'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "N/A",
    "Episode": "3",
    "References": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#partner-tier2-support"
  },
  {
    "Asset": "Privileged Authentication Administrator",
    "Category": "Entra ID role",
    "Platform": "Entra ID",
    "Identification": "Template ID: 7be44c8a-adaf-4e2a-84d6-ab2649e08a13",
    "Description": "This is a privileged role. Assign the Privileged Authentication Administrator role to users who need to do the following:\r\n- Set or reset any authentication method (including passwords) for any user, including Global Administrators.\r\n- Delete or restore any users, including Global Administrators. For more information, see Who can perform sensitive actions.\r\n- Force users to re-register against existing non-password credential (such as MFA or FIDO) and revoke remember MFA on the device, prompting for MFA on the next sign-in of all users.\r\n- Update sensitive properties for all users. For more information, see Who can perform sensitive actions.\r\n- Create and manage support tickets in Azure and the Microsoft 365 admin center.\r\n\r\nUsers with this role cannot do the following:\r\n- Cannot manage per-user MFA in the legacy MFA management portal.\r\n\r\nImportant: Users with this role can change credentials for people who may have access to sensitive or private information or critical configuration inside and outside of Microsoft Entra ID. Changing the credentials of a user may mean the ability to assume that user's identity and permissions. For example:\r\n- Application Registration and Enterprise Application owners, who can manage credentials of apps they own. Those apps may have privileged permissions in Microsoft Entra ID and elsewhere not granted to Authentication Administrators. Through this path an Authentication Administrator can assume the identity of an application owner and then further assume the identity of a privileged application by updating the credentials for the application.\r\n- Azure subscription owners, who may have access to sensitive or private information or critical configuration in Azure.\r\n- Security Group and Microsoft 365 group owners, who can manage group membership. Those groups may grant access to sensitive or private information or critical configuration in Microsoft Entra ID and elsewhere.\r\n- Administrators in other services outside of Microsoft Entra ID like Exchange Online, Microsoft 365 Defender portal, and Microsoft Purview compliance portal, and human resources systems.\r\n- Non-administrators like executives, legal counsel, and human resources employees who may have access to sensitive or private information.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Privileged Authentication Administrator role can set or reset any authentication method (including passwords) for any principal, including principals with the Global Administrator role. The role is therefore considered Tier Zero.",
    "Cypher": "MATCH (n:AZRole) \r\nWHERE n.objectid STARTS WITH '7BE44C8A-ADAF-4E2A-84D6-AB2649E08A13@'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "N/A",
    "Episode": "3",
    "References": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#privileged-authentication-administrator"
  },
  {
    "Asset": "Privileged Role Administrator",
    "Category": "Entra ID role",
    "Platform": "Entra ID",
    "Identification": "Template ID: e8611ab8-c189-46e8-94e1-60213ab1f814",
    "Description": "This is a privileged role. Users with this role can manage role assignments in Microsoft Entra ID, as well as within Microsoft Entra Privileged Identity Management. They can create and manage groups that can be assigned to Microsoft Entra roles. In addition, this role allows management of all aspects of Privileged Identity Management and administrative units.\r\n\r\n Important: This role grants the ability to manage assignments for all Microsoft Entra roles including the Global Administrator role. This role does not include any other privileged abilities in Microsoft Entra ID like creating or updating users. However, users assigned to this role can grant themselves or others additional privilege by assigning additional roles.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Privileged Role Administrator role can grant any other admin role to any principal at the tenant level. The role is therefore considered Tier Zero.",
    "Cypher": "MATCH (n:AZRole) \r\nWHERE n.objectid STARTS WITH 'E8611AB8-C189-46E8-94E1-60213AB1F814@'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "N/A",
    "Episode": "3",
    "References": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#privileged-role-administrator"
  },
  {
    "Asset": "Security Administrator",
    "Category": "Entra ID role",
    "Platform": "Entra ID",
    "Identification": "Template ID: 194ae4cb-b126-40b2-bd5b-6091b380977d",
    "Description": "This is a privileged role. Users with this role have permissions to manage security-related features in the Microsoft 365 Defender portal, Microsoft Entra ID Protection, Microsoft Entra Authentication, Azure Information Protection, and Microsoft Purview compliance portal. For more information about Office 365 permissions, see Roles and role groups in Microsoft Defender for Office 365 and Microsoft Purview compliance.",
    "Tier Zero Default Risk": "YES - Disruption",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "YES",
    "Rationale": "The Security Administrator role has access to Live Response API (if not disabled) with permission to execute scripts locally on Entra-managed devices. The role has therefore a potential attack path to Tier Zero through Entra-managed devices used by Tier Zero principals. Furthermore, the Security Administrator role can manage Conditional Access, which can be abused to lower the security of Tier Zero or prevent the operability of Tier Zero. The role is therefore considered Tier Zero.",
    "Cypher": "MATCH (n:AZRole) \r\nWHERE n.objectid STARTS WITH '194AE4CB-B126-40B2-BD5B-6091B380977D@'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "N/A",
    "Episode": "3",
    "References": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#security-administrator"
  },
  {
    "Asset": "AIA CA (AD object)",
    "Category": "AD object",
    "Platform": "Active Directory",
    "Identification": "ObjectClass certificateAuthority, under CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,<Forest root domain DN>",
    "Description": "Authority Information Access (AIA) CA objects store intermediate CA certificates and cross-certificates.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Disruption",
    "Tier Zero": "YES",
    "Rationale": "The AIA CA objects may represent offline enterprise CAs or cross CAs. In such cases, deleting the AIA CA object would cause certificates, potentially of Tier Zero principals, to lose trust. We therefore recommend to treat AIACAs as Tier Zero.",
    "Cypher": "MATCH (n:AIACA) \r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "4",
    "References": "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786443(v=ws.11)\r\nhttps://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf"
  },
  {
    "Asset": "Cert Publishers",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<domain>-517",
    "Description": "Members of the Cert Publishers group are authorized to publish certificates for User objects in Active Directory.",
    "Tier Zero Default Risk": "YES - Disruption",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "YES",
    "Rationale": "The Cert Publishers group has full control permissions on root CA and AIA CA objects. This enables an attacker to add or remove certificates for these objects, which are trusted throughout the AD forest. As certificate authentication requires the certificate to chain up to a trusted root CA, an attacker could prevent successful authentication for AD accounts and disrupt Tier Zero operations. The group is therefore Tier Zero.\r\n\r\nIn some environments, the group also has full control over the NTAuth store. In that scenario, the group can take over the forest by adding a forged root certificate, making it trusted for NTAuth.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH '-517'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "4",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#cert-publishers\r\nhttps://decoder.cloud/2023/11/20/a-deep-dive-in-cert-publishers-group/"
  },
  {
    "Asset": "Certificate template",
    "Category": "AD object",
    "Platform": "Active Directory",
    "Identification": "ObjectClass: pKICertificateTemplate",
    "Description": "Contains information for certificates issued by Certificate Server.",
    "Tier Zero Default Risk": "IT DEPENDS",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "Control over a certificate template enables the ADCS ESC4 attack and Tier Zero takeover if the template is published to a CA trusted in the NTAuth store and that chains up to a trusted root CA. There are default templates that meet this requirement; others remain unpublished. A template cannot be used if it is not published, making control over an unpublished object less concerning. However, if it is ever published, it becomes a risk. We, therefore, recommend treating all certificate templates as Tier Zero objects, whether published or not.",
    "Cypher": "MATCH (n:CertTemplate) \r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "4",
    "References": "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786443(v=ws.11)\r\nhttps://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf"
  },
  {
    "Asset": "Enterprise CA (AD object)",
    "Category": "AD object",
    "Platform": "Active Directory",
    "Identification": "ObjectClass: pKIEnrollmentService",
    "Description": "The certificate server that can process certificate requests and issue certificates.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "YES",
    "Rationale": "Control over an enterprise CA object enables an attacker to publish certificate templates. If any templates that allow ADCS domain escalation exist but are unpublished, then control over the enterprise CA object could enable a takeover of Tier Zero. An attacker could potentially also disrupt or takeover Tier Zero by deleting the certificate of the enterprise CA or changing the DNShostName of the enterprise CA to an attcker-controlled host. Enterprise CA objects are therfore Tier Zero.\r\n\r\nIf the enterprise CA certificate is removed from the NTAuth store, certificates from this CA cannot be used for domain authentication, thus preventing a Tier Zero takeover.",
    "Cypher": "MATCH (n:EnterpriseCA) \r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "4",
    "References": "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786443(v=ws.11)\r\nhttps://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf"
  },
  {
    "Asset": "Enterprise CA computer",
    "Category": "AD computer",
    "Platform": "Active Directory",
    "Identification": "DNSHostName matching the DNSHostName of the enterprise CA AD object.",
    "Description": "The AD object for the computer hosting the enterprise CA service.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "Enterprise CAs can by default issue certificates that enable authentication as anyone, thereby allowing takeover of Tier Zero. An attacker with admin rights on an enterprise CA can obtain a certificate as any user in different ways. One option is to dump the private key of the CA and craft a 'golden certificate' as a target user. This attack can be prevented by protecting the private key with hardware. Alternatively, the attacker can publish any template, modify pending certificate requests, and issue denied requests, which typically also enable a takeover of Tier Zero. Enterprise CA computer objects are therefore Tier Zero.\r\n\r\nIf the enterprise CA certificate is removed from the NTAuth store, then certificates from this CA cannot be used for domain authentication, thus preventing a Tier Zero takeover.",
    "Cypher": "MATCH (n:Computer)-[:HostsCAService]->(m:EnterpriseCA) \r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "4",
    "References": "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786443(v=ws.11)\r\nhttps://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf"
  },
  {
    "Asset": "Exchange Trusted Subsystem",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "CN: Exchange Trusted Subsystem",
    "Description": "This group contains Exchange servers that run Exchange cmdlets on behalf of users via Management service. Its members will have permission to read and modify all Exchange configuration, as well as user accounts and groups. This group should not be deleted.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Exchange Trusted Subsystem group has takeover permissions on all users with the default ACL inheritance enabled from the domain, regardless of the permission model Exchange is configured to. The compromising permission is write access to the AltSecurityIdentities attribute, which allows an attacker to add an explicit mapping for the user for domain authentication. Typically, some Tier Zero users inherit permissions from the domain. The group is therefore Tier Zero.\r\n\r\nThe group can only be treated as non-Tier Zero if all Tier Zero users are protected from this compromising permission.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.name STARTS WITH 'EXCHANGE TRUSTED SUBSYSTEM@'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "NO",
    "Episode": "4",
    "References": "https://learn.microsoft.com/en-us/exchange/permissions/split-permissions/configure-exchange-for-shared-permissions?view=exchserver-2019\r\nhttps://posts.specterops.io/pwned-by-the-mail-carrier-0750edfad43b"
  },
  {
    "Asset": "Exchange Windows Permissions",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "CN: Exchange Windows Permissions",
    "Description": "This group contains Exchange servers that run Exchange cmdlets on behalf of users via Management service. Its members will have permission to read and modify all Windows accounts and groups. This group should not be deleted.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Exchange Windows Permissions group has takeover permissions on all users (WriteDACL and reset password) and all groups (edit membership) with the default ACL inheritance enabled from the domain, if Exchange is configured with the default shared permission model or the RBAC split model. Typically, some Tier Zero users and groups inherit permissions from the domain. The group is therefore Tier Zero.\r\n\r\nIf Exchange is configured in the AD split model, then this group has no compromising permissions and can be treated as non-Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.name STARTS WITH 'EXCHANGE WINDOWS PERMISSIONS@'\r\nRETURN n",
    "Microsoft PAS Role": "YES",
    "AdminSDHolder Protected": "NO",
    "Episode": "4",
    "References": "https://learn.microsoft.com/en-us/exchange/permissions/split-permissions/configure-exchange-for-shared-permissions?view=exchserver-2019\r\nhttps://posts.specterops.io/pwned-by-the-mail-carrier-0750edfad43b"
  },
  {
    "Asset": "NTAuth store",
    "Category": "AD object",
    "Platform": "Active Directory",
    "Identification": "DistinguishedName: CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,<Forest root domain DN>",
    "Description": "The NTAuth store object is used to store the CA certificates trusted for domain authentication.",
    "Tier Zero Default Risk": "YES - Disruption",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "YES",
    "Rationale": "The NTAuth store is a security dependency for Tier Zero. A certificate that impersonates any user in AD must chain up to a trusted root CA and be issued by a CA trusted by the NTAuth store. With control over a root CA and the NTAuth store, an attacker can make an attacker-controlled root CA certificate meet these requirements and issue certificates as anyone, taking over Tier Zero. Control over the NTAuth store alone may be sufficient to disrupt Tier Zero operations, as the attacker can delete CA certificates that Tier Zero principals or systems rely on for authentication. The NTAuth store is therefore Tier Zero.",
    "Cypher": "MATCH (n:NTAuthStore) \r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "4",
    "References": "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786443(v=ws.11)\r\nhttps://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf\r\nhttps://www.gradenegger.eu/en/cleaning-up-the-ntauthcertificates-object/"
  },
  {
    "Asset": "Root CA (AD object)",
    "Category": "AD object",
    "Platform": "Active Directory",
    "Identification": "ObjectClass certificateAuthority, under CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,<Forest root domain DN>",
    "Description": "Root CA objects store root CA certificates.",
    "Tier Zero Default Risk": "YES - Disruption",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "YES",
    "Rationale": "A root CA is a security dependency for Tier Zero. A certificate that impersonates any user in AD must chain up to a trusted root CA and be issued by a CA trusted by the NTAuth store. With control over a root CA and the NTAuth store, an attacker can make an attacker-controlled root CA certificate meet these requirements and issue certificates as anyone, taking over Tier Zero. Control over a root CA alone may be sufficient to disrupt Tier Zero operations, as the attacker can delete root CA certificates that Tier Zero principals or systems rely on for authentication. Root CA objects are therefore Tier Zero.",
    "Cypher": "MATCH (n:RootCA) \r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "4",
    "References": "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786443(v=ws.11)\r\nhttps://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf"
  },
  {
    "Asset": "DnsAdmins",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "CN: DnsAdmins",
    "Description": "Members of the DnsAdmins group have access to network DNS information. The default permissions are Allow: Read, Write, Create All Child objects, Delete Child objects, Special Permissions. This group exists only if the DNS server role is or was once installed on a domain controller in the domain.\r\n\r\nFor more information about security and DNS, see DNSSEC in Windows Server 2012.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "DnsAdmins controls DNS which enables an attacker to trick a privileged victim to authenticate against an attacker-controlled host as it was another host. This enables a Kerberos relay attack. Also, control over DNS enables disruption of Tier Zero since Kerberos depends on DNS by default.\r\n\r\nThe group could previously use a feature in the Microsoft DNS management protocol to make the DNS service load any DLL and thereby obtain a session as SYSTEM on the DNS server. This vulnerability was patched in Dec 2021.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.name STARTS WITH 'DNSADMINS@'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "Community contribution",
    "References": "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html\r\nhttps://www.labofapenetrationtester.com/2017/05/abusing-dnsadmins-privilege-for-escalation-in-active-directory.html"
  },
  {
    "Asset": "Enterprise Key Admins",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<root domain>-527",
    "Description": "Members of this group can perform administrative actions on key objects within the forest.",
    "Tier Zero Default Risk": "YES",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Enterprise Key Admins group has write access to the msds-KeyCredentialLink attribute on all users (not protected by AdminSDHolder) and on all computers in the AD forest. This enables the group to compromise all these principals through Shadow Credentials attacks. The group is therefore considered Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH '-527'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "YES",
    "Episode": "Community contribution",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#enterprise-key-admins\r\nhttps://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab"
  },
  {
    "Asset": "Key Admins",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-21-<domain>-526",
    "Description": "Members of this group can perform administrative actions on key objects within the domain.",
    "Tier Zero Default Risk": "YES",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "The Key Admins group has write access to the msds-KeyCredentialLink attribute on all users (not protected by AdminSDHolder) and on all computers in the AD domain. This enables the group to compromise all these principals through Shadow Credentials attacks. The group is therefore considered Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH '-526'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "YES",
    "Episode": "Community contribution",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#key-admins\r\nhttps://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab"
  },
  {
    "Asset": "Performance Log Users",
    "Category": "DC group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-32-559",
    "Description": "Members of the Performance Log Users group can manage performance counters, logs, and alerts locally on the server and from remote clients without being a member of the Administrators group. Specifically, members of this security group:\r\n- Can use all the features that are available to the Performance Monitor Users group.\r\n- Can create and modify Data Collector Sets after the group is assigned the Log on as a batch job user right.\r\n- Can't use the Windows Kernel Trace event provider in Data Collector Sets.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "NO",
    "Tier Zero": "YES",
    "Rationale": "The Performance Log Users group has local privileges on domain controllers to launch, activate, and use Distributed COM objects but no privilege to log in.\r\n\r\nThere are no known ways to abuse the membership of the group to compromise Tier Zero. The local privileges the group has on the DCs are considered security dependency, and the group is therefore considered Tier Zero.",
    "Cypher": "MATCH (n:Group)\r\nWHERE n.objectid ENDS WITH 'S-1-5-32-559'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "Community contribution",
    "References": "https://decoder.cloud/2024/04/24/hello-im-your-domain-admin-and-i-want-to-authenticate-against-you/\r\nhttps://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#performance-log-users"
  },
  {
    "Asset": "Incoming Forest Trust Builders",
    "Category": "DC group",
    "Platform": "Active Directory",
    "Identification": "SID: S-1-5-32-557",
    "Description": "Members of this group can create incoming, one-way trusts to this forest. (Creation of outbound forest trusts is reserved for Enterprise Admins.)\r\nMembers of this group can create incoming trusts that allow TGT delegation which can lead to compromise of your forest. To learn more about TGT delegation across incoming trust, Updates to TGT delegation across incoming trusts in Windows Server.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "NO",
    "Tier Zero": "YES",
    "Rationale": "The Incoming Forest Trust Builders group can create inbound forest trusts with TGT delegation enabled, which can contribute to a full domain compromise (see external link).",
    "Cypher": "MATCH (n:Group)\r\n\r\nWHERE n.objectid ENDS WITH 'S-1-5-32-557'\r\n\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "Community contribution",
    "References": "https://specterops.io/blog/2025/06/25/untrustworthy-trust-builders-account-operators-replicating-trust-attack-aorta/"
  },
  {
    "Asset": "Microsoft Entra Connect Server",
    "Category": "Computer host",
    "Platform": "Active Directory",
    "Identification": "Not applicable - Not represented as an object. Identify by locating hosts running the Microsoft Entra Connect Sync (ADSync) service. Microsoft Entra Connect Cloud Sync is a separate product that uses the Microsoft Entra provisioning agent and is not covered by this entry.",
    "Description": "Microsoft Entra Connect (formerly Azure AD Connect) is the on-premises component used to synchronize identity data between Active Directory and Microsoft Entra ID. It runs on a server that is typically domain-joined and holds the credentials of the AD DS Connector Account, which reads from Active Directory. With Password Hash Synchronization enabled, that account holds directory replication rights on the domain. Write access to Active Directory is granted only when writeback features such as password writeback, device writeback, or group writeback are separately enabled.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "Microsoft explicitly documents that the Microsoft Entra Connect server must be treated as a Tier 0 component, the same as a domain controller. An attacker with administrative access to the server's OS can extract the credentials of the AD DS Connector Account from the Microsoft Entra Connect (ADSync) database, which by default has the privileges to perform a DCSync attack against the domain when Password Hash Synchronization is enabled. This yields full compromise of the domain, and where Entra Connect also syncs to a cloud tenant, can be leveraged toward Global Administrator in Entra ID as well - for example by hijacking a vulnerable service principal reachable from the on-premises foothold. There is no known default configuration in which the server is not a security dependency for Tier Zero, so it is Tier Zero by default.",
    "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference server inventories/CMDB against known Microsoft Entra Connect installations.",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "N/A",
    "Episode": "Community contribution",
    "References": "https://docs.azure.cn/en-us/entra/identity/hybrid/connect/how-to-connect-install-prerequisites#azure-ad-connect-server\r\nhttps://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/\r\nhttps://adsecurity.org/?p=4825\r\nhttps://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71\r\nhttps://snotra.uk/from-domain-user-to-domain-admin-da-from-da-to-global-admin-ga.html"
  },
  {
    "Asset": "AD DS Connector Account",
    "Category": "AD user",
    "Platform": "Active Directory",
    "Identification": "SamAccountName typically prefixed 'MSOL_' (auto-provisioned) or a custom name if manually created. Holds DS-Replication-Get-Changes and DS-Replication-Get-Changes-All extended rights on the domain when Password Hash Synchronization is enabled.",
    "Description": "The AD DS Connector Account is the service account Microsoft Entra Connect uses to read from, and optionally write to, on-premises Active Directory. It is created automatically during setup (or supplied as an existing account) and its credentials are stored in the Microsoft Entra Connect (ADSync) database on the Entra Connect server.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "With Password Hash Synchronization enabled (the default and most common sync method), the AD DS Connector Account is granted the Get-Changes and Get-Changes-All extended rights on the domain root, making it capable of performing a DCSync attack and thereby equivalent to Domain Admins. An attacker with administrative access to the Entra Connect server can extract this account's plaintext credentials from the ADSync database and use them directly. The account is therefore Tier Zero.",
    "Cypher": "MATCH (n:User)-[:GetChanges]->(d:Domain)\r\nMATCH (n)-[:GetChangesAll]->(d)\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "Community contribution",
    "References": "https://docs.azure.cn/en-us/entra/identity/hybrid/connect/how-to-connect-install-prerequisites#azure-ad-connect-server\r\nhttps://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/\r\nhttps://posts.specterops.io/update-dumping-entra-connect-sync-credentials-4a9114734f71"
  },
  {
    "Asset": "ESX Admins",
    "Category": "AD group",
    "Platform": "Active Directory",
    "Identification": "CN: ESX Admins (default group name; configurable per-host via the advanced setting Config.HostAgent.plugins.hostsvc.esxAdminsGroup)",
    "Description": "The ESX Admins group is not created by Active Directory, but is looked up by name by ESXi hosts that have been joined directly to an AD domain for authentication. If a group with this name exists in AD (it is not created automatically), an ESXi host will grant the full Administrator role to all of its members wherever the auto-add behavior is in effect - that is, on hosts running a version before ESXi 8.0 Update 3, on hosts where the setting has been re-enabled, or where the group already holds an explicit Administrator permission granted before the host was upgraded: \"[a]dministrators of Active Directory implicitly become administrators of any ESXi host that trusts it.\" This is distinct from the AD-integrated vCenter Server scenario described under the \"vCenter Server\" entry.\r\n\r\nThe group name itself is not tracked by SID - only by its configured name - so an attacker who can create or recreate a group with the configured name (default \"ESX Admins\") in AD obtains the same elevated privileges even if the original group is renamed or deleted.",
    "Tier Zero Default Risk": "IT DEPENDS",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "IT DEPENDS",
    "Rationale": "Joining ESXi hosts to an Active Directory domain is not a default configuration, but is common in practice. Prior to vSphere 8.0 Update 3 (released October 2024, addressing CVE-2024-37085), the advanced setting Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd defaulted to true, so any AD group named per Config.HostAgent.plugins.hostsvc.esxAdminsGroup (default \"ESX Admins\") was automatically granted full Administrator privileges on every domain-joined ESXi host, with no further configuration required - simply creating a group with that name in AD was enough. Since 8.0 Update 3 this auto-add behavior is disabled by default and must be explicitly re-enabled per host, but many environments still run pre-8.0U3 hosts or have re-enabled the setting for compatibility.\r\n\r\nWhere this access exists and the affected ESXi host(s) run virtualized domain controllers or other Tier Zero systems, members of the group can access the underlying virtual disks directly (e.g. by cloning or mounting the VM's VMDK), bypassing the guest OS's security controls entirely, extract NTDS.dit and the SYSTEM registry hive, and perform an offline DCSync-equivalent credential extraction. This has been directly observed in ransomware intrusions (e.g. Scattered Spider/UNC3944) as a path to full domain compromise. Whether the group represents a default or configuration-dependent risk therefore depends on the vSphere version/patch level and host configuration, and whether it reaches Tier Zero depends on whether the affected host(s) run Tier Zero workloads.",
    "Cypher": "// Finds the default group name only. Hosts can be pointed at a different group via Config.HostAgent.plugins.hostsvc.esxAdminsGroup, so cross-reference that setting on each domain-joined ESXi host to find custom names.\r\nMATCH (n:Group)\r\nWHERE n.name STARTS WITH 'ESX ADMINS@'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "Community contribution",
    "References": "https://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vsphere-active-directory-integration-risks"
  },
  {
    "Asset": "vCenter Server",
    "Category": "Computer host",
    "Platform": "Active Directory",
    "Identification": "Not applicable - Not represented as an object. Identify by locating the vCenter Server Appliance managing ESXi hosts; check whether it has an Active Directory Identity Source configured under vCenter Single Sign-On; and check which vSphere roles (e.g. Administrator, or a custom role) are assigned to AD users/groups, and which virtual machines those role assignments are scoped to.",
    "Description": "vCenter Server is the centralized management platform for ESXi hosts and virtual machines, and is commonly configured with Active Directory as an Identity Source for vCenter Single Sign-On so that AD users and groups can be assigned vCenter roles (e.g. Administrator) without a separate local vCenter identity. A vCenter role holder with sufficient VM-level privileges (Administrator, or a custom role granting rights such as snapshot management, console access, or virtual disk access) can interact with any virtual machine the role is scoped to, regardless of that VM's guest-level permissions. This entry covers that application-level RBAC exposure; compromise of the underlying appliance OS itself is covered separately under \"vCenter Server Appliance\", the same way \"Enterprise CA (AD object)\" and \"Enterprise CA computer\" are treated as distinct assets in this table.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "IT DEPENDS",
    "Rationale": "Neither running Tier Zero systems (such as domain controllers) as virtual machines nor federating vCenter Single Sign-On to Active Directory is a default configuration, but both are common. Where a vCenter Server manages one or more Tier Zero VMs, and AD principals can be assigned a privileged vCenter role over those VMs (directly, through an AD-backed Identity Source, or through a custom role such as \"vCenter Admins\"/\"VMware Global Administrators\"), those principals can compromise Tier Zero without ever authenticating to the guest OS or touching the appliance itself. For example, a vCenter Administrator can snapshot or clone a domain controller VM and mount its virtual disk offline to extract NTDS.dit and the SYSTEM registry hive, or use console/remote-console access, hot-add a malicious virtual disk, or modify VM boot options to obtain code execution inside the guest. This has been directly observed in ransomware intrusions (e.g. Scattered Spider/UNC3944) as a path to full domain compromise. It is common for such vCenter roles to be granted more broadly than Domain Admins/Tier Zero membership, since vCenter administration is frequently delegated to virtualization/infrastructure teams rather than identity teams. Because both the presence of Tier Zero VMs under vCenter's management and the scope of AD-derived vCenter role assignments vary by environment, the vCenter Server is Tier Zero only in environments where these conditions apply, but this is the common case in practice.",
    "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference vCenter role assignments (Administrators, and any custom roles with VM-provisioning/snapshot/console rights) and their managed VM inventory against Tier Zero systems.",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "N/A",
    "Episode": "Community contribution",
    "References": "https://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vsphere-active-directory-integration-risks"
  },
  {
    "Asset": "vCenter Server Appliance",
    "Category": "AD computer",
    "Platform": "Active Directory",
    "Identification": "Locate the computer object matching the vCenter Server Appliance's hostname when Integrated Windows Authentication (IWA) is selected as the vCenter Single Sign-On Identity Source, which joins the appliance's underlying OS to the AD domain via a bundled Likewise agent. Not identifiable this way if AD is used only as a non-IWA Identity Source (LDAP/LDAPS) or not at all. Applies to vCenter Server 7.x and 8.x only - IWA was removed in vCenter Server 9.0, which cannot be joined to an AD domain.",
    "Description": "This entry covers ownership of the vCenter Server Appliance's underlying operating system itself (root/shell-level access), as distinct from holding a vSphere role such as Administrator through the application's own RBAC (see the \"vCenter Server\" entry). Root-level access to the appliance grants control over every vCenter service running on it, and therefore the same reach as the highest-privileged vSphere role, regardless of what roles have actually been assigned. When IWA is used, the appliance is a genuine AD computer object and is therefore also reachable through ordinary domain-computer compromise paths rather than only through direct access to the box (SSH, console, hypervisor-level access, or supply chain).",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "IT DEPENDS",
    "Rationale": "Domain-joining the vCenter Server Appliance via IWA is not a default configuration, and VMware/Broadcom's own guidance is to avoid it in favor of SAML/OIDC-based identity federation. IWA was deprecated in vSphere 7.0 and removed in vCenter Server 9.0, so this entry applies to 7.x and 8.x deployments. Root or shell access to the appliance yields control of every vCenter service running on it, and through that every host and VM it manages, independent of any explicit vSphere role grant. Control of the appliance's AD computer object is not by itself root access: the appliance's root account is local and carries no vCenter SSO permissions, and AD identities need an explicit vCenter permission grant. What the computer object does give an attacker is a domain-resident foothold against the appliance - Kerberos delegation and machine-account abuse against the domain-joined OS, and the Likewise-backed authentication path into it - which has to be converted into code execution or into an authorized vCenter account before it reaches vCenter. Where an attacker completes that step, or already holds a privileged vSphere role through an AD group: \"[a]dministrators of Active Directory implicitly become administrators of any [infrastructure] that trusts it.\" A compromised appliance cedes comprehensive administrative control over the entire connected virtual estate (hosts, VMs, datastores, networking) and can be used to implant persistent backdoors on the appliance itself. Where the managed estate includes Tier Zero VMs (e.g. domain controllers), this closes a loop back into Tier Zero: an attacker who is already a Domain Admin does not need this path to reach a DC, but a principal short of Domain Admin who can reach the appliance - through a delegation or machine-account path against its computer object, an AD group holding a privileged vSphere role, or direct access to the box - can still reach Tier Zero through it without ever compromising the domain directly. Because both IWA usage and the presence of Tier Zero VMs under the appliance's management vary by environment, this is IT DEPENDS overall.",
    "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference the AD computer object matching the vCenter Server Appliance's hostname (when IWA is configured) against the appliance's managed VM inventory for Tier Zero systems.",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "Community contribution",
    "References": "https://cloud.google.com/blog/topics/threat-intelligence/defending-vsphere-from-unc3944\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/vsphere-active-directory-integration-risks\r\nhttps://knowledge.broadcom.com/external/article/314324/removal-of-integrated-windows-authentica.html\r\nhttps://knowledge.broadcom.com/external/article/433065"
  },
  {
    "Asset": "Microsoft Entra Cloud Sync Provisioning Agent Server",
    "Category": "Computer host",
    "Platform": "Active Directory",
    "Identification": "Not applicable - Not represented as an object. Identify by locating domain-joined hosts running the Microsoft Entra provisioning agent (AADConnectProvisioningAgent service). Separate from Microsoft Entra Connect Sync (ADSync); see the \"Microsoft Entra Connect Server\" entry for that product.",
    "Description": "Microsoft Entra Cloud Sync is Microsoft's agent-based alternative to Entra Connect Sync for synchronizing Active Directory and Entra ID. Each provisioning agent host runs a gMSA (commonly provAgentgMSA$) that is granted AD permissions equivalent to the classic AD DS Connector Account, letting it read from, and with writeback enabled write to, on-premises Active Directory.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "Microsoft documents that the agent server \"should be a tier 0 server\" and recommends hardening it as a Control Plane asset, the same language used for domain controllers. An attacker with admin access to the server can dump LSASS or read the gMSA's managed password from AD to obtain its credential. That credential holds Replicating Directory Changes and Replicating Directory Changes All on the domain root by default, granted automatically at install regardless of whether Password Hash Sync is enabled as a feature, which is enough to DCSync the domain.",
    "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference server inventories/CMDB against hosts running the Microsoft Entra provisioning agent.",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "N/A",
    "Episode": "Community contribution",
    "References": "https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/how-to-prerequisites\r\nhttps://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/gmsa-cloud-sync\r\nhttps://www.dsinternals.com/en/retrieving-cleartext-gmsa-passwords-from-active-directory/"
  },
  {
    "Asset": "Microsoft Entra Cloud Sync Provisioning Agent gMSA",
    "Category": "AD computer",
    "Platform": "Active Directory",
    "Identification": "objectClass: msDS-GroupManagedServiceAccount. SamAccountName typically provAgentgMSA$; enumerate with Get-ADServiceAccount. Holds DS-Replication-Get-Changes and DS-Replication-Get-Changes-All on the domain root by default.",
    "Description": "The provisioning agent runs as a gMSA rather than a standard user account. Its password is managed by AD and retrievable only by principals listed in its PrincipalsAllowedToRetrieveManagedPassword attribute, typically the computer accounts of authorized agent hosts. This is the Cloud Sync equivalent of the AD DS Connector Account.",
    "Tier Zero Default Risk": "YES - Takeover",
    "Tier Zero Config Risk": "N/A - Compromise by default",
    "Tier Zero": "YES",
    "Rationale": "Microsoft documents that Cloud Sync grants this gMSA the same DCSync-capable rights as classic Entra Connect Sync grants the AD DS Connector Account, applied by default at install. Anyone with admin access to an authorized agent host can extract the managed password (e.g. via DSInternals or GoldenGMSA) and use it to DCSync the domain. The account is therefore Tier Zero.",
    "Cypher": "// Default gMSA name is provAgentgMSA$; adjust the filter for custom names.\r\nMATCH (n)-[:GetChanges]->(d:Domain)\r\nMATCH (n)-[:GetChangesAll]->(d)\r\nWHERE n.name CONTAINS 'GMSA'\r\nRETURN n",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "NO",
    "Episode": "Community contribution",
    "References": "https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/gmsa-cloud-sync\r\nhttps://www.dsinternals.com/en/retrieving-cleartext-gmsa-passwords-from-active-directory/\r\nhttps://www.thehacker.recipes/ad/movement/dacl/readgmsapassword"
  },
  {
    "Asset": "Directory Synchronization Accounts service account",
    "Category": "Entra ID role",
    "Platform": "Entra ID",
    "Identification": "Template ID: d29b2b05-8046-44ba-8758-1e26182fcf32. Assigned to the on-premises sync service's Entra ID account, created automatically by both Entra Connect Sync and Cloud Sync (e.g. ADToAADSyncServiceAccount@<tenant>.onmicrosoft.com).",
    "Description": "Both sync products provision a dedicated Entra ID account for the sync engine, assigned the Directory Synchronization Accounts role. Microsoft's current role reference lists only microsoft.directory/onPremisesSynchronization/standard/read as an explicit permission, a narrowing from before an August 2024 hardening pass, and does not flag the role \"Privileged.\"",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "IT DEPENDS",
    "Rationale": "The role previously had a documented escalation path to Global Administrator (Tenable, 2024), largely closed by Microsoft's 2024 hardening. The account still reaches the largely undocumented Entra Connect Sync API (adminwebservice.microsoftonline.com/provisioningservice.svc), which lets a holder mint new sync principals with a cleartext password, reset the passwords of synchronized users, and, for certificate-based Service Principals, pivot through a minted User Principal to reset the Service Principal's certificate (mnemonic, 2025; Tenable, 2025). Whether this reaches a Tier Zero principal depends on which hybrid identities are in scope, since sync filtering excludes flagged built-in accounts but not ordinary members of privileged groups. This is not a Microsoft-documented Tier Zero claim, unlike the two Cloud Sync entries above.",
    "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference the sync service account's role assignment against synced/writeback-eligible identities and Tier Zero principals.",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "N/A",
    "Episode": "Community contribution",
    "References": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#directory-synchronization-accounts\r\nhttps://medium.com/tenable-techblog/stealthy-persistence-with-directory-synchronization-accounts-role-in-entra-id-63e56ce5871b\r\nhttps://www.tenable.com/blog/despite-recent-security-hardening-entra-id-synchronization-feature-remains-open-for-abuse\r\nhttps://www.mnemonic.io/resources/blog/deep-dive-into-the-entra-connect-sync-api/"
  },
  {
    "Asset": "AD FS Server",
    "Category": "Computer host",
    "Platform": "Active Directory",
    "Identification": "Not applicable - Not represented as an object. Identify by locating hosts running the Active Directory Federation Services role.",
    "Description": "AD FS issues SAML/WS-Fed/OAuth tokens so users can authenticate to federated relying parties, commonly including Microsoft Entra ID when an org federates instead of using password hash sync. For the automatically generated, AD FS-managed token-signing certificate, the private key is decrypted at runtime in the AD FS process and, in the default configuration (WID), the configuration database that stores it encrypted is otherwise readable only in the AD FS service account's own context. A custom certificate instead stores its private key through the certificate store or an HSM, which does not follow this path.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "IT DEPENDS",
    "Rationale": "Microsoft's AD DS tier model lists AD FS by name under Tier 0. A domain controller holds every credential in the domain no matter how you configure it, so it is always Tier Zero. An AD FS server is Tier Zero only if Entra ID is federated through it, if a relying party trust grants access equivalent to a Tier Zero principal, or if the AD FS service account is a member of Key Admins or Enterprise Key Admins, which on-premises Windows Hello for Business Key Trust deployments require.\r\n\r\nAn attacker with admin access to the server can dump the token-signing key from process memory, or act in the AD FS service account's context to pull the Distributed Key Manager key from AD and decrypt the key stored in the configuration database. With that key, the attacker can mint a Golden SAML token and impersonate any user with any claims against every relying party AD FS trusts. The forged tokens are generated offline and never touch AD FS again, so they do not appear in its logs.\r\n\r\nKey Admins and Enterprise Key Admins are themselves on Microsoft's protected accounts and groups list, the same list Domain Admins, Account Operators, and every other AdminSDHolder-protected group in this table is on. Membership in Key Admins gives a second, independent Tier Zero condition for that same reason, not because of what it can reach: it is a protected group, and control over the AD FS service account means control over a member of one. If none of the three conditions above apply, AD FS is not a Tier Zero security dependency.",
    "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference server inventories/CMDB against hosts running the AD FS role, and check AD FS service account membership in Key Admins/Enterprise Key Admins.",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "N/A",
    "Episode": "Community contribution",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/tier-model\r\nhttps://github.com/mandiant/ADFSDump\r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa21-008a\r\nhttps://www.hunters.security/en/blog/adfs-threat-hunting-2-golden-saml\r\nhttps://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-adfs#add-the-ad-fs-service-account-to-the-key-admins-group\r\nhttps://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory"
  },
  {
    "Asset": "AD FS Configuration Database Server (SQL Server)",
    "Category": "Computer host",
    "Platform": "Active Directory",
    "Identification": "Not applicable - Not represented as an object. Identify by locating the SQL Server instance hosting an AD FS farm's configuration database. Only present when a farm uses a SQL Server backend instead of the default Windows Internal Database (WID); optional at any farm size, but required once a farm exceeds WID's limits (100 relying party trusts or 30 nodes).",
    "Description": "AD FS farms can use a dedicated SQL Server instance for the configuration database instead of the default, locally hosted WID, for high availability, SAML artifact resolution, or token replay detection, none of which WID supports. Farms over 100 relying party trusts or 30 nodes require SQL Server, since WID cannot support them at that scale. For the automatically generated, AD FS-managed certificate, the database stores its token-signing private key encrypted with a key from the Distributed Key Manager container in Active Directory; a custom certificate's private key lives in the certificate store or an HSM instead.",
    "Tier Zero Default Risk": "NO",
    "Tier Zero Config Risk": "YES - Takeover",
    "Tier Zero": "IT DEPENDS",
    "Rationale": "Most AD FS farms run on WID, which is local to the AD FS server and readable only in the AD FS service account's own context, so this asset does not exist in most deployments. Where a farm uses a full SQL Server backend instead, sysadmin or db_owner access exposes the encrypted token-signing key blob to the SQL Server's own admin population, typically broader than the AD FS host's local admins. That access alone cannot forge tokens, since the Distributed Key Manager key from AD is also required to decrypt the blob, but it is one half of the Golden SAML chain described in the AD FS Server entry and should be scoped and monitored the same way. The server is Tier Zero whenever it is in use.",
    "Cypher": "N/A - Not identifiable via BloodHound collection alone. Cross-reference AD FS farm configuration against the SQL Server instance hosting its configuration database.",
    "Microsoft PAS Role": "NO",
    "AdminSDHolder Protected": "N/A",
    "Episode": "Community contribution",
    "References": "https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-the-ad-fs-configuration-database\r\nhttps://learn.microsoft.com/en-us/windows-server/identity/ad-fs/design/federation-server-farm-using-sql-server\r\nhttps://github.com/mandiant/ADFSDump"
  }
]