Introduction

Active Directory (AD) is a centralized directory service developed by Microsoft, widely used in enterprise environments to manage users, computers, and resources. It provides essential authentication and authorization mechanisms, enabling organizations to enforce security policies, control access to sensitive data, and streamline administrative tasks.

Due to its critical role in Identity and Access Management (IAM), Active Directory is a primary target for attackers. Security misconfigurations, weak permissions, and legacy protocols often introduce vulnerabilities that adversaries exploit to escalate privileges, perform lateral movement, and ultimately achieve domain dominance. Understanding the inner workings of AD — and how it can be abused — is essential for both defending and securing modern corporate infrastructures.

Why i built this lab?

Having participated in CTFs for over four years, always I had issues with Active Directory environments. While I initially believed that repetition alone would help me master these machines, I realized that I was still struggling to grasp the core mechanics of AD attacks and how they function from inside.

Recently, I have been pivoting my focus toward Blue Teaming. I believe that understanding the offensive perspective is just as important as knowing how to detect and mitigate these threats. Building this lab allows me to bridge that gap and gain a deeper, more technical understanding of both sides of the coin.

First step: deploying the domain controller

I installed a windows server 2022 data center

Then i created some users with different privileges and groups

To streamline the lab setup, I modified the Default Domain Password Policy to disable complexity requirements. This allowed me to provision users without the need for high-entropy passwords for every account.

CRITICAL NOTE: Disabling password complexity is one of the most significant security oversights a Domain Administrator can commit. In a production environment, this leads to weak credentials that are easily susceptible to Brute Force and Dictionary attacks. This modification was performed strictly for educational purposes within a controlled laboratory environment.

Second step: Reconnaissance

I made a simple port scan on the domain controller ip.

We can see that the most common AD ports are open, such as 53(DNS), 88(Kerberos), 135(Msrpc), 139(Netbios), 389(Ldap), 445(SMB), 5985(WinRM) and more

Understanding Kerberos: The Ticket System

Kerberos is the default authentication protocol in Active Directory. Its primary goal is to allow nodes to communicate over a non-secure network to prove their identity to one another in a secure manner. It relies on a Key Distribution Center (KDC), which resides on the Domain Controller.

Before diving into the attacks, it is essential to understand how Kerberos works.

1. AS-REQ / AS-REP (Authentication Service)

• The Request: The user sends a request to the KDC to prove their identity. Usually, this requires "Pre-authentication" (encrypting a timestamp with their password hash).
• The Ticket: If successful, the KDC issues a TGT (Ticket Granting Ticket).
• Vulnerability: This is the stage targeted by AS-REP Roasting if pre-auth is disabled.
• The Request: Once the user has a TGT, they present it to the KDC to request access to a specific service (like a SQL database or a File Share).
• The Ticket: The KDC provides a TGS (Service Ticket) encrypted with the service account's password hash.
• Vulnerability: This is the stage targeted by Kerberoasting.

3. AP-REQ / AP-REP (Application Request)

• The Access: Finally, the user presents the TGS to the actual server they want to access. The server decrypts it, and if it's valid, grants access.

User enumeration over Kerberos

To initiate the attack, I created a targeted wordlist of potential domain usernames. In a real-world engagement, an attacker would typically utilize massive datasets or OSINT to identify valid user patterns.

It is standard practice for organizations to follow specific naming conventions. Common formats include:

• [Name first letter].[Surname]
• [Surname].[Name first letter]
• [Name].[Surname]
• [Surname].[Name]
• [Name]
• [Surname]

These wordlists can be efficiently generated using custom scripts that combine common names and surnames based on these specific formats.

For this phase, I utilized Kerbrute, a specialized tool designed to interact with the Kerberos protocol. Kerbrute is particularly effective for User Enumeration because it sends TGT (Ticket Granting Ticket) requests.

Then we can see some actual existent domain users. This can lead to password bruteforcing

Password bruteforcing over Kerberos

Using the list of confirmed usernames, we can perform a targeted brute-force attack. I used Kerbrute for this task as well, testing common passwords or dictionary-based lists against the identified accounts. Unlike NTLM authentication, Kerberos-based brute forcing is highly efficient and can be executed rapidly against the Key Distribution Center (KDC).

In order to detect this type of attack we can see the windows event logs and then filter on the security logs. We can filter the EventID=4771, that are related to failed kerberos authentication. If there were multiples request on a short period of time, it means that there was a bruteforcing attack

AS-REP Roasting

Moving forward with common AD vulnerabilities, we encounter AS-REP Roasting. This technique allows an attacker to retrieve a user's password hash without needing to know their current password, provided a specific misconfiguration is present.

This attack targets accounts where Kerberos Pre-authentication is disabled (DONT_REQ_PREAUTH)

