Lions, and tigers, and DECAF...oh, my!

Most of us are aware that DECAF is back, with a new version. Ovie had interviewed Mike and posted the podcast (I'd also posted, and others had commented), and the next day, the original DECAF was taken down. Now it's back, like Die Hard sequels, or a bad MRE...but I kid. See? Smiley face. ;-)

So, how do DECAF and tools like it affect the current state of incident response (IR) and digital forensics (DF) analysis, if at all?

In order to discuss this, let's go back to COFEE. MS released COFEE as an LE-only tool, and IMHO, that's the reason for the hoopla surrounding its release and subsequent "leak"...that it was LE-only. The fact of the matter is that while COFEE was released by MS, and includes the use of several native Windows apps and some from MS/SysInternals, it's really just a glorified batch file with some add-ons to make it's use and deployment easier...which, I think, is the key to understanding the nature of COFEE.

While COFEE was released by MS, it wasn't developed by MS in the way that Windows 7 or MSWord were...instead, it was a small group within MS that led the charge on developing and releasing COFEE to law enforcement.

Now, please understand...I am not disparaging the efforts of this group at all. In fact, I applaud their efforts in stepping forward and taking the first step to do something. I mean, there have been plenty of similar frameworks out there for folks to choose from, and some of them very good...but for some reason, COFEE was very well received. However, I will suggest that perhaps making something too easy to use isn't always the best solution. Sometimes, when it really comes down to it, it may be better...albeit not necessarily easier... to educate the user than it is to make a tool easier to use and deploy.

Given that, my own personal, overall assessment of COFEE is that it's a tool produced by folks who don't do a great deal of IR or "live response" work, for folks who don't do a great deal of IR or "live response" work. Don't make this statement out to be something that it isn't...I'm not disparaging anyone when I say this. All I'm saying is that in the corporate arena, many of us have taken the time and effort to educate ourselves on the issues and nuances of live response, whereas LE may not have had that sort of time...after all, when I'm reading or testing stuff, I'm sure most LE are diligently working to put bad guys in jail.

Then there was DECAF. I remember that there was discussion about "LE-only" this and "vulnerabilities" that. However, listening to the CyberSpeak podcast interview, there's no specific mention of what those "vulnerabilities" are. The "vulnerability" that Mike and friends found in COFEE was never specifically stated during the interview, pretty much leaving that particular issue up to speculation on the part of the community as a whole.

So where does that leave us? I'd suggest that the release of DECAFv2 really doesn't change anything at all. Here's why...

First, I don't necessarily see a vast deployment of this sort of tool. Think about it...how much encryption is being used for nefarious purposes? From what I've seen over the past 10 or so years, as well as from talking to others, the use of steganography outside of the academic or lab environment seems to be another one of those "urban legends" of digital forensics. Even when looking at some pretty sophisticated or large-scale intrusions, I (and others) haven't seen a great deal of what's generally referred to "anti-forensics". I hate to say it, but it really isn't necessary.

Second, I don't see this being deployed on servers to any great extent. I mean, really...think about it. Your company gets compromised and a great deal of money is spent to get a consulting team on-site to assist. Do you want to be the one to explain to the CEO why you installed DECAF on a system, when the efforts of the responders were hampered, or worse, the system BSoD'd?

Third, DECAF is signature-based, and does ship with some default signatures (although I have no idea what "FTK Imager Port" is from the Press Release page...I don't use any tool named that, so I guess I'm safe). Beyond that, how many users are going to go about crafting and distributing custom signatures? I mean...really. Better yet, who's going to write the DECAF signature for DECAF?

Fourth, let's say that you do encounter a system with DECAF installed...it's likely going to be an uber-admin's desktop or laptop...and there are other ways to collect data. Like pull the hard drive out and image it. Sure, you may not be able to get volatile data, but you may not need it for what you're doing, or you may have other data available to you.

Finally, I have no doubt that someone's going to come up with a DECAF detection tool. There are tools available that will detect the presence of whole disk or volume encryption on live systems, and detecting the presence of DECAF running...and doing so using a tool with random signatures (remember RootkitRevealer??) makes use of capabilities that have already been employed. In a way, this reminds me of the whole escalation stuff that happens with combat weapons. Tanks have armor, so someone makes a TOW missile. Then someone puts reactive armor on the tank. Then someone else puts a probe on the end of the TOW missile. And on. And on. DECAF comes out...someone else will ultimately produce a DECAF detection tool.

