The Time I Built a Friendly Persistent USB Trojan for Fun and Profit

Reconnaissance
Years back when Windows had all sorts of fun vulnerabilities that could be exploited via USB I was approached by a vendor who made high end thermal imaging cameras. These cameras were expensive ranging in price from $3K to $300K. The problem was that these devices were often stolen, they were also on embargo/sanctions lists as they can be used for nefarious purposes so they fall under ITAR (International Traffic in Arms Regulations) and cannot be exported to certain countries. However, some unscrupulous distributors may have been circumventing these restrictions and selling these devices to intermediaries with the devices ending up in places they shouldn’t.

Resource Development & Initial Access
The trick with the cameras at the time was they had no internet connectivity, but they did store the images either on internal storage, or the more advanced ones at the time had SD cards (this was before the iPhone kids). At the time most workstations and laptops were Windows, so it made sense to build a Windows executable that would be triggered by an autorun file. Sometimes companies had competent IT staff that would disable autorun on these systems, so I also disguised the executable so it looked like a thermal image (I took a thermal photo of my cat Nabi).

Execution
The friendly USB trojan didn’t do anything nefarious, it simply gathered information about the system it was connected to such as: username, network data, computer serial number, as well as the serial number of the camera and some other basic data like IP address which I ran through IP geolocation on the receiving server.

Persistence
One problem I ran into is that SD cards are removable. So if we installed the executable on the SD card and it was swapped out, no more tracking. I ended up working with their developers to build an embedding process at the firmware level. The firmware would have the executable stored and would check to see if it was present on the SD card, if it wasn’t it would load the binary.

Defense Evasion & Exfiltration
After the executable gathered data it sent it to a random set of URLs from a list. If it couldn’t connect it would change the URL until it sent. It was sent over SSL so evaded most security measures at the time.

Nothing too fancy, particularly by today’s standards, but hey it worked. I don’t think it would work today.

Impact
I should point out that customers would pay extra for the service and the executable was not deployed to a camera unless they signed up for it. It was deployed to hundreds of cameras and I was told useful in a lot of cases including a few where the cameras ended up in places they shouldn’t have, but they were able to track to the distributors. That’s all I can say.