Active Directory Attack Path Notes (Beginner level)

These are my study notes, not a textbook. I have been going through the CRTP syllabus and writing down the paths the way I actually remember them — what starts where, what you need before it works, and what it looks like from the blue side when it does.

Everything below is for systems you are authorized to test. That is not a disclaimer I paste because someone told me to — half of these techniques are only legal inside a lab or a scope you signed.

No tool output dumps here. If a command shows up, it is a command, not proof of anything.

The mindset first

AD attacks are not a list of tricks, they are a graph. Every path starts with the same three questions:

1. Who am I? A domain user, a user with local admin somewhere, a service account, a computer account. Each of these opens different edges.
2. What trusts me? Group memberships, ACLs, delegation settings, SPNs tied to accounts I control.
3. What does the graph let me reach from there?

People memorize tools and forget the graph. The tools change; the edges have not changed in twenty years: an account authenticates here, is allowed to act there, and the next hop is one ACL away.

Enumeration — what I look at first

Before any attack technique, the passive pass. In a lab or an engagement I want, in this order:

• Domain basics — Get-ADDomain / ldapsearch against the root DSE: domain name, functional level, DCs, forest trusts.
• Users and computers — counts, naming patterns, which accounts look like service accounts (long names, no last logon, SPN attached).
• Group membership — especially anything that smells like nested administration: Domain Admins, Account Operators, and the delegated groups people create and forget.
• GPOs — scheduled tasks and startup scripts are a local-admin distribution mechanism hiding in plain sight.
• ACLs on the domain object — this is the one that matters most and gets checked last by people who are in a hurry.

BloodHound (or bloodhound-python for collection) compresses all of this into paths, and I use it — but I still read the raw LDAP for the domain object ACL, because a GenericAll in a screenshot chain is easier to argue about when you have seen the ACE itself.

Kerberoasting

The classic, and still the most reliable way to turn "any domain user" into "offline password cracking".

The edge in the graph: any authenticated domain user can request a service ticket (TGS) for any account that has an SPN — and the ticket comes back encrypted with a key derived from that account's password.

What you need: any valid domain credentials. Nothing else.

What it looks like in practice: enumerate SPNs (PowerView's Get-NetUser -SPNs, or Impacket's GetUserSPNs.py), request tickets, save them, take them offline. Impacket's example:

bash GetUserSPNs.py DOMAIN/user:password -dc-ip <DC> -request

Offline from there — hashcat mode 13100 for Kerberos TGS, or John with the krb5tgs format. The cracking is where the technique actually lives: a 40-character random service account password is a dead end, and a service account that reuses the helpdesk password is not.

Worth knowing: - Requesting with RC4 where the policy allows it gives you a cheaper hash to crack than AES. Some environments still allow it; some do not. - Service accounts are the regex of AD: nobody has ever found one that was rotated properly, and half of them are local admin on something. - You can roast without knowing any SPNs in advance — but you need the domain's SPN list first, and that is enumeration work, not attack work.

Blue side: Event 4769 for a service ticket with an unusual encryption type, from a user who does not normally talk to that service, at volume.

AS-REP roasting

The mirror image of Kerberoasting, and easier to miss.

The edge: accounts with "Do not require Kerberos preauthentication" (DONT_REQ_PREAUTH) hand you a chunk of material before you have authenticated as anything useful — you only need the username.

Enumeration and request in one shot with Impacket:

bash GetNPUsers.py DOMAIN/ -dc-ip <DC> -usersfile users.txt -no-pass

Every hit is a username that will never warn anyone that its password is being ground through a dictionary. In real environments the hits are usually service or appliance accounts where someone ticked a box to make a integration work.

Blue side: 4768 (TGT request) for accounts that should always preauthenticate; the fix is one flag in the account options.

Delegation — three different doors

Delegation is where AD gives you the edges that were designed for functionality and get used for movement.

Unconstrained delegation

