IT projects often start well, but unfortunately sometimes end with a mediocre solution or too many exceptions. Implementing credential tiering, on the other hand, requires a continuous commitment to meeting the defined objectives and minimizing exceptions. A well-defined implementation strategy is essential, along with the determination of all involved parties to significantly improve the security of a critical IT service like Active Directory through credential tiering.

This second article in a two-part series provides guidance on transitioning to a credential tiered Active Directory environment, focusing on Tier-0. Additionally, it introduces a method to measure security enhancements during the process. The described methods can be replicated for other identity centric solutions. The following section is aligned to the tiering Model from Microsoft, which is described in the first part, and on our experience with the implementation and attacking of non-segregated environments during our engagements.

The plan

Before diving into implementation, it can be beneficial to have a plan. Implementing credential tiering is often a large project that requires a detailed overview of the strategy, objectives and tasks to implement credential tiering. A project plan helps to organize resources and risk management and ensures a systematic approach. The following fundamental aspects should be considered first:

1. Everything starts with a goal. As an example: To enhance security against credential theft from privileged entities, we aim to identify privileged entities, categorise them, and protect them through strict identity-centric segregation measures.
2. If you don’t already have the attention of higher management start pitching the security concept to gain their full support. This is crucial for facilitating the mindset transition that IT employees will need to undergo.
3. Are there multiple Active Directory forests with trusts to each other? If yes, potential inter-forest security boundary violations need to be considered. This might necessitate implementing an Admin Forest or selecting an existing forest for administration, which could be considered a mediocre solution. In this article, we assume a scenario with a single forest and single domain.
4. To secure Tier-0 effectively, it must be isolated from other tiers to avoid any control-up or exposure-down risks. If, for some reason, complete separation is not feasible, identify which components cannot be tiered, as these components present an upstream risk to Tier-0.
5. Decide if you roll out Privileged Access Workstations (PAW) for all tiers or, for example, only for Tier-0. Define the high-level requirements for PAWs, i.e., Remote Access.
6. Define responsibilities for the tiers. I.e. Tier-0 are the Active Directory engineers; Tier-1 is mostly the IAM team and server team; and Tier-2 is mostly the client team.
7. Create a RACI matrix for the implementation phase and the time after the migration.
8. Create a tiering concept. The concept should include the final architecture of the solution. The new solution has an impact on the existing Active Directory disaster recovery (DR) and incident response (IR) concepts. Therefore, both the DR and IR concepts require adaptation.
9. Establish a rough timeline and allocate sufficient internal resources to the project. It is essential that at least one internal Active Directory engineer devote a minimum of 80% of their time to the implementation. This is critical due to the project’s nature. It goes beyond implementing a technical solution; it requires a mindset shift to understand, address, and permanently eliminate tiering violations. The whole endeavor would be in vain if the staff did not subsequently adhere to the rules on how Active Directory should be managed in accordance with the defined tiering ruleset.

These aspects could lead to extensive discussions in which some people may question the entire project. However, this is the first phase of a change in awareness that employees will go through. We recommend initially explaining the challenges in a broader context, detached from the organisation, and in particular avoiding a direct probability assessment. The problem of complex statements such as “if we do not carry out x, we have y number of direct or indirect attack paths to z” can be made clearer through examples. A real-life scenario could show how certain users use their daily user account to access an organisation’s password vault, which contains privileged Active Directory credentials. The daily user account is thereby an indirect domain admin along with any entity that has admin rights to the vault. This creates a risk that privileges can be escalated from any tier to Tier-0. Once the fundamental challenges are understood, the discussion can move to the business perspective to encourage nuanced conversations. The focus should consistently be on the separation of administrative access to Active Directory, which is one of the most important services in many organisations. Additional examples can be found in Credential Tiering: The Value of Containment Part 1.

Everything starts with Tier-0

A house needs a strong foundation, just like Tiering. If Tier-0 is compromised, the attacker gains downstream control over everything that is controlled by Active Directory. That’s why a robust Tier-0 should be prioritized first. The following high-level implementation steps can be used as a guideline:

