Certipy 4.0: ESC9 & ESC10, BloodHound GUI, New Authentication and Request Methods — and more!

A new version of Certipy has been released along with a forked BloodHound GUI that has PKI support! In this blog post, we will look at some of the major new features of Certipy, which includes LDAPS (Schannel) and SSPI authentication, new request options and methods, and of course support for the forked BloodHound GUI that I changed to have new nodes, edges, and prebuilt queries for AD CS. At the end of the blog post, we will also look at the two new privilege escalation techniques for AD CS: ESC9 and ESC10.

BloodHound x Certipy

The BloodHound team has delivered many impressive updates, and according to their release post on version 4.1 and version 4.2, Active Directory Certificate Services (AD CS) abuse primitives are on their road map and coming soon. However, it’s been 6 months since the release of version 4.1, so I decided to implement it myself into the BloodHound GUI. This also means that if you want to use the original version of the BloodHound GUI with Certipy, you’ll have to pass the -old-bloodhound option to Certipy’s find command, as the new BloodHound data output from Certipy is only compatible with the forked GUI. The forked version is based on the latest version of BloodHound (4.2.0, August 3, 2022) and requires neo4j ≥ 4.4.0. There’s also a forked version of BloodHound 4.1.1, which doesn’t require neo4j ≥ 4.4.0.

Now, let’s see a graph.

This graph was drawn by simply selecting the CA node and then clicking on “See Enabled Templates”, as shown below.

It’s of course also possible to easily view the object controllers of the CA like you would do with any other object.

The same is possible for certificate templates. Simply select the template and click “See Certificate Authorities”.

Want to see enrollment rights or object controllers? Also one click away.

This also comes with prebuilt queries so you don’t have to mess with your custom queries.

Even though the forked BloodHound GUI was mainly focused on PKI integration, I decided to add a few features that I personally like. For instance, you can now hover your mouse over a query and click the little “Copy” button to copy the query to your clipboard.

Once you’ve copied your query, you can paste and edit it in the new multi-lined “Raw Query” text area.

These are just some small features I personally enjoy, and I might add new ones. The source code can be found at https://github.com/ly4k/BloodHound/ and prebuilt binary releases can be found here. I’ll regularly pull commits from the upstream version so you don’t miss out on those features. If you have any additions, feel free to open an issue or create a pull request.

Old Is New Again

Now, back to Certipy. I have reintroduced and improved some old features of Certipy that I previously removed related to Certipy’s find command. For text and JSON based output, Certipy will now check for ESC1, ESC2, ESC3, ESC4, and the new ESC9 on certificate templates, and ESC6, ESC7, and ESC8 on certificate authorities based on the current user’s nested group memberships. Furthermore, if ms-DS-MachineAccountQuota is not 0 (default: 10) then Certipy will act as if the current user is also a member of the Domain Computers group, since the user will most likely be able to add a new domain computer. In addition to this, the find command now accepts the -vulnerable parameter to only show vulnerable certificate templates, and -hide-admins to hide administrators from the permissions for a cleaner output. These options only apply to text and JSON based output (-text and -json) and does not affect the BloodHound data.

For those who want a bit more stealth, the find command has also received the new -dc-only option to only connect the domain controller (DC). This means that Certipy will not connect to the CA to check for permissions, Web Enrollment, and request flags. This will affect the BloodHound data, and as shown below, Certipy cannot determine permissions, Web Enrollment, and request flags for the CA when this option is set — but it does not affect certificate templates since all this information is stored on the DC.

New Authentication Methods

Scannel (LDAPS)

Our good friends at FalconForce recently published a blog post on how to detect “UnPACing” — the technique used by Certipy and Rubeus during PKINIT Kerberos authentication to retrieve the NT hash. In the Certified Pre-Owned whitepaper, the authors, Will Schroeder and Lee Christensen, mention that Active Directory supports certificate authentication over two protocols by default: Kerberos and Secure Channel (Schannel). One protocol that supports client authentication via Schannel is LDAPS (LDAP over SSL/TLS) — assuming AD CS has been setup. As such, this is exactly what I’ve implemented into Certipy.

Once you’ve obtained your shiny new certificate, run the auth command like you’d usually do, but this time, specify the -ldap-shell option to drop into an interactive LDAP shell with a limited set of commands that should be enough to aid you in the right direction, for instance configuring Resource-based Constrained Delegation, adding a user to a group, reading LAPS, and more.

This command will connect to the domain controller, and instead of authenticating via Kerberos, Certipy will connect to LDAP and present the certificate during the StartTLS upgrade. It is worth noting that the type of certificate that can be used depends on the CertificateMappingMethods registry key.

This new feature is also relevant for ESC10 (see later in the post).

Windows Integrated Authentication (SSPI)

Now, imagine you just got code execution on a domain-joined machine. You could run your C2 agent, open a SOCKS proxy connection, and then run Certipy through that. The problem in this scenario is that you don’t know the credentials of your current user context. This has happened to me a few times. Instead, let me introduce Certipy’s new SSPI integration.

The first step is to get Certipy on your target machine. You could install Python and then Certipy, or you could just use something like PyInstaller (pyinstaller ./Certipy.spec) to pack it into an executable. Once you’ve done that, you can run all your usual commands, but instead of specifying username, password, and domain, you can just pass the -sspi option. This will make Certipy use your current user’s domain context for authentication by using Windows APIs to retrieve Kerberos tickets.

The -sspi flag can be used on all commands that require user credentials, e.g. find.

Now, -sspi is not the only new flag related to Windows authentication. The auth command now also accepts -print and -kirbi to print the ticket or save the ticket as Kirbi format — both outputs ready to be used for Rubeus. On top of this, if you would just like to inject your newly acquired domain administrator ticket into your current logon session, you can do that with the -ptt flag.

The same thing can be achieved by using -print with the auth command, and then passing the Base64 ticket to Certipy’s new ptt command in the -ticket option. The Base64 ticket can also be used for Rubeus.

The new ptt command can be used to inject tickets from a file or command line, but it can also be used to request a new TGT using credentials and inject the ticket into your logon session. This is useful if you’re not in a domain context and you don’t want to write the username, password, and domain for each command.

Change of Parameters

Certipy has also received a minor change on how a username, domain, password and target are specified. The username and domain is now specified in -username user@domain, and the password is specified in -password, whereas the target host can be specified in -target if required. Otherwise, the target will be derived from the domain. This change is because of the parsing logic related to usernames, password, domains, and targets in a single string that could prevent some usernames and passwords from being parsed correctly, for instance if the sAMAccountName or password contains an @ symbol.

New Request Methods

Web Enrollment

Some users of Certipy reported that during an engagement, they could only request certificates through the web interface and not via RPC. As such, I have implemented web based enrollment into Certipy for that exact reason. Currently, it supports both HTTP and HTTPS, but only with password or NTLM authentication. To request a certificate through the web interface, simply pass the -web option to your usual req command.

Double SAN

A feature request was sent to me to allow specifying a DNS host name instead of a UPN for the old -alt parameter. As such, the -alt parameter has been removed in favor of the two new parameters -upn and -dns. And it turns out that you can even specify both parameters in a single request.

Certipy will now print out all the account identifications found in the certificate. Now, what would happen if we tried to authenticate with this certificate?

Well, Certipy will now ask you which identification you wish to use. So can we have one certificate with identification for multiple users?

Yes, we can. As shown above, two different NT hashes were returned depending on the identification used. It is of course also possible to only specify a single identification.

Key Archival and Key Size

A user reported that a template had a different minimum key size than the one that was generated by Certipy. This will yield the error CERTSRV_E_KEY_LENGTH. Certipy now accepts the -key-size parameter to specify a different key size, as shown below.

While this was rather trivial to implement, another user reported that a certificate template was configured to require key archival. This is specified as CT_FLAG_REQUIRE_PRIVATE_KEY_ARCHIVAL in the msPKI-Private-Key-Flag of the certificate template. Key archival means that the enrollee must send its private key during the request such that it can be stored in the CA database and later recovered by a Recovery Agent. For this, Microsoft requires that the private key will be embedded in a CMC (Certificate Management over CMS) request rather than a usual PKCS10 request. After reading the RFC and the sparse Microsoft-specific documentation, Certipy can finally overcome this issue.

This is a whole different type of request and protocol, that includes retrieving the CA Exchange Certificate, crafting undocumented ASN1 structures, encrypting the private key, and a few more headaches. Nonetheless, I wouldn’t want this single flag to stand in my (or your) way to becoming domain administrator during an engagement.

Other Features

You might also encounter some other unmentioned features — which might not seem that useful — that is merely a result of my own research. For instance, it’s possible to renew a certificate using an old certificate with the -renew parameter. Since I had already implemented all the structures and functionality, I thought I’d just add it to Certipy.

New Escalations

To understand the new escalations, we must first understand Microsoft’s patch for CVE-2022–26923.

My previously reported AD privilege escalation vulnerability “Certifried” (CVE-2022–26923) actually contained four different cases. The case described in my previous blog post was that it was possible to simply duplicate the DNS host name of a machine account. This would work from a low-privileged user in a default AD CS environment. However, I also reported three other closely related vulnerabilities that required a GenericWrite permission over a low-privileged account. These were not described in the previous blog post, but here’s a brief summary of the other cases:

• Overwrite userPrincipalName of user to be <sAMAccountName> of target to hijack user account since the missing domain part does not violate an existing UPN
• Overwrite userPrincipalName of user to be <sAMAccountName>@<domain> of target to hijack machine account since machine accounts don’t have a UPN
• Delete userPrincipalName of user and overwrite sAMAccountName to be <sAMAccountName> without a trailing $ to hijack a machine account

These three cases are all related to how a certificate is mapped to an account during authentication. First of all, a missing domain part of the UPN doesn’t matter. Secondly, if the KDC can’t find an account where the userPrincipalName matches the UPN in the certificate, it will try to find an account where the sAMAccountName matches the UPN in the certificate. And lastly, if the userPrincipalName property doesn’t exist for the enrollee during the certificate request, it will build the UPN in the certificate based on the sAMAccountName. On top of this, if the KDC cannot find an account where the sAMAccountName matches the UPN in the certificate, it will simply add a $ at the end and try again, as we know from CVE-2021–42287/CVE-2021–42278.

So how did Microsoft fix this? First of all, they made sure that the “Validated write to DNS host name” permission on a machine account now only accepts a value that matches the sAMAccountName property. This means that it is still possible to duplicate the DNS host name of a domain controller (or another machine account) if you have GenericWrite over a machine account, as shown below.

This was tested against a fully patched domain controller where john only had GenericWrite over johnpc$.