The old one. A computer with unconstrained delegation stores the TGTs of users who connect to it. Compromise that machine — or coerce an authentication to it — and you are collecting tickets from whoever visits, including administrators, because browsers are not careful.

The modern exploitation path is coercion: make a privileged account authenticate to your unconstrained host (the PrinterBug / SpoolSvc trick is the usual nudge), then extract the TGT from memory. No local admin on a domain controller needed — that is the whole point of the edge.

What to check: userAccountControl with TRUSTED_FOR_DELEGATION on computer objects. Anything still configured this way in 2026 is either legacy or forgotten.

Constrained delegation

A service account constrained to specific SPNs. The interesting part is protocol transition (TRUSTED_TO_AUTH_FOR_DELEGATION): with S4U2Self and S4U2Proxy the account can ask the KDC for a ticket to itself on behalf of any user, and then exchange it for a ticket to the allowed SPN.

The abuse condition: you already control the service account (its password or hash). What delegation buys you is the impersonation of anyone — including privileged users — to the services it is allowed to reach. From "pwned service account" to "I am this user on the file server" without ever knowing their password.

Resource-based constrained delegation (RBCD)

The direction reverses: the target machine declares who may act on its behalf, in msDS-AllowedToActOnBehalfOfOtherIdentity.

What you need: write access over the target computer object (or over the object whose SID you plant there) and a computer account you control — which is usually free, because any domain user can add a machine account to the domain.

That combination — a trivial-to-get computer account plus one writable ACL — is why RBCD is the delegation edge I check first in modern environments. It turns "GenericWrite over a computer" into "local admin on that computer", every time the conditions line up.

ACL paths — the graph's real currency

Group membership is what people look at. ACLs are where the quiet paths live, because they are set by tools, migrations, and admins who delegated one thing once.

The patterns worth burning into memory:

• GenericAll / GenericWrite over a user → set that user's password, add a credential, or (see below) swap their key. Full account takeover, no cracking.
• GenericWrite over a group you are not in → add yourself, inherit whatever the group grants.
• WriteDACL / WriteOwner over an object → grant yourself the edge you wanted, then take it.
• GenericAll over a computer object → RBCD, as above.

Shadow Credentials (msDS-KeyCredentialLink)

The modern replacement for "reset the password and you own the account". Whoever controls msDS-KeyCredentialLink on an account can write a certificate-based credential into it — and then authenticate as that account with a certificate instead of a password. No password change, no lockout, no "why did helpdesk reset DA at 3 a.m." signal.

Whisker-style tooling does this in one command against the account you already have write access to. This is exactly the technique behind the Keycred tool pointer I wrote up earlier on the blog — same edge, from the tool side.

Blue side: 5136 (directory object modified) on msDS-KeyCredentialLink for accounts that never touch smartcards.

DCSync rights

The most valuable single edge in the domain: the right to replicate. An account with Replicating Directory Changes All on the domain object can pull password hashes for every account in the domain — including the krbtgt hash — using the replication protocol itself, with no logon event on any DC.

This is the one I check on the domain object ACL in every assessment:

```bash

BloodHound marks it; raw view:

Get-DomainObjectAcl -Identity "DC=domain,DC=local" -ResolveGUIDs | Where-Object { $_.ActiveDirectoryRights -match "Replicating|GenericAll|GenericWrite" } ```

Any non-DC account holding replication rights is either a misconfiguration or the wreckage of an old attack. Both are findings.

Blue side: 4662 with replication GUIDs coming from a source that is not a domain controller.

Trusts — edges that cross the border

A second domain in the picture changes the graph, and people trust (literally) trust relationships more than they should.

• Parent/child in the same forest — the default. Enterprise Admins live at the root; compromising a child domain administrator is usually not the end of the story, because forest-wide groups reach back down.
• External trusts — another forest, one-way or two-way. SID history and selective authentication decide whether a compromise walks across.
• Forest trusts with SID filtering — the control that exists precisely because SID history was being abused for cross-forest privilege escalation.