Circling back around to the beginning of the post, what we, and in particular LE, don't necessarily need is easier to use tools. Sure, there's a certain level of usability in GUI-based tools over CLI-based tools, but what's needed is education, first and foremost. After all, a knowledgeable responder is better prepared. Knowing is half the battle! or something like that...

DF and Disclosure

The subtitle of this post should be something like, "The disclosure discussion comes to digital forensics" or "Yes, Virginia...IR software has vulnerabilities, too."

For those of you who may not be aware, it wasn't long ago that MS's COFEE was leaked. Based on some of the comments you can find online, this occurred around the beginning of the second week of November. What's the big deal? Is it that this is "LE only"? Well, now that it's been exposed and you have an idea of what's in it...are you a better person for knowing? Or are you wishing you could forget?

Also, something that a lot of folks may not realize...MS is a HUGE company. At one point, I worked for SAIC, and internally folks described the environment not as one big company, but as 400 small companies that could and did compete against each other. MS is similar...don't expect that the left hand knows what the right hand is doing all the time. Remember WOLF? There've been other efforts within MS to produce tools and documentation, but it's not as if these have been released the way Windows 7 or MS Office are released. Tools like COFEE should be considered more of a grass-roots effort, and not something you're going to see Bill or Steve on stage endorsing.

Comparing COFEE to what's out there now and has already been in use may be a bit like comparing the GI Joe accelerator suit to the real-world MOPP gear, in some ways. You'll have to excuse the analogy...we in the "community" never seem to see eye-to-eye when it comes to this sort of thing. I'm simply trying to illustrate the point that while COFEE was released by MS to LE, that doesn't mean that it's entirely bleeding edge stuff.

Then, along came DECAF, reportedly a counter-intel, anti-forensics tool meant to detect the use of COFEE, and automatically react by doing things on the system, much like an anti-virus or -spyware utility would do.

Ovie then had the opportunity to interview Mike, one of the authors of DECAF. One of the most striking things about the interview is that Mike really didn't seem to have a well thought-out rational behind the creation of DECAF. For good or for bad, MS released something to assist LE, and act as a force multiplier...as a former Marine, I totally understand that. Regardless of what you actually think of the tool itself, the idea was to give LE a capability that they did not have before; specifically, officers that are first on-scene would have a tool that would allow them to collect data (which could be used as evidence) prior to spoilation due to temporal proximity to an event (that means, get it now, before it's gone). Mike apparently had an issue with the tool, and found what he determined to be a shortcoming or "vulnerability", and produced DECAF to "exploit" that shortcoming. Interestingly enough, I've listened to the podcast twice now, and I'm at a loss...Mike never said exactly what the shortcoming or vulnerability was, other than the tool could be "fingerprinted". But isn't that true for...well...just about anything?

However, what was he really doing? He wasn't so much exploiting a software "vulnerability" as he was exploiting the training (or lack thereof) of the first responders who would use COFEE. Ovie had an excellent point...what happens if a really, really bad guy had DECAF installed, and the first responders only had COFEE? There's a possibility that the bad guy could go on hurting children due to the fact that specific evidence could not be collected. If you listen to the podcast, I really think you'll see that regardless of the example used, Ovie made a very valid point, and it really seemed that Mike maybe hadn't thought all of this through.

Mike's primary issue with COFEE throughout the interview seemed to be that it could be fingerprinted...that there were automatic means by which someone could determine that COFEE was being run on a system. Okay...but isn't that true for just about ANY software? I don't know the inner workings of DECAF, but couldn't the same thing be said for other responder tools? According to an article in The Tech Herald, it appears that COFEE's primary purpose is to automate the use of 150 (wait...150?!?) tools, some of which include tools available from the MS/SysInternals site.

How many other responders use these tools?

How many other toolkits could possibly be affected by tools such as DECAF?

Consider this...why COFEE? Why not Helix? Why not WFT? Why target a tool released by MS, and not one, say, endorsed by SANS? I'm not going to speculate on those...those are for tool authors themselves to consider.

I have to say that before I actually listened to the CyberSpeak podcast, I found out that as of Friday morning, the DECAF tool had been taken down, the web site changed, and reportedly, anyone using DECAF on a system with an Internet connection would find that the tool had phoned home and self-destructed. Kind of cool, eh...an anti-forensics tool with the ability to phone home and get updates and instructions, with no user interaction beyond turning the system on...wait, that sounds kinda like a 'bot to me...

