One of the major things recommended to anyone in digital forensics, and probably network or systems administration as
Why the Cloud?
There are a number of reasons the cloud is a great place for a lab of this type:
- Server instances can be spun up and down as required, with as many or as few resources (read: CPU, RAM) as needed, very quickly
- Snapshots can be taken of each of the endpoints at any point in time, meaning any activity can be quickly and easily rolled back
- Configuring a lab in this way is inexpensive, compared to buying something like an Intel NUC and having a fully self-contained, always-on lab (which is also a great alternative to building a lab in the cloud)
- No dedicated hardware, and having a virtual lab means attributes such as network connections can be readily reconfigured
If you’ve not used a VPS provider like Vultr (or Amazon, Azure, Digital Ocean, etc.), read this post first to become familiar with the general process of creating a VM.
Network Diagram
Here’s what the lab is expected to look like in the end:
The vSwitch will be handled by the provider, which should allow for private IP addressing on an internal NIC for each VM (meaning each VM will likely have two NICs; one public and one private). All public facing NICs except that belonging to the DC will be disabled.
Ordinarily, it’s inadvisable to dual-home a DC and make it the default gateway for a network, but it’s a quick and dirty way to have a single point of access for the lab. Alternatively, a separate VM could be used to share
We’ll begin with the configuration of the primary domain controller (DC) for the domain; a Windows Server 2016 VM. Most Windows ISOs can be found in the Microsoft Evaluation Centre: https://www.microsoft.com/en-us/evalcenter/. A benefit (and disadvantage) of building a lab this way is that you’re basically required to break it down and rebuild it every six months (when the OS evaluations expire).
NB: I’ve learned from many frustrating attempts that creating a Server 2016 machine with anything less than 2048MB of RAM is a poor choice. Don’t do that. It may work, but crushingly slowly. Ideally, spring for at least 4096MB of RAM.
Initial Server Configuration
For the sake of brevity, let’s assume you’ve been able to install the OS and are at the Windows Server desktop GUI, ready for initial configuration in Server Manager. (If you followed the post mentioned previously, you should be there)
First, select Local Server on the left. Then, click the current Computer Name (mine was WIN-BUI1P3T5VQV):
The System Properties window should pop up. Click Change:
Enter a Computer Name of your choosing. I chose Hera (planning a naming scheme consisting of Greek gods/goddesses):
Click OK, OK, and Close, then Restart Later (unless you really want to restart now). I’ll let you choose your own adventure and decide whether to download/configure Windows Updates and change the timezone of the machine yourself (I did both, but understand if you’re not all about that life):
Once done, click Manage, then Add Roles and Features:
Tick Skip this page by default (or not, be your own person). Click Next. Select Role-based or feature-based installation, then click Next:
Leave Server Selection as default, click Next again. Tick Active Directory Domain Services:
Accept the additional (prerequisite) installations as well:
In my lab, this VM will not only be the primary DC but will also perform DHCP and DNS, so the two following steps are optional, but recommended. Tick DHCP Server:
Accept the feature prerequisites:
Select DNS:
Accept feature prerequisites:
Click Next. Ignore the additional feature installation for now, unless there’s something you desperately want to play with. Click Next until completion, then click Install:
Once the installations are complete, feel free to click Close.
Reboot.
Domain Controller Promotion
There will likely be some notifications regarding the Post Deployment Configuration:
Promote the server to a DC by clicking the so-named notification. A new forest will likely need creating, for example:
The root domain needs to be a fully qualified name of some kind, such as a.b or x.y.z. However, it can be entirely made up and personal to the owner of the domain. On the next page (you clicked Next, right?), fill in your restore password, leave all other defaults:
Complete the wizard by accepting all remaining defaults, then click Install (don’t mind any warnings about DNS and DHCP, they’ll be
Reboot.
Once rebooted, the VM should be joined to the newly created domain, and logging in is achieved with <domain>\Administrator credentials instead of <computername>\Administrator.
DHCP Configuration
Next we’ll configure the DHCP portion of the server:
Clicking this warning will open the DHCP configuration wizard. Click Next:
As we haven’t yet added any users to the AD forest, the default administrator credentials will be entered. Click Commit:
With DHCP authorised, it’s time to create a scope, allowing the remaining machines in the lab to have IP addresses assigned as they join the network. In Server Manager, select DHCP on the left,
In this control panel, expand the server name, right-click IPv4 and click New scope…:
Click Next. Give the scope a name, and a description if desired:
Define the IP range. Given this lab will have only a few devices I’ve allotted 10 (technically 11) IP addresses within a private address space. Once done, click Next:
The next page is where exclusions to the DHCP IP range can be added. I’ve not added any exclusions at this stage. I also made the lease duration 8 hours and told the wizard I want to configure the default client DHCP options now. The router (or default gateway) IP address will be the address of this primary DC (which hasn’t been configured yet, but we’ll get to that later, and it will be 10.0.0.10):
The next page is where we need to specify any DNS server addresses to be assigned to the DHCP clients. As this primary DC is also the DNS server, enter it’s (expected) static IP address (if a warning pops up about this not yet being a valid address, say yes to accept it):
The next page pertains to WINS servers, which won’t be used in this environment, so accept defaults and click Next. Select Yes, I want to activate this scope now and click Next, then click Finish.
Success! The DHCP server component of the primary DC has now been successfully configured!
Network Adapter Configuration
Open your private network adapter properties via the Network and Sharing Centre:
Open the IPv4 properties and configure the address details of this server:
Each cloud provider has instructions on the correct settings for a private network adapter, best to follow those guidelines where possible. For example, the default gateway above is the IP address of the public facing NIC of the VM, and the alternate DNS was supplied by the cloud provider. Yours will likely be different.
Click OK, then Close. Done.
DNS Configuration
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 (and it does in the image below), 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 in order 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:
Leave b as default, 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:
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
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 what should also be 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 are 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 will be working.
At this point, take a(nother) 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
One thing which hasn’t been covered in this write-up is how to harden a system, whether it’s a server or a workstation. This has been intentionally overlooked; if this is a lab environment designed for testing, it’s best to leave it at least somewhat default, otherwise it’s not a
This lab is designed primarily for blue team
There’s a lot that could be done with the Windows firewall, built-in or third-party antivirus and antimalware, or even purposefully installing vulnerable applications in order to test specific attack methods. Alternatively, a third-party firewall, such as
This is something that can be looked at in the future, and maybe I’ll produce something on it a little way down the line. If you followed along to this point, good job! Feel free to let me know if there are any glaring omissions, or if there’s anything which needs further clarification or explanation.
Go here to see how to continue the build with a Server 2012 R2 server as the secondary DC for the domain.