HTB | Fluffy

This is a Windows box, you can find it here

IP - 10.129.116.225

MACHINE INFORMATION - As is common in real life Windows pentests, you will start the Fluffy box with credentials for the following account: j.fleischman / J0elTHEM4n1990!

NMAP

└─$ nmap -sT -p- --min-rate 10000 10.129.116.225 -Pn -oA nmap_ports                                                                                    
Starting Nmap 7.95 ( <https://nmap.org> ) at 2025-05-25 13:09 IST
Nmap scan report for 10.129.116.225
Host is up (0.26s latency).
Not shown: 65518 filtered tcp ports (no-response)
PORT      STATE SERVICE
53/tcp    open  domain
88/tcp    open  kerberos-sec
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
3268/tcp  open  globalcatLDAP
5985/tcp  open  wsman
9389/tcp  open  adws
49667/tcp open  unknown
49677/tcp open  unknown
49678/tcp open  unknown
49680/tcp open  unknown
49698/tcp open  unknown
49713/tcp open  unknown
49747/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 103.04 seconds

LDAP

SMB

We have Read, Write on share IT

Let’s login to smb share

Let’s download everything

Foothold/shell

CVE-2025-24071

the pd Upgrade_Notice.pdf contains the report of vulnerability scans

Let’s look at the critical CVE first

Found this repo for CVE-2025-24071

Technical Explanation of NTLM Hash Leak via RAR/ZIP Extraction and .library-ms File (CVE-2025-24071)

When a specially crafted .library-ms file containing an SMB path is compressed within a RAR/ZIP archive and subsequently extracted, Windows Explorer automatically parses the contents of this file due to its built-in indexing and preview mechanism. This behaviour occurs because Windows Explorer processes certain file types automatically upon extraction to generate previews, thumbnails, or index metadata, even if the file is never explicitly opened or clicked by the user.

The .library-ms file format is XML-based and is trusted by Windows Explorer to define search and library locations. Upon extraction, the indexing service and Explorer’s built-in file parsing mechanism immediately analyze the .library-ms file content to render appropriate icons, thumbnails, or metadata information.

The provided file contains a <simpleLocation> tag pointing directly to an attacker-controlled SMB server:

Upon extraction, Windows Explorer attempts to resolve this SMB path (\\\\192.168.1.116\\shared) automatically to gather metadata and index file information. This action triggers an implicit NTLM authentication handshake from the victim's system to the attacker-controlled SMB server. Consequently, the victim's NTLMv2 hash is sent without explicit user interaction.

This vulnerability arises because Windows Explorer implicitly trusts .library-ms files and automatically processes certain file types immediately upon their extraction from archives. Attackers exploit this implicit trust and automatic file processing behaviour to leak credentials, which can then be utilized for pass-the-hash attacks or offline NTLM hash cracking.

Now, in order to exploit this, we need to run Responder.

Let's run the PoC

After running the PoC we get an exploit.zip file.

Let's use SMB to upload this file onto the IT SMB share.

After waiting for 1 minute, we get a connection back on our responder

Cracking this NTLM hash on hashcat.

we got the password

GenericAll

Since we have valid cred we can use bloodhound

We can see that P.AGILA → MemberOf → SERVERCE ACCOUNT MANAGERS → GenericAll → SERVICE ACCOUNT

This is also known as full control. This privilege allows the trustee to manipulate the target object however they wish.

Now we can either:

  • Reset SERVICE ACCOUNT password (loud), OR

  • Add a Shadow Credential (quiet).

Shadow Credential

What is a Shadow Credentials Attack?

The Shadow Credentials attack is a stealthy method that allows an attacker to impersonate any user in Active Directory by silently adding a certificate-based authentication backdoor to their account — without changing their password or hash.

This method takes advantage of Key Trust-based certificate authentication in Active Directory environments that support PKINIT (Public Key Cryptography for Initial Authentication) and involves modifying a special attribute called msDS-KeyCredentialLink on the target user object.

Why we use Shadow Credential?

Traditional Attack
Shadow Credentials

Reset password (loud)

Add certificate (quiet)

Triggers logs, breaks services

Leaves user untouched

High chance of detection

Very stealthy

Short-term access

Can provide persistent access

Shadow Credentials is often used to maintain persistence or escalate privileges without being detected.

How does it works?

  • Generate a key pair and certificate request

  • Inject the certificate’s public key into the msDS-KeyCredentialLink attribute of the target account in AD

  • Use the private key (PFX) to authenticate as that user via Kerberos PKINIT

  • You are now authenticated as the victim user, with no password, no hash, and no alerts

Prerequisites for Shadow Credential Attack

To perform this attack, the following are required:

  • The target account must be a user account (not a computer)

  • The attacker must have permissions to write to the msDS-KeyCredentialLink attribute of the target (e.g., GenericWrite, GenericAll, WriteProperty, etc.)

  • The domain must support Key-based authentication (default in modern AD environments)

Shadow Credential Attack our My Case

In our scenario, we had control of the user P.AGILA.

Analyzing ACLs via BloodHound revealed:

  • P.AGILA is a member of a group with GenericAll rights over the SERVICE ACCOUNT user

  • SERVICE ACCOUNT is a normal user account (not a computer)

  • GenericAll includes WriteProperty permission, which allows modification of the msDS-KeyCredentialLink attribute

But first we need to add p.aglia to the SERVICE ACCOUNT MANAGERS group

Now let's try and do a Shadow Credential attack against winrm_svc (since winrm_svc is a member of REMOTE MANAGEMENT USERS)

Now we have a hash for winrm_svc

Let's try winrm with this hash.

we are in and got the user.txt

Privilege Escalation

ESC16

On running certipy with -vulnerable we didn’t find any vulnerability but Under the "Certificate Authorities" section for the target CA, we can see the OID 1.3.6.1.4.1.311.25.2 in the Disabled Extensions list. For more reference refer this

Steps to exploit:

  • Change the victim account's UPN to match a target privileged(administrator in our case) account's sAMAccountName.

  • Request a certificate (which will automatically lack the SID security extension due to the CA's ESC16 configuration).

  • Revert the UPN change.

  • Use the certificate to impersonate the target.

Let’s start the exploit

Before we start we need to obtain credentials for the ca_svc account (via Shadow Credentials).

Let’s first try to read initial UPN of the victim account

Since we can now read ca_svc now we have to modify ca_svc's upn to be Administrator.

Next we can request the certificate using the vulnerable User template.

Now let's give ca_svc its original UPN back.

And let's authenticate with the pfx certificate we just grabbed.

We can winrm via the hash and get the root.txt

PreviousHTB | PuppyNextHTB | Certificate

Last updated