ADCS - Privilege Escalation as a Service

In this article, we address the risks of incorrect or incomplete setup of ADCS (Active Directory Certificate Services). Depending on the extent, an attacker can create certificates for any action and authorization, so there is a very high risk here. We will show you the three biggest risk factors, describe two possible attack paths and explain how you can protect yourself against them.

ADCS - Active Directory Certificate Services

Active Directory Certificate Services has existed under this name since Windows Server 2008, previously it was only called Root Certification Authority. Certificate Authority). The ADCS serve the creation of an own public key Infrastructure (PKI for short). Details about ADCS can be found in the corresponding article: Public Key Infrastructure with Active Directory Certificate Services

A comprehensive and structured setup and implementation of the AD certificate services is enormously important for protection against possible hacking attacks.

Risk factors in the configuration of ADCS

Incorrect configuration of the ADCS can have far-reaching consequences. For this reason, some of the most important configuration steps in the creation or adaptation of the certificate templates are described below and the consequences of some options are presented. Since these can be considered individually quite meaningful and necessary, in particular the combination of the settings is relevant thereby.

Applicant name

Two options are available in the Applicant Name tab:

Information is specified in the request: This option is active by default for the "Web server" template, for example. Here it is useful for an authorized administrator to specify the corresponding alternative names of a server in the certificate.

Attention: If this option is selected for user certificates, the applicant can issue a certificate for any user. If the permissions for creation are now still set for all users (see below), a "normal" user can request certificates for the administrator.

Create from this information in Active Directory: When this option is selected, the information used is generated from the AD entries of the user or computer. This is especially useful for users: this prevents values from other users from being used.

How secure is your Active Directory configured?

Our professional hackers will find out for you before malicious hackers do.

To the penetration test

Permissions in ADCS

The Permissions tab corresponds to the familiar layout of permission assignment. Ultimately, this is no different from other permissions and the recommendation to use the usual defaults: "As few permissions as possible".

In particular, you should question the shares for "Authenticated users", since this gives every user in AD this permission. Even read permission should only be granted here if these certificates are relevant for all users, which is rarely the case.

The "Full access" and "Write" permissions should be assigned at most to administrators or corresponding restricted user groups with concrete requirements, since here the contents of the template can be customized as desired.

The criticality of the permissions "Register" or "Register automatically" depends on the template and the degrees of freedom available there. For example, not every user should be able to use the above web server template with free entry of server data! On the other hand, for other scenarios, e.g. smart card usage, it may be necessary that each user has and may be able to create an appropriate certificate.

Application guidelines

The application guidelines define the intended use of the certificate. It is important here to specify the exact purpose of the certificate. For example, a certificate for use in the web server or for code signing does not require client authentication.

The issuance of certificates with the "Any Purpose" application policy is particularly critical. Experience shows that there are always configurations in which users or even administrators can create these certificates. The application should be kept to an absolute minimum here and the authorized account should be protected as best as possible.

Attacks on ADCS

ESC1 - Subject Alternative Name

The Subject Alternative Name or also the check mark for "Information will be provided in the request". With the alternative name you can be whoever you want: If the second name is Administrator, that works too.

First you have to get the necessary information, so a classic case for Bloodhound. For this you need valid user data from the domain, here our dcUser.

First the Bloodhound dump for user and computer information:

				
					bloodhound-python -u USER -p PASSWORD -d DOMAIN [-c all] -dc FQDN_DC [-ns ] --zip

Then use certipy (here 4.0) to get the certificate information:

				
					certipy find -u USER -p PASSWORD -target IP/FQDN_DC -old-bloodhound

Then drag the .zip's into BloodhoundGUI for further analysis.

The custom queries of @Ly4k the author of certipy are suitable for the analysis:

Here we have a 'Generic All' because the administrator "misclicked" and allowed full access to all users. This kind of thing likes to happen during implementation or troubleshooting and the 'undo' is not done if it works. In this case the Subject Alternative Name/Enrollee Supplies Subject = true is sufficient for us.

Continue on the shell with certypy:

				
					certipy req -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA  -template ESC1 -upn ADMINISTRATOR

Then use the certificate to log in:

				
					certipy auth -pfx administrator.pfx

