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 |
23 comments:
Well put Harlan. And thanks for RR and all your contributions back to DFIR.
Carlos,
"Well put".
How so?
> 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.
Facts? Which facts? IMO you basing this solely on your personal observation and experience.
Blogging is not seeking a dialog. Writing a book is not seeking a dialog. Tweeting is not seeking a dialog.
These one directional, post and forget. IMO you are giving the wrong example here if you want dialog.
Do not ask what the community can do for you ask what you can do for the community.
Start contributing to other projects; start answering questions with answers not with more questions; give RegRipper an Open Source license;
be open to other perspectives instead of "I haven't yet encountered a ...".
IMO if you want dialog, learn to communicate.
Joachim,
You and I will simply have to agree to disagree.
See you do it again. You are stopping any chance of dialog, it is you that stops a dialog, not this mythical community you keep talking about.
Not at all, Joachim...I'm more than happy to have an exchange of ideas, opinions, and I've always been open to other perspectives.
I simply didn't see an opportunity for any of that in your first comment.
There was suffucient opportunity. You mention you disagree, then elaborate what you disagree on. What you perceive as different. What you think it could be. Instead of "I disagree" end of discussion. You also did not answer my question where you base your claims on. Another thing you could have elaborated.
Joachim,
I didn't see the point, given your request for a license for RegRipper. It has a license.
which one? GPLv2 ?
https://github.com/keydet89/RegRipper2.8/blob/master/license.txt
Then please read:
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
And:
https://www.gnu.org/licenses/gpl-howto.html
You should also include
* a copy of the license itself somewhere in the distribution of your program. All programs, whether they are released under the GPL or LGPL, should include the text version of the GPL. In GNU programs the license is usually in a file called COPYING.
Where is that file?
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLOmitPreamble
The preamble and instructions are integral parts of the GNU GPL and may not be omitted. In fact, the GPL is copyrighted, and its license permits only verbatim copying of the entire GPL. (You can use the legal terms to make another license but it won't be the GNU GPL.)
Just so I'm aware...why does RegRipper need an open source license in the first place?
In your own words:
Since I first released RegRipper, my intention was that it would be community-based.
Would bit a bit hard to do this without an Open Source license, wouldn't it? Or do you think otherwise?
I don't see why an open source license is required...which is why I asked the question. Adding even a semblance of a license hasn't changed anything about the tool and how others use it, at least, not that I'm aware of.
Why does RegRipper require a license, in your mind?
No Open Source license means, copyright who ever the author is. So not Open Source as in libre or free, but then Open Source as in transparent.
That is fine with me but then don't be surprised if no one contributes to copyrighted software. Since a lot of companies/organization do not allow their employees to do since that would be in violation with their contracts.
I cite you again:
"but rather that analysts would either write and contribute their own plugins, or request (providing sample data, as well) plugins be developed."
"however, that speaker had never reached to me to say, "...here's a plugin I wrote...", "
So what do you want copyright or contributions ?
And is an Open Source license a guarantee for contributions? No way in hell, but not doing it is excluding a potential audience that might.
Also you are diverging from the subject again, as often, and still not answering questions. Another reason why having a dialog fails.
> I cite you again:
And you do so taking the statements out of context.
My point is that license or not, there have been contributions to RegRipper, but that vast majority of the community simply does not contribute.
Those who have, have done so on their own free will, regardless of licensing or copyright. A copyright did not prevent them from either doing something with the tool, or asking that something about the tool be modified.
Before there was even a reference to a license in the tool, RegRipper was incorporated into training courses, added to Linux distributions, etc. People downloaded the tool, people "used" it. Very few of those people did anything to extend the tool...some did, and I'm thankful for that.
Those who have stood up in front of others, or posted to a blog, stating "...RegRipper does not do this..." have done so after acknowledging neither copyright nor license. They would have done so regardless. Some have said that they didn't change anything because they aren't familiar with the programming language that RegRipper was developed in...they never referred to the copyright or license (or lack thereof). When I have informed others of what I've been saying from the very beginning (that I entertain requests), almost all have come back and said that they didn't know that...again, no reference to either copyright or license.
My overall point, which you seem to take exception with, is this concept of "community". In my mind, I cannot fathom that of the number of people who are using RegRipper, there aren't more who are seeing ways to extend the tool. What that tells me is that the vast majority of those using the tool are doing so blindly...and that concerns me in more ways than simply the use of the tool. There are those (very few) who are seeing ways to extend RegRipper and are doing so. There are those who are seeing ways that RegRipper can be extended, but their way of communicating this is to state in public forums, "...RegRipper has a problem and a blind spot because it does not do this...".
Maybe you're correct...maybe this idea of "community" is mythical.
> Also you are diverging from the subject again,...
Again, I do not agree. I read the links you sent, and it states that in order for the license to be correctly applied, it needs to be included in every source file.
Reading this, I felt that it was important to ask the question.
I have answered your questions. Are you perhaps trying to say that I'm diverging because I haven't fulfilled the actions that you want me to, because I have addressed the points you brought up. If you feel that I haven't, please address them specifically...blanket statements such as "you didn't answer my questions" make it difficult to respond. And I'm more than willing to respond.
> blanket statements such as "you didn't answer my questions" make it difficult to respond. And I'm more than willing to respond.
Good, we have a dialog ;) Throwing blankets seem to have helped.
> Again, I do not agree. I read the links you sent, and it states that in order for the license to be correctly applied, it needs to be included in every source file.
I asked you on which facts you based your statement below, or that it was, how it came across to me, that you are basing this solely on your personal observation and experience.
> 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.
Have you read about/talked to other projects how they perceive this? Is this something typical to the field of DFIR?
> And you do so taking the statements out of context.
Enlighten me, I respond on how I read your article. If I'm not reading the message you are trying to bring across I would like to know what your message is then? Apparently this is not clear to me from the original article, but I see you added some elaboration in your last comment.
I read you find the lack of contributions disappointing, and I give you some suggestions on why this might be.
You did not mention the license/copyright anywhere in the article, so that is not something part of your original statement. I'll leave this topic with if it should be GPL v2 please follow their instruction, if is not then except certain people NOT contributing.
> My overall point, which you seem to take exception with, is this concept of "community"
I take exception with your concept of community. Let me elaborate:
http://en.wikipedia.org/wiki/Community
"A community is a social unit of any size that shares common values."
(WARNING don't take this too literally but should bring across the point) So if no ones contributes, there are no common value of sharing, and thus not a value part of the community. That means there is no community or it is a different one.
Since you find sharing an important value, my take on this is, focus on the people that do contribute (since that is the actual community you want), not on the people that don't. This requires a bi-directional communication style, and not a mono-directional one where saying "tough shall contribute".
> What that tells me is that the vast majority of those using the tool are doing so blindly...and that concerns me in more ways than simply the use of the tool.
Totally agree (on the being concerned side), I have a similar concern with books, blog posts, and other non-peer-reviewed "stuff" that are being churned out under the banner of "forensics". Alas not much you can do there if this what the majority of people in the field value.
> There are those who are seeing ways that RegRipper can be extended, but their way of communicating this is to state in public forums, "...RegRipper has a problem and a blind spot because it does not do this..."
There is never a lack of critics, alas that most of them are uninformed.
> I asked you on which facts you based your statement below...
That was one question that I missed. You saying that I am not answering your questions implies that I missed more than one.
> Have you read about/talked to other projects how they perceive this? Is this something typical to the field of DFIR?
Yes, I have. And yes, it appears to be the case.
From what you've shared, I can see your point. If a "community" is based on shared values, and a few have a value that the majority do not seem to share, then down-size the community. And this is something I've done. I have a small group of fellow analysts that I share things with, knowing that they can appreciate it and that they will (and have) share, in return.
> ...other non-peer-reviewed "stuff" that are being churned out under the banner of "forensics"
Along those lines, part of the reason I use the blog and write the books is so that it can be peer-reviewed (and technically, the books ARE peer-reviewed).
After all, that's what happened with "The Art of Memory Forensics"...the authors published something in the book that they had researched, and while I do not consider myself a "peer" of theirs, I was able to use that information and validate their findings through my own independent use of the information. I did not replicate their tests...instead, I used the information operationally, and was able to use analysis techniques to validate and confirm their findings across multiple engagements, and multiple systems.
Why, then, cannot the same thing be done with blog posts? That's a rhetorical question.
> There is never a lack of critics, alas that most of them are uninformed.
And one of the intentions of the post was to inform them. For the true critics, it's irrelevant...but for the few who actually have an idea that they want to share, and simply don't know how...maybe it informs them.
> I have a small group of fellow analysts that I share things with, knowing that they can appreciate it and that they will (and have) share, in return
Good then one last point here, something to reflect on. Be aware of group bias (http://en.wikipedia.org/wiki/In-group_favoritism), closed "communities" lead to isolated thinking patterns. Which for me as an outsider to some of these is a very concerning development as well. Long term this will have a serious negative effect on the field.
> Yes, I have. And yes, it appears to be the case.
Then please reflect this perception of "ground truth" in terms of group bias.
There are several projects out there with a healthy "community" (talking about a broader perspective than DFIR). Reflect on what they do different, what your project and those people you've spoken to, don't.
So I don't agree with these claims here one bit. I agree that the ratio of users versus active contributors is not 1 to 1, but I don't expect it to be.
> After all, that's what happened with "The Art of Memory Forensics"...the authors published something in the book that they had researched
That book is full of stupid mistakes in computer science and forensic analysis basics. Also claims were copied without verifying and mentioning the source material. Wou can't convince me that book is peer-reviewed. I think this is a good example of the damage group bias has on your thinking.
I guess the "community" will have to wait patiently until Joachim (the self appointed god of DFIR) finally releases the "perfect" forensics book then. Until then I guess we should all just give up.
> I guess the "community" will have to wait patiently until Joachim (the self appointed god of DFIR) finally releases the "perfect" forensics book then. Until then I guess we should all just give up.
> the self appointed god of DFIR
Come on anonymously throwing mud, how mature of you.
Apparently you did not read my comments. We don't need more books, blog posts, we need more dialog, more peer-reviewed findings. Less isolated thinking, more dialog across the field.
If you don't agree with my point of forensics books then come with solid arguments not with childish remarks.
Less isolated thinking, more dialog across the field.
Funny...that's essentially what I've been saying.
> Funny...that's essentially what I've been saying.
We don't disagree there.
We disagree on how to make that happen.
The current course of things does not seem to stimulate a dialog.
It only seems to make things more silo-ed. IMO that is not because people don't want to share, it is that they don't want to be criticized.
Instead of burning the speaker of "A Blind Spot in our Incident Response Tools" in a blog post, did you start a dialog with them?
IMO give the right example there. I said this before and will keep saying this "pray what you preach".
> Less isolated thinking, more dialog across the field.
This is what I have been doing not just saying ;) and apparently that message is not as digestible for every one (our Anonymous poster).
Instead of burning the speaker of "A Blind Spot in our Incident Response Tools" in a blog post, did you start a dialog with them?
First off, how was it a "burn"?
Second, here's a quote from my post:
That being said, I contacted herrcore, and as a result of an email exchange where he sent me some sample data.
Maybe the issue isn't one of how digestible it is, but the delivery of the message.
Post a Comment