11:00 AM
Connect Directly
Repost This

Tech Insight: Cutting-Edge Techniques For Data Exfiltration

It's 3 a.m. Do you know where your data is? Here's a look at how it might be getting out

As security breaches occur with alarming frequency, one of the first things IT organizations want to know is what data was lost -- and how.

The concept of "data exfiltration" -- the removal of sensitive information from a company's network -- is becoming a crucial part of any data breach investigation. And whether the attack is carried out through physical theft or digital transfer from a compromised internal machine, the result is the same: The loss of sensitive data can have disastrous results for the organization.

Many organizations are fighting this threat with data leak prevention (DLP) technology, which can help identify and stop sensitive information before it leaves the corporate network. Unfortunately, it is often easy to manipulate, encode, or encrypt the information in a way that makes it easy to bypass DLP functions: Take a look at the Web_PII module in the recently released vSploit modules for Metasploit.

Data exfiltration techniques were the focus of a talk presented at BSides Las Vegas earlier this month. The presentation, by Iftach Ian Amit of Security Art, illustrated a trend that has been emerging as more and more companies recognize their vulnerability to data theft.

Data exfiltration is at the heart of this trend. Penetration-testing firms today are being tasked with more than just finding the different ways they can get to a company's data: Enterprises also want to know all the ways the data can be removed from the internal network.

Amit described some data exfiltration techniques that vary in practicality but have the same goal -- getting the sensitive data out. One method is simply encrypting the data before or during transmission to the Internet. This approach is very easy to accomplish, simply by connecting to a remote Web or FTP server that supports SSL or by using file-based encryption (i.e., WinZip, PDF).

Once the data is encrypted and encoded, then how does an attacker get it out? Forget email and FTP. Amit recommended using social networking sites to post the content and retrieve it later. It's incredibly easy (and free) to create a WordPress or Blogger site prior to a penetration test and then post the information there once you've obtained it.

Amit also proposed an interesting question regarding Wikipedia and wikis, in general. What is one of the pages that people rarely view? The answer came from the audience: the talk page, which is basically a discussion page about the wiki page. Put the encrypted and encoded data there, Amit said, and it's likely to go unnoticed.

What can an attacker do when there is no network access outside of the target environment? This is common in high-security environments, where the internal network is air-gapped from the Internet. Amit offered three options. The first is to encode the data and send it to a network printer in the hopes that anyone who finds it will view it as gibberish and trash it. When the trash is taken outside, the attacker can dumpster-dive for the discarded paper, scan it in, and decode it.

The second option -- one deserving of a cool hack award -- is to leverage the VoIP or phone system for the data exfiltration. First, encode the data to audio. Then, make a call out to a voicemail system or conference calling service and play the audio through the phone to record it. When ready, call to retrieve the recording and decode it.

Amit has developed a proof-of-concept tool to handle the encoding and decoding that is currently available for download.

The third option leverages an email-to-fax interface, where an internal email address receives files that can be faxed anywhere. Similarly, an attacker could leverage a multifunction printer that has the ability to scan directly to a fax number or email address.

If the data to be exfiltrated is in hard copy form, then it could be scanned or faxed and sent out directly from the device, Amit observed.

Data exfiltration options abound, which means there is no one way to prevent it. For network defenders, implementing SSL inspection at the company's Internet gateway can help identify suspicious data transfers. Web/email content filters can be configured to block encrypted file transfers. Amit recommends approaching the defensive controls first by addressing the human element, then adding technology.

In addition to doing user training, enterprises must address the issues of where data is stored and how it is stored, Amit said. If users are allowed to store data on removable media, make sure they have the means for encrypting the data and know how to use it, he advised. Better yet, make it automatic with self-encrypting flash drives.

Fax machines and multifunction devices should have controls that prevent any machine on the network from connecting to them -- and to prevent individuals from walking up and using them without a password, Amit advised.

Once the controls are in place, monitor your assets so that you know what they are and where they are, Amit said. There is no reason to be shy about monitoring your own assets, he noted. After that, he said, "Test. Then, test some more." Performing regular tests that involve internal employees and external penetration testers can help IT to identify where the controls are breaking down -- and where addition training could be needed.

Defending against data exfiltration is impossible unless you understand your organization's data flow and assets on the network. Do some exercises to see just how easy it is to get data out -- and how exposed the sensitive data stores are. Then shore up your defenses to prevent it.

Have a comment on this story? Please click "Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Current Issue
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web