Welcome to another Hack the Box exercise. In this blog post, I will show you how I pwned the Fluffy machine on Hack the Box. Hack The Box is a cybersecurity platform that helps you bridge knowledge gaps and prepares you for cyber security jobs. You can also test and grow your penetration testing skills, from gathering information to reporting. If you are new to this blog, please do not forget to like, comment, and subscribe to my YouTube channel (https://www.youtube.com/@BoltechTechnologies1) and also follow me on LinkedIn (https://www.linkedin.com/in/isiaq-ibrahim-468588156/) for more updates.
About the Machine
Fluffy is an easy-rated Windows machine on Hack the Box that takes players through a well-structured series of Active Directory exploitation techniques, emphasizing real-world misconfigurations in a corporate domain environment.
The box begins with SMB enumeration using valid credentials to access interesting files, including a PDF that references a real-world CVE—CVE-2025-24071, which involves NTLM hash leakage through .library-ms files. Leveraging this, the player captures NTLMv2 hashes using Responder, and cracks them with John the Ripper using the rockyou.txt wordlist.
With cracked credentials in hand, the user performs BloodHound enumeration via bloodhound-python to map out the AD environment, and uses bloodyAD to add a compromised user to a privileged group (SERVICE ACCOUNTS), exploiting misconfigured permissions.
The highlight of the machine revolves around Active Directory Certificate Services (AD CS) abuse. Using Certipy’s Shadow Credentials technique, the player escalates to the winrm_svc account, retrieves its NT hash, and gains remote shell access via Evil-WinRM.
Further escalation involves another Shadow Credentials attack against the ca_svc account. After modifying its userPrincipalName to administrator, a certificate is requested on its behalf—essentially granting full Domain Admin access. This final step involves requesting and using the certificate to extract the NT hash for the Administrator account and remotely execute commands with impacket-psexec, leading to the retrieval of root.txt.
The first step in pwning the Fluffy machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, you need to run the following command in your terminal:
This established a secure tunnel (tun0) to the HTB network using AES-256-CBC encryption and SHA256 authentication. I was assigned the IP 10.10.14.130 and received routes to internal labs. Once the initialization was complete, I could start enumerating and attacking the target machine from inside the HTB network.
Once the connection was successful, I started the target machine and I was assigned an IP address 10.10.11.69. The next step was performing enumeration using Nmap, I started by running a service and OS detection scan:
The scan revealed a Windows Domain Controller (DC01.fluffy.htb) with key ports open for DNS, Kerberos, LDAP, SMB, and WinRM. These confirmed the presence of an Active Directory environment. Based on the exposed services, I began enumerating SMB and LDAP for users and potential credentials, with an eye on leveraging Kerberos for ticket-based attacks.
Since many Kerberos-based operations depend on accurate time synchronization, I synced my machine’s clock with the Domain Controller using:
This adjusted my system time by several hours to match the DC's clock, resolving any potential time skew issues that could prevent Kerberos authentication or ticket validation during certificate-based exploitation. Next, I attempted to use smbmap, a tool for enumerating SMB shares and their permissions. I ran the following command in my terminal:
The IT share was found to be readable and writable, which made it a prime target for file enumeration and potential file upload (e.g., for initial access). Additionally, I noted that NETLOGON and SYSVOL were accessible in read-only mode, which suggested the presence of a Windows Active Directory environment and could later be leveraged for GPP or script-based enumeration.
1. IT share is both readable and writable:
- You can download files (smbclient, smbget) and upload payloads (e.g., reverse shells or malicious scripts).
- Good candidate for initial foothold or lateral movement.
2. NETLOGON and SYSVOL:
- These are standard shares on Domain Controllers.
- May contain GPP (Group Policy Preferences) files with encrypted credentials (Groups.xml), or scripts that leak information (like domain users, passwords, or PowerShell scripts).
3. IPC$ (Read Only):
- May allow for named pipe attacks (e.g., using rpcclient or smbexec) if additional access is gained later.
Afterward, I authenticated to the SMB share \\10.10.11.69\IT using the credentials written on the machines page (J0elTHEM4n1990!) for j.fleischman by running:
Listing the directory revealed a number of files and folders, including a KeePass archive and a PDF file:
- KeePass-2.58.zip
- Upgrade_Notice.pdf
- Everything-1.4.1.1026.x64.zip
I proceeded to download these files for offline analysis, looking for credentials or additional system information that could be leveraged further in the attack chain.
I downloaded the Upgrade_Notice.pdf, and found out that the PDF contains information about several recent vulnerabilities like CVE-2025-24996, CVE-2025-24071, CVE-2025-46785, CVE-2025-29968, CVE-2025-21193, and CVE-2025-3445 with severity from critical to low. (Note: To download the PDF, run get Upgrade_Notice.pdf in the shell and this will save the PDF file in the directory you are currently working in. You can also download the other files and check what's in them.)
Reading through the CVE's, one that stood out was CVE-2025-24071, which describes a vulnerability in Windows Explorer where simply extracting a .library-ms file from a ZIP or RAR archive could leak the user's NTLM hash via a crafted SMB path.
I searched for the CVE-2025-24071 on google and found a GitHub repository, then cloned it and navigated into it to run the proof of concept Python file (poc.py). I cloned the repository using:
When I ran the poc.py, I was prompted to enter the name of my file and I entered documents. Next, it prompted me to enter IP address, using ifconfig, I found the tun0 IP address 10.10.14.81 and entered it.
Next, I set up a Responder listener to capture any authentication attempts from the target:
- LLMNR (Link-Local Multicast Name Resolution)
- NBT-NS (NetBIOS Name Service)
- MDNS (Multicast DNS)
- WPAD (Web Proxy Auto-Discovery)
After placing a malicious .library-ms file in the writable IT share and waiting for extraction, the target system attempted to authenticate back to my machine via SMB. Responder intercepted the traffic and successfully captured several NTLMv2 hashes:
I saved the hash and attempted cracking it using john with a common wordlist:
John successfully recovered the plaintext password:
- Username: p.agila
- Password: prometheusx-303
With these credentials, I was now able to authenticate against SMB and WinRM for further enumeration and privilege escalation.
Using the credentials harvested from the NTLMv2 hash (user: p.agila, password: prometheusx-303), I authenticated against the domain and used bloodhound-python to enumerate Active Directory:
This collected:
- 10 users
- 54 groups
- 2 GPOs
- 1 computer (DC01)
- All relevant AD relationships
The results were saved into a .zip archive for analysis in the BloodHound GUI. Using BloodHound GUI, I found that the user P.AGILA@FLUFFY.HTB is a member of SERVICE ACCOUNT MAGAGERS@FLUFFY.HTB and its generic to SERVICE ACCOUNT@FLUFFY.HTB.
I noticed that the user p.agila can be added to the user group. SERVICE ACCOUNTS@HTB has relationship with WINRM_SVC@FLUFFY.HTB, LDAP_SVC@FLUFFY.HTB, CA_SVC@FLUFFY.HTB. The group has write permissions service for the user CA_SVC.
I used bloodyAD to attempt a privilege escalation by adding my compromised user p.agila to the SERVICE ACCOUNTS group. Since the user had sufficient rights (likely WriteMembers or GenericWrite), the command executed successfully:
This allowed me to escalate my access and prepare for further exploitation such as delegation abuse or service impersonation.
I used Certipy to perform a Shadow Credentials attack against the service account WINRM_SVC. Since my compromised user p.agila had write access to the target’s msDS-KeyCredentialLink, I was able to inject a certificate, authenticate as WINRM_SVC, and extract its NTLM hash without needing its password:
The NT hash for WINRM_SVC was retrieved: 33bd09dcd697600edf6b3a7af4875767. This gave me full control of the account and the ability to pivot or escalate further. With the NTLM hash of the winrm_svc user (33bd09dcd697600edf6b3a7af4875767) obtained via Shadow Credentials, I launched a remote shell using Evil-WinRM. Evil-WinRM is a post-exploitation tool that allows remote PowerShell access to a Windows host over WinRM (Windows Remote Management).
After successfully authenticating, I navigated to the user's desktop and retrieved the user flag:
- cd ../desktop
- ls
- cat user.txt
Hurray!!! I got the user flag
After compromising the p.agila user and being added to the SERVICE ACCOUNTS group (which had write permissions over other users), I launched a Shadow Credentials attack on the ca_svc account using Certipy:
This allowed me to perform subsequent actions as ca_svc by reusing the existing Kerberos tickets without needing the password.
Using Certipy, I enumerated Active Directory Certificate Services (AD CS) as the ca_svc user. The tool discovered one Certificate Authority (fluffy-DC01-CA) and multiple certificate templates, but none appeared immediately vulnerable or allowed web enrollment. However, a security extension (ESC16) was disabled, indicating a potential misconfiguration that might be exploitable with additional research or in conjunction with other findings.
I enumerated the attributes of the ca_svc account using Certipy to validate its SPN (ADCS/ca.fluffy.htb), UPN, and SID. This step confirmed that the account was associated with Active Directory Certificate Services and could be used in further certificate-based attacks. The userAccountControl flag also revealed that the password never expires, reducing the chance of operational disruption when impersonating this account.
Using Certipy, I enumerated the ca_svc user account attributes in Active Directory. This account is a service account for the AD Certificate Services (servicePrincipalName: ADCS/ca.fluffy.htb). The user account is active and appears to be linked with the certificate authority infrastructure, making it an important target for further privilege escalation or certificate-based attacks.
I used Certipy to update the ca_svc account’s User Principal Name (UPN) to administrator. Changing the UPN can be useful for abusing Kerberos or certificate-based authentication flows, possibly enabling privilege escalation or bypassing certain controls related to the original service account name.
After modifying the ca_svc account's UPN to administrator, I leveraged Certipy to request a certificate using the User template from the CA fluffy-DC01-CA. Since the UPN was now set to administrator, the certificate was issued with elevated privileges. The resulting .pfx file can be used to impersonate the domain administrator and obtain a Kerberos TGT without needing the actual administrator password.
After obtaining control over the ca_svc account, I changed its UPN to administrator, allowing me to request a certificate and impersonate the domain administrator (ESC8 abuse). Once I obtained and used the certificate to elevate privileges, I reverted the UPN to ca_svc@fluffy.htb using Certipy to reduce footprint and maintain operational stealth.
To finalize privilege escalation, I used the administrator.pfx file (obtained via ESC8) to authenticate as the Domain Administrator. Using Certipy, I authenticated against the DC and successfully retrieved the TGT and NTLM hash for administrator, confirming full domain compromise.
With the NT hash aad3b435b51404eeaad3b435b51404ee:8da83a3fa618b6e3a00e93f676c92a6e, I can now perform pass-the-hash attacks or dump secrets from the domain controller.
With the NT hash of DA (aad3b435b51404eeaad3b435b51404ee:8da83a3fa618b6e3a00e93f676c92a6e) that I have obtained via certificate abuse, I used impacket-psexec to perform a Pass-the-Hash attack and gain remote command execution as Administrator by running the following in the terminal:
After successfully executing commands on the system, I navigated to the Administrator’s desktop and retrieved the final flag:
- cd C:\Users\Administrator\Desktop
- dir
- type root.txt
Hurray!!! I got the root flag.
Don't forget to subscribe to my mailing list and also follow me on my social media pages to get immediate notifications when I publish a new writeup. My socials are:
YouTube: https://www.youtube.com/@BoltechTechnologies1
LinkedIn: https://www.linkedin.com/in/isiaq-ibrahim-468588156/
Twitter: https://x.com/Isiaq_Ibrahim99
Twitter: https://x.com/BoltechNG
Medium: https://medium.com/@ibrahimbolaji50.ib
0 Comments