<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>AD CS on LEIKAH</title><link>https://leikah.haoyingcao.xyz/en/docs/active_directory/movement/adcs/</link><description>Recent content in AD CS on LEIKAH</description><generator>Hugo</generator><language>en</language><atom:link href="https://leikah.haoyingcao.xyz/en/docs/active_directory/movement/adcs/index.xml" rel="self" type="application/rss+xml"/><item><title>ESC1 and ESC2</title><link>https://leikah.haoyingcao.xyz/en/docs/active_directory/movement/adcs/esc1_esc2/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://leikah.haoyingcao.xyz/en/docs/active_directory/movement/adcs/esc1_esc2/</guid><description>&lt;p&gt;ESC1 and ESC2 are similar privilege escalation techniques targeting certificate templates with &lt;code&gt;ENROLLEE_SUPPLIES_SUBJECT&lt;/code&gt; flag set and can be used for client authentication. The &lt;code&gt;ENROLLEE_SUPPLIES_SUBJECT&lt;/code&gt; flag means the subject of the certificate issued will be whatever the client supplies in the certificate request. Privilege escalation is then achieved by specifying a high-priv user in the subject name, then use &lt;strong&gt;Pass-the-Certificate&lt;/strong&gt; to authenticate as the target user, obtaining their Kerberos TGT.&lt;/p&gt;
&lt;p&gt;The difference between ESC1 and ESC2 come down to what specific configuration in the certificate template allowed that to happen:&lt;/p&gt;</description></item><item><title>ESC3</title><link>https://leikah.haoyingcao.xyz/en/docs/active_directory/movement/adcs/esc3/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://leikah.haoyingcao.xyz/en/docs/active_directory/movement/adcs/esc3/</guid><description>&lt;p&gt;One of the &lt;strong&gt;Extended Key Usages (EKUs)&lt;/strong&gt; for certificates issued by AD CS is &lt;strong&gt;Certificate Enrollment Agent&lt;/strong&gt;, which allows the holder of the certificate to request certificates for another user as if they are that user. To abuse this for privilege escalation, there needs to be at least two templates matching conditions below:&lt;/p&gt;
&lt;p&gt;Condition 1: A template allows a low-privileged user to enroll in an enrollment agent.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Enrollment rights granted to a user or group for which we have access to.&lt;/li&gt;
&lt;li&gt;Manager approval is disabled.&lt;/li&gt;
&lt;li&gt;No authorized signatures are required.&lt;/li&gt;
&lt;li&gt;Certificate Enrollment Agent or Any Purpose is set as the EKU.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Condition 2: A template permit a low privileged user to use the enrollment agent certificate to request a certificate on behalf of another user that can be used for authentication.&lt;/p&gt;</description></item><item><title>ESC4</title><link>https://leikah.haoyingcao.xyz/en/docs/active_directory/movement/adcs/esc4/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://leikah.haoyingcao.xyz/en/docs/active_directory/movement/adcs/esc4/</guid><description>&lt;p&gt;If a principal controlled by the attacker has the rights to modify a certificate template (&lt;strong&gt;FullControl&lt;/strong&gt;, &lt;strong&gt;WriteOwner&lt;/strong&gt;, &lt;strong&gt;WriteDacl&lt;/strong&gt;, or &lt;strong&gt;WriteProperty&lt;/strong&gt;), the attacker can modify the certificate template to one that is vulnerable to ESC1 or ESC2, that is one with &lt;strong&gt;Client Authentication&lt;/strong&gt; or &lt;strong&gt;Any Purpose&lt;/strong&gt; listed under its EKU and with the &lt;code&gt;ENROLLEE_SUPPLIES_SUBJECT&lt;/code&gt; flag set.&lt;/p&gt;
&lt;h2 id="linux-perspective"&gt;Linux Perspective&lt;a class="td-heading-self-link" href="#linux-perspective" aria-label="Heading self-link"&gt;&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;&lt;code&gt;Certipy&lt;/code&gt; includes the functionality to automatically configure a certificate template to one that is vulnerable to ESC1 if the user has sufficient rights to do so.&lt;/p&gt;</description></item></channel></rss>