Links
SANS DFIR Poster
If you haven't heard, the new SANS DFIR "Evidence of..." poster is available. I can see looking at the second page of the poster that they've added some items of interest that have been talked about recently. For example, under "Browser Usage", I see mention of Mari's Google Analytics Cookies, and under "Program Execution", I see a reference to the AmCache.hve and the RecentFileCache.bcf files.
What's New in Windows 10
Speaking of "evidence of...", one question I see quite often is, "..what's new in Windows {insert newest version number}?" Some folks at Champlain College have written up a Windows 10 Forensics guide.
The Problem with RegRipper
I was reading herrcore's blog post in which malware that persists via a user's shell extensions, and came across the following statement in the post:
The problem with the two tools I mentioned; RegRipper (shellext.pl plugin) and Autoruns is that they rely on the Shell Extension to be registered using the standard method with HKEY_CLASSES_ROOT.
This quote is taken from the first sentence under a header that says, "A Blind Spot in our Incident Response Tools".
Since I first released RegRipper, my intention was that it would be community-based. That is, that by providing a framework such as RegRipper, the strength of the tool would be not simply that it would be downloaded and blindly pointed at Registry hives, but rather that analysts would either write and contribute their own plugins, or request (providing sample data, as well) plugins be developed. That's right. I totally get that not everyone programs in Perl...which is why I provide Windows executable files for the framework. This is also why if someone doesn't program in Perl but strongly believes that they have a good idea for a plugin, all they need to do is write up a concise description of what it is they'd like to see, and email it to me along with some sample data. When this has happened, I've been able to turn around a functioning plugin pretty quickly...usually within 4 hrs, and often within 1 hr.
This sort of thing has happened before. At the SANS DFIR Summit in 2012, I sat in a presentation, during which the speaker stated, "...RegRipper does not have a plugin for {insert functionality}...". That speaker also stated that RegRipper "does not scale to the enterprise" (which is was NEVER designed to do); however, that speaker had never reached to me to say, "...here's a plugin I wrote...", nor did they ever ask me for such functionality in a plugin. I did find out after the presentation that the presentation had been written several months prior, and that a plugin had been written...the speaker had simply not updated their materials.
I get that there are some roadblocks to having a community-based tool...I completely understand that not everyone programs (nor wants to learn), and that of those who do, not all program in Perl. That's okay. I also understand that a major roadblock for a lot of DFIR analysts is simply...communicating. There are a lot of reasons for this, but the fact is that most DFIR analysts simply do not want to communicate with others within the community.
I would suggest that the real "blindspot" or "problem" isn't whether or not RegRipper (or any other tool) contains specific functionality, but rather, what are we, as analysts, are willing to do to communicate with each other.
That being said, I contacted herrcore, and as a result of an email exchange where he sent me some sample data. I'm researching his findings a little bit more to see if I can modify a current plugin (inprocserver.pl, shellext.pl), or would it make sense to write a new one?
In the meantime, here are some links where I've discussed RegRipper in this blog:
Mar, 2011 - Using RegRipper
Jul, 2012 - Thoughts on RegRipper Support
Aug, 2012 - RegRipper Updates
Addendum, 8 June: This morning, I updated a plugin, and created two others, and committed them to the plugin repository.
inprocserver.pl - I updated this plugin by adding "programdata" to the @alerts list in the alertCheckPath() function, and ran it against the test data that herrcore provided. The result was:
ALERT: inprocserver: programdata found in path: c:\programdata\{9a88e103-a20a-4e
a5-8636-c73b709a5bf8}\ieapfltr.dll
cached.pl - new plugin; run it against the NTUSER.DAT hive to get the values from the \Shell Extensions\Cached key. Running it via rip.exe displays the time value, and the two available CLSID values; I added a simple lookup for the second one. As such, the output appears as follows:
Tue May 26 05:31:59 2015 First Load: {BDFA381D-D8C6-441A-BA17-95EB7FEBEA81} (IDriveFolderExt)
Tue May 26 05:34:57 2015 First Load: {9C73F5E5-7AE7-4E32-A8E8-8D23B85255BF} (IShellFolder)
Tue May 26 05:34:57 2015 First Load: {7007ACC7-3202-11D1-AAD2-00805FC1270E} (IShellFolder)
Tue May 26 05:35:05 2015 First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A} (IDriveFolderExt)
Simple enough. However, if you use your command line fu, you can do something like this:
rip.pl -r d:\cases\herrcore\ntusertest2.dat -p cached | find "F6BF"
Launching cached v.20150608
Tue May 26 05:35:05 2015 First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A} (IDriveFolderExt)
cached_tln.pl - new plugin; similar to cached.pl, except that this plugin's output can be added directly to a timeline. Also, this plugin does not have the lookup that cached.pl has...below is an example of the output:
rip.pl -r d:\cases\herrcore\ntusertest2.dat -p cached_tln -u keydet89 | find "F6BF"
Launching cached_tln v.20150608
1432618505|REG||keydet89|Cached Shell Ext First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A}
So, there you have it. Typical caveats apply...such as "..these are based on extremely limited test data..", etc.
Also, something I wanted to mention as a result of looking through the hives herrcore sent me was that there were other indicators added to the USRCLASS.DAT hive, as seen in the image to the left. You can see that in addition to the CLSID\{GUID}\InprocServer32 key, another key was added with the path Drive\ShellEx\FolderExtensions\{GUID}.
If you haven't heard, the new SANS DFIR "Evidence of..." poster is available. I can see looking at the second page of the poster that they've added some items of interest that have been talked about recently. For example, under "Browser Usage", I see mention of Mari's Google Analytics Cookies, and under "Program Execution", I see a reference to the AmCache.hve and the RecentFileCache.bcf files.
What's New in Windows 10
Speaking of "evidence of...", one question I see quite often is, "..what's new in Windows {insert newest version number}?" Some folks at Champlain College have written up a Windows 10 Forensics guide.
The Problem with RegRipper
I was reading herrcore's blog post in which malware that persists via a user's shell extensions, and came across the following statement in the post:
The problem with the two tools I mentioned; RegRipper (shellext.pl plugin) and Autoruns is that they rely on the Shell Extension to be registered using the standard method with HKEY_CLASSES_ROOT.
This quote is taken from the first sentence under a header that says, "A Blind Spot in our Incident Response Tools".
Since I first released RegRipper, my intention was that it would be community-based. That is, that by providing a framework such as RegRipper, the strength of the tool would be not simply that it would be downloaded and blindly pointed at Registry hives, but rather that analysts would either write and contribute their own plugins, or request (providing sample data, as well) plugins be developed. That's right. I totally get that not everyone programs in Perl...which is why I provide Windows executable files for the framework. This is also why if someone doesn't program in Perl but strongly believes that they have a good idea for a plugin, all they need to do is write up a concise description of what it is they'd like to see, and email it to me along with some sample data. When this has happened, I've been able to turn around a functioning plugin pretty quickly...usually within 4 hrs, and often within 1 hr.
This sort of thing has happened before. At the SANS DFIR Summit in 2012, I sat in a presentation, during which the speaker stated, "...RegRipper does not have a plugin for {insert functionality}...". That speaker also stated that RegRipper "does not scale to the enterprise" (which is was NEVER designed to do); however, that speaker had never reached to me to say, "...here's a plugin I wrote...", nor did they ever ask me for such functionality in a plugin. I did find out after the presentation that the presentation had been written several months prior, and that a plugin had been written...the speaker had simply not updated their materials.
I get that there are some roadblocks to having a community-based tool...I completely understand that not everyone programs (nor wants to learn), and that of those who do, not all program in Perl. That's okay. I also understand that a major roadblock for a lot of DFIR analysts is simply...communicating. There are a lot of reasons for this, but the fact is that most DFIR analysts simply do not want to communicate with others within the community.
I would suggest that the real "blindspot" or "problem" isn't whether or not RegRipper (or any other tool) contains specific functionality, but rather, what are we, as analysts, are willing to do to communicate with each other.
That being said, I contacted herrcore, and as a result of an email exchange where he sent me some sample data. I'm researching his findings a little bit more to see if I can modify a current plugin (inprocserver.pl, shellext.pl), or would it make sense to write a new one?
In the meantime, here are some links where I've discussed RegRipper in this blog:
Mar, 2011 - Using RegRipper
Jul, 2012 - Thoughts on RegRipper Support
Aug, 2012 - RegRipper Updates
Addendum, 8 June: This morning, I updated a plugin, and created two others, and committed them to the plugin repository.
inprocserver.pl - I updated this plugin by adding "programdata" to the @alerts list in the alertCheckPath() function, and ran it against the test data that herrcore provided. The result was:
ALERT: inprocserver: programdata found in path: c:\programdata\{9a88e103-a20a-4e
a5-8636-c73b709a5bf8}\ieapfltr.dll
cached.pl - new plugin; run it against the NTUSER.DAT hive to get the values from the \Shell Extensions\Cached key. Running it via rip.exe displays the time value, and the two available CLSID values; I added a simple lookup for the second one. As such, the output appears as follows:
Tue May 26 05:31:59 2015 First Load: {BDFA381D-D8C6-441A-BA17-95EB7FEBEA81} (IDriveFolderExt)
Tue May 26 05:34:57 2015 First Load: {9C73F5E5-7AE7-4E32-A8E8-8D23B85255BF} (IShellFolder)
Tue May 26 05:34:57 2015 First Load: {7007ACC7-3202-11D1-AAD2-00805FC1270E} (IShellFolder)
Tue May 26 05:35:05 2015 First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A} (IDriveFolderExt)
Simple enough. However, if you use your command line fu, you can do something like this:
rip.pl -r d:\cases\herrcore\ntusertest2.dat -p cached | find "F6BF"
Launching cached v.20150608
Tue May 26 05:35:05 2015 First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A} (IDriveFolderExt)
cached_tln.pl - new plugin; similar to cached.pl, except that this plugin's output can be added directly to a timeline. Also, this plugin does not have the lookup that cached.pl has...below is an example of the output:
rip.pl -r d:\cases\herrcore\ntusertest2.dat -p cached_tln -u keydet89 | find "F6BF"
Launching cached_tln v.20150608
1432618505|REG||keydet89|Cached Shell Ext First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A}
So, there you have it. Typical caveats apply...such as "..these are based on extremely limited test data..", etc.
 |
| USRCLASS.DAT excerpt |
