Lay of the Land with Bloodhound

Sammy Marar -

BloodHound

When I came across the tool BloodHound, it quickly became one of the go-to tools in my arsenal. BloodHound has increased my speed and efficiency on most engagements and so I wanted to share what I've learned about the tool to help you get started with it. In this blog post, I'll take you through how to get started with BloodHound and how to use it to map and own Active Directory environments.

History

BloodHound was inspired by a need for an offensive dashboard that graphically represents Active Directory domain escalation attack paths. BloodHound was developed by Rohan Vazarkar, Andrew Robbins, and Will Schroeder and released during DEF CON 24. It was built on several existing toolsets and conceptual models: PowerView, Graph Theory, Derivative local admin theory, Dijkstra's Algorithm, and PowerPath.

BloodHound quickly enumerates group membership information and user privileges and compiles them to an easy-to-understand GUI. An offensive practitioner can visualize attack paths based on these relationships and find the quickest path of attack for any account, group, or computer in the domain. With limited time on each engagement, being able to quickly map relationships and locate viable attack paths can help pentesters utilize their time more effectively.

Up and Running with BloodHound

On the surface, BloodHound is relatively intuitive. The clean web interface, with the inclusion of several default queries, is simple enough to understand without extensive research or experience. However, this does not imply BloodHound lacks depth.

PowerShell Ingestor

Once you have established a foothold on the network, you can import the PowerShell ingestor for BloodHound to collect data about trusts, users, and all other object relationships in an Active Directory environment. BloodHound uses a modified version of PowerView to collect data. We can use either the BloodHound Empire Module or another C2 framework for data collection.

Empire

The PowerShell ingestor BloodHound.ps1, implements the Invoke-BloodHound function for collecting and exporting data.

_Select the module: _ Powershell/situation_awareness/network/bloodhound
Select the appropriate download location
Run the module:
CSVs are exported to the defined location

CSV Files are written to the current directory:

Uploading and Querying

Once you have exported the data to CSV, download the files and upload them to BloodHound

Alternatively, you can export the data directly to the Neo4j REST API using the -URI and -UserPass arguments as described in the BloodHound Github _ wiki._

Querying

BloodHound includes several powerful baked-in analytical queries. A notable query here is "shortest path to Domain Admins".

The example below displays the query "Find Top 10 users with the Most Admins".

BloodHound also includes custom node selection where a specified source, and target node are selected for attack path mapping. Perhaps you would like to skip finding a path to domain admin and would rather move straight to a database or the domain controller itself.

You can select the compromised object as a start node and the target machine as an end node.

Cypher

BloodHound uses Neo4j as its graph database. Neo4j interactions are driven by "Cypher". Cypher was inspired by SQL and was developed as a declarative graph query language for describing patterns in graphs visually. BloodHound comes pre-built with several "Cypher" queries; however, you can create your own to meet your specific needs.

The built-in queries are good enough for a penetration tester to achieve success on most engagements without the need to develop additional custom Cypher queries. This, and the requirement to learn Cypher, result in custom queries being frequently ignored. However, learning even just a bit of Cypher can prove to be well worth the effort, as custom queries are a powerful feature of BloodHound.

Common terms from Graph theory are directly applicable to the Neo4j Graph Database, such as edges and nodes. In the context of BloodHound, a node represents either a User, Group, Computer, or Domain. Each node represents an object that can be acted upon when moving through an Active Directory Environment.

Edges represents relationships between nodes. In the context of BloodHound, edges represent MemberOf, AdminTo, HasSession, TrustedBy. In version 1.3 of BloodHound, a new set of edges for access control entries was introduced. These include ForceChangePassword, AddMemebers, GenericAll, GenericWrite, WriteOwner, WrieDACL, and AllExtendedRights. Together edges and nodes create the paths that we use in BloodHound.

Check Out CptJesus's blog on cypher for a more advanced look!

BloodHound applied