On top of this, Microsoft implemented the new szOID_NTDS_CA_SECURITY_EXT security extension for issued certificates, which will embed the objectSid property of the requester. Furthermore, Microsoft created the new registry key values (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel) CertificateMappingMethods and (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc) StrongCertificateBindingEnforcement.

These security updates also broke our beloved ESC6. However, after the patch for CVE-2022–26923, Windows admins started reporting issues that certificated based authentication no longer worked in their environments due to the new security hardenings. On “/r/sysadmin” on Reddit, Windows admins shared workarounds for the issue by changing the values of the registry keys to be the de facto old values (just old values from now on). On top of this, Microsoft’s official workaround was to either manually map all the certificates to each user or to set the CertificateMappingMethods to the old value. Changing these registry keys to the old values will reintroduce ESC6 and introduce the new ESC10. So why are we interested in how a certificate is mapped to a user?

Certificate Mappings

As mentioned earlier, Active Directory supports certificate authentication over two protocols by default: Kerberos and Secure Channel (Schannel). As such, the two new registry keys StrongCertificateBindingEnforcement and CertificateMappingMethods correspond to Kerberos and Schannel, respectively.

Certificates can either be mapped via implicit or explicit mappings. For explicit mappings, the altSecurityIdentities property on an account object is configured to contain identifiers for a certificate, for instance the issuer and serial number. This way, when a certificate is used for authentication via explicit mapping, it must be signed by a trusted CA and then match the values specified in the altSecurityIdentities. On the other hand, when a certificate is used for authentication via implicit mapping, then the information from the certificate’s Subject Alternative Name (SAN) extension is used to map the certificate to an account, either the UPN or DNS field.

However, Schannel and Kerberos don’t use the same techniques for mapping a certificate implicitly. Let’s take a look at how a certificate is mapped implicitly for each protocol.

Kerberos Certificate Mapping

The new registry key value (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc) StrongCertificateBindingEnforcement is by default set to 1 now. Before the patch, this key did not exist, but the old value was 0, i.e. strong certificate binding was not enforced. This value can either be set to 0, 1, or 2.

If the value is 0, then no strong certificate mapping checks are done. This means that the new szOID_NTDS_CA_SECURITY_EXT certificate extension isn’t used for anything even though it’s embedded in the certificate — so certificate mapping in Kerberos is exactly as before the patch. Setting this value to 0 is not recommended by Microsoft, but according to BleepingComputer, this value fixed the authentication issues for a Windows admin.

If this value is 1 (default value after patch), the KDC checks if there is a strong certificate mapping (explicit). If yes, authentication is allowed. Otherwise, the KDC will check if the certificate has the new SID extension and validate it. If this extension is not present, authentication is allowed if the user account predates the certificate.

If this value is 2, the KDC checks if there’s a strong certificate mapping. If yes, authentication is allowed. Otherwise, the KDC will check if the certificate has the new SID extension and validate it. If this extension is not present, authentication is denied.

Microsoft is planning on setting this value to 2 by default on May 9, 2023 and removing the registry key value, such that a certificate must have a strong explicit mapping or the szOID_NTDS_CA_SECURITY_EXT extension to be used for authentication via Kerberos.

So, let’s say that the value is set to 0; how is a certificate then implicitly mapped? For this blog post, we are not interested in explicit mapping (altSecurityIdentities). When a certificate is used for authentication via Kerberos, the KDC will first verify that it is issued by a trusted CA and that the certificate can be used for client authentication. For implicit mappings, the KDC will then try to map the certificate to an account either via the UPN or DNS SAN value.

If the certificate contains a UPN with the value [email protected], the KDC will first try to see if there exists a user with a userPrincipalName property value that matches. If not, it checks if the domain part corp.local matches the Active Directory domain. If there is no domain part in the UPN SAN, i.e. the UPN is just john, then no validation is performed. Next, it will try to map the user part john to an account where the sAMAccountName property matches. If this also fails, it will try to add a $ to the end of the user part, i.e. john$, and try the previous step again (sAMAccountName). This means that a certificate with a UPN value can actually be mapped to a machine account.

If the certificate contains a DNS SAN and not a UPN SAN, then the KDC will split the DNS name into a user part and a domain part, i.e. johnpc.corp.local becomes johnpc and corp.local. The domain part is then validated to match the Active Directory domain, and the user part will be appended by a $ and then mapped to an account where the sAMAccountName property matches, i.e. johnpc will be looked up as johnpc$.

This certificate mapping is explained in MS-PKCA 3.1.5.2.1 and the DNS mapping is explained a bit more in depth in my previous blog post on CVE-2022–26923.

If the new registry key value StrongCertificateBindingEnforcement is set to 1 or 2, then the szOID_NTDS_CA_SECURITY_EXT certificate extension will be used to map the certificate to an account where the objectSid property matches. If the value is 1 and the extension is not present, then the mapping is performed as if the value was set to 0.

Schannel Certificate Mapping

Schannel will map the certificate a little bit differently than the KDC would. Let’s take a look at the possible values for the CertificateMappingMethods registry key value. This value is a DWORD that supports multiple values as a bit set. The new default value is 0x18 (0x8 and 0x10), whereas the old value was 0x1f (all of the below values).

• 0x0001 — Subject/Issuer certificate mapping (explicit)
• 0x0002 — Issuer certificate mapping (explicit)
• 0x0004 —SAN certificate mapping (implicit)
• 0x0008 — S4U2Self certificate mapping (Kerberos)
• 0x0010 — S4U2Self explicit certificate mapping (Kerberos)

