September 26, 2026
Building and Attacking My Own Active Directory Lab
What building and attacking the same Active Directory lab taught me
By Pelda Petekkaya
4 min read
What building and attacking the same Active Directory lab taught me
When I decided to work on Active Directory security, I did not want to start only from the attack side.
I wanted to build the environment myself first.
The main reason was simple: if I only learn how to exploit a system, I can understand what works, but I may not understand why that weakness exists in the first place.
So I wanted to see both sides.
Why I Built the Lab Myself
Building the lab was not always easy.
While configuring users, permissions, services, network settings and security controls, there were some parts where I had to stop and understand why a certain configuration was needed.
At first I saw these difficulties only as setup problems.
Later, I realized that this part was actually very useful.
Sometimes a more open configuration makes administration easier. Sometimes a restriction improves security but creates extra work or makes another process harder.
This made me think more about the balance between security and usability.
This was one of the main reasons building the environment myself helped me understand the attacks better.
Then I Looked at the Same Environment as an Attacker
After the environment was ready, I started testing different Active Directory attack techniques.
I worked with:
- PsExec / SMB
- LLMNR Poisoning
- Kerberoasting
- DCSync
- AS-REP Roasting
- DCShadow
- PetitPotam NTLM Relay to AD CS
- Pass-the-Ticket
I did not want to look at them only as commands to run.
I tried to understand what condition made each attack possible.
PsExec and Privileged Access
One of the first things I tested was remote command execution through PsExec and SMB.
After gaining the required access in the lab, I was able to establish a session with SYSTEM privileges.
This was a simple example, but it was useful because it made one thing clear: once privileged credentials are exposed, normal administrative functionality can also become useful for an attacker.
Misconfigurations Started to Make More Sense
While testing the environment, I started to understand why some weaknesses are not always caused by a clearly "bad" configuration.
For example, Kerberoasting showed me how service accounts with weak passwords can become a problem even when Kerberos itself is working normally.
AS-REP Roasting was another example. If Kerberos pre-authentication is disabled for an account, it creates an opportunity for offline password attacks.
LLMNR was also interesting because it is a fallback mechanism. It can be useful in some environments, but if it is left enabled unnecessarily, it can expose authentication material.
At this point, instead of only thinking:
"This is insecure."
I started asking:
"Why is this enabled, who needs it, and what happens if we disable it?"
That question became more useful to me than simply memorizing attack techniques.
DCSync and DCShadow
DCSync and DCShadow were probably the parts that changed my understanding of Active Directory the most.
Before the lab, I mostly thought about replication as a normal administrative function between Domain Controllers.
After testing these techniques, I understood how important replication permissions actually are.
With DCShadow, I was able to see how directory changes can be introduced through the replication process itself.
That was more interesting to me than simply changing an object directly.
It also made me understand that protecting passwords is not enough. Privileges and replication permissions are just as important.
Certificate-Based Authentication and AD CS
The PetitPotam and AD CS scenario was another part I found interesting because it involved more than one component.
The attack chain included NTLM authentication, relay, AD CS and Kerberos.
The certificate material was then used to obtain Kerberos authentication.
After that, I used the imported ticket to validate access to the Domain Controller.
This part helped me understand something that I had not thought about enough before: authentication material is not only usernames and passwords.
Certificates and Kerberos tickets also matter.
What I Learned From the Whole Process
The biggest thing I learned from this lab was not one specific attack.
It was seeing how different decisions connect to each other.
A permission may be given because it makes administration easier.
A protocol may stay enabled because another system still needs it.
A control may be relaxed because it causes operational problems.
Each decision can look reasonable on its own.
But when several of them come together, they can create an attack path.
That was probably the most useful lesson for me.
Building the environment first helped me understand not only how an attack works, but also why the environment may have been configured that way.
I think this is important because security is not only about restricting everything.
A system still has to work.
The challenge is reducing unnecessary risk without making the environment impossible to manage.
Final Thoughts
Building and attacking the same Active Directory environment helped me understand the subject much better than only following attack tutorials.
The attack side showed me what can happen.
The setup side helped me understand why it can happen.
I still have a lot to learn, but this approach helped me look at Active Directory from more than one perspective.
The full technical report, screenshots, findings and remediation recommendations are available on my GitHub: