Ninja Turtles in your network: LAN Turtle 3G. A how-to for red teaming

Introduction

This post will detail how to configure and utilise a LAN turtle 3G from Hak 5 to gain a persistent, remotely accessible presence within a network.

With ethernet ports becoming less common on new hardware, many people have been forced into deploying an array of various dongles and adaptors to compensate. The LAN turtle is a functional network adapter and will not disrupt normal connectivity of the device it is plugged in to. The device is also capable of a range of attacks such as capturing browser traffic, DNS poisoning, exfiltrating data and is even capable of out-of-band access (via 3G) to aid in avoiding detection.

The threat from physical implants is often overlooked by blue teams, but they can prove to be very effective – Nasa recently revealed that they suffered a data breach due to a rogue device and the attacker remained undetected for about ten months. A successful attack using the LAN turtle could be carried out in seconds – given physical access, all an attacker would have to do is disconnect the ethernet cable connected to a networked device, plug the cable into the turtle and connect the USB port into the target.

What you have to ask yourself is this: would the following device stick out in your organisation?

Figure 1 – LAN turtle

Initial Configuration

This section will walk through the basics of setting up the device to automatically connect to a cloud-based VPS server automatically on boot.

When plugged in, the LAN turtle will appear as “Realtek USB FE Family Controller” with an IP address of 172.16.84.1. This can be accessed over SSH with the following credentials:

Username: root

Password: sh3llz.

Once the default password has been changed, the first step in getting our turtle up and running is to enable WAN fallback. This allows the device to use the WAN connection if the 3G network fails. In order to make configuration as easy as possible, wait until the device is operational before enabling 3G use. This setting can be found in the Config > Configure 3G Modem menu:

Figure 2 – Enabling WAN usage

Enabling this setting allows us to utilise the connection in use by the physical network adapter connected to LAN Turtle in case the 3G connection fails. Note however that if this is enabled while on a client’s network and 3G fails it will then try and SSH out using that network connection.

The next step will be to download and configure modules that we can use to ensure persistent network access. The modules we will be using are autossh and keymanager. These will establish a persistent SSH connection to a cloud-based attack box. For the purposes of this post, we will use an Ubuntu server on AWS.

First, we have to setup key-based authentication, as it won’t be possible for the turtle to manually type in an SSH password after being plugged in. We use the keymanager module for this which will prompt us for an SSH password and then upload the public key to the server over SSH. As AWS does not allow password-based authentication by default, we have to first enable it by setting PasswordAuthentication to yes in the /etc/ssh/sshd_config file. Make sure to restart the SSH service with sudo service ssh restart to enforce the change.

The key manager process is pretty straight forward:

Generate key > copy key > submit credentials to authenticate to the SSH service.

Once this has been successful, the key pairing will be configured between the VPS and the turtle and password-based authentication should be disabled again.

Now we have the keys set up, we can move on to the autossh module and provide it with the details of our attacking box:

Figure 3 Auto SSH settings

In this case, what this module will do is SSH out to our server and port forward its local port 22 as port 2222 on the server.

With everything set up correctly, it is now possible to access the victim network remotely by SSHing to out server on port 2222, which is then tunnelled to the turtle. We can use the following command on the AWS box to do this:

ssh root@localhost -p 2222

and then enter the root password for the LAN turtle.

Congratulations, you now have a foothold on the internal network!

Figure 4 Remote access

Ensure the autossh module is set to enabled – this will configure it to run on boot and automatically establish an SSH connection to our host.

Going Beyond the Modules

The LAN Turtle 3G has limited storage space and doesn’t always have great support from the vendor. Some of the modules, including the built in Responder module, did not appear to work correctly out of the box. This is a common complaint amongst owners of the device and Hak 5 don’t seem massively concerned about addressing it.

In my experience, installing the Responder module uses up all of the device’s storage space, rendering the module and device largely useless. I attempted this a few times which resulted in having to factory reset the device and reload the OS. There are a number of interesting modules available, such as meterpreter reverse shells, automatic data exfiltration via SSHFS and URL snarfing. However, given the absolute struggle to get one module working, I wanted to limit the turtle to only carry out exactly what I needed and offload any additional responsibility to a cloud-based VPS.

Given that the device is essentially just a lightweight Linux box, we thankfully aren’t restricted to using the inbuilt modules. The turtle supports python, so we are free to use tools or scripts written in the language (assuming they don’t require additional modules installed – again, storage space is an issue). This is perfect for Responder as it’s written in python and runs on the box without the need for any further modules. Pressing Escape from the main menu will drop you into a normal bash shell, and from there we can interact with the filesystem directly.

