Active Directory Attacks — Owning the Backbone of the Enterprise

This is Part 5 of my VAPT internship series at CYBERENTITYZ. Earlier posts covered reconnaissance, scanning/enumeration, and network penetration testing. This time we move into what is, in almost every enterprise engagement, the real prize: Active Directory.

What Is Active Directory, and Why Attack It?

Active Directory (AD) is Microsoft's directory service for Windows domain environments — it's the system that manages users, computers, group memberships, and authentication for the vast majority of enterprise networks. If a company runs Windows at any scale, there's almost certainly a domain controller (DC) sitting at the center of it, deciding who gets access to what.

That centrality is exactly why AD is the highest-value target in most internal engagements. Compromise a single domain user with weak permissions and, through a chain of misconfigurations and credential abuse, you can often work your way to Domain Admin — at which point you don't just own one machine, you own every machine, account, and resource the domain controls.

Why It Matters

AD compromise isn't a niche finding — it's the headline of most red team and internal pentest reports. A few reasons it shows up so consistently:

• Decades of accumulated misconfiguration in long-lived domains (stale accounts, overly broad group memberships, forgotten service accounts with Domain Admin rights).
• Kerberos and NTLM, while well-designed protocols, have well-documented abuse paths that are hard to fully close without breaking legacy application compatibility.
• Lateral movement inside AD environments often blends in with normal authentication traffic, making it hard to detect without proper logging and SIEM tuning.
• One overprivileged service account is often all it takes to pivot from "low-privilege foothold" to "full domain compromise."

This is why frameworks like MITRE ATT&CK dedicate so much real estate to Credential Access (TA0006) and Privilege Escalation (TA0004) — most of the named techniques in those categories exist because of AD's attack surface.

Core Techniques and Tooling

Kerberoasting

Kerberoasting abuses a feature of Kerberos authentication: any authenticated domain user can request a service ticket (TGS) for any service principal name (SPN) registered in the domain. That ticket is encrypted with the service account's password hash. Since service accounts are frequently configured with weak or never-rotated passwords, an attacker can request these tickets, take them offline, and crack them without touching the domain controller again after the initial request.

GetUserSPNs.py PHANTOM.CORP/lowpriv:Password123 -dc-ip 10.10.10.1 -request

GetUserSPNs.py PHANTOM.CORP/lowpriv:Password123 -dc-ip 10.10.10.1 -request

This pulls every SPN-registered account's ticket in one pass, ready for offline cracking with Hashcat.

Pass-the-Hash (PtH)

Pass-the-Hash exploits the fact that NTLM authentication only ever needs the password hash, not the plaintext password. If an attacker dumps an NTLM hash from one compromised machine, that hash alone can authenticate to other systems where the same credentials are valid — no cracking required.

psexec.py -hashes :aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bda830b7586c PHANTOM.CORP/administrator@10.10.10.20

psexec.py -hashes :aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bda830b7586c PHANTOM.CORP/administrator@10.10.10.20

This is where tools like Impacket's secretsdump.py (for harvesting hashes) and psexec.py (for using them) form a natural one-two combination — something I worked through extensively in earlier lab sessions across the PHANTOM.CORP and GHOST.CORP domains.

DCSync

DCSync abuses legitimate Active Directory replication protocols. Domain controllers normally replicate directory data — including password hashes — between each other using the Directory Replication Service Remote Protocol (MS-DRSR). If an attacker compromises an account with replication rights (often Replicating Directory Changes and Replicating Directory Changes All), they can impersonate a domain controller and ask the real DC to "replicate" any account's hash directly to them — including the KRBTGT account, which underpins the entire domain's Kerberos trust.

secretsdump.py -just-dc PHANTOM.CORP/admin:Password123@10.10.10.1

secretsdump.py -just-dc PHANTOM.CORP/admin:Password123@10.10.10.1

This single command, run with sufficient privileges, can dump every credential hash in the domain — making DCSync one of the most consequential techniques to demonstrate (and defend against) in a domain-wide assessment.

Mimikatz / pypykatz

Mimikatz is the tool most associated with Windows credential extraction — pulling plaintext passwords, hashes, Kerberos tickets, and more directly from LSASS memory. In Linux-based lab workflows, pypykatz offers a Python reimplementation that parses the same memory structures without needing a live Windows agent, which is useful for analyzing memory dumps offline.

pypykatz lsa minidump lsass.dmp

pypykatz lsa minidump lsass.dmp

This parses an offline LSASS memory dump and extracts credential material exactly the way Mimikatz would on a live host — a technique worth understanding both offensively and for blue-team detection engineering (since LSASS access patterns are a well-known detection point in EDR/SIEM tooling).

BloodHound and PlumHound — Mapping the Attack Graph

Raw credential dumping only gets you so far without context. BloodHound solves the "what now?" problem by ingesting AD data (users, groups, sessions, ACLs, trust relationships) and modeling it as a graph — instantly surfacing non-obvious attack paths like "this help desk user is two hops from Domain Admin via nested group membership."

PlumHound builds on top of BloodHound CE's data to generate structured, shareable reports — useful for turning a graph database into something a client or report reviewer can actually read. In recent lab work, PlumHound (run from /opt/PlumHound) generated a 119-task HTML/CSV report flagging an unusually high number of Domain Admin accounts and several stale or suspicious group memberships across a multi-domain lab environment — exactly the kind of finding that looks abstract in a graph and concrete in a report.

Privilege Escalation Inside AD

Beyond the headline techniques above, AD privilege escalation often comes down to abusing misconfigured permissions: ACL abuse (a low-privilege user granted GenericAll or WriteDACL on a higher-privilege object), unconstrained/constrained delegation abuse, and AdminSDHolder misconfigurations. These are precisely the kinds of findings that BloodHound is built to surface automatically, which is why graph-based AD analysis has become standard practice rather than a "nice to have" in modern AD assessments.

Closing Thoughts

What makes Active Directory attacks worth understanding deeply isn't any single technique — it's how naturally they chain together. A single weak service account password leads to Kerberoasting, which leads to a foothold, which BloodHound maps into a path toward an account with replication rights, which leads to DCSync, which leads to full domain compromise. Each step on its own might look like a "medium" finding; strung together, they're a critical one.

This is also why defensive controls matter just as much here as offensive technique: tiered administration models, LAPS for local admin password rotation, monitoring for abnormal replication requests, and Kerberos ticket lifetime policies all exist specifically to break links in this chain.

Next up in this series: a deeper dive into AD privilege escalation paths and how blue-team detection engineering (Wazuh/Sigma) can catch these techniques in practice.

This post is part of an ongoing VAPT series documenting hands-on offensive and defensive security learning. Previous posts covered reconnaissance/information gathering, scanning/enumeration, and network penetration testing.