Lab Building Guide: Virtual Active Directory

15 min readMar 28, 2020

Introduction

As an information security professional it is extremely important to not only be able to find and exploit flaws but also understand the underlying issue and be able to articulate the reason/fixes to clients. With a home lab you can begin to gain “sysadmin” type experience if you do not already have it. A home lab provides the following benefits:

Learn how to configure things improperly and how to fix them.
Have a test bed for practicing tools/tactics/techniques and a safe place to experiment with new and potentially volatile exploits.
Experiment with major Active Directory misconfigurations (these can be configured by hand or with a tool such as BadBlood).
Fully test out and understand all of the capabilities of both built-in AD tools and automated enumeration tools such as PowerView and Bloodhound.

The objective of this post to help readers build a fully functional mini AD lab that can be spun up to practice a wide variety of attacks. We will walk through creating the following lab structure:

Two Forests with a bidirectional forest trust and an intra-forest parent-child domain trust.

1 domain controller (root DC — Forest A)
1 domain controller (child DC — Forest A)
1 domain controller (Forest B)
1 member server (web, file, SQL, application) (parent — Forest A)
1 workstation (child — Forest A)
1 workstation (Forest B)

The domain name scheme will be as follows:

octagon.local (root domain — Forest A)
dev.octagon.local (child domain — Forest A)
elysium.local (root domain — Forest B)

Initial Setup

To get started you will need to set up the following:

(4) Server 2016/2019 server VMs
(2) Windows 10 workstation VMs

Begin by building each host fully and installing VMWare Tools. For now do not worry about applying any patches/updates. You can choose your own host names but for the purposes of this exercise we will be using:

DC01(192.168.88.5)
DC02 (192.168.88.6)
DC03 (192.168.88.7)
MS01 (192.168.88.150)
WS01 (192.168.88.100)
WS02 (192.168.88.101)

Configure each with the same local administrator password for now — don’t forget it!

In order to create your lab you will need desktop virtualization software such as VMWare Workstation/Fusion, VirtualBox or a separate hypervisor (server) running ESXi or Proxmox. This guide will cover the basics of initial setup with VMWare Workstation and VirtualBox. In-depth usage of each is out of the scope of this article. The necessary software can be downloaded from the following URLs:

If possible, we recommend following this guide using VirtualBox or VMWare Workstation (provided you have purchased a valid license for the latter). Aside from other advanced features, both Workstation and VirtualBox support tabs when running multiple VMs. VMware player does not support tabs and you will need a new instance of Player running for each VM.

Creating a Virtual Machine with VMWare Workstation

In VMware Workstation start by clicking on File → New Virtual Machine.

Choose Installer disc image file (iso) and select the appropriate ISO file on your local system.

Enter a password for the administrator user. If you leave the license key blank, you will have a 90 trial period.

Ignore the product key warning if it pops up.

Choose a name for the VM based on the naming convention in prior slides. For better VM management and to avoid any conflicts create each VM in its own folder.

Select Store virtual disk as single file and give it a 40GB disk.

Click Finish on the next screen. The default 2 GB ram and 2 cores should be plenty for lab purposes but can be adjusted later if issues arise.

After clicking finish, the VM will boot. Hit enter to boot from the ISO image. Choose Windows Server 2016 Standard (Desktop Experience). If you are already comfortable with creating VMs/managing AD then you can choose Server Core Windows Server 2016 Standard. Server core has a smaller footprint on disk and utilizes less resources but does not have a GUI so all configuration must be done via PowerShell.

The installation process will start and takes a while so we recommend creating each VM in parallel to save time. Alternatively, you can create 1 VM image and clone and then sysprep it but we will not cover that in this post.

Creating a Virtual Machine with VirtualBox

The process for building a VM in VirtualBox is similar. It can be downloaded from here: https://www.virtualbox.org. VirtualBox is free to use and allows for multiple VMs to be run simultaneously. It offers many enterprise-grade features and is cross-platform (Windows, OSX, and Linux).

Start by selecting the option to create a new VM.

The defaults will work for the purposes of this lab. This can be adjusted based on your available hardware and resources. The screenshot below shows the default options for creating the virtual disk.

For the purpose of this lab, be sure to leave the default Dynamically allocated. This will only use hard drive space as it fills up and save space on your host.

As with VMware Workstation after clicking finish the VM will boot, hit enter to boot from the ISO image.

