Analysing Data using BloodHound
In this section, we will analyze the domain data using BloodHound
in Kali Linux, but it should be noted that we could install the application
and required dependencies on Windows-based systems as well.
In order to use BloodHound, we need to start the Neo4j service,
which is installed by default.
Note that when Bloodhound is installed with APT,
the Neo4j service is automatically installed as well.
Neo4j is essentially an open source graph database (NoSQL) that creates nodes,
edges, and properties instead of simple rows and columns.
This facilitates the visual representation of our collected data.
Let’s go ahead and start the Neo4j service:
As indicated in the output, the Neo4j service is now running
and it should be available via the web interface at http://localhost:7474.
Let’s browse to this location and authenticate using the default
credentials, neo4j as both username and password, or existing credentials:
If authenticating with the default credentials,
we will be prompted for a password change.
In this case, we will authenticate with existing credentials; however,
we must remember it since we’ll also use it to authenticate to the database later.
Let’s authenticate to the database and run our own queries against it.
However, since we haven’t imported any data yet there isn’t much we can do
and we’d rather allow BloodHound to run the queries for us.
With Neo4j running, it’s time to start BloodHound as well.
We can do this directly from the terminal:
Once we start BloodHound, we are met with an authentication window,
asking us to log in to the Neo4j Database:
As indicated by the green check mark in the first column,
BloodHound has automatically detected that we have the Neo4j database running.
In order to log in, we’ll use the neo4j username and the password
we created earlier.
Since we haven’t imported data yet, we don’t have any visual representation
of the domain at this point.
In order to import the data, we must first transfer the zip file
from our Windows machine to our Kali Linux machine.
We can then use the Upload Data function on the right side of the GUI to upload
the zip file, or dragand-drop it into BloodHound’s main window.
Either way, the progress bar indicates the upload progress.
Once the upload is finished, we can close the Upload Progress window.
Now it’s time to start analyzing the data.
Let’s first get an idea about how much data the database really contains.
To do this, let’s click the More Info tab at the top-left.
This presents the Database Info:
Our small environment doesn’t contain much.
But in some cases, especially in a larger environment,
the database may take some time to update.
In these cases, we can use the Refresh Database Stats button
to present an updated view.
Looking at the information, we have discovered four total sessions
in the domain, which have been enumerated using the NetSessionEnum and PsLoggedOn
techniques we used earlier.
Additionally, we have discovered a wealth of ACLs,
a total of 10 users, 57 groups, and more.
We’ll explain the Node Info later, as there isn’t much here at this point.
For now, we are mostly interested in the Analysis button.
When we click it,
we are presented with various pre-built analysis options:
There are many pre-built analytics queries to experiment with here,
and we will not be able to cover all of them in this Module.
However, to get started, let’s use Find all Domain Admins
under Domain Information.
This presents a graph:
Each of the circle icons are known as nodes,
and we can drag them to move them in the interface.
In this case the three nodes are connected and BloodHound placed them far apart from
each other, so we can simply move them closer to each other to keep everything
nice and clean.
In order to see what the two nodes on the left represent,
we can hover over them with the mouse pointer,
or we can toggle the information by pressing the control button.
While toggling on and off the information for each node may be preferred for some
analysis, we can also tell BloodHound to show this information by default
by clicking Settings on the right side of the interface and setting
Node Label Display to Always Display:
Based on this view, the Domain Admins for the domain are indeed jeffadmin
and the administrator account itself.
BloodHound shows an edge in the form of a line between the user objects and the
Domain Admins group, indicating the relationship, which in this case tells us
that the particular users are a member of the given group:
Although BloodHound is capable of deep analysis,
much of its functionality is out of scope for this Module.
For now, we’ll focus on the Shortest Paths shown in the Analysis tab.
One of the strengths of BloodHound is its ability to automatically attempt to find
the shortest path possible to reach our goal, whether that goal is to take over
a particular computer, user, or group.
Let’s start with the Find Shortest Paths to Domain Admins as it provides a nice
overview and doesn’t require any parameters.
This reveals the true power of BloodHound.
We can analyze this graph to determine our best attack approach.
In this case, the graph will reveal a few things we didn’t catch in our
earlier enumeration.
For example,let’s focus on the relationship between stephanie and
CLIENT74, which we saw in our earlier enumeration.
To get more information, we can hover the mouse over the string that indicates the
connection between the node to see what kind of connection it really is:
The small pop-up says AdminTo, and this indicates that stephanie indeed has
administrative privileges on CLIENT74.
If we right-click the line between the nodes and click ? Help,
BloodHound will show additional information:
As indicated in the pop up, stephanie has administrative privileges on CLIENT74
and has several ways to obtain code execution on it.
After further reading, and after further inspection of the graph,
we discover the connection jeffadmin has to CLIENT74.
This means that the credentials for jeffadmin may be cached on the machine,
which could be fatal for the organization.
If we are able to take advantage of the given attack path and steal the
credentials for jeffadmin, we should be able to log in as him and become
domain administrator through his Domain Admins membership.
This plays directly into the second Shortest Path we’d like to show for this
Module, namely the Shortest Paths to Domain Admins from Owned Principals.
If we run this query against corp.com without configuring BloodHound,
we receive a “NO DATA RETURNED FROM QUERY” message.
However, the Owned Principals plays a big role here,
and refers to the objects we are currently in control of in the domain.
In order to analyze, we can mark any object we’d like as owned in BloodHound,
even if we haven’t obtained access to them.
Sometimes it is a good idea to think in the lines of “what if” when it comes to
AD assessments.
In this case however, we will leave the imagination on the side and focus on
the objects we in fact have control over.
The only object we know for a fact we have control over is the stephanie user,
and we have partial control over CLIENT75, since that is where we are logged in.
We do not have administrative privileges, so we may need to think about doing
privilege escalation on the machine later,
but for now, let’s say that we have control over it.
In order for us to obtain an owned principal in BloodHound,
we will run a search (top left), right click the object that shows in the middle
of the screen, and click Mark User as Owned.
A principal marked as owned is shown in BloodHound with a skull icon next to
the node itself.
One thing to note here is that if we click the icon for the object we are searching,
it will be placed into the Node Info button where we can read more about the
object itself.
We’ll repeat the process for CLIENT75 as well, however in this case we’ll click
Mark Computer as Owned, and we end up having two owned principals.
Now that we informed BloodHound about our owned principals,
we can run the Shortest Paths to Domain Admins from Owned Principals query:
It’s a good idea to mark every object we have access to as owned to improve our
visibility into more potential attack vectors.
There may be a short path to our goals that hinges on ownership
of a particular object.
Note that we have rearranged the nodes to clarify our potential attack path.
Let’s read this by starting with the left-hand node, which is CLIENT75.
As expected, stephanie has a session there.
The stephanie user should be able to connect to CLIENT74,
where jeffadmin has a session.
jeffadmin is a part of the Domain Admins group,
so if we are able to take control of his account by either impersonating him
or stealing the credentials on CLIENT74, we will be domain administrators.
BloodHound comes with a wealth of functions and options we cannot
fully cover in this Module.
While we focused mostly on shortest paths, we highly recommend getting accustomed
to the other BloodHound pre-built queries within the Challenge Labs.