Data Theft via USB: Combating the Insider Threat
Posted by AlexWatson on 28 January 2014 01:30 PM
Data breaches and the theft of intellectual property as well as personally identifiable information (PII) are one of the biggest risks that businesses face, and an area that very few security solutions address. Just last week, a consultant working for the Korea Credit Bureau was arrested for allegedly stealing the credit card numbers, social security numbers, and personal details of more than 105.8 million accounts by copying them to a USB drive over an 11-month period. Other examples included the LA Times reporting that Edward Snowden used a USB drive to steal classified documents from the NSA.
In this blog we will discuss (and provide source code) to enable organizations to start protecting their sensitive data by harnessing intelligence from applications already running on their network. If you're ready to dive in now- go ahead and download the queries and lookups on GitHub now.
How is it that an IT consultant was able to siphon account data with a USB drive from his company over an 11 month period? Most security solutions are based on the principle of perimeter defense and keeping the bad guys out. Traditional defenses such as firewalls, antivirus, intrusion prevention and sandboxing solutions do very little to protect against data theft from within a company, where an employee may wittingly or unwittingly steal intellectual property or other sensitive data, using valid credentials.
A new breed of solutions designed to protect information, such as Websense's DLP (Data Leak Prevention) products are designed to work with existing security solutions and business policies to protect against deliberate or inadvertent transmission of a company's sensitive data from the network.
Harnessing Application Telemetry to Protect Your Network
As we will discuss in this blog post, there are a number of that a company's security teams can do to detect suspicious activity which may be the result of data theft. In a previous blog post, we discussed how Microsoft Windows Error Reporting (WER), a.k.a. Dr. Watson, sends detailed telemetry to Microsoft each time an application crashes or fails to update, or a hardware change occurs on the network. We were surprised to learn that a USB drive insertion considered a hardware change, and that detailed information about the USB device and computer that it was plugged into being sent to Microsoft. These logs are sent to Microsoft via HTTP URL-encoded messages. Organizations can use knowledge about their content and how to decode these messages to detect USB drives and devices that could be a risk to the organization. This knowledge can help organizations detect USB drives and devices such as those used in the KCB and Snowden leaks, and automatically generate reports when they are plugged into a secure system.
We mentioned in the last blog post that the information sent as part of crash logs could be harnessed by organizations. Today we will demonstrate how you can harness intelligence from these crash logs to detect and monitor new USB devices being connected to the network, and hence gain insight into where your company's sensitive data is going. The best part of this? Your company can implement this monitoring for free.
How to know each time a new USB device is connected to your network
In Microsoft Windows environments, a report is sent to Microsoft each time a hardware change happens to a PC. This includes the times that a new USB device is plugged into a computer. In Windows Vista and later, these reports became automated and are part of an opt-out program that Microsoft estimates nearly 80% of PCs in the world participate in. Depending on your operating system, reports are encoded into a GET request to http://watson.microsoft.com (Win XP, Vista, 7) or https://watson.telemetry.microsoft.com in Windows 8.
These reports can be gathered in a variety of ways, either by examining outbound web proxy logs (may we shamelessly suggest Websense Triton Security Gateway), creating an IPS rule in an open source intrusion prevention system such as Snort or Suricata, or by simply monitoring a SPAN port using a sniffer such as Wireshark. In our last blog entry, we discussed an information leakage that can arise with these reports and suggested that organizations set up a group policy that sends reports to an on-premise server which then forces encryption before forwarding to Microsoft. In this case, the reports can be processed at the organization's WER (Windows Error Reporting) collection server.
As we show below, reports from Microsoft WER (Dr. Watson) can be a bit tricky to extract information from (we provide a detailed break-out of fields and and example of how to build reports in Splunk), so let's dive in.
Dr. Watson reports such as the one below have a specific report type for USB inserted devices. We can start by filtering down to messages containing "PnPGenericDriverFound". This is followed by additional information (some is URI encoded) that looks cryptic, but with some lookup tables can be broken out into the following fields:
Step 1: Create the Vendor and Product ID Lookups in your favorite SIEM tool
It turns out the Vendor and Device ID lookups can be a little tricky - but map exactly to Windows and Linux driver databases. To see an example for yourself, try typing "lsusb" from a Linux machine. After scraping some online driver databases, we put together a lookup script that you can use for vendors and device codes that you can download on GitHub. These will obviously need to be updated periodically to remain up to date. Feel free to add new device codes yourself, or check back to our site for updates.
Our manufacturer lookup file is of the format:
And device IDs are of the format:
Using Splunk or a similar SIEM tool, create lookups to map the vendor and product IDs that you see in the Watson logs above to the manuf_ids.csv and product_ids.csv files that have been attached. Please note that our Product ID lookup contains the VID+PID (Vendor ID and Product ID) together - this is the one you'll most likely want to use in your lookups.
Step 2: Breaking out fields in the Dr. Watson reports
The next step is decoding the relatively complex-looking WER report structure. The diagram above shows popular values, and below we have included some Splunk queries that you can do to detect USB device insertions and create reports about what has been plugged into your network.
Below is a sample Splunk query with comments added to explain what is happening at each field. You'll have to remove the comments before running in Splunk. You can download the full query here.
Tweak as necessary and enjoy a detailed breakout of USB devices that have been attached to your network! (click image to enlarge)
We recommend limiting your search to remove common USB devices that you may not be concerned about, such as keyboards and mice. For example:
Taking this a step further, it's possible to configure your SIEM tool to trigger a report each time a certain type of device (such as mass storage, or smartphone) is connected to a computer on the network. To apply DTP (Data Theft Prevention) context to this, try limiting these reports by filtering on computer names or IP addresses from computers that have (or have access to) sensitive data, such as detecting mass storage devices being connected to, or on the same network segment as, your Hadoop HDFS cluster.
Read more »
APT1: A Prevention Perspective
Posted by Charles Renert on 21 February 2013 12:31 AM
There's been increased interest in targeted attacks and advanced persistent threats in the news lately, from the intrusions on large media outlets and hacks on social networking sites to a recent detailed report of the tactics behind the infiltration of a sophisticated attack family dubbed "APT1". Much of the controversy swirling around these reports stems from the attempt to identify the perpetrators behind the attacks -- a decidedly difficult enterprise. While the balance of evidence presented for APT1 does appear to point toward authorship in China (after exhaustive analysis), sophisticated attacks are faceless at the moment of attempted compromise.
Here are a few data points we've already put together from our own analysis of the ThreatSeeker Network:
A more interesting question than authorship for us is: "How can you proactively stop targeted attacks like APT1?" Signatures are obviously not the answer. Here are some of the ways that we block APT1 along the kill chain without the need for signature updates:
One trend that you can confidently predict: the attackers will continue to adapt and get smarter, and the techniques to thwart them will need to do the same.
Read more »