• A1. Identify the unknown: Your current Tier-0 entities. (Ongoing Task)
• A2. Clean up unnecessary Tier-0 entities or permissions. (Ongoing Task)
• A3. Monitor and audit changes to the now-known Tier-0 entities. (Ongoing Task)
• A4. Review and make adaptations to the tiering concept specific to the implementation of Tier-0 entities, such as hardening, MFA, host firewall and other specific configurations.
• A5. Create a rollout plan for the future Tier-0 servers that can be re-deployed and the servers that must be migrated.
• A6. For servers that cannot be re-deployed, define a thorough scan and cleanup process. Permissions, agents and users that do not belong to Tier-0 must be removed.
• A7. Create a rollout plan for your required Tier-0 entities and indicate if they are re-created or migrated. If some identities cannot be recreated, ensure that the password is rolled twice. Also verify that the identity has no other authentication method configured, i.e., the attribute msDS-KeyCredentialLink is empty. Re-creating is always the better option to avoid backdoors such as Shadow Credentials
• A8. Buy the required hardware, such as hardware for the servers, backup storage and clients for the PAWs.
• A9. Buy software licenses if required.
• A10. Define the tiering Organization Unit (OU) structure in Active Directory. Preferably for all tiers.
• A11. Create the new OU structure within a test environment, ideally with the use of a script. Proceed to test the implementation, including hardening, tiering restrictions, group policy objects (GPOs), smart card logon, and authentication policy silos.
• A12. Rack the new Tier-0 hardware in the datacenter.

From here on, the clock starts ticking. Implement these steps promptly to prevent potential tampering by not-yet-transferred Tier-0 entities during the transition.

• B1. Create the new tiered OU structure.
• B2. Create the new Tier-0 identities. The preferred approach is to create the identities new and not move them to the Tier-0 OU. If some identities cannot be recreated, follow the procedure (A7) to ensure that the password is rolled twice and that the account is not backdoored. (Ongoing Task)
• B3. Rollout Tier-0 PAW. (Ongoing Task)
• B4. Start working with PAWs and the Tier-0 accounts. (Ongoing Task)
• B5. Set up the new hardware by following the clean source principle approach.
• B6. Deploy the servers that are required to operate Tier-0, such as backup, monitoring and management services.
• B7. Redeploy the Tier-0 services such as Domain Controllers, ADCS, Entra Connect and so on by following the clean source principle.
• B8. If some servers cannot be re-deployed, follow the procedure (A6) to make them Tier-0 compliant. The network traffic of these servers should be monitored to ensure that nothing is missed.
• B9. Disable old Tier-0 entities and define a grace period for these objects.
• B10. Enumerate Tier-0 attack paths and fix Tier-0 violations. (Ongoing Task)

Identify the unknown

The identification of Tier 0 entities is one of the first steps in the implementation of Tier 0 in order to demonstrate the impact of non-segregated Tier 0 entities and support the transition to Tier 0. To identify Tier 0 entities quickly and effectively, the Graph Theory can be used. Certain tools that use graph theory have already implemented the necessary logic and help enormously with the assessment of dependency-based solutions such as Active Directory. The best-known tool is BloodHound from SpecterOps and Adalanche from Lars Karlslund. The following approach can be used for A1, A2, A3, A7, B2 and B10.

Prepare BloodHound FOSS or BloodHound CE

• Deploy an assessment server or client.
• Download BloodHound FOSS or BloodHound CE.
• Download and install Neo4j Desktop if BloodHound FOSS is used or you want to use BloodHound CE with an external Neo4j database.
• Use the standard Neo4j Desktop database or create a new database, e.g., with the name “bloodhoundfoss” or “Bloodhoundce”.
• If a new database was created, a new user should be created by running the following cypher in the Neo4j Browser.

CREATE USER bloodhoundce SET PASSWORD 'bloodhoundce' CHANGE NOT REQUIRED SET STATUS Active SET HOME DATABASE bloodhoundce;
GRANT ROLE admin TO bloodhoundce

• The plugins Graph Data Science Library (GDS) and APOC can now be installed via the Neo4j Desktop.
• To be able to use BloodHound CE with an external database, adjustments must be made to bloodhound.config.json to refer to the external Neo4j database. The use of the Neo4j Community Edition is after the modification no longer required and the docker-compose.yml can be adapted accordingly. If the containerised Neo4j Community Edition is used, docker-compose.yml must be adapted so that the Neo4j browser can be accessed externally. Furthermore, the APOC and GDS plugins must be installed manually. However, it is possible that not all the required functions are available, which are used below for the evaluation. We therefore recommend using the Neo4j desktop version, which supports multiple databases as well as functions such as graph algorithms and third-party analysis tools. Although if a server mode setup is required, the community or a licensed version is required.

