Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/windows-hardening/active-directory-methodology/acl-persistence-abuse/shadow-credentials.md
CPol bd0b87e02c
GitBook: [#3592] No subject
2022-10-10 21:08:59 +00:00

8.8 KiB
Raw Blame History

Shadow Credentials

Support HackTricks and get benefits!

Intro

Check the original post for all the information about this technique.

As summary: if you can write to the msDS-KeyCredentialLink property of a user/computer, you can retrieve the NT hash of that object.

This is because you will be able to set public-private key authentication credentials for the object and use them to obtain a special Service Ticket that contains its NTLM hash inside the Privilege Attribute Certificate (PAC) in an encrypted NTLM_SUPPLEMENTAL_CREDENTIAL entity that you can decrypt.

Requirements

This technique requires the following:

  • At least one Windows Server 2016 Domain Controller.
  • A digital certificate for Server Authentication installed on the Domain Controller.
  • Windows Server 2016 Functional Level in Active Directory.
  • Compromise an account with the delegated rights to write to the msDS-KeyCredentialLink attribute of the target object.

Abuse

Abusing Key Trust for computer objects requires additional steps after obtaining a TGT and the NTLM hash for the account. There are generally two options:

  1. Forge an RC4 silver ticket to impersonate privileged users to the corresponding host.
  2. Use the TGT to call S4U2Self to impersonate privileged users to the corresponding host. This option requires modifying the obtained Service Ticket to include a service class in the service name.

Key Trust abuse has the added benefit that it doesn’t delegate access to another account which could get compromised — it is restricted to the private key generated by the attacker. In addition, it doesn’t require creating a computer account that may be hard to clean up until privilege escalation is achieved.

Whisker

Alongside this post I am releasing a tool called “ Whisker “. Based on code from Michael’s DSInternals, Whisker provides a C# wrapper for performing this attack on engagements. Whisker updates the target object using LDAP, while DSInternals allows updating objects using both LDAP and RPC with the Directory Replication Service (DRS) Remote Protocol.

Whisker has four functions:

  • Add — This function generates a public-private key pair and adds a new key credential to the target object as if the user enrolled to WHfB from a new device.
  • List — This function lists all the entries of the msDS-KeyCredentialLink attribute of the target object.
  • Remove — This function removes a key credential from the target object specified by a DeviceID GUID.
  • Clear — This function removes all the values from the msDS-KeyCredentialLink attribute of the target object. If the target object is legitimately using WHfB, it will break.

Whisker

Whisker is a C# tool for taking over Active Directory user and computer accounts by manipulating their msDS-KeyCredentialLink attribute, effectively adding "Shadow Credentials" to the target account.

Whisker has four functions:

  • Add — This function generates a public-private key pair and adds a new key credential to the target object as if the user enrolled to WHfB from a new device.
  • List — This function lists all the entries of the msDS-KeyCredentialLink attribute of the target object.
  • Remove — This function removes a key credential from the target object specified by a DeviceID GUID.
  • Clear — This function removes all the values from the msDS-KeyCredentialLink attribute of the target object. If the target object is legitimately using WHfB, it will break.

Add

Add a new value to the msDS-KeyCredentialLink attribute of a target object:

  • /target:<samAccountName>: Required. Set the target name. Computer objects should end with a '$' sign.
  • /domain:<FQDN>: Optional. Set the target Fully Qualified Domain Name (FQDN). If not provided, will try to resolve the FQDN of the current user.
  • /dc:<IP/HOSTNAME>: Optional. Set the target Domain Controller (DC). If not provided, will try to target the Primary Domain Controller (PDC).
  • /path:<PATH>: Optional. Set the path to store the generated self-signed certificate for authentication. If not provided, the certificate will be printed as a Base64 blob.
  • /password:<PASWORD>: Optional. Set the password for the stored self-signed certificate. If not provided, a random password will be generated.

Example: Whisker.exe add /target:computername$ /domain:constoso.local /dc:dc1.contoso.local /path:C:\path\to\file.pfx /password:P@ssword1

{% hint style="info" %} More options on the Readme. {% endhint %}

ShadowSpray

In several cases, the group "Everyone" / "Authenticated Users" / "Domain Users" or some other wide group contains almost all the users in the domain has some GenericWrite/GenericAll DACLs over other objects in the domain. ShadowSpray tries to abuse therefore ShadowCredentials over all of them

It goes something like this:

  1. Login to the domain with the supplied credentials (Or use the current session).
  2. Check that the domain functional level is 2016 (Otherwise stop since the Shadow Credentials attack won't work)
  3. Gather a list of all the objects in the domain (users and computers) from LDAP.
  4. For every object in the list do the following:
    1. Try to add KeyCredential to the object's msDS-KeyCredentialLink attribute.
    2. If the above is successful, use PKINIT to request a TGT using the added KeyCredential.
    3. If the above is successful, perform an UnPACTheHash attack to reveal the user/computer NT hash.
    4. If --RestoreShadowCred was specified: Remove the added KeyCredential (clean up after yourself...)
  5. If --Recursive was specified: Do the same process using each of the user/computer accounts we successfully owned.

References

Support HackTricks and get benefits!