Tools
Arsenal Recon -
Image Mounter utility: the web site says that the tool is "
currently geared towards digital forensics and incident response developers, but we have released a sample GUI and command line mount/management utility known as "MountTool" as a proof of concept."
The web site goes on to say, "
We have heard that others in the DFIR community are already building better GUIs and extending the functionality of Arsenal Image Mounter..."; this is great to hear, and I hope that this is something that becomes public. Having a proof of concept tool is great to test things out, but seeing something that extends the capabilities of the utility is even better, and I think, far more useful.
Willi Ballenthin's
EVXTract:
Here is Willi's presentation from the SANS Summit in Prague, on 6 Oct 2013. In the sixth slide, Willi mentions the 6 steps to carving EVT records from unallocated space or other unstructured data. Somewhere in there, perhaps step 4a, should be "given the record size, read that number of bytes into the buffer, and the last 4 bytes should be the same as the first four bytes". This is the "sanity check" I've used as an initial step for validating EVT records.
Anyway, what Willi's presentation and materials really demonstrate for me is the move to carving for records rather than full files. Yes, others have been doing this for a while, in particular the
MagnetForensics folks with their IEF product, but that's not an open source tool. Understanding data structures and going after the individual records can be far more fruitful than going after full files.
Mari has written up an excellent post detailing how to
retrieve deleted data from a SQLite database; she's even provided a Python-based parser. This is yet another aspect of data retrieval that is based on a detailed knowledge and understanding of data structures, similar to
what was discussed here (IE index.dat deleted records), and
here (MFT resident file residue).
Lance's
post regarding the tools he turns to during examinations, broken down by tiers. His list is very useful in that it illustrates a thought process that others can look at for comparison. I can't say that I have a similar breakdown, which probably has more to do with the types of analysis I tend to get engaged in, and the prior information that each of us may have available.
Of course,
how a tool is used can also be very valuable information. For example, from Lance's post, as
well as what I saw at OSDFC, folks use RegRipper, but apparently not the way I use it. It seems that the predominant means of using RegRipper is to just run all the plugins against the available hives. That may be good for some folks, but like Corey Harrell, I tend to take something of a more targeted approach. Often during my own examinations, I don't need
everything...in fact, getting everything can often be an expenditure of time and effort that I can't afford, as I have to sort through a lot of data that isn't particularly useful or beneficial. While in some instances it is useful to take a broader approach, there are times and circumstances when it's far more beneficial to take something of a targeted approach, if for no other reason to do a quick check and get
something of value quickly, leaving the
everything for later. At times, I've found it very beneficial to use a Registry viewer (
WRR is pretty good, although it doesn't handle "big data" values) for viewing and searches, then run specific RegRipper plugins, and then have a plugin open in an editor for tweaking. That's kind of how I went about
this work involving shell items.
Based on recent conferences, I'm going to have to look at adding TSK
Autopsy to one of my own tiers.
Malware Response and Analysis
Claus has a new post up regarding his
Anti-Malware Response Go Kit; in this case, Claus discusses more about his requirements and process, whereas some of his previous posts have been admittedly valuable lists of tools. The one correction I would offer up, however, is in the section where he briefly discusses RegRipper: "
Plugins are developed by the community..." - actually, not so much, really. Yes, there are a number of plugins developed by other folks, for which I am very thankful, and offer a huge thanks to them for doing so. Other plugins were developed or extended because someone (
Corey Harrell) saw the need and reached out to me, but for the most part, the majority of the development of plugins have not been something that's sought after by the community at large. I have updated a couple of plugins (appcompatcache.pl) to support Windows 8/8.1 thanks to the suggestion and submission of additional test data by Eric Z. Also, I've written a number of malware-specific, "tactical" plugins based on something I've seen, usually within just a couple of minutes of reading the material...but again, these are not something that have been requested or sought by the community.
From the Handler's Diary blog,
Analyzing Malicious Processes: very cool use case for Volatility. Not only does the post illustrate how to use Volatility, but it also clearly illustrates what an artifact (in this case, of lateral movement) "looks like", which is something that we often don't see addressed. Even though artifacts are mentioned, many times, there's very little information about what to look for on disk or in memory with respect to those artifacts.
Also from the Handler's Diary - jackcr's
DFIR challenge summary; Jamie Levy (@gleeda) referred to this challenge in her "
Every Step You Take: Profiling the System" talk at OMFW2013.
From Lenny Zeltser, a list of
XOR obfuscation examination tools.
Win32/Trooti is an example of malware that "parks" on a vacant SvcHost value. [
TrendMicro,
M86 Security] It's interesting how the different write-ups address the particular value on which the malware "parks"...some tell us that it happens, others share the results of their particular analysis. More than anything else, I think that this information can help us in reviewing and if necessary, updating our own malware detection techniques.
Conference Followup
There's another write up available regarding recent conferences, in this case, the same ones I was able to attend. As such, the write-up provides something of a different perspective. You can find the
OMFW & OSDFC Recap post over at the HiddenIllusion blog site. This post is more of a blow-by-blow of the conferences, and it does give an interesting perspective on the conferences. A couple of things I wanted to comment on (and this doesn't mean that I disagree...):
From the general notes: "
I was told that my tweets and recap post of last years activities was helpful to those who couldn't attend..." - this is much more of a truism than most really recognize, I think. Not everyone can attend conferences, but very often we're able to learn more about which conferences or events would be most beneficial to us by what others share about their experiences; what was good, what wasn't so good, what there should be more or less of, etc. This sort of feedback can not only be valuable to folks who are planning out their conference attendance, but it can also be extremely valuable to conference organizers and presenters, as well. For example, in the OSDFC section, there was this quote:
On the disappointing side - I did feel like I was seeing a noticeable amount of people doing the same things as others have already done.
That's extremely valuable to know. Yes, you're right...there was content that would make folks think, "wow, I've seen this stuff before", and there could be any number of reasons for that. Sometimes, I think folks pursue something because they're seeing it for the first time, and they don't do a comprehensive literature search prior to kicking off their research. Sometimes, this is good, because it's done for educational purposes, and the researcher may find something new. Remember though...this year, the conference program was crowd-sourced, so it wasn't Brian and the BasisTech staff who decided which presentations would be given.
Under the "Memoirs of a Hidsight[sic] Hero" section, the author says,
"Don't try and write a book about Mac rootkits..."; it wasn't so much that Cem was out to disprove the authors because they were writing a book. Rather, my take was that Cem heard the claims of near-complete anonymity and thought, "that can't be right", and ended up disproving the claims. Maybe the take away from this one would be, "...if you're going to write a book on Mac rootkits, get Cem as a co-author or tech editor." ;-)
With respect to the MantaRay presentation: "...maybe useful for others but doesn't fit into my process flow." This is exactly right...depending upon the types of issues you face, you may not need to run every tool every time. However, one of the useful things about tools like MantaRay and it's predecessor, TapeWorm, is that very often, they're configurable. That is, you can trim them down or add to them in order to meet your needs. The guys who developed MantaRay have provided the tools for use by others, which is great, particularly for folks with similar use-cases, or those new to the issue at hand.
RegRipper
