🖥 Building an Active Directory Lab 🔐

In this guide, we will build an Active Directory environment in a virtualized lab and see how features can be exploited to hack Windows users. Active Directory(AD) is Microsoft’s service to manage Windows domain networks. 95% of Fortune 100 companies implement AD into their networks. If you work in IT in any way, shape, or form… you need to know how AD works.

The way you can use the same set of credentials, to log into any Windows machine within your given institution, is done though Active Directory. AD can easily span whole corporations and campus’s, acting as a “phone book” for Windows desktops, printers, and other computers that need authentication services. For our purposes, our AD will span one server and X number of workstations.

For security researchers, it’s darn important to know how AD works and it’s weaknesses. This article builds off what was done in my last guide about building up a lab. I’ve had a lot of difficultly installing an AD within VirtualBox. Instead we’ll be using VMware Workstation 15 Player.

I’ve found both VirtualBox and VMware are both useful for different things(more like some stuff will break on one but not the other), and here is one such instance. If you’re brand new to all this, after these guides, you’ll know how to you use two very useful hypervisors! Installing VMware just consists of running the installer.

Once VMware is installed and both ISO files above are downloaded, open up VMware and click “Create a New Virtual Machine”:

Click the “Use ISO image:” button and then “Browse…” for the ISO file of our Windows Server 2019 :

Though it’s not exactly accurate, select “Windows Server 2016 Standard”:

Leave everything else to it’s default setting, just keep clicking “Next” until you can click “Finish”; BUT, before you do, make sure “Power on this virtual machine after creation” is unchecked. We have one more change to make…

Click “Edit virtual machine settings”:

This floppy drive is going to give us problems if we don’t take it out. Click on it, then click “Remove”:

Now you’re all set to start up the Server. Before you, do be ready to spam your keyboard:

When you see this, spam your keyboard to “press any key” to get it to boot:

Click “Next”, then “Install Now”, then make sure you pick the “Windows Server 2019 Standard Evaluation (Desktop Experience)”:

Accept the License, Click “Custom: Install Windows only (advanced)”, then click “Next”:

Now for this part you ought to take a break or work on something else, it’ll take a few minutes:

It should reboot on its own, then you’ll get to this screen:

We’re going to be setting quite a few passwords to set up this AD. Follow along with my credentials if you like. This is just a testing environment anyway:


To login, you’ll need to go to the VMware client and select this button to Ctrl-Alt-Delete:

Type in your password and you’ll find yourself in the Server Manager:

First thing we’ll do is give our Domain Controller a domain controller-y sounding name. Something like…

Domain Controller: FARQUAAD-DC

Go to the search bar, search “computer”, and click on “View your PC name”.

Then click on “Rename this PC”

Isn’t that so much better than “WIN-D77UPO40MTO”?

Then restart your machine. Next we’re going to install Domain Services. Click on “Mange”, then “Add Roles and Features”

Then click “Next” for everything, except for the part you need to select the “Active Directory Domain Services” and clicking “Install” like so:

Next click on the flag, then “Promote this server to a domain controller”:

Click “Add a new forest” then name your Domain something medieval sounding like…

Root domain name: Duloc.local

Click Select then enter your credentials Administrator:password!1

Next you need to set a Domain Controller Password…

DC Password: noonewillknow@2

Click “Next” 5 times, then click “Install”:

The machine should reboot on it’s own after that.

Our domain needs some users or else what’s the point? Create a “Create a New Virtual Machine” machine and name it as such, then keep all the default settings by clicking “Next” for everything else:

Click the “Installer disc image file (iso):” button and then “Browse…” for the ISO file of our Windows 10 Enterprise, click “Next” then select the “Windows 10 Enterprise” edition and leave the rest blank:

Click “Next” twice, leaving the defaults, then don’t forget to switch off “Power on this virtual machine after creation”:

Click “Edit virtual machine settings” and remove the floppy disk once again:

Start your VM!

“Next” -> “Install now” -> Accept license -> “Custom” -> “Next”, you know the drill:

Click through the setup process, selecting the defaults, until you get to this screen, here pick “Domain join instead”:

Name your user something cool like…

User 1 : Thelonious

By default the password policy isn’t that strong for users, allowing us to get real lazy with the passwords:

Thelonious : Password1

Put in some random junk for the 3 security questions… Then for this part I always select “No”. Activity history sounds like tracking software.

Sorry Cortana, you’re not welcome here:

Disable as much of this tracking crap as possible:

Once the machine is booted up, click on the files icon, click on “Network”, then right click the yellow bar on top, and “Turn on network discovery and file sharing”, then click “Yes, turn on network discover and file sharing for all public networks”. This will help demonstrate SMB attacks:

