Directory - structure that stores information on objects on a network

Active Directory - Microsoft’s directory service for Windows networks

forest

Forests/domains work like child and parent relationships. Child domains are fully trusted by parents.

One way - unidirectional - Resource forest can access resources in Organizational Forest

Two way - bidirectional - Organizational and resource forests can access each other’s resources -transitive trust extends trust relationships with other forests -non-transitive trust denies relationships with other forests

What is an AD? central database with services that manages who and what exists on a corporate network

Purpose? Have a centralized management to push out policies to manage machines and their control/access on a network; Mass scale instead of configuring each computer

What does it do? holds every identity and their permissions/hashes + authenticates via Kerberos then authorizes what a user can access and modify via permissions

How? Organized into domains/forests via management boundaries (trust relationships - multiple domains that trust each other are connected via trust relationships; users in 1 domain can access resources in another)

Why is AD a large target? Compromise AD (specific account) > get admin access and privileges > able to control every each system the compromised user owns

Using attack paths: Kerboroasting and DCSync exploit boundaries (permission relationships)

ex. Attack chain: recon → Kerberoasting → DCSync → domain dominance

Attacker’s thought process: IF a child isn’t a fully isolated security boundary THEN compromise the child (via Kerberoasting a service account/ExtraSids/SID-history techniques)

Attacker’s intent: Not a contained blast radius, but get all forest-wide privileges; can become the Queen of the forest

Where to exploit: Boundary gaps = trust relationships that are overly broad (ex. Misconfigured SID filtering) that make a bridge between both forests into organizations’ AD environments

Kerberos = used for authentication

  1. VIP Badge a) Client logs in > client’s machine sends an AS-REQ (request) to domain controller

    ai) Domain controller (DC) = database of passwords

    aii) Checks client’s identity

    b) Client receives a TGT (ticket-granting ticket) = acts as proof of identity

    bi) Encrypted with key from krbtgt (account Kerberos uses to run) account’s hash

    c) Client is not required to look at their password again for the current session

  2. Backstage Pass

    a) User wants to reach a specific service (SQL server, app with a Service Principle Name (SPN))

    b) Client gives TGT to DC as a TGS-REQ (request)

    c) Client receives a TGS (service ticket)

    ci) TGS is encrypted with the service account’s hash, not the DC = an attacker’s entry point; doesn’t check if client is authorized to use the service

  3. Client shows the TGS to the service > client has access to the service now

TGS is encrypted for the service, not the attacker meaning an attack workflow looks like:

  1. enumerate accounts with SPNs set (any domain user can query this via LDAP - Lightweight Directory Access Protocol to verify user identities) > request TGS tickets for each one

  2. attacker has encrypted ciphertext

  3. crack hash offline (using Impacket’s GetUserSPNs.py for enumeration and ticket requests, Rubeus for the same on Windows, and Hashcat (mode 13100) for the offline crack)

No admin rights needed to get ciphertext or crack it

No privileged access required to enumerate > can query every SPN in the domain

Makes an attacker undetectable because they do not have to interact with the target service/no sign of multiple failed login attempts = looks like normal Kerberos traffic

Has to catch it before client receives a TGS by…drumroll please 🥁

Looks through each account with an SPN configured and flags the ones an attacker would go after first — RC4-only encryption types, passwords older than your rotation policy, and service accounts sitting in privileged groups

Looks for: LDAP bind (via impacket’s ldap3/impacket.ldap) to enumerate accounts with SPNs set

Assigns: Pull msDS-SupportedEncryptionTypes then flags RC4-only (0x4) or unset (defaults to RC4/DES on older configs) as weak

Cross-reference flagged accounts against BloodHound’s node list to see which have graph paths to sensitive assets

Produces: list of roastable (can crack offline) SPNs + risk annotation

kerbo

normal traffic: DC replicates directory data to each other; sync every change to users, groups, and password hashes across every DC in the domain

How to manipulate this pattern: DCSync makes one compromised principal look like a DC asking for a routine sync

  1. when replicating runs over DRSUAPI (Directory Replication Service Remote Protocol) protocol and the permission check to request a replication sync (GetChanges + GetChangesAll)

  2. Attacker sends DRSGetNCChanges request > target DC thinks it’s responding to as it to a real DC > DC sends requested directory data (including password hashes for any account and krbtgt)

Note: krbtgt gets rotated twice, not once after a confirmed DCSync — AD keeps the previous password valid briefly > Rotating once still leaves a window where old Golden Tickets forged with the prior hash work

Problem: assumption that only real DCs ask for replication data

DCSync abuse looks like: over-permissioned service accounts, misconfigured delegated permissions within nested groups with GetChanges + GetChangesAll privileges ; No one is tracking ACL (Access control list - access rights based on your role) inheritance

Undetectable: simple network request with no DC access required and mimics normal DC traffic requests

Fix: Bloodhound – maps every principal, permission, and group nesting in the domain – checks which accounts currently hold DCSync rights

BloodHound treats AD as a graph instead of a list

path

Node – every user, group, computer, and GPO (Group Policy Object - set of rules for computers’ and users’ behavior on a network)

ex. svc-webapp01, HELPDESK-L1, WEB-SRV03, Domain Admins

Directed edge – every relationship between them (group membership, admin rights, active sessions, ACL permissions like the GetChangesAll edge)

