Introduction

Pass-the-Certificate is a highly effective post-exploitation technique that leverages X.509 certificates instead of traditional passwords or NTLM hashes for authentication within an Active Directory environment. This technique exploits the PKINIT (Public Key Cryptography for Initial Authentication) extension of the Kerberos protocol, allowing attackers to obtain a Ticket-Granting Ticket (TGT) using a stolen or forged certificate.

In this article, we will demonstrate how an attacker, armed with a PFX certificate file (administrator.pfx) can leverage multiple tools to achieve remote command execution and interactive shell access on domain-joined machines.

Table of Contents

Introduction

Prerequisites

• Lab Environment
• Tools Required
• Kerberos Configuration

Pass the Certificate (PFX File)

• Technique 1: NetExec SMB with PFX Certificate
• Technique 2: NetExec WMI with PFX Certificate
• Technique 3: NetExec WinRM with PFX Certificate
• Technique 4: NetExec MSSQL with PFX Certificate

Tools Comparison Matrix

Detection and Defensive Recommendations

• Detection Opportunities
• Defensive Recommendations

Conclusion

The attack chain we cover in this article involves two primary authentication methods:

• PFX Certificate Authentication: Directly using a .pfx certificate file with tools like NetExec (nxc) to execute commands over SMB, WMI, WinRM, and MSSQL protocols.

This guide assumes the attacker has already obtained the administrator.pfx certificate through a prior AD CS exploitation (such as ESC1-ESC16 template misconfigurations)

Before proceeding with the techniques demonstrated in this article, ensure the following requirements are met:

Lab Environment

Kerberos Configuration

For Kerberos-based authentication using CCACHE files, the /etc/krb5.conf file on the Kali Linux attacker machine must be properly configured. This file defines the Kerberos realm, the Key Distribution Center (KDC), and the domain-to-realm mapping.

The configuration above establishes the following:

• default_realm = IGNITE.LOCAL: Sets the default Kerberos realm to IGNITE.LOCAL (must be uppercase).
• kdc = DC.ignite.local: Specifies the Domain Controller as the Key Distribution Center.
• admin_server = DC.ignite.local: Points to the administrative Kerberos server.
• domain_realm mappings: Maps both .ignite.local and ignite.local to the IGNITE.LOCAL realm.

Additionally, ensure the /etc/hosts file contains the following entry:

192.168.1.11    DC.ignite.local    dc.ignite.local

Pass the Certificate (PFX File)

In this section, we demonstrate how to use the administrator.pfx certificate file directly with NetExec (nxc) to execute commands across multiple protocols without requiring a password or NTLM hash. NetExec supports certificate-based authentication over SMB, WMI, WinRM, and MSSQL.

Technique 1: NetExec SMB with PFX Certificate

The first technique demonstrates command execution over the SMB protocol (port 445) using the PFX certificate. NetExec authenticates to the Domain Controller using the certificate and executes the ipconfig command via the default wmiexec execution method.

nxc smb 192.168.1.11 --pfx-cert administrator.pfx -u administrator -x ipconfig

The output confirms successful authentication with the administrator account’s NTLM hash (32196b56ffe6f45e294117b91a83bf38) and command execution via wmiexec. The ipconfig output reveals the Domain Controller’s network configuration: IP 192.168.1.11, Subnet 255.255.255.0, and Gateway 192.168.1.1.

Technique 2: NetExec WMI with PFX Certificate

The second technique uses the WMI protocol (port 135/RPC) for remote command execution. WMI-based execution is generally stealthier than SMB as it does not create a service on the remote host.

nxc wmi 192.168.1.11 --pfx-cert administrator.pfx -u administrator -x whoami

The output shows a successful authentication over RPC (port 135) with the Pwn3d! flag, confirming administrative privileges. The whoami command returns ignite\administrator, verifying that command execution is running under the domain administrator context. The execution method used is wmiexec.

Technique 3: NetExec WinRM with PFX Certificate

The third technique leverages the WinRM protocol (port 5985) for remote command execution. WinRM (Windows Remote Management) is a Microsoft implementation of the WS-Management protocol, commonly used for legitimate remote administration. This makes WinRM-based attacks particularly difficult to detect as they blend with normal administrative traffic.

nxc winrm 192.168.1.11 --pfx-cert administrator.pfx -u administrator -x "systeminfo" --kdcHost 192.168.1.11

The systeminfo output reveals comprehensive details about the Domain Controller: Windows Server 2019 Standard Evaluation (Build 17763), configured as a Primary Domain Controller, running on VMware with 2 processors, 2047 MB RAM, timezone UTC+05:30, and three installed hotfixes (KB4514366, KB4512577, KB4512578).

Technique 4: NetExec MSSQL with PFX Certificate

The fourth technique demonstrates command execution through the MSSQL protocol (port 1433) on a member server (WIN-SQL at 192.168.1.13). This is significant because it shows that a single domain administrator certificate can be used to execute commands not only on the Domain Controller but also on any domain-joined machine running accessible services.

nxc mssql 192.168.1.13 --pfx-cert administrator.pfx -u administrator -x "systeminfo"

The command executed via mssqlexec reveals that WIN-SQL is a separate Member Server (not a Domain Controller) with 8191 MB RAM, running on VMware, joined to the ignite.local domain. The execution method is mssqlexec, which leverages the xp_cmdshell stored procedure for OS command execution through the SQL Server instance.

Tools Comparison Matrix

The following table provides a comprehensive comparison of all nine techniques demonstrated in this article:

Detection and Defensive Recommendations

Detection Opportunities

• Event ID 4768: A Kerberos TGT was requested. Monitor for PKINIT pre-authentication (certificate-based) from unusual source IPs or non-Windows hosts.
• Event ID 4769: A Kerberos service ticket was requested. Correlate with 4768 for pass-the-ticket chains.
• Event ID 4672: Special privileges assigned to new logon. Alerts when administrative tokens are issued.
• Event ID 7045: A new service was installed. Detects PsExec-style service creation (randomly named services).
• Event ID 4688: Process creation. Monitor for cmd.exe/powershell.exe spawned by wmiprvse.exe (WMI) or wsmprovhost.exe (WinRM).
• Event ID 4698: A scheduled task was created. Detects AtExec-style task scheduler abuse.

Defensive Recommendations

• Audit AD CS Templates: Regularly review certificate templates for dangerous configurations (ESC1-ESC16). Remove unnecessary enrollment permissions.
• Monitor Certificate Issuance: Enable audit logging on the Certificate Authority. Track all certificate requests and issuances, especially for privileged accounts.
• Implement Tiered Administration: Restrict administrative accounts to specific tiers. Domain Admin certificates should only be usable from Privileged Access Workstations (PAWs).
• Enable PKINIT Freshness Extension: Windows Server 2016+ supports freshness tokens that make stolen certificates harder to replay.
• Rotate Certificates: Implement short certificate lifetimes and automated renewal processes.
• Network Segmentation: Restrict WinRM (5985/5986), SMB (445), WMI/RPC (135), and MSSQL (1433) access to only authorized administrative workstations.
• Deploy EDR: Modern EDR solutions can detect Impacket tool signatures, service creation patterns, and anomalous WMI/WinRM usage.

Conclusion

These attack paths are entirely preventable through proper AD CS configuration, certificate lifecycle management, tiered administration, and robust monitoring. Organizations should prioritize regular audits of certificate templates and implement comprehensive logging for all Kerberos authentication events.