Choose Windows Server 2016 Standard (Desktop Experience).

Follow the same process to create a base image for each server/workstation VM. While this entire process can be automated with Vagrant/Packer, Ansible, PowerCLI, etc., we feel it is important to become comfortable manually performing each task, starting from the basics, before moving towards automation.

Note: Make sure to install VMWare Tools on each VM.

Building the Lab — Creating a Domain Controller

Once the VMs are built, log in to the VM that will be your first Domain Controller. Search for ‘Computer’ in the start menu or go to Control Panel → System and Security → Security and change the computer name to a host name such as DC01 and then restart the server when prompted.

Change network settings to set a static IP address and set the DNS server to localhost (127.0.0.1). You can also set DNS back to 8.8.8.8 if you need to do updates or download something but its preferable to keep your vulnerable lab local and not internet facing the majority of the time.

Your first Domain Controller is necessary for getting everything up and running with Active Directory. Log in to Server Manager and click on Add roles and features.

Add the Active Directory Domain Services role, which is necessary before promoting the server to a domain controller. Leave all other roles unchecked and click Next.

Check the box next to Restart the destination server automatically if required and click Yes to confirm automatic restarts.

Once the role is installed click on Promote this server to a domain controller.

On the next screen, choose Add a new forest and select a root domain name. Choose something ending in .local or .ad.

Leave all of the defaults on the next screen and enter a DSRM password.

Click Next and either leave the suggested NETBIOS name or modify it if desired.

Click Next and leave all defaults, click Next again to go through prerequisite checks.

Note: If you have not set a password for the built-in administrator account yet, installation will fail. Set a password for the administrator account and click on Rerun prerequisites check.

Click on Install to complete the process.

Once rebooted, confirm the new DC by opening a PowerShell window and typing Get-ADDomain.

Note: We can do the entire process with PowerShell as well.

Rename the host

Rename-computer -newname DC01 (Do not reboot yet)

Set the IP Address

Get-NetAdapter (likely will show Ethernet0 but confirm)1: $ipaddress = "192.168.x.x"2: $dnsaddress = "127.0.0.1"3: New-NetIPAddress -InterfaceAlias Ethernet0 -IPAddress $ipaddress -AddressFamily IPv4 -PrefixLength 24

Update the DNS Server

Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses $dnsaddressRestart-Computer

Install and Configure the DC

Install-WindowsFeature AD-Domain-Services –IncludeManagementToolsInstall-ADDSForest -DomainName octagon.local

Follow all of the prompts, set the DSRM password and allow the server to reboot. Once rebooted, confirm the new DC.

Building the Lab — Joining a Host to the Domain

Go into Network Connections and then adapter settings to change the DNS server to point to the domain controller and set a static IP within whatever range your DC is in. Here the DC IP address would be 192.168.88.5.

Search for Computer in the start menu, right click and select ‘properties’. Go down to the Computer name, domain, and workgroup settings, and click on Change settings.

Click on Change next to To rename this computer or change its domain or workgroup, Click Change.

Change the domain name to match the one you set up on the DC and you will be prompted for credentials to join the computer to the domain.

Building the Lab — Setting up the Child Domain

For this lab we will set up a child domain to set up an intra-forest trust as well as a second forest in order to establish an external trust.

On the second Domain Controller go through the same process to create a DC and choose either Add a new domain to an existing forest and select Child Domain from the drop down to create a child domain within the same forest.

Make sure the DNS server on DC02 is the IP address of the parent Domain Controller. Disable Windows firewall on both machines.

Type in the the parent domain and click Select. When the popup appears type in the Administrator password for DC02 and select the parent domain from the list.

Choose a name for the child domain. This should be one word such as dev as it will be prepended to the root domain name in the form of a subdomain (i.e. *.octagon.local).

Click on Select and put the Domain Admin credentials for the first domain into the popup. You will then be prompted to select that domain within the forest. Follow all of the prompts and leave the defaults.

Enter the child domain name, one word such as dev. Continue through the remaining steps to finishing creating the new DC.

Confirm that the child domain was created.

Confirm the trust was set up from DC01.

Building the Lab — Setting up a Forest Trust

The first step is setting up a new Conditional Forwarder under DNS Manager on both DC01 and DC03 so the forests can communicate properly via DNS.