This will give you a TGT and the password hash. With the certificate you can always get a TGT and the hash as long as it is valid. Even changing the user's password and the KRBTGT does not help here.

The domain is yours as long as the certificate is not revoked.

ESC2 - Any Purpose

The "Any purpose" certificate. It is usually a CA or SubCA certificate and thus also has exactly the rights, the standard validity is 5 years. Since it can only be requested by administrative users, this is more of a persistence measure.

ESC3 - Misconfigured Enrollment Agent Templates

Requesting privileged certificates using an enrollment agent. The Enrollment Agent certificate allows us, as another user, to request a certificate that extends our privileges.

To do this, first use certipy to request the regular enrollment agent certificate and, in the second step, e.g. a user certificate of an administrator. Then use certipy auth to request a Kerbero ticket and read the NTHash.

				
					certipy req -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA  -template ESC3.1 -on-behalf-of DOMAIN/ADMIN -pfx ESC3.pfx

ESC4 - Vulnerable Certificate Template Access Control

A certificate template which may be edited by non-administrators and changed accordingly. This can be found out with certipy and Bloodhound or you can manually check the permissions on the individual templates in ADCS.

ESC5 - Vulnerable PKI Object Access Control

This problem is only indirectly related to the CA, but it is a problem if you have administrative permissions on the ADCS server. This can be used to create a "Golden Certificate", similar to the Kerberos Golden Ticket, only as a certificate. Because the CA root certificate was "stolen", it can be used to create further valid certificates. Then use certipy auth to request a Kerberos ticket and read out the NTHash.

				
					certipy ca -backup -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA

				
					certipy forge -ca-pfx ROOT_CA.pfx -upn ADMINISTRATOR -subject CN=ADMINISTRATOR,CN=USERS,DC=DOMAIN,DC=LOCAL

ESC6 - EDITF_ATTRIBUTESUBJECTALTNAME2

This parameter is set CA wide and enables ESC1 for all certificate templates, i.e. requesting with an alternative name. This can be found out with certipy or with certutil on Windows.

				
					certutil -config "FQDN_DC\CA_NAME" -getreg policy\EditFlags

ESC7 - Vulnerable Certificate Authority Access Control

This time not the administrative rights to the server, but to the CA itself. The "Manage CA" or "Manage Certificates" permission. The permission is exploited to grant the user write permissions to a certificate template and then convert this to an ESC1.

				
					certipy ca -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA -add-officer USER

This will give us the "Issue and Manage Certificates" authorization.

This allows us to approve even failed requests and roll out the corresponding certificates. For example, the "SubCA" certificate, which by default only administrators are allowed to request.

After a failed request, be sure to save the "private key", this will be needed later.

				
					certipy ca -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA -issue-request REQ_ID

After approving the request, which can also be used to bypass a "manager approval", retrieve the approved certificate.

				
					certipy req -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA -retrieve REQ_ID

ESC8 - Vulnerable Web Service

The vulnerable web server. Fully covered in our PetitPotam article.

Certifried

My computer is now named like the domain controller. For this, the value for creating more computers in the domain must be set so that more can be added. By default, this is 10 (ms-DS-MachineAccountQuota) if you don't have a more privileged account yet.

This vulnerability was patched by Microsoft in May 2022. Exploitation via Kerberos or Schannel is therefore not possible if CA and DC are patched.

The patch writes another parameter to the certificate, which is szOID_NTDS_CA_SECURITY_EXT the SID of the user.

If it was not patched after all or the CT_FLAG_NO_SECURITY_EXTENSION (0x80000) at msPKI-Enrollment-Flag is set, it still works. Create a new computer with certipy, but an alternative one dNSHostName register.

				
					certipy account create -user NEW_COMPUTER -u USER -p PASSWORD -target IP/FQDN_DC -dns DC_NAME

Then you request a certificate. Since for computer certificates the dNSHostName is used, nothing needs to be "manipulated" here. The Machine Certificate template is used for this purpose.

Pass the Cert

If the login with the certificate does not work because it is not supported, you will get the following error message:

Fehler: eRR-PDATA-Type-NOSUPP

Error Code: 16 Reason: KDC has no support for PADATA type (pre-authentication data).

A tool from AlmonOffSec, PassTheCert in C# and Python helps here. LDAPS and LDAP are exploitable through StartTLS. LDAP ChannelBinding also has no negative effect on the attack through Schannel.

