Creating a Simple Windows Domain for Offensive Testing: Part 3

By Red Siege | June 15, 2022

by Security Consultant Justin Palk

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 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 and Joining Workstations

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 (, 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

Creating and Joining Servers

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.

About Justin Palk, Security Consultant:

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.


Connect on Twitter & LinkedIn

Adventures in Shellcode Obfuscation! Part 4: RC4 with a Twist

By Red Siege | July 8, 2024

by Mike Saunders, Principal Security Consultant This blog is the fourth in a series of blogs on obfuscation techniques for hiding shellcode. You can find the rest of the series […]

Learn More
Adventures in Shellcode Obfuscation! Part 4: RC4 with a Twist

Adventures in Shellcode Obfuscation! Part 3: Encryption

By Red Siege | July 1, 2024

By Mike Saunders, Principal Security Consultant   This blog is the third in a series of blogs on obfuscation techniques for hiding shellcode. You can find the rest of the […]

Learn More
Adventures in Shellcode Obfuscation! Part 3: Encryption

Phone Switch Labs CTF – Walk-Through

By Red Siege | June 26, 2024

by Douglas Berdeaux, Senior Security Consultant CTF Getting Started Phone phreaking is the practice of exploring and hacking telephones, telephone switches, telephone test equipment, and physically exploring the telephone […]

Learn More
Phone Switch Labs CTF – Walk-Through

Find Out What’s Next

Stay in the loop with our upcoming events.