Responder can be downloaded from the GitHub page and copied over using scp. It is possible to install the package using git (the turtle uses opkg package manager) but again, this can use up precious storage space and in my experience wasn’t worth the hassle. It is also worth noting that saving anything in the /tmp/ directory will be wiped any time the device is rebooted (unplugged), so avoid storing anything you’d like to keep in there.

Most penetration testers will be familiar with Responder and its capabilities. It can often be a quick and easy route to DA if hashes are flying around the network. However, assuming your goal is to be somewhat stealthy and remain undetected, I recommend initially running Responder in ‘analyze’ mode to gain more information about what is going on within the network before you start interfering with it. Tools such as nmap are also available on the box itself to aid in enumeration of the network.

Figure 5- Responder in analyze mode

Figure 6 – Responder grabbing a hash in turtle

Another option for expanding the toolset available is to use a tool like sshuttle from our VPS. sshuttle allows an SSH connection to serve as a VPN connection, granting the ability to automatically route traffic over the tunnel without the use of proxies. This massively and effortlessly expands the toolset and capabilities available from the physical implant, as it is now possible to bypass the crippling storage and processing limitations and run tools directly from a VPS. I chose to make use of impacket, which is a collection of attacking scripts that can be used to gain execution on host machines, move laterally through the network and escalate privileges.

The following command will tunnel all of the traffic from the VPS box through the turtle:

Figure 7- sshuttle

As all of our traffic is now being routed through the LAN turtle sitting inside the victim’s network, we can use some of the tools that come with impacket to attack the internal network. The following screenshot demonstrates a successful kerberoast attack against the victim domain carried out from the VPS:

Figure 8- Kerberoasting the internal network from the AWS server through the turtle.

Out of Band Access

The most interesting aspect of the LAN turtle are its 3G capabilities, which allow us to carry out all of the activities listed so far out-of-band. This is very useful to an attacker because the device will not be using the victim network to reach out to the VPS. This can be particularly advantageous in mature environments that make use of effective network monitoring, cyber security operation centres and data loss prevention policies.

These defences would almost definitely flag the type of data and manner of traffic trying to leave the network, leading to alerts being raised about a possible compromise or rogue device planted within the network. Using out-of-band means to exfiltrate data and carry out attacks can help reduce the risk of being detected and increase the chance of maintaining access to the network for an extended period of time.

To test the 3G capability, I purchased a pre-loaded data sim on the 3 network:

Figure 9- Sim card for 3G access

The turtle takes a micro SIM card and it can be inserted into the device like so:

Figure 10 – Sim card installed

Once the card is installed, it is just a matter of updating the APN information to three.co.uk and disabling the WAN fallback to ensure all data is transmitted out-of-band.

Figure 11- 3G settings

Connectivity can be confirmed by finding out the external IP address of the turtle:

Figure 12 – External IP Address

A simple whois lookup confirms that the device is using the three network:

Figure 13- Whois information

External Power Source

One final consideration is the ability to connect the turtle to an external power source, as the device does not need to be connected to a computer to operate. This capability could allow the device to be stored in a stealthier location if a USB dongle would stand out when connected to a workstation. However, this scenario will remove the ability to carry out of some attacks based on intercepting or interfering with the connected machine. The following image demonstrates that the LAN turtle can be powered by an external battery:

Figure 14- External power source

This might be useful if you only require a limited time within the network. However, a more robust solution would be to find an unused floor panel such as this:

Figure 15 – Floor panel. Credit: comtecdirect.co.uk

These panels would be an ideal hiding spot for our rogue device. As there are power sockets and ethernet ports, it would be possible to constantly have the device powered via a USB plug and connected to the network via an ethernet cable. Throw a label on the device and it is even less likely to be disturbed:

Figure 16 – USB powered with label

Conclusion

The LAN turtle 3G is a powerful tool that could aid both penetration testers and red teamers in engagements where physical social engineering is in scope. The device does have some limitations, but these can largely be overcome by offloading the bulk of the work to a VPS.

Other workarounds such as using tools and scripts manually loaded onto the filesystem as opposed to relying on the inbuilt modules can help compensate for the device’s shortcomings. One improvement I would like to see would be power over ethernet, as the target environment may have USB ports locked down and having to find an external power source close enough to an ethernet port could be an issue.

Whilst there are certainly more powerful devices (such as the raspberry pi), a huge positive in favour of the LAN turtle is the fact that it looks the part. The casing for the device means it would be unlikely to stand out inside most networks, whereas a homemade device with the circuit board still on show sticking out of a workstation would likely raise a few eyebrows.