I've been looking at why so many files are triggering the anomaly where SI creation time is less than FN creation time. In my testing, I've noticed newer operating systems have many files with this situation. So perhaps this anomaly rule is not as relevant as it once was. Nevertheless, I still think it's worth keeping the check in place. I'd suggest though to change the code for this anomaly so that it only alerts when SI create time is less than FN create time. This cuts down a few potential false positives.
So my changes here remove alerting when the first FN entry is not present. While kind of odd, it's not exactly related to the SI-FN shift issue (at least I don't think it would be). Please have a look and see what you think.
In my testing, I ran the original "std-fn-shft" logic and my updated logic against several SANS images. Here are the results.
Old Dblake (Win XP)
Nromanoff (Win 7)
New Dblake (Win 8.1)
Vanko (Win 10)
Total number of entries parsed by analyzeMFT (all rows including files, folders, alternate data streams)
13,078
116,007
295,183
367,696
Total entries w/ SI crtime < FN crtime in original analyzeMFT
4,312
40,830
125,287
190,853
Total entries w/ SI crtime < FN crtime after these updates
4,312
40,697
123,515
173,226
File entries for primary data stream w/ SI crtime < FN crtime after updates
Hi David,
I've been looking at why so many files are triggering the anomaly where SI creation time is less than FN creation time. In my testing, I've noticed newer operating systems have many files with this situation. So perhaps this anomaly rule is not as relevant as it once was. Nevertheless, I still think it's worth keeping the check in place. I'd suggest though to change the code for this anomaly so that it only alerts when SI create time is less than FN create time. This cuts down a few potential false positives.
So my changes here remove alerting when the first FN entry is not present. While kind of odd, it's not exactly related to the SI-FN shift issue (at least I don't think it would be). Please have a look and see what you think.
In my testing, I ran the original "std-fn-shft" logic and my updated logic against several SANS images. Here are the results.