Who let the Dogs Out — Active Directory Domain Enumeration & Exploitation using BloodHound

In this blog, we will have an in-depth look at BloodHound. We will start by discussing what BloodHound is, how to install and configure it, and finally what can a potential attacker achieve with BloodHound.

What is BloodHound?

BloodHound is a JavaScript based web application that is compiled with Electron and uses Neo4j as the backend database. BloodHound uses graphs to map out the Active Directory environment, and then helps in identifying various attack paths to move laterally within the domain or to escalate privileges.

The data is fed into the BloodHound and the Neo4j database using data collectors, or Ingestors, referred to as SharpHound. These SharpHound Ingestors come in two forms, i.e. a Powershell script and a pre-built .NET binary.

BloodHound can be used by both red teams and blue teams. Red Teams use BloodHound to map out the domain environment and identify potential attack paths, and similarly blue teams can also use BloodHound to figure out those attack paths and push a suitable fix accordingly.

Developed by Andrew Robbins (@_waldo), Rohan Vazarkar (@CptJesus) and Will (@harmj0y), BloodHound is supported by Windows, Linux and MacOS.

Installation and Configuration of BloodHound:

Linux (Kali):

On kali linux, BloodHound can be installed by the single following command simple:

$ sudo apt-get install bloodhound

After BloodHound is installed, the next step is to configure Neo4j, in case of BloodHound, which is simply changing the default database password.

Start Neo4j using the following command:

$ sudo neo4j console

You will see Neo4j starting and finally you will be provided with a URL on which the Neo4j interface is running (default port is usually 7474). On a web browser visit localhost at port 7474, log in using default credentials (neo4j : neo4j) and change the default password from neo4j to something else.

Finally run BloodHound by typing in bloodhound in the terminal, press enter and enter your credentials, you will be provided with the BloodHound interface.

Domain Mapping and Enumeration and Attack Path Identification — BloodHound Walkthrough

Ingestors:

The first step is to get the data and feed it to BloodHound. Data collection is done using Ingestors, called SharpHound, which are available as both a Powershell script and a .NET binary. There are multiple flags/switches for various data collection techniques, depending on what you want to enumerate.

Let us look at some commonly used flags for SharpHound:

• Default: includes Active Directory security group membership, domain trusts, abusable permissions on AD objects, Organizational Unit (OU) tree structure, Group Policy links, the most relevant AD object properties, local groups from domain-joined Windows systems and user sessions.
• Group: includes mapping group memberships only.
• DCOnly: collects data only from the Domain Controller.
• LoggedOn: collects privileged session collection, requires local admin rights on the target systems.
• ComputerOnly: collects user sessions and local groups from domain-joined systems.
• All: perform all collection methods except for the GPOLocalGroup.

All flags are extensively explained in the link in references, for further reading.

After running SharpHound, the result will be a .zip archive. You will need to transfer that .zip file onto the box on which you have configured BloodHound, and from the application import the .zip archive into BloodHound and then you can start enumerating the domain and identify potential attack paths.

Lab Setup:

For the sake of this blog, and to keep things simple yet demonstrating the practical scenario, we will use a test database, that BloodHound provides (link in references), and we will run some queries on it and also try to identify attacks that are applicable to the test domain environment.

• BloodHound configured machine: Kali-Linux
• Domain Environment: Test domain environment, provided by BloodHound to explore the tool

To set up the test domain environment, clone the BloodHound-Tools repository from GitHub (link in references), install the prerequisites (as mentioned in the Readme) and run the DBCreator.py script.

$ pip3 install neo4j-driver
$ pip3 install -r requirements.txt
$ python3 DBCreator.py

First, we will have to configure the database connection:

$ dbconfig

Enter the bolt url and then neo4j credentials to configure the database connection.

Connect to the database:

$ connect

Generate the test domain environment:

$ clear_and_generate

It will take some time to complete. When it finishes, run BloodHound and login using your credentials, the test database will already be imported into BloodHound, and you will get to see an interface like:

