A Guide To BloodHound

a guide to bloodhound

This is a short guide on how to execute a successful Bloodhound attack using Bloodhound.py script. I will be discussing initial setup with users in your lab environment to executing the necessary commands to run the attack and finally the impact this has on your QRadar environment. In addition to this, potential logic we may be able to implement to create a custom rule to fire when this attack takes place.

The first thing we need to setup in your lab environment is a path to the Domain Controller (DC), from a regular user who has been exploited; this is how we will simulate the attack. To do this, create a user in the local device, giving him basic permissions; open your DC environment and go to server manager, click tools in the top right corner and select ‘Active Directory Users and computers. Within a new organizational unit right click and create a new user. Next, create a group which has Generic_all access to the ‘Domain Admins’ group. Add your recently created user to the newly created Group, I have called mine London Admins. In the below example you can see my created user (John Barnes) is part of the London Admins group who have full control over Domain Admins. 

You can see the permissions granted to the group in the below screenshot. ‘Generic_all’

Now we can move onto setting up Bloodhound.py in our Kali Linux environment. The first thing we need to do is to create a new file directory using the mkdir command in command window.  I have named mine ‘BH_tut’. Once inside your new file directory you should download the source code from github using the git clone command this link: ‘https://github/fox-it/Bloodhoung.py’ 

Once the file is downloaded, we can navigate into the ‘Bloodhound.py’ directory. Once here we must successfully enumerate an AD Domain account (the one we created earlier) mine is john.teacher. This is to enable data files to be extracted from Domain Directory and transferred to the Bloodhound system. See the example below for the command I ran to enumerate the required files. -c = what you want to extract, -u = exploited user, -p = password for the user, -d = domain, -ns = DC IP address.

Once the enumeration has been successfully completed, we can use the ‘ls’ command to see the different files we have generated. As you can see below a separate json file for each category is created; computers, domains, groups and users. This is data we will use to insert into our Bloodhound setup. 

When these files are enumerated, you should see new log activity within your QRadar lab environment, you will see the below Event (Event id 4799 – Success Audit: Group Membership Enumerated) approximately 4 times, 1 for each of the files created.

As you can see, the Account Name which was enumerated was ‘john.teacher’ and the Group Name was ‘Remote Desktop Users’, indicating we have successfully exploited this user via remote access, gaining crucial data for the next part of the attack.

Moving onto how to install and run the Bloodhound program, we must use neo4j an open-source Graph database. To install this run the following command in command window as demonstrated below: sudo apt install neo4j 

Once neo4j has been installed we must use the ‘sudo neo4j console’ command to establish a connection to the neo4j host. 

Use the following link on a web browser to complete the connection to neo4j: http://localhost:7474/ 

You will be prompted to change your password so go ahead and do so. 

Next, unzip the Bloodhound file with the following command: unzip BloodHound-linx-x64.zi

In a new tab in your linux terminal run ./BloodHound command

You will be prompted by the BloodHound login window upon running the command, where you can log in with neo4j and your new password which you just setup.

Once logged in, open your folder containing your newly enumerated json files and drag them into BloodHound – this will populate the paths available for each user/group. 

As you can see the path we have chosen to display is from the exploited user (bottom left) who is a member of London Admins group, and that group has GenericAll privileges to Domain Admins group (bottom right), which for a hacker will be of high interest.

The next part of this attack is to use the evil-winrm command to enable remote logon to the targeted user. -i = DC IP address, -u = user, -p= password for the user

Upon running this command, you should notice some events in your QRadar environment, Event ID 4776 ‘Success Audit: The domain controller validated the credentials for an account’ as shown below, notice the logon account was our exploited account and the source workstation remains empty, whereas compared to a normal logon you can see the workstation is clearly defined; in this case our DC.

Now using Evil Winrm we want to exploit the path we created earlier john.teacher gaining access to Domain Admins via London Admin group. Note once the command has been run you must exit out of Evil-Winrm (ctrl C) and re-enter for the change to take place.

Once entering back into evil-winrm we can run the whoami/groups command this will show you if we have successfully added our user to Domain Admins group. As you can see below, we have been successful in adding our user to this critical group.

Now we can see some of the effects this had on our QRadar environment and what events we should be looking out for. Below you can see Event ID 4728 Success Audit: A member was added to a security enabled group, this will fire once we have successfully added our user to the critical group. 

The below Event ID: 4737 ‘Success Audit: A security enabled global group was changed’ again validating that our attempt to move user groups was successful. 

You may also see Event ID: 4672 ‘Successful Audit: successful logon with administrative or special privileges’ as shown below:

Leave a Comment

Your email address will not be published. Required fields are marked *