Timelines, again
I forgot to mention Aftertime in my last blog post, which is a new tool to create and analyse timelines. Rob pointed this tool to me the other day, and I’ve done some limited testing on it. It is very easy to create the timeline, just add the image file and let it crunch through it, all point-and-click and easy. That is nice and I’m sure some will prefer that over the CLI method of log2timeline, where you need to use the command line and know the parameters of the tool, etc. The tool also provides a nice GUI to display the timeline, using separate colors for each source, and to create reports. Yet somehow I got the feeling it might be easy to overlook some of the important events, especially if they are only couple of them. This might be because I’m not used to examining timelines visually like this or because it might be hard to detect a single event that is surrounded with benign ones using a visual method like this. This is something I have to test further, since I think there are a lot of benefits of being able to visualize the timeline.
Harlan Carvey posted yesterday about some of these links that you see in this post. One of which was the addition of regtime.pl into the timeline that includes every change made to the registry. I haven’t added that functionality into log2timeline yet, that is to parse every single registry key into the timeline. Today I’ve only included the UserAssist key, which adds more context to the registry entries than simply dump everything there. In the near future you will see a lot more registry entries parsed using log2timeline, where I intend to parse only specific keys to add to the timeline, parsed and put into context. I’ve been playing around few of these entries and I hope to add in version 0.51, at least part of my thoughts on the subject.
Although I agree with Harlan that adding every registry entry into the timeline can sometimes be an overkill and drown you with events and that in some cases it might loose some context (since you are not parsing the content of the keys). However I have to admit that in some cases it really helps you find some registry entries that you might have otherwise missed. I know that it has helped me greatly in at least few exams that I’ve done where I used tools like regtime.pl or reglookup-timeline to create the timeline. In those cases I had a very specific timeframe which I was looking at, making the addition not so difficult to parse through, and found evidence or settings of software that I did not know at the time was installed (since timeline analysis is often the first step I do). That led me quickly to what I was really looking for, thereby shortening the investigation time considerably. I’m not saying that I wouldn’t have found what I was looking for using other methods, but adding the content of the entire registry into the timeline greatly reduced the investigation time so I think there is definitely value in it. That being said, adding modules for log2timeline that actually parse the content of some specific keys and adding context to those last write times adds more value to the timeline than simply just the last write time and the name of the key, but it will never catch everything and every little piece of software you might have installed. One thing that I liked about Aftertime though was that you could easily put everything into the timeline and then if you didn’t like seeing all the registry keys for example you could simply exclude them from the timeline and focus on something else, so if a particular source was somehow not useful at all, you could easily exclude it from the timeline (something that can be done using awk for instance in an ASCII file, but not something that everyone perhaps likes to do).