JuicyPotato
Last updated
Was this helpful?
Last updated
Was this helpful?
A sugared version of , with a bit of juice, i.e. another Local Privilege Escalation tool, from a Windows Service Accounts to NT AUTHORITY\SYSTEM
and its leverages the privilege escalation chain based on 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 : Say hello to Juicy Potato.
For the theory, see 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:
be instantiable by the current user, normally a “service user” which has impersonation privileges
implement the IMarshal
interface
run as an elevated user (SYSTEM, Administrator, …)
After some testing we obtained and tested an extensive list of on several Windows versions.
JuicyPotato allows you to:
Target CLSID pick any CLSID you want. you can find the list organized by OS.
COM Listening port define COM listening port you prefer (instead of the marshalled hardcoded 6666)
COM Listening IP address bind the server on any IP
Process creation mode depending on the impersonated user’s privileges you can choose from:
CreateProcessWithToken
(needs SeImpersonate
)
CreateProcessAsUser
(needs SeAssignPrimaryToken
)
both
Process to launch launch an executable or script if the exploitation succeeds
Process Argument customize the launched process arguments
RPC Server address for a stealthy approach you can authenticate to an external RPC server
RPC Server port useful if you want to authenticate to an external server and firewall is blocking port 135
…
TEST mode mainly for testing purposes, i.e. testing CLSIDs. It creates the DCOM and prints the user of token. See
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.
Oftentimes, the default CLSID that JuicyPotato uses doesn't work and the exploit fails. Usually, it takes multiple attempts to find a working CLSID. To get a list of CLSIDs to try for a specific operating system, you should visit this page:
First, you will need some executables apart from juicypotato.exe.
Check the working CLSIDs using the parameter -c
From:
Note: Visit for a list of CLSIDs to try.
Download and load it into your PS session, and download and execute . That script will create a list of possible CLSIDs to test.
Then download (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.