Following right along with the CyberSpeak interview, you can watch this YouTube video, as well, that pretty much reiterates what was said on the DECAFME.ORG web page. Speaking of which, here's a quote from the page:

As a security community at large, we need to band together and start relieving some of the burden off our government by giving back.

I agree with this 100%...and I agree that two guys did have an impact. However, from the interview, Mike seems like a really smart guy, so I have to ask myself...if you see something wrong, why not fix it? If you see an issue with a tool or process, why not do something to improve it? If you find an issue with a tool, particularly one aimed at assisting LE or others with their job, why not fix it? If you have a better tool or process and want to get it out there, consider Facebook, Twitter, blogging, and even contacting guys like Ovie and Brett. If the issue is the training received by LE, remember that a lot of LE is really strapped for cash...again, contact Ovie, or your local HTCIA or InfraGuard chapter and see what you can do.

My point is, two smart guys can have an impact, but their motives will dictate the impact that they have. This wasn't an issue like what's seen in the usual "full disclosure" discussions...we're not talking about server software that's been deployed across the globe that has a severe vulnerability. We're talking about a tool that can and should be used by a discriminating, knowledgeable responder...and if you don't think that the tool is sufficient, do something to fix it...other than subverting it. Provide something better.

Thoughts?

In The News

The Register is reporting that bot masters have hidden a control channel in the Google cloud via AppEngine. Interesting article, take a read. The article also points out that both Facebook and Twitter accounts have been seen being leveraged as control mechanisms. Quoted from the article:

And that may be another reason why black hats are flocking to the cloud.

"Going to a company as big as Google and saying 'Can we get an image of that server,' that's a pretty high barrier," he said.

I'd suggest that that would have to do with the implementation. Cloud is being sold as the next big thing...but what is it? Well, it depends on who you're talking to.

Something else that's been making its rounds is spilled COFEE...Dark Reading picked it up, as well. Folks, the only reason this is getting the press it is, is because this was originally released only to law enforcement. Other than that, it's really not that big of a deal. Hogfly weighed in on this, as well...he apparently felt so strongly about this...dude, his last post was in August! ;-)

FTK 3 has "explicit image detection" capabilities (PDF here). This looks to be very useful for finding images, but I'm not sure that that's really the issue at hand these days...I may be wrong. I mean, I thought that it wasn't so much a matter for LE to find the images (although the coolness factor might be that in the video, Erika Lee uses the term "trained", implying a neural network of some kind...), but it was more a matter of addressing the Trojan Defense. I mean, once you find the images, you have to then demonstrate that the user in question intentionally downloaded and viewed them, and possibly shared them. This is were browser/web history, P2P, and Registry analysis come into play. Know anyone who knows anything about "Registry analysis"?

Speaking of which...

I ran across this AP article regarding the "Trojan Defense" hosted at the Fox News site. This is an interesting article to me, because this is something I've been discussing with LE for a number of years now. One of the key aspects of the analysis performed can be seen here:

A technician found child porn in the PC folder that stores images viewed online.

For most examiners, this refers to the browser cache; for IE, the Temporary Internet Files subfolders. Now, I'm not about to disparage any analysts skills or capabilities...all I'm going to do is point some things out. First, those TIF subfolders aren't created by IE, they're created by the use of the WinInet APIs, which IE uses. Now, this means that another app that uses the same APIs would also create the subfolders, and if it were running in the context of the logged on user, the folders would be created in the user's TIF directory.

Where did I get this? Well, I got a little help from my buddy Robert "Van" Hensing...check out his blog post from 2006. This was valuable to me, as I had conducted an exam for a customer, and one of the oddities I found was that the Default User's web history (I was using ProDiscover in my examination, and there's an extremely useful function to search for and parse web history...) had been populated. I tracked that back to a copy of wget.exe running with privileges elevated to System level...but I digress.

So, it's entirely possible to get just about anything on a system and make it look like the user did it. Why do that? Perhaps to discredit the user or law enforcement...I don't know, I'm not this guy.

My point is that we can't simply look at the folder the files are located in and their date/time stamps, and think we've got it wrapped up. There are a number of other places on the system that we can look...Prefetch folder, Registry, etc...in order to answer the question of did a Trojan do it? before it's asked.