Carv, I think that we are in substantial agreement. I do believe that MAC analysis can be defended. But I do not think that your "point" can be dismissed as facilely as some appear to think. It is not possible to prove a negative. You can never prove that the MAC times have *not* been altered (unless the computer was buried in the ground). The best that an investigator ever can say is that he performed a thorough investigation in keeping with current professional standards and that he was unable to uncover evidence of MAC time obfuscation. The question is what constitutes a "thorough" investigation. Given that this question is likely to reappear in another venue where we will be required to give an answer, it would be better to discuss this question openly and to develop a professional consensus. At a minimum I would say that an investigator should not rely on MAC analysis alone when other pertinent evidence (e.g. audit logs, IDS logs, firewall logs, and process accounting records) is available that might substantiate or disprove the investigative hypothesis. Process tracking has some drawbacks on Windows 2000. Event Id 593 (A process has exited) uses a different pid (or more precisely an apid) than event Id 592 (A process as started). In addition, event id 593 may not be recorded for all processes, depending on your service pack level. An automated tool such as R592 from http://www.heysoft.de is necessary to do meaningful process tracking on Windows 2000. On Windows XP, process tracking is fairly straight forward. Hard disk space is cheap. I do not view the volume of events as sufficient reason not to do process tracking. In many (most) cases, process tracking data will not be available. But the investigator should not ignore this information when it is. Regards, George. -----Original Message----- From: H C [mailto:keydet89at_private] Sent: Monday, January 14, 2002 10:28 PM To: George M. Garner Jr. Subject: Re: FW: 'touch' on Win32 > However, anyone with > a knowledge of VB script could do the same thing. Which is exactly my point. > The FUNCTIONALITY is a part of the Win32 subsystem > and is in place on any Windows box. Yes, the APIs are there. However, what I was asking is if anyone performing investigations had seen this actually USED, as a means of obfuscating their timeline of activity. > To all those who have responded to your original > post by saying that > they have not seen, or only rarely seen, this > "touch" functionality used > I ask the obvious question: How do you know that? Well, that's not something I tend to pursue publicly, and I have tried to push in that direction off of public forums. > Is it not possible > that this functionality WAS used and you simply were > not aware of it? > To be more precise, what are the *artifacts* of > using the > SetFileTime()API on Windows or comparable > functionality on Unix and how > does one, from a methodological perspective, rule > out its use in a > relevant manner during an investigation? > > One way would be to install a function call monitor > and record calls to > the SetFileTime() API. However, this is not a > common administrative > practice and may not be useful by the time the > investigator arrives on > the scene. Another way would be to enable auditing, > including full > process accounting. Subsequent examination of the > eventlog then should > reveal inconsistencies between file MAC times and > the audit trail. Having process tracking enabled may not provide the information you're refering to. When I open an image viewer to look at an image, the process for the viewer appears in the (properly configured) EventLog, with no reference to the image itself. I can look at a dozen images and the only activity to appear in the EventLog would be reference to the viewer. Now, if I were to enable auditing of File and Object Access, and *then* proceed to designate which files I want audited and how (such as successful READ on all image files), then I would have something I could use in the EventLog. However, I've done testing with this very functionality, and I was inundated with data, much of which I couldn't make heads or tails of without knowing exactly what I'd just done. Another possibility that is admittedly less probable to occur is the use of a tripwire-like utility to protect critical systems. I once wrote a utility in Perl, just as an academic exercise. By combing the entire file system, and comparing not only MD5/SHA1, but MAC times (as well as scanning for ADSs), useful evidence may be found...but only if there is something to compare it to. > The bottom line is that an investigator should not > rely exclusively on > MAC time analysis as an investigative method. Not that I've asked every one, but those analysts I know don't tend to do this. > MAC times will carry > greater probative value when correlated with other > evidence such as > audit logs, IDS logs, firewall logs, and process > accounting records. Agreed. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Tue Jan 29 2002 - 18:03:51 PST