Run SharpHound

• Run SharpHound from the context of a domain user or through another method such as runas /netonly. If the user has admin rights on the endpoints, you could additionaly also run the collection method LoggedOn or go from the start with All to collect more accurate data regarding logged on users on the endpoints. If you use BloodHound FOSS use the SharpHound version v1.1.1.

SharpHound.exe --SecureLDAP --disablecertverification --domain yourdomain.intra -c DCOnly
SharpHound.exe --SecureLDAP --disablecertverification --domain yourdomain.intra -c ComputerOnly

• If you can, you should collect active session data from your endpoints for at least four hours. Note that, as of Server 2016+ and Windows 10 1607+, administrator rights or SAM-R rights are required on the endpoints.

SharpHound.exe --SecureLDAP --disablecertverification --domain yourdomain.intra -c Session --Loop --Loopduration 04:00:00

• Import the collected data into BloodHound

Mark Tier-0 entities

• The following cyper queries identify all tier-0 entities and mark them with the tier0 and highvalue flags. The queries should be executed via the Neo4j browser.

// Reset highvalue property
Match (u)
SET u.highvalue=false;

// Assign three new properties (Tiering) to all nodes
MATCH (u)
SET u.tier0 = false,
    u.tier1 = false,
    u.tier2 = false;

// Set the Tier-0 property to true for well known Tier-0 objects
UNWIND ["500","502","512","516","518","519","520","526","527","544","548","549","550","551","555","557","562","569","580"] as TierZeroRid MATCH (u) where u.objectid ENDS WITH "-"+TierZeroRid Set u.tier0=true;

// Find all domain objects and set the tier0 property
MATCH (u:Domain) SET u.tier0=true;

//Find all objects that allow unconstrained delegation and set the tier0 property
MATCH (u{unconstraineddelegation:true}) Set u.tier0=true;

//Find all objects that can directly or indirectly manipulate objects that have the property tier0 set to true
Match p=allshortestpaths((u)-[r:MemberOf|AdminTo|AllExtendedRights|AddMember|ForceChangePassword|GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner|ExecuteDCOM|AllowedToDelegate|ReadLAPSPassword|Contains|GPLink|AddAllowedToAct|AllowedToAct|SQLAdmin|ReadGMSAPassword|HasSIDHistory|SyncLAPSPassword|AddSelf|WriteSPN|AddKeyCredentialLink|DCSync*1..]->(n{tier0:true})) Where u<>n Set u.tier0=true;

//Identify all entities with remote access to Tier-0 assets. These entities matter because they could become indirect Tier-0 administrators by escalating privileges on the target. For example, if a user can RDP to a client where a Tier-0 administrator is active, it might lead to compromising the Tier-0 accounts.
Match p2=allshortestpaths((u)-[r2:HasSession|CanRDP|CanPSRemote|ExecuteDCOM*1..]->(n{tier0:true})) Where u<>n Set u.tier0=true;

//OPTIONAL: Set all Tier-0 marked nodes as highvalue to have a better visibility in the BloodHound GUI (All Tier-0 objects will receive a diamond icon in BloodHound)
MATCH (u{tier0:true})
SET u.highvalue = true;

Find and flag external Tier-0 services

All Tier-0 entities that are managed directly through Active Directory should now have been identified automatically. What is missing are applications or services that can manage Tier-0 objects indirectly, but whose access management is handled by an external application. For example, solutions such as backup (NetBackup, ARCserve, Veeam), virtualisation (ESX, Hyper-V), monitoring (SCOM, Ivanti), system management (SCCM, Ivanti), vulnerability scanner (Nessus), AV (McAfee, Symantec, Defender), EDR (MDE, Tanium, CrowdStrike, SentinelOne), IAM (One identity, Sailpoint, NetIQ), SIEM (Splunk, Microsoft Sentinel, Qradar) etc. These services often use an agent on the endpoints or service accounts and have their own Role-based access control (RBAC) implementation. Therefore, to find out who has access to what, it is necessary to first identify the services running on Tier-0 systems and then interview the solution owner. In addition, system management tools or vulnerability scanners can assist in identifying active services and processes on a Tier-0 system. Also, if you do not have access to system management tools or vulnerability scanners, you can identify possible Tier-0 relevant services by running a simple PowerShell script on a Tier-0 system.

