When a tool is just a tool, pt I
A tool is just a tool...that's it. A tool by any other name would smell so sweet...no, wait...what? Who let Willy Shakes in here? ;-)
I know what you're thinking..."fount of wisdom, dude." Sweet. But think about it...think about what we do, and how we do it. If you hear someone say, "yeah...I do forensics. But I need <insert commercial tool name here>", then back away slowly, don't make direct eye contact and make no sudden movements.
It's long been known that subversive tools and techniques, colloquially referred to as "anti-forensics" tools, haven't been directed at subverting other tools...no, tools such as timestomp aren't meant to subvert EnCase or even NTFS. What's being targeted here is the analyst and their training.
Not sure what I mean by this? Check out Simon's post over on Praetorian Prefect that discusses, in part, that whole COFEE/DECAF yawnfest. Simon had a previous post that addressed COFEE and some of the hype surrounding the tool set being "leaked".
When you really think about it, DECAF is meant for one thing...to subvert the use of COFEE. If the responder is a one-trick pony, and ALL they have is that COFEE package...game over, and DECAF has...no, wait...I wasn't gonna say "done it's job". No, what I was gonna say was the DECAF has demonstrated the shortcomings inherent to types of responders that rely solely on the use of one tool, such as COFEE.
Have you ever heard, "...I ran these tools, some of them didn't work...but here ya go."? I was working a fairly (in)famous engagement back in Dec '06 and one of the analysts from the primary on the contract ran the Windows tools from Helix 1.9 against a live system. I was handed the data the next day, and found that a little over half of the tools didn't have output from the tool available...they just had that "XXX is not recognized as an internal or external command" message. In this case, the issue wasn't due to something being loaded on the system, rather it was an issue of someone really knowledgeable in Linux trying to do IR on a Windows system. The one tool they had didn't work...but the system could ONLY be accessed at 2am, and the analyst had no idea that anything had gone wrong. So, even though I was tasked with doing "emergency" IR, I (and everyone else) had to wait another 24 hrs to get the data we needed.
Okay, that was three years ago...but in a lot of ways, for a LOT of responders, this really hasn't changed too terribly much. Take a malware detection gig, for example...someone has a system that they think has malware on it, so the responder acquires an image of the system, and maybe memory. They take the data back to the lab, in-process the data, then mount a working copy of the acquired image read-only and scan it with one AV scanner...and find nothing, and that's ALL they do, and they report their findings. But wait...did they check to see if the scanner they used was the same one already installed on the system? If it is, what have they really done at that point? What about the fact that a great deal of malware (depending upon what you read and who you believe, this could be as much as 40-60%) isn't detected by commercial AV the first couple of months that it's in the wild?
Are you beginning to see my point here? Look at Conficker...remember Conficker? One of the things I found most interesting about it was that it took advantage of standard business processes (ie, file shares, thumb drives) to spread on internal networks. Imagine responding to a customer site and telling them, "you're gonna have to shut down your file servers until we get this cleaned up." What the...?? A great many calls came in over the next couple of months as organizations with up-to-date AV scanning engines and signatures got p0wnd'd by variants of Conficker, Virut, and other nastiness. That's right...variants. As in, stuff that the AV couldn't see, but eventually got classified as being pretty close to the stuff that the AV could see...just not close enough for it to see it. See what I mean? Not the stuff the AV could detect, but the new stuff...stuff that did the same thing as the other stuff, but just "looked" different.
The problems and p0wnage that folks faced with this stuff had everything to do with the fact that they relied on a tool, rather than a process, to protect them. "Hey, I've got AV in place...I'm good." Who said that...the dudes from AIG? If your fallback plan was to call in an IR team...well, the malware continues to own you for 72 hrs or more as you go through contract negotiations, waiting for analysts to arrive, and finally getting them spun up on your infrastructure and the situation.
I know what you're thinking..."fount of wisdom, dude." Sweet. But think about it...think about what we do, and how we do it. If you hear someone say, "yeah...I do forensics. But I need <insert commercial tool name here>", then back away slowly, don't make direct eye contact and make no sudden movements.
It's long been known that subversive tools and techniques, colloquially referred to as "anti-forensics" tools, haven't been directed at subverting other tools...no, tools such as timestomp aren't meant to subvert EnCase or even NTFS. What's being targeted here is the analyst and their training.
Not sure what I mean by this? Check out Simon's post over on Praetorian Prefect that discusses, in part, that whole COFEE/DECAF yawnfest. Simon had a previous post that addressed COFEE and some of the hype surrounding the tool set being "leaked".
When you really think about it, DECAF is meant for one thing...to subvert the use of COFEE. If the responder is a one-trick pony, and ALL they have is that COFEE package...game over, and DECAF has...no, wait...I wasn't gonna say "done it's job". No, what I was gonna say was the DECAF has demonstrated the shortcomings inherent to types of responders that rely solely on the use of one tool, such as COFEE.
Have you ever heard, "...I ran these tools, some of them didn't work...but here ya go."? I was working a fairly (in)famous engagement back in Dec '06 and one of the analysts from the primary on the contract ran the Windows tools from Helix 1.9 against a live system. I was handed the data the next day, and found that a little over half of the tools didn't have output from the tool available...they just had that "XXX is not recognized as an internal or external command" message. In this case, the issue wasn't due to something being loaded on the system, rather it was an issue of someone really knowledgeable in Linux trying to do IR on a Windows system. The one tool they had didn't work...but the system could ONLY be accessed at 2am, and the analyst had no idea that anything had gone wrong. So, even though I was tasked with doing "emergency" IR, I (and everyone else) had to wait another 24 hrs to get the data we needed.
Okay, that was three years ago...but in a lot of ways, for a LOT of responders, this really hasn't changed too terribly much. Take a malware detection gig, for example...someone has a system that they think has malware on it, so the responder acquires an image of the system, and maybe memory. They take the data back to the lab, in-process the data, then mount a working copy of the acquired image read-only and scan it with one AV scanner...and find nothing, and that's ALL they do, and they report their findings. But wait...did they check to see if the scanner they used was the same one already installed on the system? If it is, what have they really done at that point? What about the fact that a great deal of malware (depending upon what you read and who you believe, this could be as much as 40-60%) isn't detected by commercial AV the first couple of months that it's in the wild?
Are you beginning to see my point here? Look at Conficker...remember Conficker? One of the things I found most interesting about it was that it took advantage of standard business processes (ie, file shares, thumb drives) to spread on internal networks. Imagine responding to a customer site and telling them, "you're gonna have to shut down your file servers until we get this cleaned up." What the...?? A great many calls came in over the next couple of months as organizations with up-to-date AV scanning engines and signatures got p0wnd'd by variants of Conficker, Virut, and other nastiness. That's right...variants. As in, stuff that the AV couldn't see, but eventually got classified as being pretty close to the stuff that the AV could see...just not close enough for it to see it. See what I mean? Not the stuff the AV could detect, but the new stuff...stuff that did the same thing as the other stuff, but just "looked" different.
The problems and p0wnage that folks faced with this stuff had everything to do with the fact that they relied on a tool, rather than a process, to protect them. "Hey, I've got AV in place...I'm good." Who said that...the dudes from AIG? If your fallback plan was to call in an IR team...well, the malware continues to own you for 72 hrs or more as you go through contract negotiations, waiting for analysts to arrive, and finally getting them spun up on your infrastructure and the situation.