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

Vishing: How to Protect Your Business from Phone-Based Social Engineering Attacks

By Red Siege | September 22, 2023

from Jason Downey, Security Consultant In our digital world today, where cyber stuff keeps changing all the time, there’s this sneaky attack method that’s been popping up more and more […]

Learn More
Vishing: How to Protect Your Business from Phone-Based Social Engineering Attacks

House cat to Hashcat

By Red Siege | August 22, 2023

by Jason Downey, Security Consultant   The Basics  Password cracking is a key tool in every penetration tester’s toolbox and is something blue teamers should do on a regular basis […]

Learn More
House cat to Hashcat

Obfuscating Shellcode Using Jargon

By Red Siege | July 31, 2023

by Mike Saunders, Principal Security Consultant In a recent blog , we discussed how encrypting shellcode leads to increased entropy, which may result in your shellcode loader being blocked and/or […]

Learn More
Obfuscating Shellcode Using Jargon

Find Out What’s Next

Stay in the loop with our upcoming events.