Posted on August 04, 2022 · 5 mins read



We are back with another LAB post, this time focusing in on one device at a time as they get setup. This post, the fat Domain Controller (DC).

The DC is arguable one of the most important machines within a network as it controls a lot. When we look at the basic principals of security we come down to the CIA triad. Confidentiality, Integrity, and Availability. A lot of systems will integrate with your Active Directory infrastructure to allow it to achieve the first of these, Confidentiality.

At the same time from an attacker point of view trying to escalate their privilege within the network, this is where the keys to the kingdom are held and is often the target of initial attacks. If the attacker can gain access to the Active Directory database (NTDS.dat) it is generally game over. They have taken those keys and are now able to squat in your house if they want.


Well… In my lab I don’t care if they compromise the DC or the Active Directory… I have snap shots that I will rollback to. I have not, in my years in cyber seen an automated piece of malware go after and compromise a domain controller. There is almost always a human at the other end of the attack attempting to breach the DC.

When I say Automated malware, im talking things like Emotet, Dridex and other trojans of a similar nature. These will compromise the device via phishing or some kind of other user interaction like a drive-by download and will steal credentials automatically and farm them off to their C2. These are generally then used in further attacks, whether for financial gain or more sophisticated attacks, like trying to compromise a domain controller. Some will use the stolen credentials from the machine to laterally move and redeploy the malware yes, but an attack on the Active Directory database and the keys to the kingdom is normally done via an operator.

So how to stop it

Well there are a large number of different blogs, guides and videos out there on how to secure your Active Directory environment and how to minimize impact. That is not the purpose of this post. The purpose of this post is more to explain the rational on how I AM setting up my DC in my lab environment. I am purposely making it vulnerable to different things and exploitable as I have a number of plans in the works that require this.

The DC Setup

I will go over in more detail how users are setup in the Domain Controller but at this point in time, the Domain Controller is just a standard setup. A few group policy setting will be enacted and ill list them out later.

The main thing to note is that we are using the main Domain Controller not just for Active Directory Services but for DHCP and DNS. Its the end all for main services. As part of a previous job I would set something similar to this up called a Windows Small Business Server, or Windows SBS. Great for small businesses like the one we are trying to emulate.

Setting up the domain to reflect something that would line up with the operations of the company is key here. In the previous post about the lab I indicated that we would need to ensure that the lab mirrored the company that we claim to be. In this case, the domain will be CENCODINETESTING.local. As part of this lab I’ve decided it will pretend to be a testing lab (mainly cause I started naming things lab then remembered I needed a theme :smile: ).

I have kept the names of machines generic so far. Things like DC and SOCWRK1 as basic labels of machines. I could go all fancy and name them after movie characters or the different types of toothpaste or toothbrushes but honestly, most businesses do not do this and I want this to look as realistic as possible.

There is not much more to the DC setup, just run through the wizard and away you go. Group policy and the configuration of users and enforcing policies is a whole different beast… but that will have to wait for the next blog post :wink: