Creating a Simple Windows Domain for Offensive Testing : Part 1

By Red Siege | June 1, 2022

By: Justin Palk, Security Consultant

While doing some tool development recently I realized that for the first time I was writing a tool specifically targeting an Active Directory domain and domain-joined machines, and I had no way to test it. I needed my own AD Domain. While getting the initial domain up and running only took a few hours, it led to a week of on-again, off-again interruptions in my other work as I discovered something wasn’t working, scurried off to search for, implement and test solutions, and then tried to remember what I’d been doing before fixing the domain problem. Having gone through that, I thought I’d share what I’d learned and put together a guide to standing up a simple domain with a couple of common key features enabled.

Warning

I am neither a Windows nor an AD administrator. This domain will be based almost entirely on Microsoft’s defaults, with no additional hardening. This is not intended as a guide for setting up a production domain, and will almost certainly include security weaknesses. This domain should only be built in an isolated enclave and not exposed to the Internet.

Overview

This series assumes you have a lab environment with virtualization software installed and running, and that you have the ability to administer your router to set static IPs and hostnames. If you don’t, I recommend you check out the 2nd edition of Tony Robinson’s excellent Building Virtual Machines . Tony goes in-depth on setting up a virtualization environment, including walkthroughs for multiple hypervisors, and detailed instructions on how to set up virtualized lab networks.

For purposes of this lab, I’m going to be setting up a simple lab of five machines:

  • A pFsense box as a firewall, gateway, router, DNS and DHCP server (assumed to already be in place, but needing some configuration)
    192.168.1.1
    10 GB Storage, 1 GB RAM, 2 NICS
  • A Windows Server 2019 server for a DC
    192.168.1.2
    40 GB Storage, 4 GB RAM
  • A Windows Server 2019 as a file server
    192.168.1.3
    40 GB Storage, 4 GB RAM
  • Two Windows 10 Enterprise workstations
    IP addresses assigned by DHCP
    40 GB Storage, 4 GB RAM (each)

Once the domain is up and running, I’ll add some users and groups, and build out a handful of Group Policy Objects (GPOs) to grant some users administrator privileges and RDP access, and allow WMI access on all the hosts.

Getting Software

The easiest place to get legitimate copies of Windows for testing purposes is the Microsoft Evaluation Center . The evaluation center has time-limited full copies of Windows Server 2019 (180 Days) and Windows 10 Enterprise (90 days), among other products. The available formats include ISOs and pre-built virtual machines for popular virtualization platforms including VMWare and Hyper-V. It is also possible to extend the lifetime of these evaluation VMs.

Network Setup

I’m going to be setting up this test domain in an isolated network, separated from everything else in my virtualization environment and the rest of my LAN. A dual-homed pfSense vm will act as a firewall, router, gateway, and DHCP server for everything in the domain. In my example, the WAN interface is at 192.168.109.193, and the LAN interface is 192.168.1.1. If you are using something other than a pfSense firewall to manage your network, you’ll need to adjust these instructions accordingly.

The setup I do in this section is primarily so that any non-domain-joined machines I add to the network, such as a Linux jumpbox, get registered with DNS. If this isn’t something that concerns you, you can skip the rest of this section.

First, I need to set a DNS domain name for my network on the `System/General Setup` page. In this case, I chose `rsinfra.lan` and entered this in the `Domain` field. The domain I set here will *not* be the domain name I give my Windows domain.

Next, I need to ensure the DNS resolver is properly configured. Under `Services/DNS Resolver/General Settings`, I make sure the DNS resolver is enabled, as shown below.

Then I scroll down to near the bottom and make sure that both `DHCP Registration` and `Static DHCP` are checked. This ensures that machines that register via DHCP are registered with DNS and findable by hostname.

Depending on what you’re going want to do with your domain, this would also be an appropriate time to modify your DHCP configuration to modify the ranges available for DHCP leases, but the default settings should be fine for most uses.

Creating the DC host

With the basic network setup completed, my next task is to create a domain controller. The specifics of creating the virtual machine will vary depending on the hypervisor. In my case, I’m using VMWare Workstation 16. I start with a typical configuration, but when prompted for `Guest Operating System Installation`, I choose `I will install the operating system later`. Adding an ISO here will cause the rest of the installation to use Easy Install mode, which I have never gotten to work properly. I suspect this has something to do with using evaluation copies of Windows Server.

When prompted to `Select a Guest Operating System`, I choose `Microsoft Windows` and `Windows Server 2019`.

I then name my VM `lab-dc` and choose where on disk I want to save its files. By default, VMWare will give the VM 60 GB of storage. This is an upper bound on the size of the disk, and the actual virtual disk file will only take about 12 GB once I’m done, so the default is fine.

When I reach the `Ready to Create Virtual Machine` dialog, I hit the `Customize Hardware` button so I can adjust the RAM, the Network Adapter and the number of CPU cores; and select the OS installation ISO.

In the hardware manager, I first go to `Memory` and use either the slider or the text box to increase the RAM for 4 GB (4096 MB).

I then go to `Processors`, and make sure the `Number of Processors` and `Number of cores per processor` are both `1`.

Next, I go to `Network Adapter` and make sure that the Network Connection is set to the same virtual switch as the LAN side of the pfSense switch. In this case, that’s VMnet4. This ensures that the VM will be created in the isolated network.