The following example is a simple use-case for BloodHound in which we use a theoretically compromised user as a start point; identifying the strategic lateral movements required to help us pivot through the network. Our target is the Domain Administrator account. We've selected a compromised account as the start point and the Domain Administrator account as our target node.

  1. In the example above we have compromised the user TEST1@PTEST.LOCAL after acquiring valid user credentials via Responder or through an exploit.
  2. This user has administrative access to both TESTHOST.PTEST.local and TESTHOST2.PTEST.local indicated by the "AdminTo" relationships.

3.Theoretically, we can use the MSF module "psexec_psh" to gain an active session on either TESTHOST.PTEST.local or TESTHOST2.PTEST.local.
4. BloodHound indicates both machines have an active session with the user, SMARAR@PTEST.local.
5.
5.With the active session on TESTHOST.PTEST.LOCAL , we can enumerate processes and the owner of each process. We do this to locate a process owned by the identified user with the active sessions. If we find a process for one of the users, we can then steal the token from that process "steal_token PID" (ex. "steal_token 694"). By stealing this token, we can impersonate the selected user.

Cleartext passwords

SAM Hashes

  1. Analyzing the attack path, we can see our target user has administrative access to DC-01.PTEST.LOCAL, which is our target.

If we wish to verify this, we can use "ls \DC-01\C$". This command lists the C$ directory and can only be done with valid access".

With the user having administrative access to this machine, we can use this user for our attack path.

  1. BloodHound indicates SMARAR@PTEST.LOCAL has a session with DC-01.PTEST.LOCAL. We identify this by the hassession relationship between the user and the identified machine.

8.Using SMARAR@PTEST.LOCAL , we can psexec_psh into DC-01.PTEST.LOCAL. Once we have established a session on the system, we again have multiple options to compromise the administrator account and achieve our goal. Using either Mimikatz, Lazykatz, or stealing a token we can gain access to the user ADMINISTRATOR@PTEST.local. Once we've completed this step, we have successfully compromised the Domain Administrator account.

ACL Attack Paths

Version 1.3 of BloodHound introduced an exciting new feature which gives an attacker more options to exploit different Active Directory objects. Version 1.3 includes new edge types based on Active Directory object control. The update adds several new edges based on object permissions that BloodHound indicates as abusable. ACL-based attack paths identify exploitable object access control entries (ACE)s within discretionary access control Lists (DACL)s.

DACLs

Active Directory has several common securable objects which contain security descriptors. These security descriptors contain DACLs which hold Access Control Entries. Common objects include users, groups, and computers which correlate to the nodes in BloodHound.

The example below you can see the DACL and individual ACEs for the user smarar.

An object can have different access rights to another object. For example, Domain Admins usually have full control over user accounts within the domain. Alternatively, an authenticated user perhaps only has read access to certain information about the user. As an attacker, we are interested in understanding how we can leverage these access rights to gain control over objects of interest to get us closer to our goal.

DACLs in BloodHound

Version 1.3 of BloodHound includes the PowerShell "ACLs" cmdlet that performs the collection of object to object permissions in an AD environment.

_Invoke-Bloodhound _ -CollectionMethod ACLs :

When we upload the data to BloodHound we can see the new edge types displayed.

In the example above we can see two new edge types of object to object permissions:

GenericAll: Full object control, including the ability to add other principals to a group, change a user password without knowing its current value, register an SPN with a user object, etc. Abused with Set-DomainUserPassword or Add-DomainGroupMember cmdlets.

_WriteDACL: The ability to write a new ACE to the target object's DACL. For example, an attacker may write a new ACE to the target object DACL giving the attacker "full control" of the target object. Abused with Add-NewADObjectAccessControlEntry. _("BloodHound 1.3 – The ACL Attack Path Update." wald0.Com)

These are just two examples of new edges. Other edges include ForceChangePassword, AddMembers, GenericAll,GenericWrite,WriteOwner, WriteDACL,AllExtendedRights.

