HackTheBox Write-Up - Help

(Presumptuous Commoner) #1

Welcome to another HackTheBox write-up. This week’s write-up is special; Help was the first box I ever attempted, and I did it all on my own before I started doing HackTheBox with 0x00sec. Emotional moments aside, let’s get started.

You know the drill. We start with Nmap.

nmap -sC -sV -oA Help


-sC - Script scanning using the default script list.
-sV - Attempts version detection of protocols/applications during scan.
-oA - Output files in all formats
Help - The name of the files for -oA output. - The target machine’s IP address.

This was my first box, so I ended up in a rabbit hole on port 3000 (which isn’t actually a rabbit hole, as it turns out, as there are multiple paths to owning this box), then tried some silliness with OpenSSH exploits to enumerate users on SSH. Like I said, it was my first box.

Eventually, I got smart and ran dirb (I did not know about gobuster at the time).

dirb http://help.htb/ /usr/share/wordlists/dirb/small.txt -o Help.dirb


hxxp://help.htb/ - Specifies the URL to run dirb against.
/usr/share/wordlists/dirb/small.txt - Specifies the wordlist to use for brute-forcing directories. I find that small.txt is a good, default starting point for me. If needed, I can work my way up to bigger wordlists, but it hasn’t been necessary for me up to this point.
-o - Specifies the ouput file name.

The directory I became interested in was /support. I browsed to that page:

I saw some input fields, so I started running a bunch of tools I had no business running (such as sqlmap). Eventually, I got wise and turned to searchsploit:

There is an arbitrary file upload exploit available.

I had never exploited anything up to this point, if I’m honest, so I had no clue what was going on. I got the general idea, having watched some IppSec videos. I tried using the exploit, but all my attempts to upload my chosen PHP shell as an attachment to the ticket failed.


I tried renaming the file using all the tricks (shell.php.jpg, shell.php1, using null bytes, etc.) I tried editing the magic number bytes of the file to make it look like a JPG, I tried using Burp to intercept the request and convince the page that I was uploading a JPG file, but nothing worked. After a bit more research, I realized how the exploit works.

Quite simply, despite the fact that the page tells us that the attachment type was not allowed, it still writes the file to the disk. However, it “randomly” renames it so we can’t just execute it after the fact. The problem is that the renaming of the file is not as random as the developers would have liked, so we can predict it and call our file via it’s new name and path. That’s where the exploit itself comes in. Let’s review the source code snippet of the HelpDeskZ application inside the script so we can understand what’s happening. We’ll then review the script itself.

Here’s the important bit from the source:

$filename = md5($_FILES['attachment']['name'].time())...$ext;

That may be enough for you to understand the problem. Either way, let’s look at the exploit to see how we’re going to weaponize our newfound knowledge.

print "Usage: {} [baseUrl] [nameOfUploadedFile]".format(sys.argv[0])

This is just the usage portion of the script, but it’s important to note the inputs to understand what the script will do. The base URL is easy, as the script needs to know where the file was uploaded so it can print the correct full path when finished. The filename is interesting, though. Since the file is renamed after upload, why would knowing the original filename be important? We’ll see shortly.

NOTE: The comments in the script included in Kali are not exactly accurate. The full path required to leverage this exploit is hxxp:// How did I figure this out? I reviewed the source of HelpDeskZ on GitHub:


NOTE (continued): If you combine this line with our dirb output, you’ll work out that the path where attachments are finally written is hxxp://

Let’s review the exploit:

currentTime = int(time.time())

The comment here should be obvious; we’re pulling the current time from our machine. Even more interesting.

NOTE: The version of the exploit included in Kali pulls the time from your attacking machine, as noted above. This means the time on your local machine must match the server, or the script won’t work. You can verify it with the below command, or use the version of the exploit on Exploit-DB, which gets the time from the server itself. Be forewarned, though, that the version of the script on Exploit-DB may not run in it’s raw form for you. You could, of course, combine the two scripts. Just a thought.

curl -I http://help.htb

Moving deeper into the script:

for x in range(0, 300):
    plaintext = fileName + str(currentTime - x)
    md5hash = hashlib.md5(plaintext).hexdigest()

    url = helpdeskzBaseUrl+md5hash+'.php'
    response = requests.head(url)
    if response.status_code == 200:
        print "found!"
        print url

Here’s the rundown. We’re taking the name of the file, plus the current time, and storing it as a string (we have some offset of the current time less our current x value, which is any number between 0-300; we need this to deal with delays and time differences; essentially, we’re looping through our calculation 300 times to get 300 different values.) We then take the md5 value of that string. This is our file name. The script will try the full URL with all 300 filename variants and report which one returns an HTTP reponse code of 200. This is our uploaded shell’s URL path.

NOTE: Because time is such a sensitive factor in this exploit, it is imperative that you have your exploit primed and ready to launch as soon as you upload the file. You’ve got a small window to work with if your 300 requests are to fall within the same time frame as your file upload; of course, you can also edit the exploit script yourself to make it more forgiving, but that means more requests and a longer run time. Pick your battles, as your mileage may vary.

Assuming all went well, you should have the URL of your uploaded shell.

Set up a listener to catch your reverse shell:

nc -lp 2113


-l - Listen mode.
-p 2113 - Specifies the port on which to listen.

Now browse to the URL path of your shell. If done correctly, your listener should now be connected. Grab your user flag and prepare to move on to root.

Considering this was my first box, I am surprised I got to root as quickly as I did. This box predates my knowledge of popular Linux enumeration tools like Linenum and pspy. Instead, I poked around files a bit, then checked the version of Linux installed:

uname -a


-a - Tells uname to print all details.

We see the installed version of Linux. That knowledge in hand, we consult searchsploit yet again and locate CVE-2017-16995, a local privilege escalation exploit.

Once again I allowed my inexperience to waste my time; I went through the whole process of re-abusing the file upload vulnerability to get the .c file for compiling the exploit onto the victim machine. I could’ve done something much simpler, like hosting a python SimpleHTTPServer on my attacking machine. I can’t remember if this didn’t work for me or if I didn’t try it, but when I ran through this box again for this write-up it worked without any issue.

With the .c file successfully transferred to the victim, we can simply run the below command to compile the executable:

make 44298.c

By default, this creates a file called a.out. We then run chmod +x a.out to grant executable permissions to the file. Then, run the file with ./a.out, and you’ll have your root shell!


And that is it for this box. I would like to note that other 0x00sec members have mentioned that they had different paths for both user and root, so please know that these may not be the only paths to success on this box. Perhaps those members might take the time to comment below with their paths; if not, it’s up to you to try harder and find new ways to win.

Thanks for sticking with me through this one. I’ll see you next time!



This is one of the hardest boxes I have done yet, took me ages to get the script right as I could not find the correct directory.

1 Like

(Presumptuous Commoner) #3

The funny part for me is that the first time I did this box (again, it was my first box), I got the exploit to fire on my first try. The next time it took me ages to get it to work due to the timing weirdness. Hahaha!

1 Like


Also depends on what you called it as well i think… calling it W4K3Y_REV was a bad idea first time around…



Good write-up, I really like it! I think for this being the very first box you’ve done, you’ve done a good job. Looking forward to more like this

1 Like


Thanks for the write-up! I always get a lot of knowledge out of descriptions about the “why” when paired a with the “what.” I’m going to have to poke around at port 3000, never looked into that as much.