Lutra Security<p>Active Directory Certificate Services (AD CS) is Microsoft's way to establish and manage a public key infrastructure in Active Directory. It can be used to manage certificate templates, issue certificates or revoke them. And because those certificates can be used for client authentication, AD CS is a very appealing target for attackers.</p><p>We have already looked at the escalation primitive "ESC1" before (<a href="https://infosec.exchange/@lutrasecurity/112399051244845571" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">infosec.exchange/@lutrasecurit</span><span class="invisible">y/112399051244845571</span></a>). Today we will have a look at ESC4. Just like ESC1, an attacker can abuse this misconfiguration to escalate their privileges from a regular domain user to Domain Admin. </p><p>This time, the misconfiguration is that a regular domain user can modify a certificate template. This means, that an attacker can simply modify the template and configure it to be vulnerable to ESC1. Then, the attacker can easily exploit the ESC1 misconfiguration they added and escalate their privileges.</p><p>The tool "Certify" can be used to identify and perform almost all AD CS attacks. In case of ESC4, an attacker only needs to change the certificate template to allow the enrollee to supply a subject (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT). Then, an attacker can request a certificate using the modified template and provide the username that they want to impersonate as an argument. That’s it. They can now impersonate the user and take over the entire domain.</p><p>So how can you detect and defend against it?</p><p>First and foremost: CA servers are Tier 0 assets. This means that they are as important as your Domain Controller and should be hardened as such. To fix the misconfiguration, you need to review the permissions for the certificate template in question. For this, open “Certificate Authority”, right-click on “Certificate Templates” and choose “Manage”. There you can view the “Security” tab within the properties and manage the permissions (see screenshot). In this case, remove the dangerous permissions of the Domain Users group (Full Control, Write). </p><p>For detection, monitor requests (EID 4886) and issuing (EID 4887) of certificates as well as the modification of CA settings, such as certificate template modifications. And of course: Search for these types of misconfigurations to find them before the real attackers do.</p><p><a href="https://infosec.exchange/tags/itsecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>itsecurity</span></a> <a href="https://infosec.exchange/tags/adcs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>adcs</span></a> <a href="https://infosec.exchange/tags/esc4" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>esc4</span></a> <a href="https://infosec.exchange/tags/ttp" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ttp</span></a> <a href="https://infosec.exchange/tags/mitre" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>mitre</span></a> <a href="https://infosec.exchange/tags/redteam" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>redteam</span></a> <a href="https://infosec.exchange/tags/redteaming" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>redteaming</span></a> <a href="https://infosec.exchange/tags/TechTuesday" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>TechTuesday</span></a></p>