Building a Budget Red Team Implant

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.

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.

The Hardware:

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 this image, 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:

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:

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:

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 our work on our GitHub! Happy Hacking!