ADScanPro/Claude-AD

# ACL Abuse

Active Directory permissions are a graph. A single misconfigured Access Control Entry (ACE), say a low-priv user with `GenericAll` over a group, `WriteDacl` over a computer, or `WriteOwner` over an OU, is a directed edge you can walk from where you are toward Domain Admin. This skill turns those edges into concrete commands with **bloodyAD** and **impacket**, after **BloodHound CE** (Apache-2.0, genuinely open source) has drawn the path.

**Find the paths first (BloodHound CE).** Collect with a standard collector, import into BloodHound CE, and look at the outbound control edges from your owned principal: `GenericAll`, `GenericWrite`, `WriteDacl`, `Owns`/`WriteOwner`, `AddMember`, `ForceChangePassword`, `AllExtendedRights`, and `DCSync`. Pre-built queries like "Shortest paths from Owned principals" and "Find principals with DCSync rights" hand you the chain.

Collect edges with a standard collector, for example:
```
nxc ldap 10.0.0.10 -u user -p 'Password123' --bloodhound --collection All --dns-server 10.0.0.10
```
or run `rusthound-ce` / SharpHound CE and import the ZIP into BloodHound CE.

---

# AD Environment Constraints

Code and commands that work in a lab break in a hardened domain, and the failure almost
never says what it is. A Kerberos SPN mismatch surfaces as `invalidCredentials`. NTLM
being disabled surfaces as a logon failure. AES-only KDCs reject your RC4 request with an
etype error you have to know to read. This skill is the checklist of those constraints and
how to survive each one with standard tooling.

**Detect the posture before you authenticate.** Every constraint below is detectable up
front: probe whether NTLM answers, whether the KDC accepts RC4, whether LDAP signing is
required, whether LDAPS is listening. Fingerprint first, then choose your auth path to
match. Fixing an auth path reactively after each failure is slower and noisier than
reading the environment once and picking the right transport from the start.

# AD Pentest Methodology: Phase Order

A domain assessment is not a bag of tricks you run in random order. The order is the
craft. Enumeration feeds exploitation; a credential harvested cheaply saves you a spray
that locks accounts; a graph collected once tells you which of a hundred possible attacks
actually reaches Domain Admin. Run the phases in order and each one narrows the next.

Four phases, in sequence:

1. **Setup**: reachability, name resolution, environment posture, first credentials.
2. **Collection**: topology, trusts, directory objects, hosts, shares. Read, do not touch.
3. **Exploitation**: attack-path discovery, then cheap wins, then spraying, then hunting.
4. **Post-processing**: consolidate loot, re-collect as the owned set grows, report.

# AD OPSEC and Telemetry

Every technique leaves a trace. The goal here is not evasion. It is knowing the noise
profile of each action so you can document it for the client before the engagement, pick
the quieter of two functionally equivalent techniques, and correlate what you did with what
their SOC saw. For a defender, read the same tables backwards: they are the events to
monitor and alert on.

Two rules of engagement throughout:

- **Document the noise.** Tell the client what each high-signal action generated, with the
  event ID and the source IP, so they can find it in their logs.
- **Coordinate the loud ones.** DCSync, mass spraying, coercion at scale, and LSASS dumps
  need explicit client sign-off or an end-of-engagement window when detection no longer

# AD CS Attacks (ESC1–ESC17)

AD CS is the single richest privilege-escalation surface in modern AD. A misconfigured template or CA lets a low-privileged user obtain a certificate that authenticates as a Domain Admin. This skill uses **Certipy** (the `ly4k` project) throughout. You drive it by hand.

The whole thing starts with one enumeration pass. Run it first, read the output, then pick the ESC that applies.

```
certipy find -u user@corp.local -p 'Password123' -dc-ip 10.0.0.10 -vulnerable -stdout
```

Certipy names each finding by its ESC number, so the tool's output tells you which of the below applies. Save the full JSON/BloodHound output for the report:
```
certipy find -u user@corp.local -p 'Password123' -dc-ip 10.0.0.10 -vulnerable -old-bloodhound
```

# Coercion + NTLM Relay

Two techniques that combine into one of the most reliable domain-compromise chains: **force** a target (usually a Domain Controller's machine account) to authenticate to a host you control, then **relay** that authentication to a service that lacks the protection to reject it. No credential cracking involved; you are borrowing a live authentication.

The chain only works when a relay target is unprotected:
- **Relay to LDAP/LDAPS** requires **LDAP signing not enforced** and **channel binding (EPA) absent**.
- **Relay to SMB** requires **SMB signing not enforced** on the destination.
- **Relay to AD CS web enrollment (ESC8)** requires the HTTP enrollment endpoint up **without EPA**.

Check signing posture first:
```
nxc smb 10.0.0.0/24 --gen-relay-list relay_targets.txt        # hosts without SMB signing
nxc ldap 10.0.0.10 -u user -p 'Password123' -M ldap-checker   # LDAP signing / channel binding state
```

# AD Technique → Compliance Control (Conceptual Mapping)

> **Disclaimer, read first.** This is a *conceptual, orientative* mapping. It shows, at a
> high level, which family of controls an AD attack technique relates to, so a practitioner
> can point a finding in the right regulatory direction. **It is not an auditor-defensible
> control matrix.** A defensible mapping (one an auditor accepts, cross-referenced ID by ID
> to the exact control text, scoped to your organization's applicability statement, with
> evidence per control) is a curated product, not something you infer from a technique name.
> ADscan (free and source-available) produces that curated, ID-by-ID matrix as part of its
> report. Use this skill to orient a finding; do not present it to an auditor as compliance
> evidence.

## How to read this

# Kerberos Attacks

Standard-tooling playbook for the four Kerberos abuse families you meet on almost every internal AD engagement. You drive every tool yourself. This skill tells you what each attack is, the exact command, how the loot looks and how to crack it, what the DC logs, and what the remediation write-up should say.

Requirements before you touch these: valid domain credentials (any user is enough for Kerberoasting and delegation reads; AS-REP roasting needs only a username list), correct DNS pointing at the DC, and clock skew under 5 minutes or Kerberos rejects your tickets (`KRB_AP_ERR_SKEW`). Sync with `sudo ntpdate <dc-ip>` or `faketime`.

---

## 1. Kerberoasting

**MITRE ATT&CK:** T1558.003 (Steal or Forge Kerberos Tickets: Kerberoasting)

**What it is.** Any authenticated user can request a service ticket (TGS) for any account that has a Service Principal Name (SPN) set. The TGS is encrypted with the service account's password-derived key. If the DC hands you an RC4 (etype 23) ticket, you crack it offline to recover the account's cleartext password. Service accounts are the target because they often have weak, non-expiring, human-set passwords and elevated rights.