Listen to this Post
Introduction
Active Directory Certificate Services (AD CS) has long been a target for attackers due to misconfigurations that allow privilege escalation. Now, with cloud integration via Microsoft Intune, this attack surface extends beyond on-premises environments. Security researcher Dirk-jan Mollema reveals how Intune-issued certificates can be abused to gain Domain Admin access—even from a low-privileged Intune Administrator or any user with an Intune license.
Learning Objectives
- Understand how Intune PKCS certificate deployment can be weaponized.
- Learn how ESC1 (AD CS exploitation) applies to cloud-managed devices.
- Discover mitigation strategies to prevent certificate-based privilege escalation.
You Should Know
1. How Intune PKCS Certificate Deployment Works
Intune’s PKCS certificate flow allows automatic certificate issuance to enrolled devices. Attackers can abuse this by manipulating certificate templates to grant excessive permissions.
Exploitation Steps:
1. Enumerate Vulnerable Templates (PowerShell):
Get-ADObject -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com" -Filter -Properties | Where-Object { $_.msPKI-Certificate-Name-Flag -match "ENROLLEE_SUPPLIES_SUBJECT" }
This identifies templates allowing user-supplied Subject Alternative Names (SANs), a key requirement for ESC1.
- Request a Certificate via Intune (Using Dirk-jan’s Tool):
– The tool automates the attack by requesting a certificate with elevated privileges.
– Download: https://lnkd.in/eV5j7QfW
2. Exploiting ESC1 via Intune
ESC1 traditionally requires on-prem access, but Intune bridges this gap.
Attack Flow:
- Compromise an Intune Administrator (or any user with an Intune license).
- Deploy a Malicious PKCS Profile via Intune to issue a certificate with `Domain Admin` rights.
3. Authenticate Using the Certificate for lateral movement.
Mitigation Command (Disable Vulnerable Templates):
Set-ADObject -Identity "CN=TemplateName,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com" -Replace @{msPKI-Enrollment-Flag = "0"}
3. Detecting Suspicious Certificate Requests
Monitor Event IDs for anomalous certificate enrollments:
- Event ID 4886 (Certificate Services received a request)
- Event ID 4887 (Certificate issued)
SIEM Query (Splunk):
index=windows EventID=4886 OR EventID=4887 | stats count by Subject, Requester
4. Hardening Intune PKCS Deployments
1. Restrict Template Permissions:
certutil -template -vulnerabilities
2. Enable Certificate Transparency Logs:
certutil -setreg CA\LogLevel 0x00000001
5. Cloud-Specific Countermeasures
- Conditional Access Policies: Require MFA for Intune certificate enrollment.
- Audit Intune Device Compliance: Ensure only trusted devices receive certificates.
What Undercode Say
- Key Takeaway 1: Intune’s integration with AD CS introduces new attack paths—cloud admins must audit certificate templates.
- Key Takeaway 2: Traditional AD CS mitigations (like disabling SAN edits) still apply but require cloud-aware enforcement.
Analysis:
The shift to hybrid AD environments means attackers no longer need on-prem access to exploit AD CS flaws. Organizations must extend certificate governance to Intune-managed devices, treating cloud-based certificate issuance with the same scrutiny as on-prem.
Prediction
As cloud-based certificate deployment grows, expect more ESC1-style attacks via Intune, especially in poorly configured hybrid environments. Future attacks may leverage AI-driven automation to identify and exploit vulnerable templates at scale.
Further Reading:
- Full Blog: https://lnkd.in/ePbNKH7v
- Exploitation Tool: https://lnkd.in/eV5j7QfW
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Dirkjanm Extending – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
