Privileged Access – The Proverbial "Keys to the Kingdom"
Obtaining privileged access in an organization is the new holy grail for malicious perpetrators, because once someone has privileged access, he/she can circumvent or disable just about any additional security control that may be in place and easily access, copy, tamper, steal and/or divulge virtually any and every organizational IT asset, thereby inflicting colossal damage in no time.
In fact, 100% of all major recent cyber security breaches (Snowden, JP Morgan, Target, Sony Hack etc.) involved the compromise and subsequent misuse of just 1 privileged access account.
Given the colossal damage inflictable by the compromise of a single privileged access account, the adequate protection of privileged access accounts must be cyber security priority #1.
However, to adequately protect privileged access accounts, one must first understand what constitutes a privileged access account, because you cannot protect what you cannot identify.
Today, unfortunately, for most organizations, privileged access begins and ends with Domain Admins. In reality, Domain Admins are merely the tip of the iceberg.
Domain Admins – Merely the "Tip of the Iceberg"
Today, in most organizations, the naive assumption is that the only accounts that are privileged in nature are those of Domain Admins, and for some, those of the Enterprise Admins.
Based on this assumption, they attempt to reduce the number of their Domain Admins and Enterprise Admins. Incidentally, so many organizations, even today have 100s of such accounts.
Unfortunately, Domain Admins and Enterprise Admins are merely the tip of the iceberg, and organizations that rely solely on reducing the number of these accounts remain vastly vulnerable.
Fortunately for them, it turns out that at least for now, even malicious perpetrators don't seem to know better, and thus primarily focus their efforts on trying to compromise these accounts.
The day is not far though when malicious perpetrators realize that these accounts are merely the tip of the iceberg. When they do, the security of 85+% of all organizations could be in peril.
The reality is that in any organization there are far more accounts than merely Domain Admins & Enterprise Admins that are, for all practical purposes, at least as powerful as these accounts.
Active Directory – The Heart of Privileged Access
In order to understand what truly constitutes privileged access, one must consider the Privileged Access Hierarchy, particularly in Microsoft Windows Server based IT environments.
First things 1st though; the IT infrastructures of 85+% of organizations worldwide operate on Microsoft Windows Server platform. In other words virtually everything runs on Windows Server.
In a Microsoft Windows Server based IT infrastructure, at the foundation of virtually everything, including of course cyber security and privileged access lies Microsoft Active Directory.
Here's why –
Kerberos is the native authentication protocol in a Windows network, and Kerberos is completely integrated with and relies on Active Directory, which is also its account database
Every single user account (of every single employee/contractor) in a Windows network is an Active Directory account, that is stored, managed in and protected by Active Directory.
Every single security group that is used to provision secure access to IT resources across the entire network is stored in, managed in and protected by Active Directory.
Every single computer in a Windows network is joined to the Active Directory, has a secure-channel established with the Active Directory and is protected by the Active Directory.
Every single securable IT resource in a Windows network is stored on an Active Directory joined computer, and secured using Active Directory security groups.
Every single administrative group, including Domain Admins, that has unrestricted access across the entire network is also stored in, managed in and protected by Active Directory.
When a computer is joined to Active Directory, specific Active Directory administrative groups such as Domain Admins, are added to that computer's Local Administrators group.
Also, various policies, including local group membership assignments, can be specified and pushed to Active Directory joined computers via a mechanism known as Group Policy.
Anyone with privileged access in Active Directory can always control, disable or bypass any additional security measure deployed on an Active Directory joined computer.
At the end of the day, it is the effective access provisioned on Active Directory content that governs who truly has what privileged access in Active Directory and across the network.
It is by virtue of the above that by default and as such Domain Admins have virtually unrestricted access to virtually every IT resource in a network powered by Microsoft Windows Server.
Furthermore, it follows that should an organization's foundational Active Directory deployment be compromised, literally everything is exposed to risk and the entire organization is compromised.
With this foundation in mind, one can now understand the Privileged Access Hierarchy
Three Types of Privileged User Accounts
There are 3 types of privileged user accounts in every Microsoft Windows Server based IT infrastructure, and they are not all equal. They vary substantially in their scope of use and impact –
- Local Admin Accounts - These accounts are local accounts that exist on every Windows computer and their scope is limited to being able to access resources on that computer itself.
- Domain Unrestricted Admin Accounts - These accounts are all-powerful Active Directory domain accounts and can access all resources on all computers in an Active Directory domain.
Domain Delegated Admin Accounts - These accounts are Active Directory domain accounts that have been delegated privileged access so that they can manage the organization's building blocks of cyber security i.e. domain user accounts, domain computer accounts, domain security groups etc., all of which are stored, protected and managed in Active Directory.
The scope of access of a domain delegated admin account is substantially broader than that of a Local Admin account. For instance –
- A delegated admin that can manage a domain user account (e.g. the CEO's account) can reset that account's password and obtain access to everything that user can access.
- A delegated admin that can manage a domain security group (e.g. All Employees) can change the group's membership and obtain access to everything that group can access.
- A delegated admin that can manage a domain computer account (e.g. HBI Server) can control the computer's security and obtain access to everything stored on that computer.
- A delegated admin that can create a domain user account (e.g. JDoe) can use it to logon to the domain and access any resource to which Authenticated Users have access.
- A delegated admin that can delete an existing domain user account (e.g. the CIOs account) can prevent that user from logging on and cause long-term disruption of access.
- A delegated admin that can manage an Organizational Unit containing 100s or 1000s of domain user, computer accounts and security groups can do all of the above.
Considering the broad scope of system-wide access that both Domain Unrestricted Admins and Domain Delegated Admins have in an organization, it is paramount for organizations to be able to precisely identify, minimize and adequately protect each one of these accounts. It is more important to be able to identify these accounts than it is to be able to identify Local Admin accounts.
Privileged Access Hierarchy
In order to be able to identify all accounts that truly are privileged in nature, one must consider the Privileged Access Hierarchy in networks powered by Active Directory.
The Privileged Access Hierarchy depicts the actual hierarchy (i.e. beginning with the most powerful group) of administrative power in Active Directory based networks and is as follows –
Note – Every single member of each of the below identified groups is, and must be considered a privileged access account.
The Built-in Admins group of the Active Directory forest's root domain.
The Schema Admins group, which resides in the Active Directory forest's root domain.
The Enterprise Admins group, which also resides in the Active Directory forest's root domain.
The Server Operators, Account Operators, Backup Operators, Print Operators, Domain Controllers and Domain Controllers groups in the Active Directory forest's root domain.
The Built-in Admins group in each domain.
The Domain Admins group in each domain (including in the Active Directory forest's root domain).
The Server Operators, Account Operators, Backup Operators, Print Operators, Domain Controllers and Read-only Domain Controllers groups in each domain.
Any groups that are configured (via Group Policy) to be a member of the Local Administrators group on a large number of Active Directory joined computers.
Any PKI administrative groups, if Microsoft Certificate Services or another PKI solution is deployed, such as to enable 2-factor (Smart-card) authentication.
In addition, at a minimum, any groups (or users) that can enact the following administrative tasks in Active Directory –
Promote a machine to become a Domain Controller (DCPROMO)
Manage the Schema or Configuration partitions, and modify security permissions protecting the content of these partitions
Modify the security permissions protecting any of the following – a) the domain root, b) the Users container, c) the Builtin container or d) the System container
Modify the Default Domain Controllers Policy and/or the Default Domain Policy
Link a GPO to any top-level OU, or any OU that contains a large number of computer accounts
Modify the security permissions protecting all top-level OUs, or any OU that contains a large number of computer accounts
Manage administrative groups, and the OUs in which these groups reside (and all OUs from there up till the domain root.)
Manage administrative accounts, including the Administrator and krbtgt account, and the OUs in which these accounts reside (and all OUs from there up to the domain root.)
Manage the computer accounts of the computers used by administrative users, and the OUs in which these accounts reside (and all OUs from there up to the domain root.)
Manage any group that is granted administrative access on organizational computers via GPOs, and the OU in which it resides (and all OUs from there up to the domain root.)
In addition, any groups (or users) that can modify the local Administrators group on either all or a large number of organizational computers must also be considered privileged.
Finally, in the interest of completeness, it may be noted that strictly speaking, all computer accounts that are trusted for unconstrained delegation should also be considered to be privileged.
Important Note: The list above is only designed to identify individuals that have unrestricted privileged access. To identify individuals that possess restricted (delegated) privileged access in Active Directory, organizations must identify all individuals who are sufficiently privileged to be able to enact administrative tasks in Active Directory, such as being able to create, delete and manage user accounts, computer accounts, security groups and Organizational Units in Active Directory. For details, please review the Impact of Compromise and Attack Surface sections.
It is imperative to note that any individual who can manage an Active Directory administrative account or security group, must for all practical purposes also be considered to be in possession of unrestricted privileged access. Thus it is imperative that organizations additionally identify exactly who can manage their unrestricted privileged access administrative accounts and groups.
Correctly Identifying Privileged Access Accounts
As mentioned above, in order to identify all accounts that truly are privileged in nature, one must methodically consider the Privileged Access Hierarchy provided above as follows.
To arrive at the complete list of all privileged access accounts, for each group mentioned above, one must include each account that meets the following criteria –
- Level 1 (Immediate, Direct Access)
- Each account that is directly or indirectly a member of this group.
- Level 2 (Immediate, Indirect Access)
- Each account that can (i.e. has sufficient effective permissions/access to be able to) –
- Modify the membership of this group.
- Modify the security permissions protecting this group (i.e. the group object in Active Directory.)
- Level 3 (Non-immediate (30-seconds away), Indirect Access)
- For each account identified in Level 1 and Level 2, additionally identify and include each account that can (i.e. has sufficient effective permissions/access to be able to) –
- Reset the account's password.
- Set the Password-not-required flag. Alternatively, if smartcards are in use, uncheck the Smart card is required for interactive logon option.
- Modify the security permissions protecting the account.
Strictly speaking, at the discretion of the organization, the analysis suggested in Level 3 above could /
should be recursed to exhaustion i.e. be applied again to each of the accounts identified in a given step.
It may be noted that accounts identified in Level 1 are directly privileged in nature, and accounts identified in Levels 2 and 3 above are realistically equally privileged in nature.
Note: It must be reiterated that any individual who can manage an Active Directory administrative account or security group, must for all practical purposes also be considered to have unrestricted privileged access. Thus it is imperative to additionally identify exactly who can manage unrestricted privileged access administrative accounts and groups in Active Directory.
Imperative to Security
It is imperative to understand that the compromise of any 1 of these accounts could be sufficient for a malicious perpetrator to gain privileged access and inflict colossal damage.
The process of correctly identifying privileged access accounts can seem daunting, but it is imperative and with the right process and tools (e.g. one, two, three), it can be completed in a month.