Now to rename your computer something related to your username.

I picked…Torturer. Sounds strange, yes, but not as strange as DESKTOP-QELSR11:

Then restart the machine. You can repeat this process to create as many workstations as you wish.

Now your lab is really growing!

Do you feel as cool as this guy yet?

Boot up your Windows Server 2019 and put in your password(supasecret!1). At the Dashboard click “Tools” then “Active Directory Users and Computers”:

Lets create a basic user. Click the arrow next to “Duloc.local”, click on “Users”, then right click in the white part, hover over “New”, then select “User”

Name your user like so:

Then enter in a password. Check off “User must change password at next logon” and check “Password never expires”. This is very bad policy if you were setting up a real Active Directory, however this makes things simpler for our testing purposes. Then click “Next” and “Finish”.

Now our credentials are pfiona:password123!

Now lets create a domain admin to help us out on our network. Right click the “Administrator” user then click “Copy”.

Enter a name just like before:

Enter a password, “Next”, then “Finish”:

Since this a domain admin I up’ed the complexity a bit, here are our credentials:


[All of these password are very bad, please use a better password policy when building a production Active Directory.]

Lets Create a few more users. Copy our Princess Fiona user and repeat the previous steps:

Do you know… the Muffin Man?



Next lets create a SQL database account just for testing purposes(we won’t actually be setting up a SQL database in this walk through). Copy the Sir Shrek account so all the permissions of an Administrator account are carried over to the SQL account. Service accounts ought not be domain administrators, this has the potential for exploitation…



Some administrators put passwords in account descriptions, thinking no one else can see them. To see how this can be a vulnerability, put the password in the description of the SQLDatabase account by right clicking it, and selecting “Properties”:

Then type in the password, then click “Apply”, then “OK”. Safe as can be right?

Many Active Directory’s utilize file shares. Lets set up a file share to see how that common feature can be a vulnerability. Close out of the “Users and Computers” window, then click on “File and Storage Services”:

Then click “Shares”, “Tasks”, then “New Share…”:

Click “Next”, twice, leaving the defaults until we get to this screen. Name your share something slightly ironic like canttouchthis because unlike MC Hammer you can touch and exploit this configuration… That was a bad joke…

Click “Next” 3 times, click “Create”, and that's it, you have a file share.

Next lets set up our machine to test out Kerberoasting, a popular attack to passively grab Active Directory credentials. Open Command Prompt by pressing your Windows Key, typing “cmd”, then pressing Enter:

Then enter this command:

setspn -a FARQUAAD-DC/SQLDatabase.Duloc.local:1337 Duloc\SQLDatabase

This command sets up a service principle name using your Domain Controllers name(FARQUAAD-DC), a random port(1337), the name of your SQLDatabase user and your Root Domain Name(Duloc.local). Then you should see a similar output to below:

Confirm everything was done correctly with this command:

