Active Directory (AD) is the central administrative point for access data, roles and rights. Along with the Windows infrastructure, other applications are integrated via single sign-on. Anyone with administrative access to AD can control access to applications and their data and issue Kerberos tickets, which allow access to information. An intruder (offense) in the internal network will therefore attempt to gain privileged rights in AD. Meanwhile, the relevant IT department (defense) will work hard to prevent precisely this from happening. Domain users already have extensive read rights in AD and are able to access plenty of information, including attributes of users and groups, access rights (ACL) and group policies. These standard rights make it harder to protect AD, because the intruder can already get hold of plenty of information in this way.

Introducing BloodHound

On August 4, 2016, Defcon 24 saw the introduction of the BloodHound tool in the talk Six Degrees of Domain Admin by the developers and penetration testers Andy Robbins, Will Schroeder and Rohan Vazarkar, with version 1.0 appearing two days later. This tool makes use of precisely this configuration of open read rights in Active Directory. With the ‘Ingestor’, AD objects are read and then displayed graphically. The tool takes the data retrieved and generates a list of users and groups, their rights and the systems they are presently logged into. These connections are extremely valuable to intruders, allowing them to find pathways to members of the Domain Admins group and perhaps attack them. But BloodHound is also highly useful in defending against such attacks, as it can be used to identify any vulnerabilities and fix them.

Version 1.4 of BloodHound was released a little over a year later, in October 2017. This version comes with a number of improvements. BloodHound now displays object properties, such as user name, last password change and time of login. In addition, the ingestor previously based on PowerShell v2 was completely reworked and rewritten in C#. This new C# ingestor is called Sharp Hound and is available as a binary file or PowerShell script. With the PowerShell script, the binary is unpacked and executed at run time. In a blog post entitled SharpHound: Evolution of the BloodHound Ingestor, Rohan Vazarkar describes how SharpHound has been reworked and its new functions.

Collecting data

First, SharpHound retrieves information from Active Directory and stores it in the backend. BloodHound stores data with Neo4j. The backend can be installed on Windows, Linux or MacOS. By default, SharpHound generates CSV files, which are imported into the backend. The parameters --Uri and --UserPass are used to write the data collected directly to the Neo4j instance. This is useful if SharpHound is being run on multiple systems, or if there is a loop that regularly reads sessions (parameter -c SessionLoop). Depending on the AD topology and network segmentation, SharpHound’s analysis may be incomplete, as it may not be able to access the server, preventing enumeration of sessions. Where possible, SharpHound should be run on multiple systems and network segments in order to cover any blind spots.

SharpHound always reads trusts, sessions, local admin and group membership. Further attributes can be added with the parameter -CollectionMethod. For the initial data collection we recommend adding logged on, ACL and object props to the collection. The logged on attribute requires administrative rights to the target system in order to read the users. An intruder with domain user rights will not be able to access this data. SharpHound creates a cache file called BloodHound.bin to speed up execution for multiple queries.

For the intruder, the --Stealth and --ExcludeDC options are of interest. The latter prevents session information from being queried by domain controllers (DCs). This prevents Microsoft ATA from detecting scans, because ATA only monitors DCs in this context.

Visualization of AD objects

BloodHound shows the information collected. Context-related information for the respective object is found under Node Info:

You can navigate further from any given node, for instance, to see the groups to which a user belongs, or for which systems the user has local administrator rights. Here there is a distinction between directly allocated and inherited rights.

Version 1.4 offers an additional function that shows which users or groups have DCSync rights.

DCSync rights allow objects to be replicated. An intruder can use them to obtain access data for the account krbtgt using Mimikatz.

Pathways to the domain admin

We set BloodHound on the path of members of the group Domain Admins in our lab lab.scip.ch to find out how an intruder can obtain domain admin privileges. In the first example, the domain admin adm_hwashburne is logged onto the computer client02.

The user adm_jcobb, who holds local administrator rights to all workstations in the domain as a member of the IT Supporter group (G-IT-ADM-Support), would be able to obtain domain admin credentials. Here intruders could also exploit the service user for the workstation anti-virus software (srv_antivirus). For security reasons, accounts with domain admin rights should not log in on workstations or other systems that are not extra well-secured.

In the second example, there is a backup job running on the computer file01, executed by the service user srv_backup. This user has domain admin rights.

The user adm_zwashburne, an IT staff member and administrator of member servers, would then have the ability to gain access data. This case raises the question of whether backup service users really need domain admin rights, or if dedicated rights might suffice instead.

In the third example, a domain user may gain domain admin rights directly. The user rtam is a developer and has gained administrator rights to the application server app01. The domain admin adm_hwashburne is currently logged on to this server.

The rights of the account rtam can be directly escalated to those of a domain admin. This is an unsecured allocation of rights. A normal user account should never have administrator rights on a server. Separate accounts should always be used – normal accounts for basic tasks and special accounts with administrative privileges. Developers and other user groups should have no other special rights, even when it comes to exceptions or – as in this case – individual servers. This improper configuration could allow an intruder to take control of domains.

Conclusion

These examples illustrate benefits for offense and defense in equal measure. The offense approach found a number of interesting targets that can be exploited to gain additional rights. BloodHound can be used to collect data and effectively identify such attack routes, without having to manually test systems with targeted procedures.

On the defense side, a number of potential vulnerabilities were discovered, allowing appropriate countermeasures to be taken. For instance, it is a good idea to create a policy that prevents domain admin accounts from being used to log in from workstations.

I can highly recommend running BloodHound on your AD infrastructure and studying the most direct route to the domain admin. Happy hunting!

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• https://blog.cptjesus.com/
• https://blog.cptjesus.com/posts/bloodhoundobjectproperties
• https://blog.cptjesus.com/posts/newbloodhoundingestor
• https://github.com/BloodHoundAD
• https://github.com/BloodHoundAD/BloodHound/releases/tag/1.4
• https://github.com/BloodHoundAD/BloodHound/releases/tag/v1.0.0
• https://github.com/BloodHoundAD/BloodHound/wiki/Getting-started
• https://github.com/BloodHoundAD/SharpHound
• https://github.com/gentilkiwi/mimikatz/wiki/module-~-kerberos
• https://github.com/gentilkiwi/mimikatz/wiki/module-~-lsadump#dcsync
• https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Robbins-Vazarkar-Schroeder-Six-Degrees-of-Domain-Admin.pdf
• https://neo4j.com/download/
• https://twitter.com/harmj0y
• https://www.defcon.org/html/defcon-24/dc-24-schedule.html
• https://www.microsoft.com/en-us/cloud-platform/advanced-threat-analytics
• https://www.twitter.com/_wald0