The first step is setting up a new Conditional Forwarder under DNS Manager on both DC01 and DC03 so the forests can communicate properly via DNS. Right click on Conditional Forwarders and select New Conditional Forwarder.

On DC01 enter the domain name that you set on DC03 as well as the IP address of that Domain Controller.

Click OK and check that the Conditional Forwarder appears in the list.

Test that DNS is resolving properly.

Do the same on DC03.

Next, open up Active Directory Domains and Trusts on DC01, right-click on the forest root and select Properties. You’ll see the Child domain created prior.

Click on New Trust. Click Next and type in the domain name for DC03. Click Next and select Forest trust.

Select Two-way to create a bidirectional trust, meaning that users in Forest A can authenticate to Forest B and vice-versa.

To save from having to repeat this process on DC03 select Both this domain and the specified domain.

Type in the credentials for the Domain Admin in the other forest (DC03).

To simplify things select Forest-wide authentication on the following two screens.

Confirm the trust settings and click Next.

Then click Next again.

Click Yes, confirm the outgoing trust and Yes, confirm the incoming trust.

If everything went to plan you will get a confirmation message that the trust relationship was successfully created.

Click Finish and the new Forest trust will appear.

Validate the trust relationship on both sides by running this command on both DC01 and DC03.

Note: Take snapshots of all VMs in a powered off state before continuing. This will preserve the trusts in case you have to revert all of the images.

Building the Lab — Adding in Misconfigurations

Now it is time to make a mess of these domains. You can add user/computer objects manually or use BadBlood in each domain to add OUs, users, groups, computer objects and ACLs.

Download BadBlood to the machine.

Note: If you receive the error message “Could not Create SSL/TLS secure channel because PowerShell defaults to TLS1.0 use enter the following command and re-try the wget request:

[Net.ServicePointManager]::SecurityProtocol =[Net.SecurityProtocolType]::Tls12

Open up the script to modify the number of users to speed things up. Change 1000…5000 to 100..500 or something smaller than the default.

Run the script by typing .\Invoke-BadBlood.ps1

Check the results.

Many flaws and misconfigurations can be added to the lab to practice common and more advanced Attack Directory enumeration and attacks.

Utilize BadBlood to add OUs, users and computers and set up many misconfigured ACLs and groups. This can also be done manually.
Give a user DCSync privileges.
Set up SPNs for Kerberoasting (set this up across the forest trust too!).
Configure a user with a password in the description field.
Add ANONYMOUS LOGON to the Pre-Windows 2000 Compatible Access group to be able to leverage SMB NULL sessions to practice “internal” password spraying.
Configure a user with Kerberos pre-authentication not required.
Set up unconstrained/constrained delegation.

Utilize scheduled tasks to simulate user activity:

Browsing a file share for using Responder/Inveigh.
Simulated Phishing.
Simulate a user clicking on a malicious executable.

Note: An unpatched Server 2016 is vulnerable to EternalBlue by default.

Below are a few examples of misconfigurations that you can add to your lab.

Building the Lab — Example Misconfigurations

Password in Description Field

Kerberos pre-authentication not required (ASREPRoast). There are a few ways to set this up. The easiest way is opening Active Directory Users and Computers, right click on a user and choose Properties, and then browse to the Account tab.

You can confirm the setting with PowerView.

The attack can be tested out locally with Rubeus or remotely with the Impacket toolkit GetNPUsers.py.

Set up SPNs for Kerberoasting

Enumerate the newly created SPN with PowerView.

Test out the attack locally with Rubeus.

SMB NULL Session

Add ANONYMOUS LOGON to the Pre-Windows 2000 Compatible Access built-in group. This will allow for retrieval of the domain password policy and all users in order to mount a password spraying attack.

Add some users with common/weak passwords. This can be done a number of ways (cmd, PowerShell, etc.).

Confirm user list and password policy with enum4linux.

enum4linux -U -P 192.168.88.5

Make a user list from the output and attempt password spraying for a common password that you set for multiple users on DC01. Password spraying can be performed a variety of ways. One way is using rpcclient from Linux. A nice Bash script for performing password spraying with rpcclient can be found here.

Experiment with adding in more flaws/attacks as you see fit!

We will demonstrate adding in additional misconfigurations, simulated user activity, as well as building this lab with PowerShell and Vagrant/Packer automation in later posts.

Interested in hearing more about our services?

Lab Building Guide: Virtual Active Directory

Written by Vartai Security