# Get all running services and processes
$RunningServices = Get-Service | Select-Object @{Name="Type"; Expression={"Service"}}, Name, DisplayName, Status
$RunningProcesses = Get-Process | Select-Object @{Name="Type"; Expression={"Process"}}, Name, Id
# Combine and output to grid view
$RunningServices + $RunningProcesses | Out-GridView -Title "Running Services and Processes"

After identifying services or processes running on Tier-0 servers, the application owner should be able to provide the necessary information about which users have administrative permissions. Often, AD groups or AD users are used in the Application itself. The identified AD objects should be flagged as Tier-0. You can use the following cypher query to search for a particular samaccountname and set the tier0 flag:

// Example to set the tier0 and highvalue flag on the node with the samaccountname grp-TenableAdmin
MATCH (u) where toLower(u.samaccountname) = toLower("grp-TenableAdmin") Set u.tier0=true, u.highvalue = true

Besides getting in touch with the Tier-0 application owners, it is sometimes also helpful to search the Neo4j database for well-known services. The following cypher query can be used for that:

// Modify the following keywords with service terms to suit your specific environment
UNWIND ["nessus", "tenable", "sccm", "scom", "ivanti", "esx", "vmware", "mcafee", "symantec", "tanium", "splunk", "qradar", "netbackup", "arcserve", "veeam", "crowdstrike", "sentinelone", "sailpoint", "netiq"] AS word MATCH (n) WHERE toLower(n.name) CONTAINS toLower(word) OR 
toLower(n.description) CONTAINS toLower(word) OR 
any(x IN n.serviceprincipalnames WHERE toLower(x) CONTAINS toLower(word)) OR 
toLower(n.distinguishedname) CONTAINS toLower(word) 
RETURN word as keyword, LABELS(n)[1] as type, n.name, n.description, n.distinguishedname 
ORDER BY type

Create a list of the identified Tier-0 entities

After following the steps described above, most Tier-0 entities should have been identified. The very “popular” tool Excel is often used for further planning. A csv file can be generated via the Neo4j browser. If the data set is too large, the following cypher query can be used:

// Create a csv file with all Tier-0 entities
// Enable apoc.export.file.enabled=true in the neo4j.conf
// Will be saved to: C:\neo4j\Database\relate-data\dbmss\dbms-guid\import

CALL apoc.export.csv.query("Match (u) where u.tier0=true return distinct LABELS(u)[0] as type, u.name, u.enabled,u.description,u.objectid, u.distinguishedname order by type", 'all-tier0-entities.csv', {quotes: true, delimiter: ','});

Evaluation and progress tracking

During the evaluation phase, identified unused Tier-0 entities can already be removed. Entities that have to be recreated or migrated can be flagged according to the implementation schedule. To track improvements before, during and after the implementation of Tier-0, the following dashboard may become handy.

The figure shows how many entities have a direct or indirect path to the Domain Admin group or other Tier-0 entities. The percentage may require adjustments depending on the size of the organization. The environment depicted in the demo has a total of 2489 enabled user accounts. Therefore, the target for the Tier-0 accounts should be around 0.4% to 0.5%, depending on the size of the Active Directory team and the service accounts that are required for the Tier-0 segregation.

Further down in the dashboard, the graph algorithms of closeness centrality and degree centrality were employed to display potential privileged entities.

The degree centrality algorithm can help determine popular nodes in a graph database. The algorithm measures the number of incoming and outgoing edges from a node. If nodes have a high number of edges, in particular outgoing edges, the node respectively the AD entity may be highly privileged. In contrast, the closeness centrality measures the node’s average distance to all other nodes and generates a list of nodes that can propagate information efficiently through a graph. Therefore, nodes with a high closeness score have the shortest distances to all other nodes, which can be an indication that the entity is privileged. Further information regarding the two algorithms can be found on the official Neo4j website or in the paper Start thinking in graphs: using graphs to address critical attack paths in a Microsoft cloud tenant.