Case 1: Standard Authentication (Pre-auth Required)

1. AS-REQ: The client sends an initial request to the KDC (Key Distribution Center).
2. KDC Error: The KDC checks the user's account and sees that pre-authentication is required. It responds with a KRB_ERROR: PREAUTH_REQUIRED.
3. AS-REQ (with Pre-auth): The client sends a new request, this time including a timestamp encrypted with their password hash.
4. AS-REP: The KDC decrypts the timestamp. If it matches, the KDC verifies the user's identity and issues the TGT (Ticket Granting Ticket).

Case 2: Vulnerable Authentication (Pre-auth Disabled)

1. AS-REQ: An attacker sends a request on behalf of a user (e.g., j.jordan) saying: "I am j.jordan, please provide my ticket."
2. KDC Validation: The KDC checks its database and finds that the account has the DONT_REQ_PREAUTH flag set.
3. Direct AS-REP: Instead of requesting a timestamp or throwing an error, the KDC immediately responds with the AS-REP message.
4. The Catch: This AS-REP message contains a session key encrypted with the user's password hash. Since the attacker now has this encrypted data, they can take it offline to attempt to crack the password without any further interaction with the Domain Controller.

Then if the password is weak we can crack the hash with tools such john or hashcat

The way we can detect this attack is on the event log searching for EventID=4769 that this records TGT requests and most important PreAuthType=0, that means that KDC give the hash without a pre-auth

Kerberoasting attack

This attack targets the Kerberos protocol to compromise service accounts. Specifically, it allows an adversary to request and steal service tickets (TGS) to crack the passwords of accounts associated with a Service Principal Name (SPN).

The strength of this attack lies in its stealth. Since the attacker is already authenticated as a domain user, they can legitimately request a Ticket Granting Service (TGS) for any service in the domain.

1. Request: The attacker requests a TGS for a specific SPN (e.g., a SQL or IIS service account).
2. Issuance: Because the request comes from a valid domain user, the KDC delivers the ticket without suspicion.
3. Extraction: The attacker extracts the ticket from memory and takes it offline.
4. Offline Cracking: The service ticket is encrypted with the service account's password hash. The attacker can then use brute-force or dictionary attacks to recover the clear-text password.

To detect this attack, we can filter for EventID=4769, which means that a TGS was requested from the Domain Controller. We look for TicketEncryptionType 0x17, which means the encryption type is RC4. This is faster to crack than AES, so attackers usually use RC4.

SMB unprivileged access

Server message block is a windows protocol used to share files, printers and resources between the machines on the network.

Allowing unauthenticated users to read shared resources can lead to the expousure of sensitive files.

Another case is when a domain user can access privileged shares, ignoring the principle of least privilege. If this user is compromised, the risk of data loss is unacceptable.

We can see that an unprivileged user can open privileged shares like Admin folder and credentials. The other shares are default shares, is better to only admins can access these shares, they can contain sensitive data

SMB brute forcing

Having a user and password wordlist we can test if there is a valid user. As we previously seen, this attack can be inefficient if we dont know how the format to set the username

For detecting this attack we can filter by EventID=4625, thats mean failed login attempt

SMB Relaying

This attack comes into play when using NTLM authentication. When a user requests access to a shared resource, SMB authentication is started and authenticates with Active Directory.

The attacker can act as a Man-in-the-Middle, intercepting this authentication, forwarding it to another server, and impersonating the user.

This is possible if Active Directory does not have SMB signing enabled, which allows attackers to gain unauthorized access. Also, you cannot relay credentials to the same machine they were captured from due to patch MS08–068 (CVE-2008–4037). This patch introduced a mechanism where the Windows kernel flags authentication requests; if it detects that the incoming response is "echoed" from the same interface, it discards it.

For this attack, we are going to use two tools:

1. Responder: This is a poisoning tool for name resolution protocols (LLMNR, NBT-NS, and MDNS). Its function is to fool other devices so that they send their authentication hashes. If a user misspells the name of a shared folder, the device asks over the network who knows where this folder is; Responder listens to this request and responds, "I am here." Then, the victim sends their username and their NTLMv2 hash.

responder -I eht0 -wd

2. NtlmRelayx: This tool takes the hash that Responder captured and relays it to another server. This way, the attacker can gain access to that server. If the compromised user has high privileges, the attacker can perform any action without knowing the original password.

impacket-ntlmrelayx -t ad.lab -smb2support -i

DC sync

This attack is commonly used to steal credentials from an active directory database. The attacker pretends to be a domain controller in order to request the password hashes from the target active directory

This attack is possible because the attacker exploits the Directory Replication Service (DRS) Remote Protocol. Normally, Domain Controllers use this protocol to synchronize database changes with each other.

