BadBlood - Active Directory vulnérable

populate a vulnerable Active Directory quickly

I. Presentation

In this article, we will see how to automatically popular (= providing information to a database) a Active Directory by integrating vulnerabilities. This can be useful in the context of formation or for learn to handle offensive or defensive tools around the Active Directory.

II. Precautions for use

The script we are going to use must be run as the domain administrator. Indeed, its role is to add different objects and relationships between these objects within the Active Directory. It will also install features like LAPS which can be helpful in deploying specific vulnerabilities.

It goes without saying thatthis tool should absolutely not be used in a production Active Directory environment. So be careful not to be under no circumstances able to communicate with your production Active Directory during its execution.

For my part, I installed an Active Directory on a test Windows VM, in a local network dedicated to my VirtualBox. My primary goal is to study the behavior of the script and see if it can introduce vulnerabilities visible to tools like Bloodhound, PingCastle, etc.

III. Using BadBlood

The BadBlood tool is composed ofun script principal (Invoke-Badblood.ps1) as well as several folders storing PS1, ADMX, MSI files (for example to install and configure LAPS.) As well as different word lists for generating objects with random names.

It should be noted that at each executionBadBlood will generate different AD objectsthe names and natures of the relations between the objects are generated randomly.

Le script PowerShell Invoke-Badblood.ps1 obtained only needs to be executed, no need toimport-module. The idea is therefore to create a population in our Active Directory containing:

  • users,
  • groups/OR,
  • workstations,
  • relationships of any type between these different objects.

Here is the count of user, computer, and group objects before running the script:

Object count before running BadBlood (freshly installed AD)
Object count before running BadBlood (freshly installed AD)

After downloading the Github repository content locally, the execution of the script is done via the following PowerShell commands:

Set-ExecutionPolicy bypass
.\Invoke-BadBlood.ps1

As it is a VM used for tests, we can afford to switch the execution policy to “Bypass”. At runtime, the actions performed are detailed in the terminal output. Please note that some error messages may appear:

Terminal return from BadBlood execution
Terminal return from BadBlood execution

It seems that depending on your version of PowerShell, your AD environment or installed ADSI commands, some commands are not accessible. In the various tests that I have been able to do, this has not didn’t really have any impact on the final result.

Here are the same accounts after running the script:

Observation of the number of objects created by BadBlood in an Active DIrectory
Observation of the number of objects created by BadBlood in an Active DIrectory

It can be seen that more than 2400 users, 500 groups and 100 computers were created on my Active Directory, all in a few minutes. If we look carefully at the content of the main script, we notice the possibility of indicating the number of objects to create for each category, for this you must use the position of the desired parameter:

param
(
[Parameter(Mandatory = $false,
Position = 1,
HelpMessage = 'Supply a count for user creation default 2500')]
[Int32]$UserCount = 2500,
[Parameter(Mandatory = $false,
Position = 2,
HelpMessage = 'Supply a count for user creation default 500')]
[int32]$GroupCount = 500,
[Parameter(Mandatory = $false,
Position = 3,
HelpMessage = 'Supply the script directory for where this script is stored')]
[int32]$ComputerCount = 100,
[Parameter(Mandatory = $false,
Position = 4,
HelpMessage = 'Skip the OU creation if you already have done it')]
[switch]$SkipOuCreation,
[Parameter(Mandatory = $false,
Position = 5,
HelpMessage = 'Skip the LAPS deployment if you already have done it')]
[switch]$SkipLapsInstall,
[Parameter(Mandatory = $false,
Position = 6,
HelpMessage = 'Make non-interactive for automation')]
[switch]$NonInteractive
)

IV. Example of result

Following the execution of the script, I sought to discover vulnerabilities quickly with the Bloodhound tool. This makes it possible to discover complex attack paths via the different relationships that may exist between AD objects:

Examples of attack paths in populated AD via BadBlood
Examples of attack paths in populated AD via BadBlood
Examples of attack paths in populated AD via BadBlood
Examples of attack paths in populated AD via BadBlood

I quickly noticed that many paths of attack were present, which was more than enough to confirm the proper functioning of this tool :). I also did some analysis using PingCastle:

Result of a PingCastle scan after running Badblood
Result of a PingCastle scan after running Badblood

Here too, several vulnerabilities have been reported.

Badblood is in my opinion one of the most faster and easier to use for deploying vulnerabilities around Active Directory (omitting VM/ADDS service installation time). Perfect for practicing using tools like BloodHound :).

Active Directory,Sécurité Informatique,Active DirectoryPowerShellPowerShell,Active DirectorySécurité,Powershell,Sécurité,

#populate #vulnerable #Active #Directory #quickly

Leave a Comment

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