setspn -T Duloc.local -Q */*

If you see “Existing SPN found!” at the bottom, you were successful:

Next lets disable Windows Defender so we can focus on the learning basics of attacking Active Directory, not Anti-virus evasion. Close out of command prompt and search for “Group Policy Management” in the task bar and open that up:

Click the following arrows, then right click your root domain name, click “Create a GPO in this Domain, and Link it here…”:

Then enter in our policy name:

Click on the following arrow again, right click “Disable Windows Defender”, then click “Edit…”:

Click the following arrows:

Hover your mouse over this part to adjust the window:

But that’s not it, scroll down until you can click on “Windows Defender Antivirus” and then double click “Turn off Windows Defender Antivirus

Then click “Enabled”, “Apply”, “OK”:

Lets start with Thelonious on one of our Windows 10 Enterprise systems:

Go to your C Drive and create a new folder:

This folder will be act as our share drive in our AD system, perform the following actions to set it up:

Now you need the IP Address of your domain controller to join this workstation to the domain. Go back to your Windows Server 2019 machine and open up the command prompt again. Type in ipconfig:

Now we know the IP of the Domain Controller is

Back on the Windows 10 Enterprise machine, rightclick on the networking icon and click “Open Network & Internet Settings”:

Click “Change adapter options”:

Right click on “Ethernet” and select “Properties”:

Double click “Internet Protocol Version 4 (TCP/IPv4):

Then set your “Preferred DNS server:” as the IP of the domain controller, then check off “Validate settings upon exit” so we know it works, then click “OK” on the last 2 windows:

If no problems are found, we’re good to go!

In the task bar search “domain” and click on “Access work or school”:

Click “Connect”:

Click “Join this device to local Active Directory domain”:

Type in your Root domain name and click “Next”:

Type in your Administrator(:supasecret!1) credentials, then click “OK”:

This part isn’t necessary, just click “Skip”, then let your machine restart now:

Try login in as one of the user’s we configured on our domain controller now like pfiona:password123! :

Repeat these steps in Connecting Users to Domain with any other Windows 10 Enterprise workstations you want to hook up to your Active Directory!

We’re almost ready to attack our Active Directory. However(assuming your only knowledge of installing Kali is on VirutalBox from my previous post), how the heck do you install a Kali VM on VMware?

Luckily there are VMware images to download right here.

Once that’s downloaded and extracted, go to your VMware client menu bar. Click on “File”, then click “Open”, and look for the VMware image you downloaded, should look a bit like this:

Once you double click that it should open up on your VMware client, boot it up and lets start hacking! Remember default credentials are kali:kali.

Finally we’re at the good part. We’re going to exploit our Active Directory by capturing NTLMv2 Hashes with Responder from Impacket. NTLMv2 hashes are basically the scrambled version of Windows passwords. We’ll get to unscrambling them soon enough…

On your Kali machine. Open a terminal by right clicking the desktop and selecting “Open Terminal Here” like so:

Then run sudo apt update and type in your password to update your packages. Then run sudo apt install python-pip -y to install the pip package manager.

We’ll use pip to install the network exploitation toolkit Impacket. Download it to your Kali system with git clone https://github.com/SecureAuthCorp/impacket then change into that directory cd impacket/

Then run these 3 following commands to install all of Impacket’s dependencies:

Begin running responder on your Kali machine with the following command sudo responder -I eth0 -rdwv

-I to listen on your eth0 network interface, -rto enable answers for netbois wredir, -d to enable answers for netbois domain, -w to start WPAD rouge proxy server, -v for verbose output. These are the most common settings.

Now responder is listening on the network, poisoning services like LLMNR and NBT-NS as you can see in the output. Listen long enough Sir Shrek will innocuously try to access one of the shared files on the network:

The sshrek user just got pwned because responder picked up his password hash in result of his action:

How do we turn this has into a password? This is where hash cracking comes in. The most popular tool to crack hashes of any kind is hashcat. You’ll find this preinstalled on your Kali machine:

First copy your hash into a file like so:

Then to put it into a file type echo 'on your keyboard then paste it in with Ctrl-Alt-V. Then close the quotes and direct the output to a file with ` > hashes.txt. Then confirm the hash is in the file with cat hashes.txt

To crack this hash, we’re going to use a word list to compare the hashes too. If we get a match we’ve found the password! A very popular wordlist is already pre installed on every Kali machine. Unzip it with this command: sudo gunzip /usr/share/wordlist/rock.txt.gz

Fire up hashcat with hashcat -m 5600 hashes.txt /usr/share/wordlists/rockyou.txt — force

-m 5600 is the number that designates NTMLv2 hashes and — force ignores any errors we get from running hashcat in a VM

Since we chose a very weak password for this user, password cracking took all but 12 seconds:

So we have credentials. How do we turn that into a shell?

psexec is a Microsoft developed lightweight remote access program. Every Kali Linux is preinstalled with it. We can use it to remotely access Sir Shrek’s computer with our new found credentials. You need to enter the Root domain name(Duloc.local), the username(sshrek), the password(‘!password!23’), then the IP address of Shrek’s machine( The password needs to be in quotes otherwise the exclamation marks will be interpreted by Bash as regular expressions and mess things up.

psexec.py [domainaddress]/[username]:[password]@[IP]

psexec.py Duloc.local/sshrek:’!password!23'@

That’s how you own Shrek’s computer. Since Shrek is an admin user we can see we also have an admin shell with the whoami command.

Using responder to capture hashes, cracking with hashcat, then using psexec to login to a remote shell is just one of hundreds of common ways to exploit Active Directory. Search engines are a hackers deadliest weapon, use it to find out more about Active Directory attacks.

Credit where credit is due: Most of what I’ve learned about AD is from The Cyber Mentor’s videos. He makes tons of offensive security content and runs his own pen-testing company. Awesome dude, highly recommend you check him out.

Next post will probably be more attacks on Active Directory. While building this Active Directory, we used many other features that could be used by attackers as vulnerabilities(like with the share folder or user descriptions). I encourage you to figure out how those features can be exploited before my next post!

If you have any criticisms or questions I’d be happy to write to you over my email: robertscocca@protonmail.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store