Exploitation Tools

Juicy Potato – Another Local Privilege Escalation Tool

Juicy Potato - A Sugared Version Of RottenPotatoNG, With A Bit Of Juice, I.E. Another Local Privilege Escalation Tool, From A Windows Service Accounts To NT AUTHORITYSYSTEM


A sugared version of RottenPotatoNG, with a bit of juice, i.e. another Local Privilege Escalation tool, from a Windows Service Accounts to NT AUTHORITYSYSTEM

RottenPotatoNG and its variants leverages the privilege escalation chain based on BITS service having the MiTM listener on 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:

  1. be instantiable by the current user, normally a “service user” which has impersonation privileges
  2. implement the IMarshal interface
  3. run as an elevated user (SYSTEM, Administrator, …)

After some testing we obtained and tested an extensive list of interesting CLSID’s on several Windows versions.

Juicy details
JuicyPotato allows you to:

  • Target CLSID
    pick any CLSID you want. Here 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 here for testing


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
-a <argument>: command line argument to pass to program (default NULL)
-k <ip>: RPC server ip address (default
-n <port>: RPC server listen port (default 135)
-c <{clsid}>: CLSID (default BITS:{4991d34b-80a1-4291-83b6-3328366b9097})
-z only test CLSID and print token's user


Final thoughts
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 to modify 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.

An automatic build is available. Binaries can be downloaded from the Artifacts section here.
Also available in BlackArch.



About the author

Mazen Elzanaty

Add Comment

Click here to post a comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: