Thursday, July 10, 2008

Idenfitication Woes

Last year, Tom and I worked on a project called Obfuscator for our forensics course. The project was to demonstrate, to our class, that changing file signatures was as easy as changing file extensions and therefore the thoroughness of file signature analysis tools is questionable. When Harlan blogged that anti-forensics , "techniques don't defeat tools...they defeat examiners." I quickly replied alluding to our (Tom and my) conclusion about fully understanding the capabilities of our forensic tools and how file identification (just like people authentication) is HARD.


A while back, Harlan asked a question about a script from Didier Stevens that embeds an executable inside a VBScript.

"What would you look for if you were analyzing a system and trying to determine if something like this had been used?"

Well no one posted a reply to you Harlan... and after thinking about this question since July 2nd, my response is still: I don't know.

Static file analysis could search for binary execution methods ... like Run for wscript ... but that would be impractical, I think. As with identifying a file, identifying a malicious script isn't as easy as it looks.

So rather than really answering Harlan's question, I'll ask one:
Is writing and executing an executable a common scenario in scripting?

6 comments:

Didier Stevens said...

> Is writing and executing an executable a common scenario in scripting?

I believe it's common for installation programs. Scripting is often used to install applications, and some EXE installation programs also launch scripts during their installation.

Jason Koppe said...

Didier, thanks for your script and beliefs.

H. Carvey said...

This perhaps wouldn't be too terribly difficult. I'm "cheating" a bit b/c I have Didier's Python script right in front of me, but looking at it, I can see some terms to use as keyword searches...for example, look for the use of "FileSystemObject".

I haven't run the Python script yet, but I would imagine that whichever EXE or DLL you use is going to (a) make the .vbs file large, and (b) include something like the PE file signature (both MZ and PE\0\0.

Knowing that the next thing that someone will say is, yes, but we can change that so that it doesn't appear that way in the .vbs file itself...okay, so look for the use of FileSystemObject as well as any other API functions that would allow one to change the code of the PE file.

On a side note, I think it's great to have discussions like this, and for those who have the time, to go ahead and look at what artifacts are left by certain activities. However, in over 2 1/2 yrs w/ my current employer (and several years prior to that) I haven't seen any really sophisticated means of obfuscation or hiding of activity during an examination. In fact, it was only recently that some of the encoding in SQL Injection attacks came to light (fun stuff), and it was also within the past several months that I saw the use of the "Image File Execution Options" Registry key as a means of persistence used by an intruder...and at seeing that, I got all excited like a little grrrl!! ;-)

Jamie Levy said...

``...I haven't seen any really sophisticated means of obfuscation or hiding of activity during an examination.''

Hmmm... How could you be *absolutely* sure ;-)

Jason Koppe said...

@harlan & JL

thanks for your comments :)

H. Carvey said...

One can never be absolutely sure...just as one can never be absolutely sure that there weren't any such hiding techniques employed.

However, during an examination, many other things come into play, as an examiner should always consider context, and try to not view artifacts in isolation. For example, there were no indications through any other means that demonstrated attempts...sophisticated or otherwise...to hide. In most cases that I have seen, this simply is not necessary. Many attackers get on systems rather easily, and there is no need to hide what they're doing. I've actually seen indications of intruders on systems for weeks or months, and then appear to get bored and just leave...all without being detected by the admins.

So...you're right, one can never be absolutely sure of something like this during an examination. But then, it is extremely difficult to deal in absolutes...the examiner should instead deal in "indications" and context.