ImproHound v2.0.1 releases: Identify the attack paths in BloodHound
Identify the attack paths in BloodHound breaking your AD tiering
ImproHound is a dotnet standalone win x64 exe with GUI. To use ImproHound, you must run SharpHound to collect the necessary data from the AD. You will then upload the data to your BloodHound installation. ImproHound will connect to the underlying Neo4j database of BloodHound. In ImproHound, you will categorize the AD into tiers via the OU structure, and ImproHound will identify the AD relations that enable AD objects to compromise an object of a higher (closer to zero) tier and save the tiering violations in a csv file.
Connect to database
Enter the database credentials and establish a connection. It is the same credentials you use in BloodHound GUI.
Continue or start over
ImproHound creates a ‘TierX’ label on nodes in the BloodHound database. If you have used ImproHound before with this BloodHound database, you will be asked if you want to continue with the tiering you have already created or if you want to start over.
This is the page where you will categorize the AD objects into tiers. The window displays the OU structure. Each AD object has a tier value which can be increased and decreased with the arrows.
Set children to tier
If you select a domain or an AD container, you can click ‘Set children to tier’ to set all children (recursively) to the tier level of the given domain/container.
Set members to tier
If you select a group, you can click ‘Set children to tier’ to set all members (recursively) to the tier level of the given group.
Set tier for GPOs
If you click ‘Set tier for GPOs’ each GPO will have their tier level set to the tier level of the OU with the highest tier (closest to zero) which the GPO is linked to. GPOs not linked to an OU will not have their tier level changed.
Get tiering violations
Find all relations in the BloodHound database where an AD object has control of an AD object from a higher tier (closer to zero).
Two CSV files are generated as output:
- adobjects-[timestamp].csv: All AD objects and which tier they are in.
- tiering-violations-[timestamp].csv: The tiering violations.
The first record is a Tier 1 service account with permission to change the password of a Tier 0 user account. The relation is inherited. Unfortunately, it is not always possible to view where the relation is inherited from in the BloodHound data, but you can check it manually by inspecting the permissions on the targeted AD object in Users and Computers. The second record is a group with permission to edit a GPO, which is likely linked to OU containing Tier 0 servers since it is a Tier 0 GPO.
You can look up all the relation types and how they are exploited here.
If you discover that an object is in a too high tier (closest to zero), you should correct it in ImproHound, and then check for violations with this object as SOURCE. If an object is in a too low tier (closest to infinity), you should correct it in ImproHound and check for violations with the object as TARGET.
All tier labels and ImproHound created nodes in the BloodHound database will be deleted.
Guidelines for tiering AD objects
It is important to tier the AD objects correctly. If you set a DC and a regular low privileged user to be Tier 0 objects, ImproHound will not find that the user’s admin access to the DC is a tiering violation. Same case if you add the two of them to Tier 2.
Computers are tiered after how critical it would be if the computer was compromised.
- Tier 0 – Domain Controllers and other systems categorized as critical. Systems such as SCCM, ADFS, PKI, and virtualization servers (VMware, Hyper V, etc.)
- Tier 1 – The rest of the server infrastructure
- Tier 2 – Regular workstations
Users are tiered after the computers they can logon to and after the AD objects, they have control over. An example of control permission could be a user with rights to edit GPOs linked to Tier 1 servers, which would make the user a Tier 1 object.
A group belongs to the lowest tier (closest to infinity) of its members unless the group has bad members, e.g. a regular user as a member of Domain Admins.
Examples: Domain Users is a Tier 2 group even though your Tier 0 users are members of the group because it is not the membership of Domain Users that gives the users privileges. On the other hand, the Domain Admins group is a Tier 0 group because the membership of this group makes users very privileged. Cloneable Domain Controllers does not have any AD privileges AFAIK, but it should only contain Tier 0 objects i.e. DCs, so it is a Tier 0 group.
Container (incl. OU and Domain)
A container belongs to the highest tier (closest to zero) of its child objects, or higher.
Example: You have all Tier 0, Tier 1, and Tier 2 users in the Users container. A user with Full Control permission on the Users container would be able to compromise all the users including the Tier 0 users (except some which are protected but that is not important for the example), so the Users container must be a Tier 0 object.
A GPO’s tier level is determined by the tier level of the OUs it is linked to. The GPO belongs to the highest tier (closest to zero) of the OUs it is linked to. Use the ‘Set tier for GPOs’ button to make sure all GPOs follow this principle.
Example: A user with permission to edit a GPO linked to a Tier 1 OU would be able to control the membership of Administrators on all servers under the Tier 1 OU by modifying the GPO.
- Fixed bug regarding setting the tier level of GPOs, caused by GpLink edge renamed to GPLink in Bloodhound.
Copyright 2021 Improsec A/S