Reverse Shell Using Bad USB

Background Info

4/24/2025

Not too long ago I started my master's program in cybersecurity at my university. While I did have some limited experience and knowledge about the field, there were many new things that I had learned about both attacking and defending computer systems. One vector of attack which especially captured my interest was physical security, how one can exploit it and use it to their advantage. As a result, I had recently bought myself a Flipper Zero device which works as a beginner swiss army knife physical testing tool, allowing for the user to copy and send subGhz radio transmissions, RFID and NFC signals, and the topic of this project, to emulate virtual keystrokes with scripts using BadUSB.

Proof of Concept

5/4/2025

For my project I wanted to write Bad USB scripts which, once run, would open up a terminal on the victims computer, and would execute commands to spawn a revere shell and "infect" the computer. The Bad USB functionality of the Flipper Zero uses a scripting language called Ducky Script which works by defining in the script what the Flipper Zero is going to "type" once the payload is executed. I wrote some small scripts which did things like open up powershell and start Google Chrome. I then moved on to researching how to craft a reverse shell attack, understanding the mechanisms and parts required for the attack. Initially I just used an unsecure version of netcat with local ip addresses to create an early proof of concept of sorts. This worked surprisingly well but it turned out there were a couple of limitations with this setup which needed addressing to make the hack useful.

Highlights

• Wrote various ducky script programs testing out basic functionality.
• Was able to write a local reverse shell attack which makes use of a purposefully unsecure version of netcat.

Setting up the C2 Server

5/15/2025

While I was able to reliably spawn a reverse shell on Windows computers and control those computers through the spawned shell, one significant limitation of my current approach was that it only worked on a local network. This was about the same time that I started thinking about self hosting a portfolio page and as such decided to configure my home server to also receive the reverse shell connections. I set this up by modifying the Ducky Script payload to use my home networks public ip address instead of whatever my laptop's ip address may be on the private network. I configured my home router to accept connections on a specific port and to route those connections to my C2 server to capture as reverse shells. Since the reverse shells would constantly be sending data back to my C2 server, all I would need to do is SSH into my server, allowing for me to access and control attacked computers through the internet anywhere in the world!

Highlights

• Configured own server to accept and capture reverse shell connections.
• Tested out functionality over the internet successfully.

Next Steps

8/12/2025

With the C2 server and Ducky Scripts working correctly, the next step for me would be to write my own reverse shell program, so that I won't have to rely on netcat, and so I could implement persistence so that the program remains running on the computer for longer periods of time. With the current method, netcat exits after one captured session of the reverse shell which, while good for a proof of concept, isn't suitable for a more serious exploit.