Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers – is the security community’s go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

Detecting A Surveillance State - Part 1 Hardware Implants

This is the first in a series of four blog posts that will cover defenses and detection methods for hardware some state-actor surveillance groups may have been using. I felt it would be a good mental exercise to examine the programs and devices which were allegedly being used or in development about five years ago. In this first post I will cover a little introduction and get in to the details about some hardware implants. In subsequent posts I will discuss leaks regarding: radio transceiver bugs, firmware injections and cellular network monitoring.

The source of my knowledge about these devices is restricted to the now public knowledge about them found on Wikipedia, and what was publically disclosed at 30c3.

In total, over 40 devices and programs used by state-actor spy agencies were released. I will cover some theoretical defenses and detection methods for a hand-selected group of these leaked surveillance programs and services in a short series of posts. Due to the age and limited scope of the leaked documents, the defenses covered in this series of posts should not be relied upon for protection and I make no guarantees to their accuracy. They are provided for entertainment purposes only, so if you find yourself on the bad side of any nation's spying agency, don't blame this blog post for any misinformation (also, you may want to take a moment to reflect upon your life choices.)

At the time of my writing this post, no one has come forward with physical evidence of these hardware bugs installed on a system. So, you may wish to read their descriptions with a bit of healthy skepticism and remember, this is just a thought experiment covering theoretical defenses against these attacks and not intended to spread fear, uncertainty or doubt about surveillance states.

In this first post I will cover three devices that are relatively similar: they each provide persistent access to a target system. They would also each be detected in similar ways because they are physical devices.


This is a physical device plugged-in to the Joint Test Action Group or JTAG headers on a system's motherboard, specifically targeting a certain hardware vendor. If you know what JTAG does, there is nothing exemplary to this sort of attack, except that it is a persistent device. If you're interested in learning more about JTAG, read these other blog posts from the Spiderlabs Blog: Getting Terminal Access to a Cisco Linksys E-1000 and Oops, I pwned your router.

To detect if a system has a GODSURGE device attached to it you would want to look for the JTAG connecter on the motherboard. The location of the JTAG headers may differ, but they tend to be near the CPU and may have exposed pins (or not). See the Wikipedia page on JTAG for more information and to see what they look like.

For those interested, here is what a JTAG header without it's pins would look like:


JTAG headers can be found on many systems and are notoriously common in embedded devices. These headers are used during the development process for debugging purposes: they give you a direct interface with the CPU and are extremely helpful. They are commonly left on the production boards, so finding them on a device is normal and not a security concern. However, if there is a chip or board wired in to a device's JTAG headers that you did not wire in yourself, then something fishy may be going on.


GINSU provides software application persistence on target systems with the PCI bus hardware implant, BULLDOZER.

Since this is a device that plugs in to the PCI bus on a system, it could be detected by simply opening the computer's case and looking for a PCI card that does not belong. For example, if you find a PCI card that appears to serve no purpose (e.g.. not your network card or it has no external ports), then perhaps try removing it and see how things work. If a few black SUVs roll up to your house after unplugging the PCI card, it's probably not because your domicile is the set for a rap superstar's new music video.


Of these three, the COTTONMOUTH bugs are the more interesting attacks. These bugs are embedded somewhere along the USB bus and function as an air gap bridge to assist in exfiltration of data as well as allow persistent compromise. It can be embedded directly in the USB headers in an existing USB peripheral (USB hub or keyboard). These devices allow for exfiltration of data over unknown radio frequencies to listening devices in the area, even on a system that is not connected to the internet.

The only problem is, once again it is physical. You could open up the keyboard or USB hub and will be able to identify a board that serves no purpose to the device. The malicious USB device would also likely show up on your computer's list of USB devices, so just checking there would be a good place to start.

In order to initiate an exploit against the target system for that persistent backdoor, the COTTONMOUTH device would perform a USB host attack, which means it will likely identify itself as a new USB device to the system (complete with USB ID etc.). Once it has done this it has given itself away. If you plug in a new USB device you got from a conference or dinner into your laptop and more than one USB device shows up on your system, you may want to grab a screwdriver and see what's going on inside the keyboard. Be wary of gifts given at conferences.

You could also detect each of these devices by monitoring radio frequencies in the room, but that is far too complicated for these specific backdoors. If there is physical evidence of tampering, then looking for physical devices will always be the easiest solution to detect them.

In the next post I will talk about some more complicated hardware backdoors. Including HOWLERMONKEY chips and a set of Radio Frequency (RF) bugs used for data exfiltration.

Read part two of this series here.

Recent SpiderLabs Blog Posts