BloodHound, available at bloodhound.readthedocs.io, maps Windows Active Directory permissions to a graph database that lets users trace attack paths using a GUI and a query system. To make that more concrete, BloodHound can answer questions such as:

  • Who is allowed to RDP to Computer132?
  • Which computers does JohnSmith have admin access to?
  • What are all the users with effective Domain Administrator access?
  • How can an attacker escalate privileges on the network?

In the rest of this post, I will give specific recommendations for what to look for in BloodHound to find quick wins securing a network.

Setup

Install Neo4j and BloodHound as described in the docs. Consider installing it in a VM or with some form of sandboxing, mainly because of CVE-2019-15701.

Gather the data with SharpHound. Note that the precompiled version is often detected as malware. BloodHound.py can also be used, but it won’t collect as much data.

The docs have a good introduction to the GUI. In particular, the fourth from the top button on the right side is used to upload the collected data.

Using BloodHound

As a sanity check, search for a username in the search bar, select the node in the main window, and make sure the node properties in the top left panel look right. Consider repeating with a hostname. This usage pattern is probably the most common: clicking on nodes and reviewing/clicking the information in the left panel.

Another common usage pattern is searching for more complex queries. Pre-built queries are found in the analysis tab in the left panel, and these can be modified or written by using the Raw Query tray at the bottom of the window.

Query 1: Computers with all users granted Local Admin access

Now that BloodHound is set up, you can start looking for permission issues on the domain. The first query to try is the pre-built query “Find Computers where Domain Users are Local Admin”, which does what it says. It should return no results. If any computers do appear, ensure that domain users are no longer granted local admin access.

We see at least one computer configured this way on about half of our internal assessments. These computers provide an easy stepping stone for an attacker to go from a single domain account to significantly more access. Having admin on a computer would allow an attacker to dump all other secrets on that machine (Windows loves to store credentials), read configurations and perform more recon, and convert that computer to a honeypot, gathering more credentials from anyone who connects to it.

Query 2: Path from low-privilege user to high value targets

Pick a normal low-privilege user (not in any special groups), search for it, and select it. In the left panel, look in the “OVERVIEW” section in the “Node Info” tab for “Reachable High Value Targets”. If the number in that row is 0, that’s good. If it is nonzero, click it for an attack path.

This attack path can range from straightforward to long and arcane, but it is important. Starting from the source user, look up the edges in the BloodHound docs. Some of the edge types are simple, like “AdminTo” and “CanRDP”, but some are more complex, like “Owns”. Snip enough of these edges to break the attack path.

Query 3: Kerberoastable users

Kerberoasting is a technique where attackers can gather hashes for domain accounts that have an SPN. The attacker can then attempt to crack these hashes offline. The more technical details of this attack are outside the scope of this post, but we frequently find kerberoastable users with crackable passwords on assessments.

There are many ways, manual or automated, to find kerberoastable users, but BloodHound both makes it easy and can help prioritize which kerberoastable accounts are the most sensitive. Go to the “Analysis” tab in the left pane and select the pre-built query “List all Kerberoastable Accounts”. If this returns too many users, start with “Find Kerberoastable Members of High Value Groups” instead.

For each of these accounts, assume that an attacker is attempting to crack its hash offline. Ensure that:

  1. The password is regularly rotated.
  2. The password is long and complex enough to stand up to a dedicated attack for the rotation period.
  3. As always, the password is randomly generated.

A reasonable default is a random 64-character password rotated every 30 days. This recommendation works because these are service accounts (since they have SPNs), and users won’t need to type in the passwords anywhere. In addition, consider auditing the permissions for these users and reducing them to only what is necessary. This extra effort is warranted because of how easy it is to attack these accounts.

And beyond

BloodHound can be used for so much more, but these three queries can fix a lot of the low-hanging fruit in terms of security issues. Here are some more things to try:

  1. Go through all of the other pre-built queries.
  2. Try repeating query 2 with other accounts. For example, is there a way for the service desk to compromise the domain?
  3. Try searching for attack paths to sensitive computers that are custom to your environment. You can mark nodes as high-value by right-clicking.
  4. Start writing custom queries. Part 4 of Dog Whisperer at https://github.com/SadProcessor/HandsOnBloodHound/tree/master/BH21 is a great introduction.
  5. Automate collection and queries with the Neo4j API. Here’s a jump-start: curl -s localhost:7474/db/data/transaction/commit -H 'Authorization: Basic <snip>' -H "Content-Type: application/json" -d '{"statements":[{"statement":"<query>"}]}' | jq -r .results[].data[].row[]