Toolkit

Story: Expert undermines hacking suspect's defence

Posted by: Anonymous (Friday 10 October 2003, 5:03 AM)

Windows doesn't do nearly enough to "protect" syslogs, assuming that logging has been enabled and properly configured to begin with.

Best Practices call for active, ongoing archival of individual system syslogs to at least one known-to-be-secure repository system that is not the generator of the original logfiles. You then test for tampering by comparing the (various) archived copies, as a time series of data, against one another. That's where you look for and perhaps find syslog discrepancies.

Given syslogs residing on the very same system that generated them, any number of things could happen to those log files... not the least of which could be filesystem defragmentation, which can and does fully defrag syslogs (provided that the event logging service is taken offline and/or redirected to write to a different set of target files and/or that the defrag occurs before GUI boot).

More compelling evidence would be the presence/absence of significant time gaps in syslog entries (indicating rather inept syslog deletions) and/or syslog entry forgeries (attempting to cover the deletions of legitimate entries).

This "expert"'s so-called block/sector-level analysis of the disk blocks/sectors on which the log files were eventually found to reside, at least as described and (probably) summarized in the article, leaves too much to be desired. It make this expert sound too "block-headed" to be believed, let alone to convict on.

Direct editing of a so-called file, using a disk-level binary editor, would not necessarily "fracture" unfractured blocks, but it would require artful and precise forgeries to cover time gaps created by deleted entries.