DarthSidious
  • Darth Sidious
  • GETTING STARTED
    • Getting started
    • External network access to Domain Admin
    • Intro to Windows hashes
  • Building a lab
    • Building a lab
    • Preparing Kali
    • Building a small lab
    • Building a lab with ESXI and Vagrant
    • Cuckoo malware analysis lab
  • Initial access
    • Password spraying
    • Initial access through exchange
  • ENUMERATION
    • Powershell
    • BloodHound
    • PowerView
    • Azure enumeration
  • Execution
    • Pass the hash
    • Responder with NTLM relay and Empire
    • DeathStar
    • CrackMapExec
  • Privilege escalation
    • Mimikatz
    • Token Impersonation
    • Juicy Potato
    • ALPC bug 0day
  • Defense evasion
    • Bypassing Applocker and Powershell contstrained language mode
    • From RDS app to Empire shell
    • Stealth
  • OTHER
    • Link encyclopedia
    • Writeups
      • lkylabs v1
    • War stories
      • Domain admin in 30 minutes
  • Credential access
    • Password cracking and auditing
  • Command & Control
    • SILENTTRINITY
Powered by GitBook
On this page
  • How does it work?
  • How to use
  • Mitigation
  1. Privilege escalation

Juicy Potato

Using the juicy potato exploit for privilege escalation

PreviousToken ImpersonationNextALPC bug 0day

Last updated 6 years ago

Juicy potato is basically a weaponized version of the RottenPotato exploit that exploits the way Microsoft handles tokens. Through this, we achieve privilege escalation.

How does it work?

I will admit I am not an expert in Windows internals, but I have tried to understand how this exploit works. A CLSID is a globally unique identifier that identifies a COM class object. The exploit allows us to escalate from service accounts in session 0 to SYSTEM. More to come once I understand it all!

How to use

As we can see, we are on Windows 10 Enterprise 1709, but the OS shouldn't matter. We need to have a shell as a service account. For demo purposes I usednt authority\local service

The only real requirement however, is that the account has the SeAssignPrimaryTokenPrivilege and/or SeImpersonatePrivilege which most service accounts do have.

PsExec64.exe -i -u "nt authority\local service" cmd.exe

Now we run the exploit by specifiying a COM port of 1337, and executing the process cmd.exe trying both techniques CreateProcessWithTokenW, CreateProcessAsUser A shell pops as nt authority\system

juicypotato.exe -l 1337 -p c:\windows\system32\cmd.exe -t * -c {F87B28F1-DA9A-4F35-8EC0-800EFCF26B83}

Mitigation

According to the creators, the actual solution is to protect sensitive accounts and applications which run under the * SERVICE accounts.

To try this yourself, you can open a shell as the service account using from Microsoft Sysinternals as displayed in the screenshot below.

We then pick a CLSID from . Interesting note: Numerous CLSIDs belong to LOGGED-IN-USER, so if you select this use this and a domain admin is logged in you can basically escalate directly to DA. However, it will only get the user of the first session (1). Finding a way to predict which user that is will require further testing. Either way, SYSTEM level privileges will get you where you want.

This can't simply be patched. It's due to how service accounts needing to impersonate users when is enabled.

psexec
here
kerberos delegation
Juicy Potato (abusing the golden privileges)juicy-potato