To use the above dashboard, get the NeoDash application and import the dashboard from GitHub. NeoDash can be downloaded through the Neo4j Desktop application from the graph app gallery or directly from GitHub. NeoDash works also with the Neo4j Community Edition.

Next steps

Tier-0 can normally be implemented without exception or downtime. It takes, depending on the technical level of the employees, 6-12 months (excluding political debates). The implementation of Tier-1 is more difficult and can take a long time. Maybe not everything can be fully segregated, but important is the prioritization of privileged Tier-1 administrators and business-critical applications. They must be segregated and protected from less important Tier-1 assets. Another approach is to add another Tier. That means Tier-1 is only for IT and business-critical solutions. Tier-2 is for the less critical server applications, and Tier-3 is for client administrators.

A topic that was not touched on in this article but is essential for the tiering implementation is hardening and access policies. The hardening should follow either the CIS or Microsoft guidelines. My colleague Michael Schneider wrote a tool named HardeningKitty with which the hardening policies can be verified. Even more important are the access policies, which allow or deny cross-tier access. The preferred way is to use Authentication Policies and Authentication Policy Silos in combination with Authentication Mechanism Assurance (AMA). But also starting just with SmarCards and Group Policies is sufficient.

Conclusion

Implementing tiering is a challenging task, not primarily because of the technical difficulty of such an implementation, but due to the existing routine of operating an Active Directory. It remains a challenge for organizations to alter this routine, establish transparency about which AD objects are now privileged and effectively protect them. Tiering is not an installable tool; rather, it is a defined method of operating an Active Directory more securely. It establishes a particular state based on a set of rules that must be followed. If an Active Directory does not have a set of rules that restrictively protects the privileged entities, the Active Directory is exposed to risk to get compromised. Indirect Tier-0 permissions in particular are growing exponentially in large organisations without tiering, as more and more tools are installed that typically affect all servers or clients, and therefore the Active Directory domain controllers or their administrators. The two articles Part 1 and Part 2 explore how to implement tiering with both theoretical and practical examples of how to get started with a tiering implementation. The focus of both articles was primarily on Active Directory, but all identity provider solutions share the same challenges, so the approach presented can be used with other solutions such as Microsoft Entra ID, Google Cloud Identity and AWS Identity to effectively protect privileged entities.

About the Author

Marius Elmiger is a security professional since the early 2000’s. He worked in various IT roles such as an administrator, engineer, architect, and consultant. His main activities included the implementation of complex IT infrastructure projects, implementation of security hardening concepts, and compromise recoveries. Later he transitioned to the offensive side. As a foundation, in addition to numerous IT certificates, Marius graduated with an MSc in Advanced Security & Digital Forensics at Edinburgh Napier University. (ORCID 0000-0002-2580-5636)

Links

• https://github.com/BloodHoundAD/BloodHound
• https://github.com/BloodHoundAD/SharpHound
• https://github.com/SpecterOps/BloodHound
• https://github.com/lkarlslund/Adalanche
• https://github.com/m8r1us/Tier0Hound
• https://github.com/neo4j-labs/neodash
• https://install.graphapp.io/
• https://learn.microsoft.com/en-us/defender-for-identity/remote-calls-samare
• https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd378897(v=ws.10)?redirectedfrom=MSDN
• https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831791(v=ws.11
• https://learn.microsoft.com/en-us/security/privileged-access-workstations/esae-retirement
• https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-devices
• https://learn.microsoft.com/en-us/security/privileged-access-workstationsprivileged-access-success-criteria#clean-source-principle
• https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos
• https://link.springer.com/article/10.1007/s10207-023-00751-6
• https://neo4j.com/blog/graph-theory-predictive-modeling/
• https://neo4j.com/deployment-center/
• https://neo4j.com/developer/neo4j-desktop/#desktop-add-plugin
• https://neo4j.com/developer/neo4j-desktop/#desktop-create-DBM
• https://neo4j.com/docs/browser-manual/current/visual-tour/
• https://neo4j.com/docs/graph-data-science/current/algorithms/
• https://neo4j.com/labs/neodash/
• https://posts.specterops.io/shadow-credentialsfneo-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab