Black Box Assessment — Windows Server 2016 Host

Scope of Work

The client requested a black box assessment of a single virtual host, simulating the perspective of an external attacker with no prior knowledge of the environment. No credentials, architecture diagrams, or application documentation were provided ahead of the engagement.

The client asked that manual exploitation be attempted first, with automated tools and techniques permitted where manual methods were impractical. Only the IP address assigned to the target machine was in scope. The client requested that all discovered vulnerabilities be documented — not only the path used to reach root — since more than one path to full compromise was known to exist in this environment.

Two flags were defined as proof of successful exploitation:

• User.txt
• Root.txt

---

Executive Summary

The assessment identified a critical path to full system compromise, driven by two chained weaknesses: an anonymously accessible SMB file share that permitted upload of an executable web shell to a location served by the host's web server, and a locally assigned SeImpersonatePrivilege token on the resulting service account that allowed escalation to NT AUTHORITY\SYSTEM.

Both the user-level and root-level flags were recovered. The chain required no credentials and no client-side interaction, and is assessed as Critical severity given the combination of unauthenticated initial access and trivial escalation to full system privileges.

Finding	Severity
Anonymous SMB share permitting file upload to a web-accessible path	Critical
Unrestricted file upload leading to remote code execution (web shell)	Critical
Local privilege escalation via SeImpersonatePrivilege (Potato-family exploit)	High

---

Reconnaissance

Port & Service Enumeration

An initial full-port TCP scan was run against the assigned target IP using Nmap, with service/version detection and default script scanning enabled:

nmap --privileged -sC -sV -sS -O -oN relevantFull -p- <target-ip>

The scan returned the following relevant open ports:

Port	Service	Notes
80/tcp	HTTP	Microsoft IIS 10.0, TRACE method enabled
135/tcp	MSRPC	Standard Windows RPC endpoint mapper
139/tcp	NetBIOS-SSN
445/tcp	SMB	Windows Server 2016 Standard (build 14393)
3389/tcp	RDP	NTLM info disclosed hostname/domain
49663/tcp	HTTP	Secondary IIS instance, TRACE enabled
49666, 49667/tcp	MSRPC	Dynamic RPC ports

The combination of SMB (445) and a second, higher-numbered IIS instance (49663) stood out as the most likely initial access surface — a Windows Server 2016 box exposing SMB externally is a strong signal to check for weak share permissions before anything else.

SMB Enumeration

Anonymous/null session enumeration against SMB revealed an accessible, non-default share:

smbclient -L //<target-ip>/ -N
...
Sharename       Type      Comment
---------       ----      -------
nt4wrksv        Disk

The nt4wrksv share permitted anonymous connection and, critically, allowed write access — meaning files could be uploaded to it without any authentication.

Web Enumeration

The secondary IIS instance on port 49663 was checked against the same directory structure implied by the SMB share name. The share's contents were found to be served directly by this web instance, meaning any file written to nt4wrksv over SMB became immediately reachable over HTTP.

---

Exploitation — Initial Access

An ASPX-based reverse shell payload was generated and uploaded to the nt4wrksv share over the anonymous SMB session:

smbclient //<target-ip>/nt4wrksv -N
smb: \> put shell.aspx

With a listener staged locally, the uploaded payload was triggered by requesting it directly through the web server on port 49663:

curl http://<target-ip>:49663/shell.aspx

This returned a reverse shell connection to the listener, executing in the context of the IIS application pool account.

---

Exploitation — Privilege Escalation

With an initial foothold established, the current account's privileges were enumerated:

whoami /priv

The output confirmed SeImpersonatePrivilege was enabled for the shell's context — a common configuration for IIS application pool identities, and a well-known escalation path on Windows Server builds predating the relevant token-handling fixes.

PrintSpoofer was transferred to the host and executed to abuse this privilege directly:

PrintSpoofer.exe -i -c cmd

This returned a shell running as NT AUTHORITY\SYSTEM, confirming full system compromise.

---

Additional Findings

The client noted that more than one path to full compromise exists in this environment. Only the path actually executed during this assessment — anonymous SMB write access chained with SeImpersonatePrivilege abuse via PrintSpoofer — is documented above with full technical detail, in line with what was verified firsthand.

Given that SeImpersonatePrivilege escalation is exploitable via multiple tools targeting the same underlying token abuse (PrintSpoofer, and other Potato-family variants), it is likely that at least one alternate escalation route exists using a different tool against the same misconfiguration, rather than a structurally distinct vulnerability. This should be confirmed in a follow-up pass rather than assumed.

Additionally, the following lower-priority observations were made during the assessment and are worth remediating alongside the primary findings:

• HTTP TRACE method enabled on both IIS instances (ports 80 and 49663) — while not directly exploited in this engagement, this can facilitate Cross-Site Tracing (XST) attacks in certain browser/application contexts and should be disabled.
• RDP service (3389) exposed externally with NTLM information disclosure, revealing internal hostname and domain naming — useful reconnaissance data for an attacker even without a direct exploit path.

---

Remediation Recommendations

1. Restrict SMB share permissions. Remove anonymous/null session access to all shares, and ensure no share used for application content is writable by unauthenticated users.
2. Separate storage from web-served paths. File shares should never share a physical directory with a path served directly by a web application. If shared storage must back a web app, mediate access through the application layer rather than direct filesystem overlap.
3. Restrict SeImpersonatePrivilege. Remove this privilege from service accounts that do not explicitly require it, and apply current Windows patches addressing known Potato-family token abuse paths.
4. Disable HTTP TRACE on both IIS instances via web.config or server-level configuration.
5. Review external exposure of RDP. If remote administration is required, restrict access via VPN or IP allowlisting rather than direct internet exposure.