Creating a Simple Windows Domain for Offensive Testing: Part 3
By Red Siege | June 15, 2022

Welcome back to my series on setting up a Windows domain for offensive testing. In the first two installments (Part 1, Part 2), I stood up a DC for the rslabs.net
domain, and created users, groups and organizational units (OU) to organize it. Now I’m going to stand up some machines other than the DC inside the domain.
Creating one or more workstation VMs for the domain will be very similar to the process of creating server VMs. I’m only going to hit key parts of the process here. First, I make sure to set that I’ll install the operating system later, so as not to engage the Quick Install
process.
The only real differences with standing up a server are that when given the option to set my guest operating system, I choose Windows 10 and later x64
, and I make sure to mount the Windows 10 Enterprise evaluation ISO, rather than the Windows Server 2019 ISO.
Otherwise, I drop the vm to 1 CPU, 40GB of storage, and set the network adapter to the one for the domain network, just as I did with the server. I also drop the RAM to 2 GB.
Once the VM boots, I accept the license terms, pick a custom Windows installation, and direct it to the sole hard disk for the VM, just as I did for the server. After a few minutes of installation and a restart or two, the VM comes up for its initial configuration. Most of this is a matter of personal preference (region, keyboard layout, etc), except for when I hit the Sign in with Microsoft
page. Here, rather than entering an account name, I hit Domain join instead
.
Perversely, this does not start the process of joining a machine to a domain. What it will do is create a local account with admin privileges I can then use to domain join the computer. So, I pick an account name (rslabs-admin
), set a password and pick security questions and answers.
After this comes setting the device’s privacy settings, all of which I set to No
. This goes along with disabling Cortana, on the following screen.
After a few more minutes of under-the-hood work the workstation presents its desktop. This Before attempting to join the computer to the domain, I need to change the computer’s DNS server to point at the DC. I type ethernet
into the search bar, then click on Ethernet Settings
. I click on Change Adapter Options
in the settings window, then right-click on the ethernet adapter and choose Properties
.
When the Properties
window opens, I select Internet Protocol Version 4 (TCP/IPv4) Properties
, and the hit the Properties
button.
Here I configure leave the setting to Obtain an IP Address Automatically
checked, because I want the workstation to get its address from DHCP, but I set the DNS server to the address of the DC (192.168.1.2), which is handling DNS for the domain. I hit OK
, then close my way out of the network configuration screens.
If I wanted to add a bunch of workstations to the domain in rapid succession, this would be a good time to shut the machine down and snapshot it so I can make clones.
To domain join the workstation, I go back to the desktop, type name
into the search bar, then click on Change workgroup name
in the results.
In the System Properties
window, I hit the Change
button, then set the name I want the computer to have in the domain, and set the domain name and hit OK
.
I’m then prompted for credentials. Any domain user should work for this.
After a minute or two of thinking, I’m welcomed to the domain.
I’m also asked whether I want this machine to be discoverable on this network, and I select Yes
.
After rebooting, as prompted, I receive a RSLABS domain login screen.
I’m not quite done getting things set up. I did create a Workstations
OU earlier, and I’d like to put this host into it so the proper GPOs will be applied. Going back to my DC, I open the AD Users and Computers manager from the Tools
menu in the upper right hand corner of the Server Manager. Clicking on the Computers
OU, I see the new computer rsl-wks-1
there. I click and drag it into the Workstations
OU, so that it will receive GPOs I’ve applied to that OU.
I can repeat this process
I’m leaving this as an exercise for the reader. The process for standing up the VM is exactly the same as that for the Domain Controller, other than, instead of promoting the computer to a DC, it gets joined to the domain. I can even bypass most of the VM creation process by cloning the VM, since I made a snapshot right after standing it up. The domain-joining process is exactly the same as that for workstations, unless you want to give the computer a static IP rather than using DHCP when configuring the networking.
That’s it for part three. I now have a domain with a DC, one or more workstations, and one or more servers. The fourth and final part of the series will focus on creating Group Policy Objects (GPOs) to enable services and manage access to machines based on us.
Justin Palk has more than 16 years of experience in IT and information security, and has worked in the academic, federal civilian government and health research sectors. He has held a variety of roles including system administrator, developer, auditor, assessment team lead and web application penetration tester. He regularly competes in CTFs in the U.S. and Europe.
Certifications:
GCIH, GWAPT, GPEN, GMOB, GDSA
Related Stories
View MoreBy Red Siege | June 5, 2023
Red Siege strengthens its offensive security consulting offerings with the acquisition of FortyNorth Security. The transaction expands Red Siege’s services to its clients with more leading-edge open source and private […]
Learn MoreBy Red Siege | April 11, 2023
from Mike Saunders, Principal Consultant tl/dr You’re encrypting your shellcode so you don’t get caught, and that might get you caught. Introduction I’ve encountered CrowdStrike Falcon Protect on engagements many […]
Learn MoreBy Red Siege | December 5, 2022
by Senior Security Consultant Douglas Berdeaux The Almighty Strategy Guide to the Rescue! With the end of the year approaching, I took some time to reflect on what the […]
Learn More