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

[Gadi Evron <ge () linuxbox org>]

> Just b/c something *can* happen, doesn't mean that it
> *does* happen.

Absolutely. That is how the world of security is built.

We need to make three distinctions:
1. If it *can* happen, we need to be prepared for it.
2. Do we have an adversary smart enough, determined enough and
   resourceful enough to be innovative?
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).

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.
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.
Changing file dates happened in the past, especially with viruses. I 
can't come up with any example at the moment though so.. don't take my 
word for it.
>>It's easier on some systems than others, and
>>practically ridiculous on FAT file systems.
>
>
> To be honest, I'm not aware that there's any real
> distinction with regards to file system.  On both NTFS
> and FAT, as long as you have write access to the file
> in question, the file times can be changed.  I've
> demonstrated this time and again, in presentations as
> well as in my book.
>
> If I'm missing something with regards to the
> distinction with regards to how easy it is to change
> MAC times on FAT vs NTFS, please let me know.

The reason I mentioned FAT as an example is because you can find tools 
which will do it for you for many years now. PC Tools, diskedit, etc. 
You don't need to study or check into anything yourself.
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.
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.
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.
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."
        Gadi Evron.

--
Email: ge () linuxbox org   Work: gadie () cbs gov il  Backup: ge () warp mx dk 
Phone: +972-50-428610 (Cell).
PGP key for attachments: http://vapid.reprehensible.net/~ge/Gadi_Evron.asc
ID: 0xD9216A06 FP: 5BB0 D3E2 D3C1 19B7 2104  C0D0 A7B3 1CF7 D921 6A06
GPG key for encrypted email: 
http://vapid.reprehensible.net/~ge/Gadi_Evron_Emails.asc
ID: 0x06C7D450 FP: 3B88 845A DF1F 4062 E5BA  569A A87E 8DB7 06C7 D450