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 window opens, I select
Internet Protocol Version 4 (TCP/IPv4) Properties, and the hit the
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.
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
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
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.
GCIH, GWAPT, GPEN, GMOB, GDSA
Related StoriesView More
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
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
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