Pitfalls of Interpreting Forensic Artifacts in the Registry
Please use this topic for discussion of the webinar
presented by Jacky Fox, student at UCD School of Computer Science and Informatics.
A DigitalFIRE (Digital Forensics Investigation Research Laboratory) blog post with a link to the dissertation and scripts referenced in the video can be found here.
I just finished the first 10 pages, and am quite impressed. I can't wait to finish the 101 page document and get on to trying this suite of tools.
-= Bruce D. Meyer, GCWN, GCED, GCFE
Honestly it's a quick read. Thank you for your interest.
Thanks a lot for your presentaion. I found it very useful )
I'm glad you found it useful. If you get on to using the tools please let me know how you get on. I would welcome the feedback.
Can you please contact me so I can get additional information…scripts, paper, etc. Great information.
Thanks for spending the time to share your work with the rest of the community - a really useful and interesting piece of work.
The work on USB artefacts was a great reminder of all the extra areas of evidence that are available (I am not sure I have seen all the information in one useful slide before), as well as some interesting new points on Insertion dates/times and SIDs associated with the access - the quick switching "undocumented feature" whereby additional user accounts become associated with a device is very useful to be aware of, and something that I was unaware of.
It will be interesting to see any outcome of the reasons for the UserAssist counter anomaly.
With regard to establishing the process causing the bulk Enum Key updates. Perhaps ProcessMon within Sysinternals can shed some light on this. ( a filter on Path contains HKLM\System\CurrentControlSet\Enum and Operation contains Set) - a quick check on a windows 7 HP within a VM didn't throw up any bulk changes so far (I guess I would need to leave it going for 24hrs+). The idea being that the process spawning the change should be traceable through Processmon.
Very thought provoking. I jokingly tell my students that Windows was aquired from aliens and this presentation seems to be proof of that. (not to make light of your presentation) There are things in the registry that I'm not sure Microsoft understands. I am very impressed with your presentation and the willingness to dive into this abyss of data. Congratulations! Great presentation!
I'm glad that you followed my presentation so well. I would be very interested to hear the results from your VM experiment. Thaks for your interest and comments.
I watched the video and was pretty fascinated by it, so I took the opportunity to download the paper and tools, and I'm currently reading through the paper. I did learn a couple of new things from the video, so I'm very interested to see what's in the paper.
So far, reading through the paper (I'm only up to page 5), I'm reminded of the gap between academics and practitioners that is so obvious at conferences such as OSDFC.
For example, on page 5, there is the following statement
"Most available open source tools work on extracted registry files meaning that the examiner has to manually extract the registry and associated files prior to usage. This was considered to be a barrier to usage from both a technical skills and a time consumption perspective."
Considered, by whom? The GUI portion of RegRipper does require that the files be extracted, but most folks I've talked to have been more than happy to do that. However, rip.pl does not require that the files be extracted…folks such as Corey Harrell have written and shared batch files that use rip.exe, and only require that a couple of arguments be passed to it, such as the drive letter to which the image is mounted. In short, I think that someone with one perspective will look at something as a shortcoming, while others will look at it as an opportunity.
Based on a quick glance at some other pages, and from the video, I like the idea of research such as this being made available, and I greatly appreciate the time and effort you put into not only doing the work, but writing it all up, as well.
I still have another 96 pages to read…
I am delighted that you have learnt some things from my work, it is nice to return the favour as I have certainly learnt a lot of things from your books.
My tools require extracted registry hives too, so I'm not trying to critisise tools that require this. My thesis as you will see if you get to the end (sorry I know it's long) is really about automation and correlation of work that is often performed manually, hence the idea of automating registry hive extraction. I included a little script to achieve this along with the main tools. I was hoping that the tools might be useful for triage so automating this aspect was an important feature for me.
If you do get a chance to use/look at the tools I would welcome your comments. For me it has been a pleasure to share my research with the community, while I'm back in the real world practising for now I hope to get the opportunity to do some more research in the future.
Again, thanks for publishing your research.
Do you have any concern that by opting to use bash scripts to achieve automation, you're alienating a pretty large user population?
I did visit this very point in my self critisms at the end of the thesis and indeed if I were starting again I think I would give more consideration to Perl. However, to date I have found that anyone that has used my scripts and is capable of extracting registry hives has not been daunted or put off by running bash scripts.
I agree…those who can use the scripts will. However, what the scripts really achieve is a greater level of correlation, not so much interpretation; that is to say that while the scripts bring a lot of information together in one location, the user still has to memorize or look up what each time stamp listed in the USB report means.
My question regarding the user base stems from comments I've heard from analysts that Linux and tools such as SIFT are "too hard". Sure, people will use your scripts, without a doubt…but there's a huge user base out there that ONLY uses EnCase and/or FTK, meaning that they run on Windows systems and therefore cannot use your scripts without installing Cygwin.
After reading through your dissertation, I can see that the end result is a greater level of correlation, along with some valuable research that aids in the interpretation of information available from the Registry…however, I'm having some difficulty seeing where "automated interpretation" was achieved, as analysts still need to know (memorize or look up) to what the various time stamps in the USB report correlate.
Some other comments
Pg 23 - James' Perl module is misidentified throughout the document; first, it is "ParseWin32Registry". Second, it is a Perl module that includes example scripts as part of the distribution; it is not "a suite of Perl scripts". It would be more correct to say that it "includes" a suite of Perl scripts.
pg 38 - "This is a good demonstration of the need to analyse a system as a whole rather than just focusing on one aspect." <- excellent point, couldn't agree more.
pg 52 - "The output generated from regripper is considerably larger and requires manual correlation…" <- this is the result of a design decision early on in the development of RegRipper, as a number of responses were, "…show me everything, let me decide what is important…". Something similar is seen on pg 57, with the comment "…there are also advantages to using an integrated approach, namely the ability to provide greater correlation and automated interpretation." This is true, but from a design perspective with respect to RegRipper, this is not what folks asked for early on in the development. Also, while the tools described in the paper do provide a higher level of correlation, I'm not sure that I see how they provide for "automated interpretation", per se.
pg 53 - "The output from ssid.pl could be reported by network instance rather than as a list." Point taken…but RegRipper is open source and rather than writing an entirely new tool, you can simply change the plugin, or ask someone (me) to do so.
pg 57 - "Every effort has been made to make sure the tools produce output that would be acceptable in court." Interesting statement, as I'm not sure what it means, exactly.
Again, I greatly appreciate your time and effort in this endeavor, as well as the fact that you made the results of your efforts publicly available. Thank you.