Modifying Security Focus With Bloodhound
Prerequisite viewing: Let’s Enhance
At a very basic level, Active Directory authenticates and authorizes users and computers in a Windows domain environment. It can also be used to enforce security policies, Group Policy, BitLocker, registry settings, Certificate Services, Federations Services and much more.
As an organization’s Windows domain grows, it becomes increasingly complex. Understanding all of the relationships and potential security concerns created by a complex Active Directory environment can be extremely challenging. The image below is an example of how many ACL’s and relationships there could be in a domain with around 7,000 users:
In comes Bloodhound (https://github.com/BloodHoundAD/BloodHound) which creates a visual mapping of hidden and often unintended relationships with Active Directory. Attackers and Defenders can both use this tool to identify and eliminate complex relationships within Active Directory that may allow an attacker to escalate privileges.
As an attacker, Bloodhound is an essential part of my toolset and the best tool I have encountered for mapping Active Directory relationships in this way. Bloodhound offers many pre-built queries to look for common attack paths. However, there are still many attack paths that Bloodhound may identify that must be manually found through the Bloodhound interface. I was recently reminded of this on a penetration test when it took a while until I came across the following relationship:
In this case, the Authenticated Users group (which contains all Domain Users) had Generic Write permissions (for more info https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces) to various Users and Groups. Most of the groups happened to be privileged groups which granted administrative access to a system here and there. However, one of these groups granted all members of this group administrative privileges to vCenter.
We then used PowerView to add a user account we had previously compromised to the privileged group.
Due to the Authenticated Users group having Generic Write permissions on these privileged groups, we now have administrative access to vCenter which opens up a number of attack vectors for an attacker. We decided to use this access to create a new VMware snapshot of a Domain Controller:
We then downloaded the .vmem (virtual machines paging file) and .vmsn (stores state of virtual machine) snapshot files. At this point you may see that we intend to use Mimikatz on an offline copy of the Domain Controllers snapshot. The next step was to convert the previously obtained files into a format that Mimikatz can parse. This was accomplished via the following VMware Fusion tool and command:
At this point we are ready to use load the .dmp file into memory and use Mimikatz to extract out any credentials that may have been a part of the Domain Controller virtual machine snapshot. To do this we use WinDBG and the following article (http://carnal0wnage.attackresearch.com/2014/06/mimikatz-against-virtual-machine-memory.html?m=1):
We were then able to validate the compromised account had administrative privileges on the domain. None of which would have been possible if we did not take the time to thoroughly review our tool output and not just rely on the pre-built queries.
It is important for attackers and defenders alike to spend the time to take a deep look at the environment to identify any hidden configurations or relationships that may seem innocuous at a first glance but could have severe impact when abused. There is no one tool that can accomplish every task. Whether it be an attacker’s tool or a defender’s tool, each has a specific purpose and provides a certain level of detail or scope of information. To truly understand our environments and the risk present, we must consistently and repeatedly enhance our focus to reduce the likelihood of a configuration going unnoticed that may negatively affect the security of the organization.