What I actually check: Get-TrustRelationship / nltest /domain_trusts, which side is trusted, and whether authentication flows toward the domain I just pwned or away from it. The direction decides whether the edge is traversable in my direction — a one-way trust pointing the wrong way is a door that only opens one way, and knowing which way saves an hour of confused shell time.

The payouts: DCSync, golden and silver tickets

Once the hashes are out, the tickets follow:

• DCSync gets you the krbtgt hash → forge a golden ticket: TGT minted by you, valid until krbtgt is rotated — and a single rotation does not kill it, because krbtgt has to be reset twice before every existing forged TGT stops validating. That is why the double rotation, spaced out, is the documented recovery and not paranoia.
• A silver ticket is the smaller cousin: forge a TGS with a service account's hash, no DC involvement, and it lives until that password changes. Lower blast radius, much quieter.

I am deliberately not writing the forge commands here. They are two lines in every cheatsheet linked at the bottom, and the interesting part of both tickets is knowing when they apply — not the syntax.

Lateral movement — short notes

• Pass-the-hash still works wherever NTLM is accepted, which is everywhere. The edge is local admin on one box + NTLM hash of a user who has local admin on another.
• RDP with NLA forces a real authentication, so a bare NTLM hash stops at the door — you need a TGT (pass-the-ticket), cleartext from somewhere (a cracked kerberoast, DPAPI, LSASS), or a path that does not require an interactive session at all.
• WinRM / evil-winrm is usually the friendliest shell once you have credentials; SMB exec leaves more artifacts than people assume.
• Local admin ≠ domain compromise, and forgetting that is how assessments over-report. The question is always: what does this box's session material unlock next?

Putting it together: how a medium becomes Domain Admin

A typical chain, no single step being impressive on its own:

1. GPO/startup script review → a share writable by a group you belong to (medium finding on paper).
2. Writable share → local admin on the jump server.
3. Kerberoast from there → a service account with a weak password that is local admin on the SQL box.
4. SQL box has unconstrained delegation → coerce a Tier-1 login → TGT in memory.
5. That account has Replicating Directory Changes All because a migration left it there (low, years old, never remediated).

Each edge alone is a ticket. Together they are a graph, and this is exactly why report-writing advice says to rate findings in context — a chain of three mediums with a DA payout is not three mediums.

What I keep open while working

A short honest list of what made these techniques click for me:

• Learn the event IDs next to the technique. 4768, 4769, 4662, 5136 — once you know what each attack costs in logs, you understand both the technique and the detection in one pass.
• Enumerate edges, not just objects. A user list is not a graph. ACLs, delegation attributes and group nesting are the graph.
• Every technique has a precondition. Write it down before the tool name. Kerberoasting: any valid user. RBCD: write ACL + computer account. DCSync: replication rights. Half of "why did this not work" is a missing precondition.

Further reading and cheatsheets

Everything here was live when I checked it (2026-10-06):

• HackTricks — Active Directory Methodology — the closest thing to a single-page map of every path above; my default tab during an engagement.
• ADSecurity (adsecurity.org) — long-form posts on delegation, Kerberos and credential theft; the deep explanations when the cheatsheet is not enough.
• ired.team — sharp, practical notes across AD and Windows internals.
• PayloadsAllTheThings — Active Directory section — payload and technique inventory, useful when you want the raw material.
• MITRE ATT&CK — Kerberoasting (T1558.003) and Valid Accounts (T1078) — mapping these to ATT&CK is what makes a report read like an assessment instead of a tool log.
• Microsoft — Kerberos authentication overview — vendor-side truth about the protocol you are abusing.
• Microsoft — Best practices for securing Active Directory — read this after the attack notes, not before; it tells you which edges your own environment is advertising.
• SpecterOps / BloodHound documentation — when you want to go deeper on the graph itself than any write-up gets.
• Altered Security — where the CRTP syllabus material these notes were built from comes from.

---

These are study notes I write for myself first — if something here is outdated or wrong, say so and I will correct it. The contact form works.