±Forensic Focus Partners
±Your Account

![]() |
![]() |
![]() |
![]() |
±Latest Articles
±Latest Videos
±Latest Jobs
Back to top
Skip to content
Skip to menu
Back to top
Back to main
Skip to menu
Pitfalls of Interpreting Forensic Artifacts in the Registry
Page Previous 1, 2, 3, 4, 5, 6, 7, 8 Next-
woolleybiker - Newbie
Re: Pitfalls of Interpreting Forensic Artifacts in the Regis
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
Last edited by woolleybiker on Nov 01, 12 21:16; edited 1 time in total
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
Last edited by woolleybiker on Nov 01, 12 21:16; edited 1 time in total
-
mpawlik - Newbie
Re: Pitfalls of Interpreting Forensic Artifacts in the Regis
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!
-
JackyFox - Member
Re: Pitfalls of Interpreting Forensic Artifacts in the Regis
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
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
-
keydet89 - Senior Member
Re: Pitfalls of Interpreting Forensic Artifacts in the Registry
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...
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...
-
JackyFox - Member
Re: Pitfalls of Interpreting Forensic Artifacts in the Regis
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
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
-
keydet89 - Senior Member
Re: Pitfalls of Interpreting Forensic Artifacts in the Registry
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?
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?
-
JackyFox - Member
Re: Pitfalls of Interpreting Forensic Artifacts in the Regis
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
Regards,
Jacky