So, Schannel actually doesn’t support the new szOID_NTDS_CA_SECURITY_EXT extension directly. Instead, it will use S4U2Self to map the certificate via Kerberos, which then supports the szOID_NTDS_CA_SECURITY_EXT extension. However, this is performed as the last step if the other supported mappings fail. This means that if certificate contains a UPN or DNS name, and the CertificateMappingMethods contains the 0x4 value, then the szOID_NTDS_CA_SECURITY_EXT certificate extension and StrongCertificateBindingEnforcement registry value will have absolutely no influence on the certificate mapping via Schannel. This is a bit more interesting to us, since Microsoft officially suggested setting this registry key value to the old value 0x1f (all of the above methods) as an alternative to manually mapping all certificates if the security updates caused authentication issues: “If you experience authentication failures with Schannel-based server applications, we suggest that you perform a test. Add or modify the CertificateMappingMethods registry key value on the domain controller and set it to 0x1F and see if that addresses the issue.”

Now that we understand the patch for CVE-2022–26923, let’s look at the new ESCs and some examples.

ESC9 — No Security Extension

Description

ESC9 refers to the new msPKI-Enrollment-Flag value CT_FLAG_NO_SECURITY_EXTENSION (0x80000). If this flag is set on a certificate template, the new szOID_NTDS_CA_SECURITY_EXT security extension will not be embedded. ESC9 is only useful when StrongCertificateBindingEnforcement is set to 1 (default), since a weaker certificate mapping configuration for Kerberos or Schannel can be abused as ESC10 — without ESC9 — as the requirements will be the same.

Conditions:

• StrongCertificateBindingEnforcement not set to 2 (default: 1) or CertificateMappingMethods contains UPN flag
• Certificate contains the CT_FLAG_NO_SECURITY_EXTENSION flag in the msPKI-Enrollment-Flag value
• Certificate specifies any client authentication EKU

Abuse

Please see the “Examples” section for a practical example. To abuse this misconfiguration, the attacker needs GenericWrite over any account A that is allowed to enroll in the certificate template to compromise account B (target).

ESC10 — Weak Certificate Mappings

Description

ESC10 refers to two registry key values on the domain controller.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel CertificateMappingMethods. Default value 0x18 (0x8 | 0x10), previously 0x1F.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc StrongCertificateBindingEnforcement. Default value 1, previously 0.

Case 1

StrongCertificateBindingEnforcement set to 0

Case 2

CertificateMappingMethods contains UPN bit (0x4)

Abuse

Please see the “Examples” section for practical examples for each case. To abuse these misconfigurations, the attacker needs GenericWrite over any account A that is allowed to enroll in a certificate with client authentication to compromise account B (target).

Unfortunately, these registry keys cannot be read by a low-privileged user remotely. However, if you ever find yourself in a scenario, where you have GenericWrite over any account, it might be worth trying each abuse case nonetheless.

Examples

ESC9

Conditions:

• StrongCertificateBindingEnforcement set to 1 (default) or 0
• Certificate contains the CT_FLAG_NO_SECURITY_EXTENSION flag in the msPKI-Enrollment-Flag value
• Certificate specifies any client authentication EKU

Requisites:

• GenericWrite over any account A to compromise any account B

In this case, [email protected] has GenericWrite over [email protected], and we wish to compromise [email protected]. [email protected] is allowed to enroll in the certificate template ESC9 that specifies the CT_FLAG_NO_SECURITY_EXTENSION flag in the msPKI-Enrollment-Flag value.

First, we obtain the hash of Jane with for instance Shadow Credentials (using our GenericWrite).

Next, we change the userPrincipalName of Jane to be Administrator. Notice that we’re leaving out the @corp.local part.

This is not a constraint violation, since the Administrator user’s userPrincipalName is [email protected] and not Administrator.

Now, we request the vulnerable certificate template ESC9. We must request the certificate as Jane.

Notice that the userPrincipalName in the certificate is Administrator and that the issued certificate contains no “object SID”.

Then, we change back the userPrincipalName of Jane to be something else, like her original userPrincipalName [email protected].

Now, if we try to authenticate with the certificate, we will receive the NT hash of the [email protected] user. You will need to add -domain <domain> to your command line since there is no domain specified in the certificate.

And voilà.

ESC10(Case 1)

Conditions:

• StrongCertificateBindingEnforcement set to 0

Requisites:

• GenericWrite over any account A to compromise any account B

In this case, [email protected] has GenericWrite over [email protected], and we wish to compromise [email protected]. The abuse steps are almost identical to ESC9, except that any certificate template can be used.

First, we obtain the hash of Jane with for instance Shadow Credentials (using our GenericWrite).

Next, we change the userPrincipalName of Jane to be Administrator. Notice that we’re leaving out the @corp.local part.

This is not a constraint violation, since the Administrator user’s userPrincipalName is [email protected] and not Administrator.

Now, we request any certificate that permits client authentication, for instance the default User template. We must request the certificate as Jane.

Notice that the userPrincipalName in the certificate is Administrator.

Then, we change back the userPrincipalName of Jane to be something else, like her original userPrincipalName [email protected].

Now, if we try to authenticate with the certificate, we will receive the NT hash of the [email protected] user. You will need to add -domain <domain> to your command line since there is no domain specified in the certificate.

ESC10(Case 2)

Conditions:

• CertificateMappingMethods contains UPN bit flag (0x4)

