Infiltrated dot Net

Data Exflitration Clarity
Written by J. Oquendo   

Over on the Crucial Security Forensics Blog, Brian Hussey gives an excellent read on data exfiltration. The following was re-written based on an e-mail counterpoint I would have posted directly to the blog, however, comments are disable. To Brian I say: thanks for the read however, I'd like to gripe slightly about something written concerning exfiltration of data.


My gripe with the article stemmed namely from the statement: "For those not familiar with the term, data exfiltration files are created by an attacker to contain stolen data on the victim box. It is basically a storage container that he later intends to transfer back to his own computer." ANYTHING and EVERYTHING is a storage file and I don't believe "hard core" attackers will write to disk in order to avoid potential HIPS. I am commenting now with my "pentest" hat on.

There was an engagement I did about two years ago. Web based escalation into RFI, into client side code execution. I couldn't get data PAST normal means, so I one-lined the equiv of:

sed 's:^:<!--:g;s:$:-->:g' propietarydata.sql >> index.html

The data I needed to get was now a comment inside of a webpage. Oblivious to any HIDS since I did not create a file. I know based off of system engineering experience, rarely if ever: 1) are webservers running HIDS and 2) even if they are running HIDS, may will whitelist index pages as they often change.

In my scenario there was no need to 1) introduce any tools which would have set off warnings and 2) create any files. This is also a mechanism to bypass most DLP systems. Sure you can flag a file for anything you want. You truly can't stop the data from leaving if its being read can you. I can copy and paste it, take a screenshot, etc.

I enjoyed the article but there are "more than two ways to skin a cat." I thought about writing something along those lines: "This is how I would do it, and what you should look for" but figured too many people would misconstrue the intent of my article, which would be to "think outside of the box." I did something similar - which was also the last time I did this - 3 to 4 years ago. "Hiding in plain sight" a complete backdoor via SSL Cert: http://www.infiltrated.net/scripts/dsphunxion.output

 

To see the output of the above you could use:

 



If you re-piped it to |sh it would create the account and keep it. The premise was based on "Tai Chi" where via a oneliner, using system tools and calls already on the system, the system would yield control, never once creating anything out of the ordinary except for the bogus cert. I GUARANTEE you, even more experience security pros wouldn't think nothing of that realistic looking cert.

In any event, it is good reading however, I would not go as far as saying that data that need be exfiltrated is a storage container. I would say "could be a storage container." (Just my two cents)

Mind you, when I do pentesting work, I use a combo of ICMP, IGMP, DNS Tunneling and other voodoo to bypass a LOT of things. (firewalls,{N,H}I{D,P,T}S, DLP, etc.)

This still does not take into account that I can also pipe stdout straight to netcat never once writing to a local file. Nor does it take into consideration the use of inserting data into existing files via say steganography (thanks for the tip @jadedsecurity). At the end of the day from the forensics standpoint, Brian makes some great observations however, for those unfamiliar with covert channels, there are more nefarious means to siphon data off the network,

 

 

Choices