Active Directory Part 2: Advanced Attacks Every Pentester Should Know

Part 1 covered the foundation — what AD is, how it's structured, and the basic recon that gets you in the door. This post picks up where that left off: the attack techniques that turn a single compromised account into full domain compromise.

Introduction to Active Directory: What Every Pentester Needs to Know First Walk into almost any internal penetration test and you'll find the same thing running the show: Active Directory. It's…

Every technique here maps back to a concept from Part 1 — Kerberos tickets, LDAP permissions, trust relationships. Understanding why each attack works, not just the command to run, is what separates someone running a checklist from someone who can adapt when a target doesn't match the textbook case.

Tools referenced: Impacket suite, Rubeus, PowerView/BloodHound, Mimikatz — all standard in an AD assessment toolkit

Quick Recap: Why These Attacks Work

Every technique in this post abuses one of three trust assumptions AD makes by design:

• Kerberos tickets are trusted once issued — the service receiving a ticket doesn't re-verify the password.
• Any authenticated user can read most of the directory — that's how AD is supposed to work.
• Permissions delegated for convenience (password resets, service accounts) often grant far more than intended.

Keep that lens on through this post — it's the same pattern repeating in six different forms.

1. AS-REP Roasting

Kerberos normally requires "pre-authentication" — proving you know a password before the DC issues a ticket. But if an account has pre-auth disabled (a legacy setting, sometimes left on by mistake), anyone can request a ticket for it without any credentials at all, as shown in the terminal above.

Why it matters: unlike Kerberoasting, this needs zero valid credentials — just a list of usernames. The returned ticket is encrypted with the account's password hash and can be cracked offline with hashcat or John the Ripper.

Finding accounts with pre-auth disabled is usually a quick win during the earliest stage of an engagement, often before you have any domain access at all.

2. Pass-the-Hash (PtH)

NTLM authentication doesn't require the plaintext password — just its hash. If you've dumped password hashes (from a compromised machine's SAM database, or via DCSync below), you can authenticate to other machines using the hash directly, no cracking required.

3. DCSync: Impersonating a Domain Controller

Domain Controllers replicate directory data between each other using a specific protocol (DRSUAPI). If an account has the right replication permissions — normally reserved for DCs themselves — it can request that same replication data, including every password hash in the domain, without ever touching the NTDS.dit file directly.

4. Golden Tickets: Forging Domain Admin, Offline

The krbtgt account's password hash is used to encrypt every single Kerberos TGT issued in the domain. If you obtain that hash (commonly via DCSync), you can forge a completely valid TGT for any user — including one that doesn't exist — with any group membership you want.

5. Delegation Abuse

Delegation lets a service impersonate a user to access a second resource on their behalf — useful for legitimate multi-tier applications, but a major privilege escalation path when misconfigured.

Unconstrained delegation   The trusted server can impersonate ANY user
                           that authenticates to it — including Domain Admins
Constrained delegation      Limited to specific, pre-defined services
Resource-Based Constrained    The target resource itself defines who can
Delegation (RBCD)             delegate to it — abusable if you can write
                               to that resource's attributes

Unconstrained delegation   The trusted server can impersonate ANY user
                           that authenticates to it — including Domain Admins
Constrained delegation      Limited to specific, pre-defined services
Resource-Based Constrained    The target resource itself defines who can
Delegation (RBCD)             delegate to it — abusable if you can write
                               to that resource's attributes

6. ACL Abuse: The Permissions Nobody Reviews

Every object in AD has an Access Control List (ACL) defining exactly who can do what to it — reset a password, add to a group, modify properties. These get granted for convenience (an IT helpdesk needing password-reset rights) and almost never get cleaned up.

GenericAll          Full control — reset password, add to groups, anything
GenericWrite         Modify most attributes, including logon scripts
WriteDACL              Modify the object's own permissions (escalate further)
ForceChangePassword      Reset the password without knowing the current one
AddMember                  Add yourself or others to a group directly

GenericAll          Full control — reset password, add to groups, anything
GenericWrite         Modify most attributes, including logon scripts
WriteDACL              Modify the object's own permissions (escalate further)
ForceChangePassword      Reset the password without knowing the current one
AddMember                  Add yourself or others to a group directly

Why it matters: this is exactly the kind of attack path BloodHound is built to surface — individually boring permission grants that chain into a direct route to Domain Admin. It rarely shows up in a vulnerability scanner because there's no "CVE" for a misconfigured ACL.

7. Trust Relationship Abuse

Domains and forests can establish trusts to share resources. A compromised domain with a trust to another can sometimes pivot across that trust boundary, particularly if the trust is configured bidirectionally or the trusted domain has weak hygiene.

This is advanced territory best explored after the fundamentals above are solid — but worth knowing it exists if you're assessing a multi-domain or multi-forest environment.

8. A Realistic Advanced Attack Chain

Put together, these techniques often chain like this on a real (lab-based) engagement:

1. AS-REP Roast a list of usernames -> crack offline -> low-priv creds
2. Enumerate ACLs with BloodHound -> find a GenericAll path to a privileged user
3. Abuse that ACL -> reset the target's password -> now a more privileged user
4. Check for DCSync rights on that account -> dump all domain hashes
5. Extract krbtgt hash -> forge a Golden Ticket -> full, durable domain access

1. AS-REP Roast a list of usernames -> crack offline -> low-priv creds
2. Enumerate ACLs with BloodHound -> find a GenericAll path to a privileged user
3. Abuse that ACL -> reset the target's password -> now a more privileged user
4. Check for DCSync rights on that account -> dump all domain hashes
5. Extract krbtgt hash -> forge a Golden Ticket -> full, durable domain access

Five steps, each building on the last — and importantly, none of them require a software vulnerability or a CVE. Every one is a misconfiguration or a default AD behavior being used exactly as designed, just not as intended.

9. A Word on Detection and Defense

Since this content is for VAPT work, it's worth closing the loop on what defenders actually watch for — useful context for writing a report that's more than just a list of exploited findings:

• AS-REP/Kerberoasting show up as unusual ticket requests — Event ID 4769 with specific encryption types
• DCSync attempts are logged as replication requests from non-DC accounts — a major red flag in SIEM alerting
• Golden Ticket detection often relies on anomalies like a TGT's lifetime not matching domain policy
• Regular krbtgt password rotation (twice, per Microsoft's guidance) limits the blast radius of a compromise

A good pentest report doesn't just say "this was exploitable" — it explains what detection opportunity existed, which is often more valuable to the client's security team than the finding itself.