Requisites:

• GenericWrite over any account A to compromise any account B without a userPrincipalName property (machine accounts and built-in domain administrator Administrator)

In this case, [email protected] has GenericWrite over [email protected], and we wish to compromise the domain controller [email protected].

First, we obtain the hash of Jane with for instance Shadow Credentials (using our GenericWrite).

Next, we change the userPrincipalName of Jane to be [email protected].

This is not a constraint violation, since the DC$ computer account does not have userPrincipalName.

Now, we request any certificate that permits client authentication, for instance the default User template. We must request the certificate as Jane.

Then, we change back the userPrincipalName of Jane to be something else, like her original userPrincipalName ([email protected]).

Now, since this registry key applies to Schannel, we must use the certificate for authentication via Schannel. This is where Certipy’s new -ldap-shell option comes in.

If we try to authenticate with the certificate and -ldap-shell, we will notice that we’re authenticated as u:CORP\DC$. This is a string that is sent by the server.

One of the available commands for the LDAP shell is set_rbcd which will set Resource-Based Constrained Delegation (RBCD) on the target. So we could perform a RBCD attack to compromise the domain controller.

Alternatively, we can also compromise any user account where there is no userPrincipalName set or where the userPrincipalName doesn’t match the sAMAccountName of that account. From my own testing, the default domain administrator [email protected] doesn’t have a userPrincipalName set by default, and this account should by default have more privileges in LDAP than domain controllers.

Conclusion

In this blog post, we looked at some new features of Certipy and the forked BloodHound GUI that I changed to have full PKI support. Furthermore, we looked at the new ESCs — which are not as juicy as ESC1 or ESC8 — but I have seen many environments where everyone or a specific group had GenericWrite over a single user or computer. On top of this, we might see more and more admins change these registry key values or enabling the vulnerable flag on a template — simply because it makes thing work — just like ESC6.

If you have any questions, feel free to message me on Twitter (@ly4k_). In the next blog post, we’ll look at two Windows privilege escalation vulnerabilities in the Print Spooler (CVE-2022–29104 & CVE-2022–30138). This is an interesting technique that might work for other services, and the NSA was subsequently acknowledged for reporting these vulnerabilities as well. A presto!

Certipy 4.0: ESC9 & ESC10, BloodHound GUI, New Authentication and Request Methods — and more! was originally published in IFCR on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this blog post, we present new techniques for recovering the NTLM hash from an encrypted credential protected by Windows Defender Credential Guard. While previous techniques for bypassing Credential Guard focus on attackers targeting new victims who log into a compromised server, these new techniques can also be applied to victims logged on before the server was compromised.

Credential Guard is intended to safeguard both NTLM hashes and Kerberos tickets, but for the purposes of this post, we will focus solely on NTLM hashes.

We will provide a general overview of the technical details, with the option to explore further for those who are interested in the underlying mechanics.

Note that when we mention an “NTLM hash,” we are actually referring to the NT hash, as the LM hash is obsolete.

Credential Guard 101

There are many blog posts about Credential Guard, some of which are more accurate than others. In this section, we will provide an overview of Credential Guard and explain why it is important for attackers and defenders to understand it.

To quote Microsoft about Credential Guard, Pass-the-Hash, and Pass-The-Ticket:

Windows Defender Credential Guard prevents these attacks [Pass-the-Hash and Pass-The-Ticket] by protecting NTLM password hashes, Kerberos Ticket Granting Tickets, and credentials stored by applications as domain credentials.

The LSASS (Local Security Authority Subsystem Service) process is responsible for managing and enforcing security policies on a Windows system. It handles tasks such as authenticating users, granting access to resources, and enforcing security policies.

The LSASS process stores credentials in memory, including hashed passwords. Windows Defender Credential Guard aims to safeguard these credentials by isolating them from the LSASS process memory. We will cover the implementation of this in more detail shortly.

Why do we care?

Attackers often attempt to dump credentials from the LSASS process memory on a compromised machine in order to move laterally within the network, using tools like Mimikatz that can extract various credentials, including plaintext passwords, NTLM hashes, and Kerberos tickets.

In a Pass-the-Hash (PtH) attack, an attacker can use a compromised NTLM hash to authenticate to a system or service without knowing the actual password. This is possible because NTLM hashes are derived from the user’s password and are used for authentication in many protocols.

Credential Guard appears to protect against these types of attacks by isolating NTLM hashes (and Kerberos tickets) in the LSASS process memory, thus protect against the initial compromise of a user’s NTLM hash.

Now, if we compromise a system that has Credential Guard enabled and attempt to extract credentials from the LSASS process memory using Mimikatz, what do we observe?

As demonstrated above, we are unable to extract the NTLM hash from LSASS memory and are instead presented with “LSA Isolated Data: NtlmHash”. For comparison, this is what the output would look like on a system that is not protected by Credential Guard.

This compromised NTLM hash could then be used to authenticate to a system or service.

At IFCR, we have noticed an increasing number of systems protected by Credential Guard during our Red Team engagements. Additionally, starting with the Windows 11 Enterprise version 22H2 and Windows 11 Education version 22H2, systems that are compatible with Credential Guard have it turned on by default.

How?

Windows Defender Credential Guard uses virtualization-based security (VBS) to isolate secrets. VBS utilizes hardware virtualization features to create a secure region of memory that is separate from the normal operating system.

