Skip to main content
ESC10 is a misconfiguration in Windows Secure Channel (Schannel), which stems from insecure management of new security features. Specifically, if the certificate mapping configuration of Schannel is reduced below the standard of Strong Certificate Mapping, an attacker can potentially abuse the weak certificate mapping to impersonate arbitrary users in the environment.
The misconfiguration was initially disclosed by Oliver Lyak in this blogpost.

​
Vulnerability Criteria

The following criteria comprise an ESC10 vulnerability:
  • The Schannel certificate mapping has been downgraded to allow userPrincipalName (UPN) mapping.
  • We have GenericWrite rights on a user or computer object in the environment.
Additionally, we require a certificate template with the following criteria:
  • The enterprise CA grants enrollment rights to the attacker-controlled user.
  • The certificate template grants enrollment rights to the attacker-controlled user.
  • The “manager approval” feature is disabled for the certificate template.
  • The “authorized signature” feature is disabled for the certificate template.
  • The certificate template defines an Extended Key Usage (EKU) that enables Schannel client authentication:
    • Client Authentication (1.3.6.1.5.5.7.3.2)
    • Any Purpose (2.5.29.37.0)
    • Subordinate CA (No EKUs)
  • The certificate template must define a UPN-mappable or DNS-mappable flag in its Certificate Name Flag attribute:
    • SUBJECT_ALT_REQUIRE_UPN
    • SUBJECT_ALT_REQUIRE_SPN - This flag relies on the userPrincipalName attribute, despite the name hinting at SPN.
    • SUBJECT_ALT_REQUIRE_DNS - This does not work if the target is a user (as they do not have the dNSHostName attribute)

​
Attack Process

The attack scenario consists of the following steps:
  1. Temporarily modify a mapping attribute of the principal to match that of the target principal that we want to impersonate.
    • If the template has the SUBJECT_ALT_REQUIRE_UPN flag or the SUBJECT_ALT_REQUIRE_SPN flag, the userPrincipalName attribute of the attacker-controlled principal must match the userPrincipalName or sAMAccountName attribute of the target principal.
    • If the template has the SUBJECT_ALT_REQUIRE_DNS flag, the dNSHostName attribute of the attacker-controlled principal must match the dNSHostName attribute of the target principal.
  2. Request a certificate from the vulnerable template. The issued certificate will contain a Subject Alternative Name (SAN) based on the mapping attribute of our requesting user (which is identical to that of our target principal).
  3. Revert the temporary mapping attribute modification. The target principal is now the only user in the domain with an attribute that matches the one in our issued certificate.
  4. Authenticate over Schannel as the impersonated user. This is possible because Schannel ignores the SID security extension in the certificate and the mapping attribute of the certificate matches only our target principal (after we reverted our own changes).

​
Detection

We can search for certificate templates with these conditions using the enum-templates --filter-client-auth command from Certify. For more information about the command and its parameters, please refer to the Command Overview page. 
Certify.exe enum-templates --filter-enabled --filter-client-auth --hide-admins

​
Exploitation Example

Once we have identified a certificate template that our attacker-controlled user can enroll in, we can perform the weak certificate mapping attack. Since the certificate template contains the SUBJECT_ALT_REQUIRE_UPN flag, we must modify the userPrincipalName of our attacker-controlled user to match a target principal that we want to impersonate.
Please note that Schannel requires the full userPrincipalName format (e.g. Administrator@corp.local).
Set-ADUser -Identity impersonator -UserPrincipalName 'Administrator@corp.local'
Get-ADUser -Identity impersonator
We can then request a certificate based on the identified template as the attacker-controlled user and obtain a certificate with a Subject Alternative Name (SAN) that contains the mapping attribute that will link to the target principal (e.g. Administrator). This can be done using the request command from Certify. 
Certify.exe request --ca ca01.corp.local\CORP-CA01-CA --template User
Once we have obtained the certificate, we can revert our mapping attribute modifications. 
Set-ADUser -Identity impersonator -Clear UserPrincipalName
Get-ADUser -Identity impersonator
Now that only the target principal has a mapping attribute that matches the one in the issued certificate, we can authenticate as the target principal by presenting the issued certificate. Since we rely on the weakened mapping settings for Schannel, we will authenticate to LDAPS using PassTheCert. First, we write the issued certificate to a file (cert.pfx). 
[IO.File]::WriteAllBytes("cert.pfx", [Convert]::FromBase64String("MIACAQMwgAYJKoZIhvcNAQcBoIAkgASCA+gwgDCABgkqh..."))
Then, we can authenticate over LDAP Schannel with PassTheCert and confirm that we have successfully elevated our privileges by impersonating the Administrator user. 
PassTheCert.exe --server dc01.corp.local --cert-path cert.pfx --whoami