Create a Personal Forensics Lab Part 1: The Primary Domain Controller
NB: This post was originally written in 2019. Expect that some content may be dated at this point.
One of the major things I recommend to anyone working in DFIR – as well as network or systems administration – is to build a lab in which to test tools, techniques, theories, or anything else you might encounter in day‑to‑day work or personal research. This post is part one of a guide on building a very simple lab in a cloud environment. Readers earlier in their career will probably see more benefit from this series than those near the end, but the principles apply broadly to the industry.
One thing that’s easy to overlook when building labs (especially cloud-based) is that real-world investigations don’t happen in clean environments. If you also work cases involving physical systems, removable media, or on-site response, it’s worth remembering that PPE and basic evidence-handling considerations still matter. Gloves, anti-static precautions, and proper evidence and Faraday bags are highly context-dependent, but practising good habits in a lab helps ensure they’re second nature when it counts.
Why the Cloud?
There are several reasons the cloud is a great place for this type of lab:
- Server instances can be spun up and down as required, with as many or as few resources (e.g. CPU, RAM, etc.) as needed, very quickly
- You can take snapshots of each endpoint at any point in time, meaning activity can be rolled back easily
- Configuring a lab this way is relatively inexpensive compared to buying dedicated hardware like an Intel NUC (which is also a perfectly valid alternative)
- No dedicated hardware is required, and networking can be reconfigured easily
If you haven’t used a VPS provider such as Vultr (or AWS, Azure, DigitalOcean, etc.) before, it’s worth reading this earlier post first to become familiar with the basic process of creating a VM.
Network Diagram
Here’s what the lab is expected to look like once complete:
The virtual switch is handled by the provider and allows private IP addressing on an internal NIC for each VM. Each system will therefore typically have two interfaces: one public and one private. All public‑facing NICs except the one belonging to the domain controller (DC) will be disabled.
Ordinarily, dual‑homing a domain controller and making it the default gateway isn’t recommended. In this case, however, it’s a pragmatic way to provide a single point of access for a small lab. A separate routing VM would be cleaner, but also adds complexity that doesn’t buy us much for this use‑case.
We’ll start by building the primary DC: a Windows Server 2016 VM. Evaluation ISOs can be downloaded from the Microsoft Evaluation Center. One side‑effect of building labs this way is that they need to be rebuilt every six months when the evaluation period expires.
NB: From painful experience, anything less than 2GB of RAM for Server 2016 is a bad idea. It may technically work, but it will be extremely slow. Use at least 4GB (or whatever the minimum requirement is for the OS you choose).
Initial Server Configuration
At this point, we’ll assume the OS is installed and you’re at the Windows Server desktop, ready to configure things in Server Manager.
Open Server Manager, select Local Server, and click the current computer name:
Click Change in the System Properties window:
Enter a computer name of your choosing. I went with Hera, following a loose Greek mythology naming scheme:
Click OK, OK, and Close, then choose whether to restart now or later. This is also a good time to run Windows Updates and set the correct timezone.
Installing Required Roles
From Server Manager, click Manage → Add Roles and Features:
Tick Skip this page by default. Choose Role‑based or feature‑based installation, then click Next:
Accept the default Server Selection, click Next again, then select Active Directory Domain Services:
Accept the required features when prompted:
In this lab, the DC will also handle DNS and DHCP, so select those roles as well:
Proceed through the wizard, accepting defaults, then click Install:
Once installation completes,** reboot**.
Domain Controller Promotion
After rebooting, a notification will appear in Server Manager prompting for Post‑Deployment Configuration:
Click the notification and promote the server to a domain controller. Create a new forest and supply a domain name of your choosing. Set a Directory Services Restore Mode password and accept the remaining defaults, then click Install:
Ignore warnings about DNS or DHCP at this stage; they’ll be addressed shortly. Complete the wizard and reboot again.
Once rebooted, log in using DOMAIN\Administrator credentials.
DHCP Configuration
With AD in place, configure DHCP so other lab machines can obtain addresses automatically.
Open Server Manager → DHCP:
Complete the post‑install configuration:
Open DHCP Manager and create a new IPv4 scope. I used a small private range, as the lab only requires a handful of systems:
Set the router (default gateway) to the private IP of the DC and configure DNS to point to the DC itself:
Accept defaults on the remaining pages, select Yes, I want to activate this scope now and click Next, then click Finish. Once the scope is activated, clients joining the network will receive IP addresses automatically.
Network Adapter Configuration
Next, configure a static private IP on the DC’s internal network adapter:
Assign an address consistent with your DHCP scope, following any guidance provided by your cloud provider. The default gateway should be the public‑facing NIC:
Click OK, then Close. Done.
DNS Verification
It’s best to double-check that the primary DNS zone has been created before moving on. In Server Manager, select DNS on the left, right-click the server and click DNS Manager:
Expand the server name in DNS Manager and open the forward lookup zone. As long as the primary domain shows up in here, we’re good to go:
If not, right-click Forward Lookup Zones on the left, and click New zone…:
In the wizard, accept defaults until asked for a zone name. Enter a name which matches your domain (in my case, the domain name was cherrypie.corp, so that’s what should be entered as the zone name). Accept defaults till the end, click Finish and the new primary zone should be created.
NAT Configuration
With the DC effectively acting as a router to provide Internet to the private lab network, it needs to have the Remote Access role installed and correctly configured, otherwise there will be weird routing issues internally which present as VMs being able to resolve Internet domain names via ping, but unable to receive ICMP responses.
In Server Manager, click Manage, then Add Roles and Features:
Select Role-based or feature-based installation, then click Next:
Click Next. Select Remote Access on the role selection page:
Click Next. Leave Features as default, click Next, then Next again. On the Role Services page, select DirectAccess and VPN (RAS) and Routing:
Accept the feature prerequisites as necessary, click Next, Next, then Install.
Reboot.
In Server Manager, select Remote Access on the left, then right-click the server and click Remote Access Management:
In the window that pops up, select DirectAccess and VPN on the left, then Open RRAS Management on the right:
In the Routing and Remote Access window, right-click the server on the left, then click Configure and Enable Routing and Remote Access:
When the wizard opens, click Next. Tick the NAT radio button and click Next:
NB: If no network adapters show up on the next page, make sure IPv6 is enabled on both NICs and try again.
Select the public facing NIC as the interface which connects to the Internet, then click Next, then Finish:
This completes the NAT configuration. Further lab machines should now be able to connect through this VM to the Internet.
One last thing before signing off on this VM, we should create some users in AD.
Creating Active Directory Users
Finally, create a small set of test users:
- One standard domain user
- One named administrative account added to the Domain Admins group
This allows realistic testing without relying on the built‑in Administrator account for everything.
Open Active Directory Users and Computers:
Expand the domain and select the Users folder, then click New user…:
Fill in the details, click Next:
Fill in the password, untick User must change password at next logon, and click Next:
Click Finish:
Repeat this for a second user; we want one regular domain user and one named domain administrator account.
To add domain admin privileges to one of the accounts, open the Properties for that user, go to the Member Of tab at the top, click Add, then add the Domain Admins group, click Apply, then click OK.
Now we have a fully functional DC, and a working DHCP and DNS server, plus an everyday domain user, and a named administrative account which can be used to add the other machines to the domain as they’re created.
Most of this configuration could be automated, either by using a Sysprep image to roll out images over the network or by using command prompt or PowerShell. However, I think there’s value in following a manual process from time to time, if for no other reason than to stay up to date on the process of administering systems. It also allows the analyst to gain a better understanding of the systems with which they’ll be working.
At this point, take another snapshot of the system so that it can be easily rolled back to a known working state after testing, if and when necessary. The updated network diagram should look like this:
Extra Credit
System hardening hasn’t been covered here deliberately. For testing purposes, a relatively default configuration is often more useful. You can experiment later with firewall rules, endpoint protection, vulnerable applications, or even adding a dedicated firewall VM such as pfSense.
This lab is intended primarily for blue‑team testing. Any red‑team activity should only be performed with explicit written permission from the cloud provider and in accordance with local laws.
In the next part, we’ll extend this lab by adding a secondary domain controller. Let me know if there’s anything you’d like clarified or expanded on before moving on.