If a regular user is granted specific privileges — specifically "Replicating Directory Changes" and "Replicating Directory Changes All" — they can trick the Domain Controller into thinking they are another DC and request all the password hashes from the database (including the krbtgt hash).

Here is a post that explains this attack very well

In this example, I assigned GenericAll privileges over the domain to the user j.jordan, which allows this user to perform a DCSync attack. This attack can also be executed using Mimikatz

Using secretsdump, we can dump the NTDS.dit (the Active Directory database) or the SAM. The output follows this format:

User : RID : LM Hash : NT Hash :::

Since the attacker has the hashes, they can attempt to recover the clear-text passwords without interacting with the target machine anymore.

If cracking the password takes too long, the attacker can use the hash itself to authenticate. In Windows environments, you don't always need the clear-text password to log in; the NTLM hash is enough.

This technique is called Pass-the-Hash. It is widely used by attackers to gain access to a system without knowing the user's clear-text password.

Instead of cracking the hash to find the original password, the attacker uses the captured NTLM hash directly to authenticate to a remote target. This is possible because the NTLM protocol uses the hash itself as the "proof" of identity during the challenge-response handshake.

Golden ticket attack

A Golden Ticket is a forged Ticket Granting Ticket (TGT) that grants an attacker total control over an Active Directory domain. It is one of the most powerful post-exploitation techniques because it allows for long-term persistence.

The security of the Kerberos protocol relies on the krbtgt account. The password hash of this account is used by the Key Distribution Center (KDC) to encrypt and sign all TGTs.

If an attacker obtains the krbtgt hash (typically through a DCSync attack), they can forge their own TGTs. This forged ticket, known as a "Golden Ticket," allows the attacker to:

• Impersonate any user in the domain (usually the Domain Admin).
• Access any resource in the network.
• Stay persistent even if the real Domain Admin changes their password.

Requirements for the Attack

To forge a Golden Ticket, the following information is required:

1. Domain Name (FQDN): The full name of the domain.
2. Domain SID: The unique Security Identifier of the domain(using lookupsid from impacket)
3. Username to Impersonate: Usually a high-privileged account like Administrator.
4. KRBTGT Password Hash: The NTLM or AES hash of the krbtgt account(we got with the dcsync attack)

Event ID 4662 registers operations performed over Active Directory objects. In a DCSync attack, we can identify specific indicators:

• SubjectUserName: lowpriv — This indicates that a low-privileged user is performing operations usually reserved for Domain Controllers or Domain Admins.
• AccessMask: 0x100 — This shows that the user is not just reading an object, but is also invoking a specific extended right.
• Properties: {1131f6ad-9c07–11d1-f79f-00c04fc2dcd2} — This GUID corresponds to DS-Replication-Get-Changes, which allows a client to request updates from Domain Controller replication.

Access control list abuse

An Access Control List (ACL) is a security mechanism that defines permissions (Read, Write, Execute) for users and groups over objects such as files, folders, or Active Directory objects.

Certain permissions can be abused by an attacker to gain elevated privileges. There is no direct "patch" for this, as these are often legitimate features; the only way to prevent abuse is to implement strict security policies and follow the principle of least privilege to ensure attackers cannot compromise accounts with these permissions.

In CTFs and real-world environments, there are four common ACL abuses. Tools like BloodHound are essential for detecting these hidden attack paths.

1. GenericAll: This privilege allows to manipulate the objective object as this user wants

To detect if someone has abused these permissions, we should monitor specific EventIDs in the Security logs of the Domain Controller:

• Password changed(most common): 4724
• Modifying user atributes(memberOf, scriptPath, servicePrincipalName:5136
• Adding user to privileged group:4728,4732,4756
• ACLs change: 4670

2. Write DACl: allows to an user to change the pivileges over an object(allowing to get GenericAll over the object)

To detect if someone has abused these permissions, we should monitor specific EventIDs in the Security logs of the Domain Controller:

• ACL change: 4662

3. Write Owner: allows user to take possession over an object

Then we can change ACL and reset user password

To detect if someone has abused these permissions, we should monitor specific EventIDs in the Security logs of the Domain Controller:

• Owner change: 4662/4670

4. ForceChangePassword: An user can change the password over other user

We can change the password as we have previously seen

To detect if someone has abused these permissions, we should monitor specific EventIDs in the Security logs of the Domain Controller:

• Password change: 4724

Conclusion

It is critical to be aware of the impact an Active Directory attack can have. An entire organization becomes vulnerable when misconfigurations are present, and the resulting damage can be catastrophic.

This report covers fundamental concepts, but many more techniques and attack vectors exist. I will dive deeper into those in Part 2 of this series.

If you made it this far, thank you for reading!