Re: Changing file times, was -> Re: Trojan of somesort - Update

[Harlan Carvey <keydet89 () yahoo com>]

Gadi,

> We need to make three distinctions:
> 1. If it *can* happen, we need to be prepared for
> it.

True.  

> 2. Do we have an adversary smart enough, determined
> enough and
>     resourceful enough to be innovative?

It doesn't take a great deal to simply add the
necessary API calls to an existing Trojan or worm.

> 3. Cost vs. benefit. Would it be worth it or even
> needed to invent new
>     tools or even use them on a target, depending on
> the target? (on both
>     ends, the attacking and defending/forensic).

Bots like russiantopz show us that it's not necessary
to invent new "tools" at all, if you've got all of the
necessary components already.
 
> What I am saying is, that unlike usual security cost
> vs. benefit/risk 
> vs. gain situations with targets, resources, and how
> much you are 
> willing to invest to defend/attack, as a person
> doing forensic work you 
> need to take any possibility into account.

True. 
 
> You'd look for what you know might be there, but
> your analysis should be 
> complete, looking for anything and everything - once
> again, under your 
> cost vs. benefit guidelines.

Again, that depends on the situation.  When a company
calls in a forensics consulting firm, one of the first
things that the consultant does (perhaps not *the*
first thing...) is to determine what the customer is
looking for?  Trojans?  CP?  Fraud?  

Handing a consultant a drive (or several drives) and
telling them simply, "find everything" can be
prohibitively expensive.  
  
> Obviously, once access to a local machine is secured
> *anything* can be 
> done. Regardless, I am not too familiar with NTFS as
> I didn't get to do 
> any forensic work on it and can't comment on it
> without further study.

Well, with regards to your original comment about
changing file times, it's simply a matter of calling
the SetFileTime() API.  Simply for
example/proof-of-concept, the touch.pl Perl script
(located at http://patriot.net/~carvdawg/perl.html)
illustrates the use of this API.
 
> It might be just as easy and I do stand corrected,
> as it is pointless 
> how easy it is once access is gained to a machine,
> especially locally. 
> However, FAT systems have been around for a while..
> and come on - it 
> doesn't get any easier than that.

I completely agree with you in that when someone gets
access to a system, particularly w/ admin privileges,
what they can do is pretty much limitless.  

The FAT file system *has* been around much longer than
NTFS, but I still don't understand your reference that
changing file times on FAT is any easier than on NTFS.
 It can be done through the API, and that API doesn't
necessarily change (at least, not at higher levels)
depending on the file system.  The SetFileTime() API
will change file times on NTFS just as easily as on
FAT.
 
> One other thing I always look for is inconsistencies
> and erroneous file 
> information. People make mistakes. Finding a windows
> DLL dated to 1990 
> or a file without a date raises suspicion.

Yes, this is something to look for...

> Which is why I'd like to repeat what you said:
> "When performing incident response and forensics,
> one should never rely 
> on one piece of information/evidence exclusively."

True dat!