Tech Talk: Abusing ESC13 from Linux

Whilst abusing ESC13 in itself is not really a exploit or even misconfiguration, it can still be used to escalate privileges within a domain. At its core, ESC13 revolves around a certificate template that is configured with a specific issuance policy that is linked through an Object Identifier (OID), to an Active Directory group. This setup creates a unique situation where users, upon authenticating with a certificate derived from this template, are treated as if they are members of the linked group – even if they are not apart of it. Now again, this functionality is working as intended, however as you can most likely see already, this could be problematic if for example, Domain/Authenticated Users can enroll into this template and request a certificate that has a linked group to a privileged group within the domain. This will essentially allow that unprivileged user to have membership in that group and perform any actions that that group is allowed.

So, it should be noted again that this mechanism is totally intended and in essence, no exploitation is really done, the only thing here that’s being done is leveraging an intended feature of ADCS to meet organisational needs for dynamic access control. However, as with other ESC based exploits it is possible to potentially detect unusual activity by monitoring certificate enrollment and authentication events.

For this demonstration, Ludus was used to quickly spin up an ADCS lab that already has a pre-configured ESC13 template setup.

To begin, there is currently a Pull Request for the popular tool Certipy which adds support for finding templates which are misconfigured to allow ESC13. Pulling this fork from GitHub and installing it will allow us to enumerate ADCS and potentially find any templates where we can abuse this technique. Using Certipy as normal to find templates, we can see that there is one that is ESC13:

As the output above shows, we can see it found 1 OID linked to a template, this is what was mentioned briefly earlier and is a sign of ESC13!

Now there are a few pre-requisites for this to work, our principal must have enrolment rights on the certificate template, the certificate must have an issuance policy extension, also the issuance policy has to have an OID group link to a group within AD, also it has to be a universal group and the group must be empty (no members apart of the group). This is because OID mapped groups cannot have members, so in essence, it will always be empty since AD will not allow people to be added to this group once the msDS-OIDToGroupLink attribute has been set. Finally, the certificate template must define EKUs that enable client authentication.

Now, after clearly seeing from the above figure that we meet all the pre-requisites, we know that it is possible for us to enrol a certificate that allows us to obtain access as a member of the group specified in the OID group link. So, after checking this linked "esc13group" group in Bloodhound, we can also see it is a member of Enterprise Admins:

This is just an example of how this could be misconfigured. For this demonstration, the esc13group was added as a member of the Enterprise Admins group but in reality, it could be anything whether that is a privileged group or not.

So, now what we can do here is we can enrol into this template and request a certificate. We can pass this certificate to request a valid TGT, we are now essentially placed into the ESC13 group. Since it is a part of the Enterprise Admins group, we now have full control over the domain.

With this pfx now obtained, we can use gettgtpkinit.py to authenticate with the pfx and obtain ourselves a valid TGT.

Now we have a valid TGT, we can use this to request kerberos service tickets and abuse any permissions that the ESC13Group has been granted in the domain, whilst not actually being a member of this group. Since we know the ESC13Group is a member of Enterprise Admins, we can simply authenticate to the domain controller with this ticket and execute a command:

As seen above, it shows us (admin) but it also executes our command to list our groups, which show Enterprise Admins as well as the esc13group.

So, where is this actually used in real environments you may be thinking? Well, good question, as it states in the blog post from Jonas Bülow Knudsen who discovered this attack vector, this ADCS feature is used under the Microsoft's Authentication Mechanism Assurance (AMA) concept, to improve security via certificate-based authentication. This approach is aimed at protecting resources by granting access permissions exclusively to empty groups on the resources. Users are then required to authenticate using specific certificates linked to these groups to gain access, ensuring that only authorised individuals with the appropriate certificates can access designated resources or execute certain actions.

Summing up

In summary, it's important to examine and adjust your access control settings. Only the appropriate individuals that an organisation plans to recognise as members of specific groups should be given enrollment rights. For a deeper dive into this technique, the blog post above is a great resource to fully understand this technique.