But first the .pfx must be converted to a .crt and to a .key, that is, have the private key and the certificate itself as separate data.

				
					certipy cert -pfx ADMIN.pfx -nokey -out ADMIN.crt

				
					certipy cert -pfx ADMIN.pfx -nocert -out ADMIN.key

After that we create a new computer, if we do not have control over one yet. Login as the system should be possible with a password.

				
					python3 PassTheCert/Python/passthecert.py -dc-ip IP_DC -crt ADMIN.crt -key ADMIN.key -domain DOMAIN -action add_computer -computer-name NEW_COMPUTER

Then we create a delegation from our "new computer" to the domain controller. msDS-AllowedToActOnBehalfOfOtherIdentity, a ResourceBasedConstrainedDelegation. For assistance the -delegate-from and -delegate-to: the from is the computer that I control, and the data I write in the to, so my goal.

				
					python3 PassTheCert/Python/passthecert.py -dc-ip IP_DC -crt ADMIN.crt -key ADMIN.key -domain DOMAIN -action write_rbcd -delegate-from NEW_COMPUTER -delegate-to FQDN_DC

Using the delegated permissions to request Kerberos, takeover.

				
					impacket-getST -spn 'cifs/FQDN_DC' -impersonate Administrator 'DOMAIN/NEW_COMPUTER:PASSWORD' -dc-ip IP_DC

Certipy has also implemented an LDAP shell with simple commands, through which this scenario can also be exploited.

Certificate utilization via GUI

If you want to recreate the danger of incorrectly configured certificate templates in a pure Windows environment without using Kali-Linux, you can do this using normal Windows board means and the smartcard emulator PIVert.

In our use case we use a Windows 10 client. In the MMC Console, we add the corresponding snap-in of certificates to subsequently create a certificate from the existing templates.

"Fortunately", in our templates there is a template for creating a SmartCard certificate, in which we can enter the applicant name ourselves. So we can create a certificate for the administrator as a logged-in standard user!

It is important to set the private key as exportable when creating it and to leave the applicant name blank for use in PIVert, otherwise problems may occur here.

After the successful creation of the certificate you have to export it as *.pfx. The private key must be exported and a password must be specified.

You can then include this certificate in PIVert and emulate a corresponding smart card. This establishes an RDP connection, in the example case as administrator to the ADCS.

Protection from attacks

Configuration

The best protection against attacks is provided by a conscious and appropriate configuration of templates and authorizations. In particular, the above-mentioned risks must be considered and minimized during configuration.

The requestor name should, whenever possible, be pulled directly from the AD user data and not be editable itself, using the "Create from this information in Active Directory" selection from the screenshot above.

Assign permissions as restrictively as possible, especially if the applicant name is not specified or the certificate's capabilities are very broad.

Furthermore, when setting the application guidelines to define the purpose of use: Select only those in a certificate that are necessary for the intended use. Different templates must be created for different fields of application.

Correct and deliberate configuration of certificate templates is the most important step in protecting against misuse and attacks.

Approval of the certificate management

Another way to minimize the risk of misuse is to enable certificate manager approval. If you activate this in the corresponding certificate template, a certificate can be requested, but the approval must be done by an administrator on the ADCS. This makes it more difficult to create certificates - this is correspondingly associated with additional effort in the creation process.

Another challenge of this method is "playing back" the released certificates to the applicant. There are various options here, which we will not present in detail here:

Set up automatic enrollment using GPO. This distributes the released certificates at regular intervals (this can also be actively triggered on the client using "certutil -pulse")
Distributing a Shared Certificate via Active Directory Public Key Policies
Export of the certificate and import on the target system

Attack detection

Analysis of issued certificates

The active detection of the attacks shown so far is not trivial, since the generation and use of the certificates is part of the desired applications. At this point, we recommend a regular check of the issued certificates. This can be done either directly in the ADCS interface or, in the case of a larger number, using PowerShell.

This is particularly recommended if multiple certificates are created or if they are created on a regular basis. The use of PowerShell PKI Solutions makes sense here. Enclosed is an example for querying the currently issued certificates:

You want to avoid the consequences of a successful hacker attack on
your IT system?

Test your IT now with a professional penetration test!