Full Report
Active Directory Certificate Services (ADCS) is used to manage certificates for systems, users, applications, and more in an enterprise environment. Misconfigurations in ADCS can introduce critical vulnerabilities into an enterprise Active Directory environment. The post Detecting ADCS Privilege Escalation appeared first on Black Hills Information Security, Inc..
Analysis Summary
# Tool/Technique: Active Directory Certificate Services Misconfigurations (ESC Family)
## Overview
This summary focuses on detecting and understanding attacks that leverage misconfigurations within Active Directory Certificate Services (ADCS) to achieve privilege escalation within an Active Directory environment. The primary technique discussed is related to **ESC1**, where a low-privileged user obtains a certificate for a privileged account (e.g., Domain Admin).
## Technical Details
- Type: Technique (Leveraging system configuration vulnerabilities)
- Platform: Windows Active Directory / Certificate Services
- Capabilities: Privilege Escalation, Identity Spoofing (via certificate issuance)
- First Seen: References span multiple years, with specific ESC techniques (like ESC1) being documented for several years (e.g., SpecterOps report linked is from 2022, prior blog posts noted).
## MITRE ATT&CK Mapping
The core focus is on privilege escalation via abuse of certificate services.
- **TA0004 - Privilege Escalation**
- T1136.002 - Create Account: Domain Account (If new accounts are created based on the certificate)
- T1648 - Abuse Web Services (Broadly applicable as ADCS is a web service endpoint)
- **TA0005 - Defense Evasion**
- T1550.003 - Use Alternate Authentication Material (Using a forged certificate)
*Note: Specific CVE/ESC numbers map to detailed techniques best described by SpecterOps' "Certified Pre-Owned" framework, often relating to T1550 (Abuse Authentication Material) or T1136 (Create Account).*
## Functionality
### Core Capabilities
- **Certificate Request Abuse (ESC1):** A low-privileged user (e.g., `noprivuserADCS`) requests a certificate intended for a high-privileged user (e.g., `doadmin`) using vulnerable certificate templates.
- **Log Analysis:** Utilization of Microsoft Sentinel and KQL to filter relevant Security Events (4886, 4887) to find instances where the certificate `Requester` and the `UPN` (Subject) do not match.
- **Post-Patch Detection:** Detecting Event IDs 39 or 41, which occur when Windows prevents certificate issuance if the Requestor's SID does not match the Subject's SID (following recent Microsoft patches).
### Advanced Features
- **Automated Exploitation:** Use of tools like `certipy` to automate the process of requesting certificates against vulnerable Certificate Authorities (CAs).
- **Auditing Management:** The technique involves identifying that ADCS auditing is disabled by default and enabling logging (via `certsrv` utility) across various security event IDs (4886, 4887, 4900, 4899).
## Indicators of Compromise
The focus here is on *detection logic* based on event logs, rather than traditional malware IoCs.
- File Hashes: N/A (Focus is on system log events)
- File Names: N/A
- Registry Keys: N/A
- Network Indicators: Usage of internal communication paths to interact with the CA server (e.g., communication with `doazlab-DC01-CA`).
- Behavioral Indicators:
- Security Event ID **4886** (Request for certificate)
- Security Event ID **4887** (Certificate Issued)
- Security Event ID **39** or **41** (SID mismatch error after patching)
- Security Event ID **4900** (Security permissions for a certificate template changed)
- Security Event ID **4899** (Certificate template was updated)
- Detection Logic: `EventID == 4886 or EventID == 4887` where `Requester != UPN`.
## Associated Threat Actors
The article does not explicitly name threat actors currently using this technique, but it references well-known AD penetration testing techniques documented by security researchers (e.g., SpecterOps research referenced in the provided links).
## Detection Methods
Detection is primarily achieved through centralized logging and SIEM correlation (specifically Microsoft Sentinel).
- Signature-based detection: Not directly applicable, as it relies on exploiting default settings vs. running a known malicious binary.
- **Behavioral detection:** Monitoring for ADCS event IDs (4886, 4887) and applying KQL logic to flag discrepancies between the requestor and the certificate subject (UPN/SID).
- YARA rules: N/A
## Mitigation Strategies
- **Prevention Measures:**
1. **Enable ADCS Auditing:** By default, ADCS does not log relevant events. Auditing must be explicitly enabled via CA Properties > Auditing using the `certsrv` utility.
2. **Apply Patches:** Ensure Domain Controllers have security updates applied that enforce certificate authentication changes (checking for SID mapping mismatches, generating Event IDs 39/41 if mapping fails).
3. **Review Template Permissions:** Monitor Event ID 4900 for unauthorized changes to template security permissions. Auditing changes to templates (Event ID 4899) is also critical.
- **Hardening Recommendations:** Enforce strong mapping between the SID of the requestor and the SID of the certificate subject (enforced by recent Microsoft patches).
## Related Tools/Techniques
- ESC2, ESC3, ESC4, ESC8 (Other documented ADCS misconfiguration exploitation techniques).
- `certipy` (Tool used by attackers to automate certificate requests).