When BloodHound creates an attack path against Active Directory using ACLs, it will likely use more than one type of permission. Exploiting these permissions can be invasive and detected fairly easily. If an attacker, for example, leverages 'GenericAll' permission to change a password, and that user then is unable to log in, this could alert the user of your presence.

Will Schroeder (harmj0y) and Lee Christensen (tifkin) created a whole suite of new PowerShell cmdlets to exploit each ACE. These functions have not been committed to the Master Branch yet and so you will need to grab the Powerview.ps1 script from the dev branch, if you want to try them out.

https://github.com/PowerShellMafia/PowerSploit/tree/dev

Upload the script to Empire and take a crack at some of these awesome cmdlets.

You can check to see if you have done this correctly by verifying the new cmdlets exist
Note: Many of these modules are still in development and may not work correctly out of the box with Empire.

A Blue Team Perspective

Risk Auditing

Auditing Active Directory best practices and properly maintaining an effective AD security posture is a complex and challenging topic that is vital to an organizations overall security. Assessing an AD environment should be done frequently to ensure a secure architecture and alignment with business goals.
An organization must be able to answer questions including but not limited to; Who has what level of privileged access in our AD environment? Who can create or delete objects? Who can reset passwords and modify group memberships?

BloodHound is a viable tool for performing risk audits for an Active Directory environment. The same attack paths used by an attacker can be identified and remediated by a defensive practitioner. A defensive practitioner can use BloodHound to easily visualize object privileges and relationships. The addition of ACL attack paths in version 1.3 also added far more opportunities to identify risk past simply group membership and active session information. Defensive practitioners can audit security descriptors by enumerating DACL entries. This gives us deeper insight to specific object permissions.

After running BloodHound against your own environment, you can identify risks in object memberships, effective permissions, GPOs, or DACL entry misconfigurations. An organization should carefully audit these policies and ensure an appropriate architecture for their organization that enforces least privilege and a tiered administrative model. This will ensure that even if an attacker has mapped the environment, there will be limited and monitored viable attack paths.

Check out https://adsecurity.org/?p=3658 and https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material for an in depth look at Auditing privileged access.

Detection and Mitigation

But what can we do as far as active defense? When this tool is used as a reconnaissance tool against our environment, what can a defensive practitioner do to detect and mitigate BloodHound? BloodHound is nearly invisible, so understanding how it works at its core is essential to be able to detect it.

BloodHound's core components are data ingestion and visualization. As mentioned previously, BloodHound is a specialized version of Powerview. Powerview only needs version 2.0 of PowerShell to run, making it able to run on default configurations on machines running Windows 7 or later.

The collection modules which PowerView uses to enumerate AD information do not require special permissions. These can be run by regular users on the network. Enumeration is done using LDAP via ADSI. Since there is traditionally no logging for these features, this makes detection of BloodHound increasingly difficult.

The traffic sent to the domain controller through port 389 is negligible. Traditional event logging would not provide us any events in this situation.

So, what does BloodHound traffic look like? While running BloodHound, we can look at Wireshark to see what behavior BloodHound prompts.
We can see that BloodHound causes high volumes of LDAP traffic. An option for defensive practitioners is to monitor for this high volume of LDAP traffic and enable a rule to log this traffic.

Network administrators can enable a rule that would log high volumes of LDAP traffic with LDAP sessions longer than traditional. It is best to baseline your network traffic and then observe the changes when running BloodHound.

Wrapping Up

With limited time to analyze each unique Active Directory environment, its trusts, relationships, and objects, BloodHound could mean the difference between hours of effort or quickly owning an environment in a matter of a few steps. The reduced overhead and complexity in AD analysis alone are enough to make BloodHound a must have tool in any penetration testers toolbelt.

Bloodhound continues to receive new features and the developers of BloodHound are continuously researching ways to create more stealthy attack paths. Be sure to check out the ACE attack path update. Future updates should include exploitable GPO edges.

References