Attacker’s intent: Start out as low-privilege user > hop routes through a forgotten server sessions to become Domain Admin by answering this question: Is there a path from this node to that one and which one is the shortest/least amount of hops? Attackers only need to find one path. Defenders have to find and close all of them. Tiring to do manually, so time to automate the process:

bloodhound_client/ – BloodHound query automation: Python script queries BloodHound API for top 10 most dangerous attack paths in the domain

  1. Run a fixed set of Cypher queries: shortest paths to Domain Admins, high-value target exposure, Kerberoastable accounts with paths, ACL abuse chains
  2. Rank by a simple severity score (path length, privilege of target, number of tier-0 assets touched)
  3. Output: top 10 paths as structured JSON

bloodhound

2 hops needed for bob to become domain admin ; weakness: GenericAll

Mapping the attack chain to Event IDs

Every stage of an attack chain leaves a loggable signature:

Event ID 4768 — TGT request – Generated every time any user authenticates

Suspicious when: spike of 4768s from a single account in a short window

Attacker’s intent: Send requests to get service tickets

Event ID 4769 — TGS request – Generated every time a service ticket is issued

Suspicious when: Ticket Encryption Type field contains a value of 0x17 (Outdated RC4-encrypted 4769s against multiple SPNs from one account environment) + dozens of TGS requests against dozens of different SPNs in seconds

Event ID 4662 — DCSync’s real signature - watching for the GUIDs behind GetChanges + GetChangesAll

Suspicious when: fires with specific GUIDs and the account requesting it isn’t a domain controller

Note: Object access auditing (needed to generate 4662 events at all) requires a SACL (System Access Control List - logs the success or failure when someone tries to access/modify/delete a specific file or registry key) to be configured on the domain root for the specific replication rights — most orgs never set this up >>> DCSync is invisible to them even with logging otherwise “enabled.”

Event IDs 4624 / 4625 — logon success / failure

Suspicious when: A DCSync-flagged account + anomalous interactive logon/service account that’s never logged in confirms an attacker is compromising a DC

Fix: Sigma rules and SIEM queries

SigmaHQ repository maintains community rules for most of this — Kerberoasting detections built around 4769 + RC4 encryption type + request volume thresholds, and DCSync detections watching 4662 for the specific replication GUIDs against non-DC accounts

Practical move: Pull existing rule > adjust threshold to environment’s baseline > deploy

Looks like: Splunk SPL, Sentinel KQL, or Elastic EQL via the sigma-cli converter

Event log correlation engine: parse Windows events 4624/4625/4768/4769 and correlate with BloodHound paths to detect active exploitation

parser

TGS request and DCSync’s real signature found

Prevention beats detection when dealing with these attack paths. BloodHound’s real value isn’t catching an attack in progress — it’s finding and fixing the path before anyone can use their stolen access.

Steps: BloodHound → Python analyzer → Claude narrator → hardening output

attck_path

Used Docker to run BloodHound’s three components (Postgres, Neo4j, the app itself) in pre-wired containers so they do not have to be installed and configured each one by hand. BloodHound maps every user, group, and permission in an Active Directory domain as a graph, then lets you query that graph to find real (often accidental) privilege-escalation paths. BloodHound identifies which accounts sit on a dangerous path, while the log correlator answers the follow-up question BloodHound can’t: is anyone actually walking that path right now?

Weak misconfigurations put in test fixtures:

1. Excessive delegated permission (the ACL misconfiguration)

User bob was given GenericAll rights over helpdesk_svc.

GenericAll - “full control” over that object — bob can reset helpdesk_svc’s password without ever needing to know it. This permission can be granted for a legitimate reason (some IT process) and then never get cleaned up.

2. Dangerous group membership (the privilege escalation)

helpdesk_svc was a member of Domain Admins

control over helpdesk_svc → control of Domain Admins → control of the entire domain

Neither #1 and #2 is catastrophic alone; the combination is the attack path

3. Weak Kerberos encryption (the Kerberoasting exposure)

helpdesk_svc’s msDS-SupportedEncryptionTypes was set to 4 (RC4-only)

Helpdesk_svc has an SPN – any authenticated domain user can request a service ticket for it and crack it offline — RC4 is fast to brute-force, unlike AES

4. Replication rights granted to a non-DC principal (the DCSync misconfiguration)

helpdesk_svc was explicitly granted DS-Replication-Get-Changes and DS-Replication-Get-Changes-All on the domain root — rights that should only belong to actual Domain Controllers

helpdesk_svc can impersonate a DC and pull password hashes for any account, including krbtgt

AI attack path narrator: Claude reads BloodHound JSON and writes a plain-English executive brief on each path

hardening

Confirmed evidence + risk of admin accounts being exposed if left unaddressed + list of steps to remediate threat

If you’d like to play around please clone my repo

git clone https://github.com/cybersecbella/AD-attck.git

Common trait attack techniques have - does not look like malware

There’s no payload to sandbox, no suspicious binary to flag, no exploit signature to match. A Kerberoasting request is a standard TGS-REQ. A DCSync call is a standard replication request. The account walking the BloodHound path to Domain Admin is, as far as the network is concerned, just an authenticated user doing authenticated-user things. EDR tools are built to catch abnormal code execution and network behavior. The attacker isn’t breaking in; they’re logging in, and then asking the directory questions it’s designed to answer.

Key takeaways