{
	"id": "0b3a40c2-15ea-476a-ba46-bc8309949014",
	"created_at": "2026-04-06T00:18:19.632388Z",
	"updated_at": "2026-04-10T13:11:48.491271Z",
	"deleted_at": null,
	"sha1_hash": "2248e0c1a429bbea9896a4fcf442fcaf933f9c49",
	"title": "GitHub - ohpe/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 AUTHORITY\\SYSTEM.",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 174943,
	"plain_text": "GitHub - ohpe/juicy-potato: A sugared version of RottenPotatoNG,\r\nwith a bit of juice, i.e. another Local Privilege Escalation tool, from\r\na Windows Service Accounts to NT AUTHORITY\\SYSTEM.\r\nBy ohpe\r\nArchived: 2026-04-05 19:57:21 UTC\r\nJuicy Potato (abusing the golden privileges)\r\nA sugared version of RottenPotatoNG, with a bit of juice, i.e. another Local Privilege Escalation tool, from a\r\nWindows Service Accounts to NT AUTHORITY\\SYSTEM\r\nSummary\r\nRottenPotatoNG and its variants leverages the privilege escalation chain based on BITS service having the\r\nMiTM listener on 127.0.0.1:6666 and when you have SeImpersonate or SeAssignPrimaryToken privileges.\r\nDuring a Windows build review we found a setup where BITS was intentionally disabled and port 6666 was\r\ntaken.\r\nWe decided to weaponize RottenPotatoNG: Say hello to Juicy Potato.\r\nFor the theory, see Rotten Potato - Privilege Escalation from Service Accounts to SYSTEM and follow\r\nthe chain of links and references.\r\nWe discovered that, other than BITS there are a several COM servers we can abuse. They just need to:\r\n1. be instantiable by the current user, normally a \"service user\" which has impersonation privileges\r\n2. implement the IMarshal interface\r\n3. run as an elevated user (SYSTEM, Administrator, ...)\r\nAfter some testing we obtained and tested an extensive list of interesting CLSID's on several Windows versions.\r\nJuicy details\r\nJuicyPotato allows you to:\r\nTarget CLSID\r\npick any CLSID you want. Here you can find the list organized by OS.\r\nCOM Listening port\r\ndefine COM listening port you prefer (instead of the marshalled hardcoded 6666)\r\nhttps://github.com/ohpe/juicy-potato\r\nPage 1 of 4\n\nCOM Listening IP address\r\nbind the server on any IP\r\nProcess creation mode\r\ndepending on the impersonated user's privileges you can choose from:\r\nCreateProcessWithToken (needs SeImpersonate )\r\nCreateProcessAsUser (needs SeAssignPrimaryToken )\r\nboth\r\nProcess to launch\r\nlaunch an executable or script if the exploitation succeeds\r\nProcess Argument\r\ncustomize the launched process arguments\r\nRPC Server address\r\nfor a stealthy approach you can authenticate to an external RPC server\r\nRPC Server port\r\nuseful if you want to authenticate to an external server and firewall is blocking port 135 ...\r\nTEST mode\r\nmainly for testing purposes, i.e. testing CLSIDs. It creates the DCOM and prints the user of token. See here\r\nfor testing\r\nUsage\r\nT:\\\u003eJuicyPotato.exe\r\nJuicyPotato v0.1\r\nMandatory args:\r\n-t createprocess call: \u003ct\u003e CreateProcessWithTokenW, \u003cu\u003e CreateProcessAsUser, \u003c*\u003e try both\r\n-p \u003cprogram\u003e: program to launch\r\n-l \u003cport\u003e: COM server listen port\r\nOptional args:\r\n-m \u003cip\u003e: COM server listen address (default 127.0.0.1)\r\n-a \u003cargument\u003e: command line argument to pass to program (default NULL)\r\n-k \u003cip\u003e: RPC server ip address (default 127.0.0.1)\r\n-n \u003cport\u003e: RPC server listen port (default 135)\r\n-c \u003c{clsid}\u003e: CLSID (default BITS:{4991d34b-80a1-4291-83b6-3328366b9097})\r\n-z only test CLSID and print token's user\r\nExample\r\nhttps://github.com/ohpe/juicy-potato\r\nPage 2 of 4\n\nFinal thoughts\r\nIf the user has SeImpersonate or SeAssignPrimaryToken privileges then you are SYSTEM.\r\nIt's nearly impossible to prevent the abuse of all these COM Servers. You could think to modify the permissions of\r\nthese objects via DCOMCNFG but good luck, this is gonna be challenging.\r\nThe actual solution is to protect sensitive accounts and applications which run under the * SERVICE accounts.\r\nStopping DCOM would certainly inhibit this exploit but could have a serious impact on the underlying OS.\r\nBinaries\r\nbuild passing\r\nAn automatic build is available. Binaries can be downloaded from the Artifacts section here.\r\nAlso available in BlackArch.\r\nAuthors\r\nAndrea Pierini\r\nGiuseppe Trotta\r\nReferences\r\nRotten Potato - Privilege Escalation from Service Accounts to SYSTEM\r\nWindows: DCOM DCE/RPC Local NTLM Reflection Elevation of Privilege\r\nPotatoes and Tokens\r\nThe lonely Potato\r\nhttps://github.com/ohpe/juicy-potato\r\nPage 3 of 4\n\nSocial Engineering the Windows Kernel by James Forshaw\r\nSource: https://github.com/ohpe/juicy-potato\r\nhttps://github.com/ohpe/juicy-potato\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://github.com/ohpe/juicy-potato"
	],
	"report_names": [
		"juicy-potato"
	],
	"threat_actors": [],
	"ts_created_at": 1775434699,
	"ts_updated_at": 1775826708,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2248e0c1a429bbea9896a4fcf442fcaf933f9c49.pdf",
		"text": "https://archive.orkl.eu/2248e0c1a429bbea9896a4fcf442fcaf933f9c49.txt",
		"img": "https://archive.orkl.eu/2248e0c1a429bbea9896a4fcf442fcaf933f9c49.jpg"
	}
}