To understand the challenges attackers face when dealing with Credential Guard, it can be helpful to think of the normal operating system running inside one virtual machine (VM) and secure processes running inside another VM with a separate kernel. These VMs are managed by the “Hypervisor”.

Even if attackers were to gain kernel code execution within the normal operating system, they would still need to escape the VM by attacking the Hypervisor or the secure VM. This scenario is similar to what happens with virtualization-based security.

So, how does Credential Guard work? When Credential Guard is enabled, a process called LSAIso (LSA Isolated) runs inside the secure VM. LSASS and LSAIso can communicate through advanced local procedure calls (ALPCs)

When the LSASS process wants to protect a secret, it can call upon LSAIso to encrypt it. The encrypted secret is then returned to LSASS. Ideally, only LSAIso should be able to decrypt the secret. Once an NTLM hash is protected, the LSASS process only holds an isolated secret (an encrypted blob).

As shown in the picture above, the LSAIso process has “NTLM support”. When the LSASS process wants to perform an NTLM operation on the encrypted secret, it can call on various methods in the LSAIso process to perform the operation. It’s worth pointing out that LSAIso does not have network access. Therefore, even though LSAIso can perform NTLM operations, the LSASS process is still responsible for carrying out any actions that come before and after the operation. For example, while LSAIso can compute an NTLM Challenge/Response pair, LSASS is responsible for receiving and sending the pair.

Previous State of Defeating Credential Guard

Until now, the only publicly known attacks against Credential Guard involve attacking the authentication pipeline of LSASS before secrets are protected. For example, this could involve hooking a function in LSASS so that when a new victim logs on to a compromised server, their credentials can be compromised before they are sent to LSAIso.

New State of Defeating Credential Guard

Although it requires a few additional steps, it is still possible to recover the NTLM hash of an NTLM isolated secret. In other words, if we manage to compromise a system and come across encrypted NTLM credentials in the LSASS process’ memory, we can still extract the NTLM hash.

By leveraging the exposed functionality of the LSAIso process along with the encrypted credentials, we can perform the required operations to ultimately obtain the NTLM hash.

Recovering the NTLM hash

In this section, we will demonstrate two techniques for obtaining the NTLM hash.

First, we must gain code execution within the LSASS process in order to communicate with the LSAIso process over the established ALPC communication channel. This step is described in more detail in the “Technical Details” section for those interested in the underlying mechanics.

Second, we must obtain a memory dump of the LSASS process to extract the encrypted credentials. I have modified the Pypykatz code to accomplish this, and the details are also provided in the “Technical Details” section.

For this example, I have created a domain administrator account with a long, random password that corresponds to the NTLM hash 65A13AB2FAEB5B700DE1A938AE5621CA.

In this scenario, we have obtained a memory dump of the LSASS process and extracted the encrypted credentials using the modified version of Pypykatz, as illustrated below.

In the next two sections, we will demonstrate how to extract the NTLM hash 65A13AB2FAEB5B700DE1A938AE5621CA from the “encrypted blob” (isolated secret).

I have also created a tool called “PassTheChallenge” that invokes LSAIso methods by loading a library into the LSASS process. This tool will be made available with this blog post, and the technical details and required information will be provided in the “Technical Details” section.

PtCv1

This technique allows us to recover the NTLM hash in a relatively short amount of time.

The LSAIso process exposes a method named NtlmIumCalculateNtResponse, which allows us to calculate an NTLMv1 response for an arbitrary server challenge using the encrypted credentials.

By utilizing the “Context Handle”, “Proxy Info”, and “Encrypted blob” from the memory dump, we can pass these parameters to PassTheChallenge.exe using the command nthash. By default, the tool uses the static challenge 1122334455667788. If all goes well, it will produce an NTHASH. Despite the format, this is not the NTLM hash, but rather an NTLMv1 response.

Now for the interesting part. With the NTLMv1 response and the static challenge 1122334455667788, we can submit it to crack.sh and have it cracked for free. Before you think that this requires hours cracking, just keep reading. We’re not cracking the NTLMv1 response into a password, but rather into an NTLM hash.

If you need a refresher on how an NTLMv1 response is generated, you can refer to the following code:

The NTLMv1 response consists of three 8-byte chunks. Each chunk is created by encrypting the challenge with DES and a 7-byte chunk of the key. You may have noticed that three 7-byte chunks of the key add up to 21 bytes, which is larger than the 16-byte NTLM hash. To address this, the last chunk of the key is made up of the first 2 bytes of the NTLM hash followed by null bytes.

To summarize, we need to crack three DES encryptions using three different 7-byte keys, one of which only has 2 unknown bytes, to recover the NTLM hash. This process is much simpler than cracking a single 16-byte key. Fortunately, crack.sh has built one of the largest publicly available Rainbow Tables for the entire DES keyspace. They claim to be able to achieve an average crack time of 25 seconds and a success rate of 99.5%. If the system is unable to crack the key immediately, it will pass the job on to a brute-force rig, which should be able to find the key within a few days.

Let’s see it in action. First, we can submit the NTHASH format to crack.sh for free.

In less than a minute, I received an email from crack.sh stating that the NTLM hash was successfully recovered in 30 seconds: 65A13AB2FAEB5B700DE1A938AE5621CA.

While this is not an advertisement for crack.sh, it does illustrate how straightforward it is to crack an NTLMv1 hash back into an NTLM hash.

This particular hash was not previously submitted to crack.sh, and the use of a long, random password indicates that cracking is not a matter of password complexity, but rather the inherent weakness of NTLMv1 hashes.