Mapping out the Domain:

Now that we have our DB zip file imported into BloodHound, let us map out the domain. We will look at a few examples in this blog. To get a basic overview of our Domain we click the three-bars icon at the top-left corner, and we are presented with the Domain stats:

To run queries, select queries from the menu.

Example # 1: Identifying Domain Admins:

Clicking on the “Find all Domain Admins” presents us with all the Domain Admins in the Domain joined environment.

Example # 2: Getting More Information about a Specific Domain Admin:

Click on any of the Domain Admins, and a menu will open showing all possible properties for that specific Domain Admin.

Identifying Attack Paths:

BloodHound can be used to identify certain attack paths, which can be exploited by the attacker for lateral movement or privilege escalation. It also provides additional information about how to exploit. Similarly, as above we will have a look at a few examples.

Example # 1: Shortest Path to Domain Admins:

By clicking on the “Find Shortest Path to Domain Admins,” we are presented with an updated graph showing all the users that eventually lead to the Domain Admins.

We see that some users can RDP into some computer objects, while others have logged on sessions and all lead to Domain Admins.

Let us map out an attack path, to Domain Admins from the IT00238@TESTLAB.LOCAL group.

We right-click on IT00238@TESTLAB.LOCAL group and click on “set as starting node”.

Then we click on the road-like icon at the top-left corner and set our target to Domain Admins.

We see that a path has been generated which ends at the Domain Admins group.

We see that users in the IT00238 group are also a member of IT00408 group, and they are local admins on the COMP00037 computer on which BDETONE00479 user has a session, where the attacker can dump the credentials for this user and get access to the computer, which will make him a member of the IT00314 group.

Further along the path, we see that members of IT00314 group have administrative access to a bunch of computers, on which certain users of the Domain Admins have sessions.

Example # 2: Kerberoasting:

Going back to Queries, and clicking on “List All Kerberoastable Accounts”, we are presented with all the users in the domain that are prone to kerberoasting.

Example # 3: DCSync Attack:

Back to Queries and clicking on “Find Principals with DCSync Rights” we are presented with an attack path leading to the Domain Controller.

From here, we see that the most suitable attack path would be through the Domain Admins group, since we mapped out our attack path to own the Domain Admins group previously. We right-click on Domain Admins group and click on expand to see all the members of the Domain Admins group that can perform the DCSync Attack.

Further, if we right-click on “GetChanges or GetChangesAll” path and click on help we are presented with a dialogue box showing detailed information about this property.

By clicking on the Abuse Info tab, we are presented with information on how to perform the DCSync Attack.

Next, we have the OpSec Considerations and the References tabs that provide further reading material for exploitation and mitigation of the abuse.

The red team during an engagement, may compromise certain user accounts, they can mark those user objects as owned in BloodHound, and figure out the path to the Domain Controller from owned users/computers.

Custom Queries:

BloodHound also supports custom queries, in addition to the pre-built ones. You can define your own custom query in a json format, by clicking on the Queries tab, and then the edit icon at the bottom of the menu.

Similarly, Neo4j web-interface can also be used to run custom queries. This requires that your query be in Cypher.

Detecting BloodHound Usage:

Detection of BloodHound usage depends upon the detection of its Ingestors, i.e. SharpHound. Detection of SharpHound is simple. Look for events that query the TCP port 389 (LDAP) and/or TCP port 636 (LDAPS). Also look for events that show a large set of queries to the Active Directory simultaneously.

References:

• All SharpHound flags explained: https://bloodHound.readthedocs.io/en/latest/data-collection/sharphound-all-flags.html
• BloodHound GitHub repo: https://github.com/BloodHoundAD/BloodHound
• BloodHound example database for a test domain environment: https://github.com/BloodHoundAD/BloodHound-Tools
• Intro to Cypher: https://blog.cptjesus.com/posts/introtocypher
• Some BloodHound Custom Queries: https://gist.github.com/seajaysec/a4d4a545047a51053d52cba567f78a9b