Finally, I go to `New CD/DVD (SATA)`, select `Use ISO image file` and browse to my Windows Server installation ISO.

Having made those changes, I close the hardware manager, check that my configuration is correct, and then hit `Finish`

At this point, I power on the VM, hit a key to boot from DVD, and after a moment the Windows Server installation prompt comes up. After hitting the `Install Now` button and selecting my language preferences, I select `Windows Server 2019 Standard Evaluation (Desktop Experience)` as my Windows version to install.

I then accept the license terms, and chose `Custom: Install Windows only (advanced)` as my installation type.

When prompted for where to install Windows, I have only one option, so I just hit `Next`.

At thist point, installation begins in earnest and I go get a cup of coffee.

After a restart or two, the machine comes back and presents me with a prompt for setting the Administrator password, after which the login screen comes up.

Upon logging in for the first time, I’m asked whether this host should be discoverable. Since it’s only ever going to exist in an isolated network, I hit `yes` here.

I now have a fully functional Windows Server 2019 host, suitable for use as a domain controller or other Windows server role. I shutdown the server and take a snapshot at this point to make it easier to recover in case I screw something up after this. This will also allow me to clone the VM if I want to add a non-DC server to my domain.

Configuring Networking for the DC

Before promoting the server to DC, I want to give it a more meaningful name, and I have to give it a static IP. First, to change the name, I open the Windows control panel, search for `Name`, then select `Rename this computer`

The `System Properties` dialog opens, and I hit the `Change` button to rename the computer.

When the `Computer Name/Domain Changes` dialog opens, I change the name of the computer to `rslabs-dc`. I do **not** change the workgroup or domain at this point, because there isn’t a domain yet.

This change won’t take effect until after a reboot. When prompted to restart the computer, I choose `Restart Later`, because I need to configure the computer to use a static IP first.
Going back to the control panel, I search for `network adapter`, then select `View network connections`.

In the window that opens up, I select the only network adapter (Ethernet0), right-click, and choose `Properties`.

In the `Properties` dialog that opens, I select Internet Protocol Version 4 (TCP/IPv4), and again hit `Properties`.

Now I can set the IP address, subnet mask, default gateway and DNS server for my DC. The specifics will depend on how your DHCP server is configured. By default, pfSense reserves everything below 192.186.1.10 for static IPs, and has a default netmask of 255.255.255.0. I set DC’s IP to 192.168.1.2, and set the default gateway and preferred DNS server to the pfSense box (192.168.1.1). This step is important, because a server gets promoted to a DC and it also becomes a DNS server, it will use the DNS servers defined here as its upstream DNS servers to which it will forward requests it can’t answer. Hit `OK`, close out of the networking properties, and restart the computer.

Promoting the Server to Domain Controller

Going to the Server Manager, I select `Add Roles and Features`, hit `Next` on `Before You Begin`, then select `Role-based or feature-based installation` when prompted to select installation type.


I then hit `Next` twice, at which point I’m presented with a list of selectable server roles. I check `Active Directory Domain Services` then agree to add the needed features and management tools.

I then click `Next` three times, until I’m prompted to confirm my installation selections, and I hit `Install`, then `Close`.


In the upper-right hand corner of the Server Manager there’s a notification for a post-deployment task of promoting the server to a domain controller.


Clicking the link brings up the AD Domain Services Configuration Wizard. On the first page, I specify that I’m going to be adding a new forest, `rslabs.lan`, then hit `Next`.


On the Domain Controller Options page, I leave the Forest and Domain functional level and specify the domain capabilities, at the defaults, and set the Directory Services Restore Mode password. I pick a strong DSRM password, and leave the DC capabilities at the default then hit `Next` twice.

Under `Additional Options` I confirm that my netbios name (`RSLABS`) is correct and hit `Next` twice again.

I review my options, hit `Next`, make sure the server passes the prerequisites check, then hit `Install`.

Promotion takes a few minutes, followed by a reboot. After the server reboots, I have a functional DC.

Conclusion

This is it for part 1. I’ve set up my network, and created a DC for the `rslabs.lan` domain. In part 2, I’ll create users and groups, and organizational units so I can separate hosts in the domain by function.

 

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.

Certifications:
GCIH, GWAPT, GPEN, GMOB, GDSA

Connect on Twitter & LinkedIn

Introduction to Sliver

By Red Siege | November 7, 2022

By: Justin Palk, Security Consultant Around the time Tim decided he was going to give a Siegecast on selecting a C2, I finished building out a test Windows AD domain […]

Learn More
Introduction to Sliver

The power of adaptability through experience.

By Red Siege | November 3, 2022

By: Mike Saunders, Principal Security Consultant tldr: With experience comes the ability to adapt to challenges, and even experienced testers need to phone a friend now and then. In the […]

Learn More
The power of adaptability through experience.

Moving beyond T4 – Deconstructing Nmap Tuning

By Red Siege | July 6, 2022

by Alex Norman, Senior Security Consultant Nmap -T4 -iL targets.txt This is a very common scan string that many people use to get initial recon done on assessments and, to […]

Learn More
Moving beyond T4 – Deconstructing Nmap Tuning

Find Out What’s Next

Stay in the loop with our upcoming events.