PtCv2

Now, let’s suppose that the NTLMv1 option is not available for some reason — perhaps Microsoft decided to remove it. Another interesting option is to compute an NTLMv2 respone using the LSAIso method NtlmIumLm20GetNtlm3ChallengeResponse.

To demonstrate this, I have modified the Impacket function computeResponseNTLMv2 to interactively print the challenge and prompt for a response. This single modification will work with all scripts and tools that utilize Impacket for authentication, such as Certipy.

When the password is set to CHALLENGE, the computeResponseNTLMv2 function in Impacket will instead print out the challenge and prompt for a response. Let’s see it in action. For the first demonstration, we will use Impacket’s psexec.py to gain code execution on the domain controller DC.

We will run the script as usual, but for my modification to take effect, we need to specify the password CHALLENGE. Impacket will then print out a custom formatted challenge and wait for a response, as shown below.

We can then utilize PassTheChallenge.exe as before, but this time we use the command challenge and append the challenge to the previously used parameters.

The tool will then output a response, which we will provide to psexec.py.

As shown above, psexec.py performs multiple authentications, so we will need to repeat these steps a few times. However, we eventually gain access to a shell and achieve code execution.

While this did not allow us to recover the NTLM hash, it does raise the possibility of other ways to do so using our NTLMv2 primitive.

If you’ve read some of my other posts, you may have noticed my fondness for Active Directory Certificate Services (AD CS). If you’re not familiar with AD CS, I recommend checking out one of my previous posts on the topic.

Now, let’s utilize our NTLMv2 primitive and Certipy to request a certificate for the victim user “Administrator” through Active Directory Certificate Services.

As previously mentioned, the modified Impacket function will even cause Certipy to print the challenge and prompt for a response when the password is set to CHALLENGE. As shown above, the certificate request was successful and the issued certificate along with the private key was saved to administrator.pfx.

Finally, we can use the certificate and Certipy to authenticate as the administrator user and retrieve the NTLM hash, as demonstrated below.

It’s worth mentioning that in order to request certificates and authenticate with them, it is necessary to have AD CS installed in the environment. Once AD CS is enabled, any user can be targeted by default.

An Extra Note

Based on my own testing, it appears that encrypted credentials can be used across reboots, contrary to some existing information. It seems that LSAIso does not use a per-boot secret to encrypt the credentials. Therefore, it is possible to return to the compromised machine at a later time to perform these operations. The only thing to keep in mind is that the “Context Handle” and “Proxy Info” are memory addresses extracted from the memory dump, and these need to be recalculated through a new memory dump or similar methods. The “Context Handle” and “Proxy Info” addresses are not tied to a specific set of credentials, and all encrypted NTLM credentials will have the same “Context Handle” and “Proxy Info” address in the memory dump. Refer to the “Technical Details” section for more information.

Conclusion

In this blog post, we focused specifically on NTLM. However, it’s worth considering that Kerberos may also offer interesting functionality that could help us achieve our goals.

Earlier in the post, we referenced a quote from Microsoft’s page on Credential Guard. Here’s how that same page concludes:

While Windows Defender Credential Guard is a powerful mitigation, persistent threat attacks will likely shift to new attack techniques(…)

And so we did.

Technical Details

If you’ve read this far, you may be interested in the technical details, whether you are an attacker or a defender.

LSASS and LSAIso

As previously mentioned, LSASS and LSAIso communicate with each other through ALPC and RPC.

The Security Support Provider (SSP) “MSV” (msv1_0.dll) is responsible for NTLM and Kerberos authentication. When the msv1_0.dll module is loaded into LSASS and the SpInitialize function is called to initialize the SSP, if Credential Guard is enabled, the module will create a new NtlmCredIsoIum object and save the address of this object to the global variable LocalhostNtLmCredIsoObj::IsoObj. This object acts as an interface for implementations of the NtlmCredIsoApi interface. If Credential Guard is not enabled, the LocalhostNtLmCredIsoObj::IsoObj variable will instead store the NtLmCredIsoInProc object, which implements methods that do not communicate with LSAIso, resulting in the credentials not being encrypted.

When a new NtlmCredIsoIum object is created, it establishes an ALPC binding to LSA_ISO_RPC_SERVER, where LSAIso is already listening for procedure calls. After the binding is established, MSV will call LSAIso’s NtlmIumGetContext method to obtain a unique context handle.

The context handle is passed to the NtlmCredIsoIum object during initialization and stored at offset +0x10.

Inside LSAIso, the NtlmIumGetContext method checks if an “auth cookie” has already been given out. If it has, the method aborts. If not, it stores the “auth cookie” in the provided context handle.

Based on my own testing, the LSAIso process assigns a unique “auth cookie” value to its own memory and associates it with the context handle provided by the LSASS process. This means that the LSASS process cannot directly access the “auth cookie” value, but when it communicates with LSAIso using the context handle, LSAIso can recognize that the “auth cookie” value is associated with that specific context handle.

In order to utilize the binding established between the LSASS and LSAIso processes, I have implemented a tool that loads a module into LSASS. Initially, I attempted to duplicate or extract the binding, but it appears that the inner workings of RPC bindings are more complex than just a single pointer or value within a process.

As for the use of the context handle, by examining the LSAIso executable, we can see the methods supported by the NTLM interface.

