Join Us!

Pitfalls of Interpr...
 
Notifications
Clear all

Pitfalls of Interpreting Forensic Artifacts in the Registry  

Page 1 / 4
  RSS
Jamie
(@jamie)
Community Legend

Please use this topic for discussion of the webinar

Some Pitfalls of Interpreting Forensic Artifacts in the Windows Registry

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.

Quote
Posted : 01/11/2012 3:55 pm
bdmeyer
(@bdmeyer)
Junior Member

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.
very Promising!

-= Bruce D. Meyer, GCWN, GCED, GCFE
https://sc-isac.sc.gov

ReplyQuote
Posted : 01/11/2012 8:21 pm
JackyFox
(@jackyfox)
New Member

Hi Bruce,

Honestly it's a quick read. Thank you for your interest.

Jacky

ReplyQuote
Posted : 01/11/2012 8:23 pm
galmood
(@galmood)
New Member

Hello Jacky,

Thanks a lot for your presentaion. I found it very useful )

ReplyQuote
Posted : 01/11/2012 8:33 pm
JackyFox
(@jackyfox)
New Member

Hi,

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.

Thanks,

Jacky

ReplyQuote
Posted : 01/11/2012 8:37 pm
jwyeager
(@jwyeager)
New Member

Jackie,

Can you please contact me so I can get additional information…scripts, paper, etc. Great information.

John Y.

ReplyQuote
Posted : 01/11/2012 8:40 pm
JackyFox
(@jackyfox)
New Member

Hi John,

Thank you, glad you liked the information. The scripts and full paper are available at http//digitalfire.ucd.ie/?p=337

Regards,

Jacky

ReplyQuote
Posted : 01/11/2012 8:47 pm
woolleybiker
(@woolleybiker)
New Member

Jackie,

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.

Regards

ReplyQuote
Posted : 01/11/2012 9:10 pm
mpawlik
(@mpawlik)
New Member

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!

ReplyQuote
Posted : 01/11/2012 9:12 pm
JackyFox
(@jackyfox)
New Member

Hi Woolleybiker,

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.

Jacky

ReplyQuote
Posted : 01/11/2012 9:42 pm
keydet89
(@keydet89)
Community Legend

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…

ReplyQuote
Posted : 02/11/2012 12:55 am
JackyFox
(@jackyfox)
New Member

Hi keydet89,

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.

Regards Jacky

ReplyQuote
Posted : 02/11/2012 2:29 am
keydet89
(@keydet89)
Community Legend

Jacky,

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?

ReplyQuote
Posted : 02/11/2012 2:37 am
JackyFox
(@jackyfox)
New Member

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.

Regards,

Jacky

ReplyQuote
Posted : 02/11/2012 3:12 am
keydet89
(@keydet89)
Community Legend

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.

ReplyQuote
Posted : 02/11/2012 3:59 am
Page 1 / 4
Share: