Assumed breach to Domain Admin, in a day.

#Why we start already inside

The perimeter is not where modern intrusions are decided. Phishing, a stolen VPN credential, a contractor's unmanaged laptop, or an exposed service will eventually put someone on the inside; the interesting question is what happens next. So a network assessment usually skips the theatre of getting in and starts from the position that matters: assumed breach, a single low-privileged account or host, the same footing an attacker holds after one successful click.

From that footing, the internal network looks nothing like the hardened edge. It is flat, chatty, and full of relationships nobody drew on purpose. What follows is the path we walk most often, stage by stage, and, more importantly, the specific place in your estate where the walk turns into a dead end.

#Step 1: read the map before you move

The first thing a competent operator does is not attack anything. It is to enumerate. Active Directory is a graph of principals, permissions, group memberships, sessions, and delegation, and most of that graph is readable by any authenticated user. BloodHound turns that readable graph into attack paths: it collects the data with a collector such as SharpHound and then answers questions like “what is the shortest path from the account I control to Domain Admin?”

# collect the directory as the low-priv user we already have
netexec ldap dc01.corp.local -u alice -p '<pass>' --bloodhound --collection All

# then, in BloodHound, ask the only question that matters:
#   "Shortest paths to Domain Admins from owned principals"
ALICE@CORP.LOCAL  -[MemberOf]->  HELPDESK
HELPDESK        -[GenericAll]->  SVC_BACKUP       # an ACL nobody remembers granting
SVC_BACKUP      -[MemberOf]->  SERVER OPERATORS
SERVER OPERATORS-[reachable]->  DC01              # three hops to a domain controller

That output is the whole engagement in miniature. The attacker does not need to compromise everything; they need one path, and the graph hands it to them. Defenders, meanwhile, almost never see their own directory this way, which is how a three-hop route to a domain controller survives for years.

#Step 2: harvest credentials without touching a password

With the map in hand, the operator collects material to become other principals. The classic techniques abuse Kerberos itself and need no exploit:

• Kerberoasting. Any domain user can request a service ticket (TGS) for any account that has a Service Principal Name. Part of that ticket is encrypted with the service account's password hash, so it can be taken offline and cracked. Service accounts often have old, human-chosen, never-rotated passwords, which makes this the single highest-yield move on most engagements.
• AS-REP roasting. Accounts with “do not require Kerberos pre-authentication” set will hand out an encrypted blob to an unauthenticated requester. Same offline-cracking idea, even lower barrier.
• Credentials in memory and on disk. Where we already hold local admin on a host, LSASS memory, the SAM, cached logons, and stored credentials give up hashes and sometimes cleartext. This is the noisiest option and the one EDR is most likely to catch, so it is used late, not first.

# request roastable service tickets for every SPN-bearing account
impacket-GetUserSPNs corp.local/alice:'<pass>' -request -outputfile tgs.hash

# crack offline; service accounts love "Winter2024!" and its cousins
hashcat -m 13100 tgs.hash wordlist.txt
$krb5tgs$23$*SVC_SQL*...:Summer2023!          # one weak password, one service account owned

#Step 3: move laterally on what you collected

Cracked passwords and stolen hashes are only useful if they open doors. Active Directory obliges: with a valid hash you rarely need the cleartext at all. Pass-the-hash authenticates with the NT hash directly; pass-the-ticket reuses a Kerberos ticket; overpass-the-hash turns a hash into a fresh ticket. Tooling such as NetExec and Impacket sprays a credential across the estate and reports every host where it grants access.

# where does the SVC_SQL credential let us in?
netexec smb 10.0.0.0/24 -u SVC_SQL -p 'Summer2023!' --local-auth
10.0.0.41  FIN-SQL-01   [+] corp.local\SVC_SQL (Pwn3d!)   # admin on the SQL box
10.0.0.52  FIN-APP-02   [+] corp.local\SVC_SQL (Pwn3d!)   # and re-used here too

The multiplier is credential re-use. One account with local-admin rights re-used across a fleet of machines (a shared local administrator password is the textbook case) turns a single win into estate-wide reach. Each new host is another LSASS to read, another set of cached credentials, another rung up.

#Step 4: escalate to Tier-0

Lateral movement gets you breadth; escalation gets you the crown. The routes we lean on are the ones that abuse trust rather than memory, because they are quiet and reliable:

• Dangerous ACLs. The BloodHound graph from Step 1 usually reveals a principal we can reach that holds GenericAll, GenericWrite, WriteDacl, or ForceChangePassword over a privileged object. Any one of those is a takeover primitive: reset a password, add ourselves to a group, or write an SPN and roast it.
• Kerberos delegation. Unconstrained, constrained, and resource-based constrained delegation each, when misconfigured, let a controlled account impersonate others to sensitive services.
• NTLM relay and coercion. Techniques such as PetitPotam coerce a privileged machine (even a domain controller) into authenticating to us; that authentication is then relayed to a service that accepts it. Relayed to Active Directory Certificate Services, it yields a certificate for the coerced machine and a direct route to domain compromise.
• AD CS misconfiguration. The certificate-template attacks (ESC1 through ESC11) are so often present that they deserve their own treatment.

#Step 5: DCSync and domain dominance

Once the operator controls an account with directory-replication rights (a Domain Admin, or anything holding the Replicating Directory Changes permissions), the endgame is DCSync: impersonating a domain controller to ask a real one for the password hashes of every account, including the krbtgt account whose hash signs every Kerberos ticket in the domain.

# ask a DC to replicate secrets to us, as if we were another DC
impacket-secretsdump corp.local/da_account@dc01.corp.local -just-dc-user krbtgt
krbtgt:502:aad3b...:<the key that signs every ticket>
# with the krbtgt hash, an attacker can forge Golden Tickets at will

With the krbtgt hash an attacker can forge Golden Tickets, valid Kerberos tickets for any user, any group, on demand, that survive password resets. At that point the domain is not merely compromised; it is owned, and evicting the attacker requires a painful double-reset of the krbtgt account. This is why the whole exercise is about preventing the walk, not detecting its final step.

#Where to break the chain

The good news hiding in all of this: the chain has many links, and the defender only has to cut one that the attacker cannot route around. In order of leverage:

The highest-leverage cut is almost always the tiered administration model: Domain Admins never log on to workstations, so their credentials never land in a memory an attacker can read. Get that right and the most common lateral-to-escalation bridge simply is not there to cross.

#What defenders should be watching

Each stage leaves a signal, if the logs are collected and someone is looking:

• 4769  A spike of Kerberos service-ticket requests, especially with RC4 encryption, is the Kerberoasting tell.
• 4768  TGT requests for AS-REP-roastable accounts, and later, tickets bearing certificate info (the AD CS path).
• 4662  Directory-replication access from anything that is not a domain controller is the DCSync alarm, and it should be a loud one.
• SharpHound-style LDAP enumeration, mass SMB authentication from one source, and new group memberships on privileged groups are all worth an alert.

#What this engagement is, and isn't

• It is not a vulnerability scan. Nothing above shows up as a red CVE. The findings are relationships and configurations, which is why they need an operator, not a tool, to surface.
• It is not destructive. We prove one path to Tier-0 and stop; we do not forge Golden Tickets against production or touch data. The deliverable is the map and the single cheapest cut, not a smoking crater.
• It is bounded and repeatable. The output is a prioritised list of the links in your chain, each with the config or architecture change that removes it, so remediation is a checklist and a retest, not a mystery.