If we examine the NtlmIumProtectCredential method within LSAIso, we can see that it checks if the provided context handle matches the global “auth cookie” value. If there is no match, the method will pause for 5 milliseconds before returning an error code (0xc0000022).

The “auth cookie” may seem to be the first argument of the function, but it is actually the RPC marshalling and context handling that transforms the context handle into the “auth cookie”. If we attempt to call the function using a 64-bit value rather than a context handle, the RPC server within LSAIso will return a “bad RPC stub” or “invalid handle” error because the marshalling of our client does not match the unmarshalling of the server.

It may be possible for someone to come up with a smarter implementation for duplicating the binding and context handle across processes.

Now that we understand how LSASS and LSAIso communicate, let’s look at some examples. The NtlmIumProtectCredential method mentioned earlier is used to protect an unprotected credential set (such as NTLM).

To summarize, the IumpProtectCredential function will encrypt the credentials within the MSV1_0_SECRETS_WRAPPER structure and return it to LSASS. This means that LSAIso does not maintain a record of encrypted credentials; it is LSASS’ responsibility to do so. LSAIso just knows how to decrypt the credentials and perform operations on them.

Let’s examine the NtlmIumCalculateNtResponse method within LSAIso.

As before, the method first verifies that the context handle is valid. It then checks if the IsEncrypted field and NtPasswordPresent field of the MSV1_0_SECRETS_WRAPPER structure are set to true. This structure is not documented, but I have reverse engineered it and it can be found in the released tool.

If both fields are true, the method then calls IumpUnprotectCredential to decrypt the credentials. It’s worth noting that the declaration of this method in the RPC interface does not return the decrypted MSV1_0_SECRETS_WRAPPER to LSASS. After decrypting the credentials, the method calls SystemFunction009 inside CRYPTSP.DLL. The Wine implementation of that function can be found here.

Now let’s take a look at how this method is called within LSASS.

As can be seen, the call to NdrClientCall3 uses the “Proxy Info” object (_MIDL_STUBLESS_PROXY_INFO) as its first parameter. The procedure number 3 for NtlmIumCalculateNtResponse is passed as the second parameter, followed by the context handle (this + 0x10) as the fourth parameter, the server challenge as the fifth parameter, the MSV1_0_SECRETS_WRAPPER (encrypted credentials) as the sixth parameter, and a pointer to the response as the seventh parameter.

The RPC interface shared between LSASS and LSAIso specifies which data is exchanged between the two processes. As a result, one cannot assume that an operation on a parameter within LSAIso will have any effect on the corresponding parameter in LSASS.

These are just examples of how LSASS and LSAIso can communicate.

Pypykatz

I have made a few modifications to Pypykatz in my own version to print out additional information. Specifically, I have added a feature to read and print out the encrypted blob in the case that the credential is encrypted, rather than reading the encrypted blob as NT, LM, and SHA values.

Additionally, the variable pNtlmCredIsoInProc actually holds a pointer to the NtlmCredIsoIum object mentioned in the previous section if the credential is protected by Credential Guard. As a result, the “Context Handle” can be found at offset +0x10 of this address.

We will also dynamically extract the address of the “Proxy Info” object used in the NdrClientCall3 call.

The output will appear as follows:

The modified version can be found on my Github.

PassTheChallenge

Finally, I have created a tool that consists of an executable and a SSP (Security Support Provider) provider (DLL).

The plan is to use AddSecurityPackage to load a new SSP provider into the LSASS process. Our custom SSP will then start a local RPC server that we can communicate with from our executable.

This allows the PassTheChallenge tool to connect to the new local RPC server started by our security package, allowing us to communicate back and forth and call various functions.

The PassTheChallenge executable includes several different commands. One of them is the injection of the module, which can be done as follows:

Once the module is loaded, we can issue a simple “ping” command to see if it is responding.

Here is how the tool can be used:

For instance, LSAIso enables us to compare two encrypted blobs. By combining this with a method for securing our own credentials, we can compare an encrypted blob with another encrypted blob or with an NT hash.

The <addresses> parameter is obtained from the output of Pypykatz and represents the <context handle>:<proxy info>. This is followed by an encrypted blob, which can then be compared to either another encrypted blob or an NT hash.

From an operational security perspective, it’s important to be aware that the tool may not be very secure and there may be errors present. It’s crucial to use caution when working with this tool as crashing the LSASS process can compromise the stability of the operating system. Therefore, it’s advisable to be careful and avoid introducing any incorrect addresses or similar. After the module is loaded, it will remain in the LSASS memory until the next system reboot.

The tool can be found here.

Impacket

I have also added six lines of code to the Impacket source code in the computeResponseNTLMv2 function within the ntlm.py file.

The patch is relatively straightforward. If the password is CHALLENGE, it will print out the domain, user, server name, and server challenge in a specific format. This challenge can then be used with the PassTheChallenge tool. The output from PassTheChallenge can then be passed back to Impacket, which will use the challenge response and session key that are computed.

The patched version can be found on my Github page.

Further Research

In this post, we have not yet discussed Kerberos, which will be a focus of future research. If you are interested in researching Credential Guard, you may encounter challenges such as “How to debug LSAIso?” (spoiler alert: I am not aware of a solution). However, I have likely encountered many other challenges and may be able to help. Feel free to reach out to me on Twitter with any questions you may have, regardless of their size, and I will try my best to help.

Pass-the-Challenge: Defeating Windows Defender Credential Guard was originally published in IFCR on Medium, where people are continuing the conversation by highlighting and responding to this story.