WRF 2/e Contest

I recently posted that Syngress has agreed to publish a second edition of Windows Registry Forensics, and in that post, I mentioned that I wanted to provide those in the community with an opportunity to have input into the content of the book prior to it being published.  I know that it's only been a couple of days since the post was published, but historically, requests like these haven't really panned out.  As such, I wanted to take something of a different approach...at the recommendation of a friend, and stealing a page from the Volatility folks, I'm starting a contest for submissions of "case studies" to appear in the second edition.

Contest
So what I'm looking for is submissions of detailed case studies (or "write-ups", "war stories", etc...I don't want to get tangled up on the terminology) of your triumphs via and innovations in Registry analysis.

Please read through this entire blog post before sending in a submission.

What I don't want is case information, user and system names, etc.  Please provide enough detail in your write-up to give context, but not so much that case information is exposed and privacy is violated.

For the moment, I plan to accept submissions until midnight, 31 Dec 2014.  I may extend that in the future...it really depends on how the schedule for the book writing works out, how far I get, how many submissions come in, etc.  The really good submissions will be included in the book, and the author of the submission will received a signed copy of the book.  And yes, when I say "signed", I mean by me.  That also means that your submission needs to include a name and email address, so that I can reach back to you, if your submission is accepted, and get your mailing address.

I'm looking for the top 10 or so submissions; however, if there are more really good ones than just ten, I'll consider adding them, as well.

Consideration will be given to...
Those submissions that require the least effort to incorporate into the book, with respect to spelling and grammar.  I'm all about cut-and-paste, but I don't want to have the copy editor come back with more modifications and edits than there is original text.  I can take care of incorporating the submission into the book in the correct format, but I don't want to have to spend a great deal of time correcting spelling and grammar.

Those submissions that are more complete and thorough, illustrating the overall process.  For example, "...I looked at this value..." or "...I ran RegRipper..." isn't nearly as useful as correlating multiple Registry keys and values, even with other data sources (i.e., Windows Event Logs, etc.).

Those submissions that include more than just, "...I used RegRipper..." or "...I used auto_rip...".  Submissions should talk about how tools (any tools, not just the ones mentioned...) were used.

Those submissions that include process, data, results, RR plugins used, created, or modified, etc.

Note that if you include the newly created or modified plugin along with your submission, the plugin will be added to the RR distribution.

Submissions
Send submissions so to me as text.  Use "WRF 2/e contest submission" as the subject line.   If you have images (screen captures, etc.) that you'd like to share, reference the image in the text ("insert figure 1 here"), and provide the image in TIFF format.

If you have multiple files (the write-up, a plugin, images, etc.), just zip them up.

Please include your name along with the information.  If you do not want your name included in the content when it's added to the book, please specify as such...however, anonymous submissions will not be considered, as I may want to reach back to you and ask a clarifying question (or two).  So, please also be willing to answer questions!  ;-)

Please let me know if it would be okay to post the submission to this blog, and if so, should your name be included (or not).

If you have any questions about this contest, please feel free to ask.

RegRipper v2.8 is now on GitHub

RegRipper v2.8 is now available on GitHub.

From this point forward, this repository should be considered THE repository for RegRipper version 2.8.  If you want a copy of RegRipper, just click the "Download ZIP" button on the right of the browser window, and save the file...doing so, you'll have the latest-and-greatest set of plugins available.

If you have any questions, please feel free to contact me.

Windows Event Logs

Dan recently tweeted:

Most complete forensics-focused Event Log write-ups? #DFIR

I have no idea what that means.  I'm going to assume that what Dan's looking for is information regarding Event Logs records that have been found useful or valuable to forensic analysts, or potentially could be.

EVT vs EVTX
Windows XP is no longer supported by Microsoft, but there are still XP and 2003 systems out there, and as such, some of us are still going to need to know the difference between Event Logs (XP, 2003), and Windows Event Logs (Vista+).

Besides the binary differences in the records and Event Log files themselves, on XP/2003, there were three main Event Log files; System, Application, and Security.  On my Windows 7 system, a 'dir' of the winevt\Logs folder reports 143 files.  So, there is a LOT of information being recorded by default on a Windows 7 system; while not all of it may be useful to you, there is a great deal of information that can be extracted from the logs when used properly.

Wevtx.bat
When I released Windows Forensic Toolkit 4/e, one of the things included in the additional materials is a batch file, wevtx.bat.  What the batch file does is use LogParser to parse a directory full of .evtx files, and then parse those entries into TLN format for inclusion in a timeline.  The tool evtxparse.exe, used by the batch file, makes use of a mapping file (i.e., eventmap.txt) to map event source/ID pairs to an artifact category tag.  As such, when the entry in written to a timeline, records such as "Microsoft-Windows-Security-Auditing/4624" are prepended with an appropriate tag (i.e., "[Logon]"), based on the artifact category.

I really love this tool!  What I like about it is that it's easy to update (eventmap.txt is just a text file), I can add comments to it to show the source of the information I used to map an event record to something specific, and it acts as a fantastic little repository for all of my past experiences.  Not only is it a great repository, but it's incorporated right into the tools that I use on just about every engagement.

Records
Here are some of the event source/ID pairs that I've found to be useful during investigations, for such things as malware detection, determining the window of compromise, etc.  I'll say up front that these records are not 100% infallible, and may not have extremely high fidelity (some do, others don't...), but they've worked quite well for me at one time or another, so I'll share them here.

Microsoft-Windows-DNS-Client/1014 – DNS name resolution timeout; I've used this one more than once to help demonstrate that malware was on a system, even in the face of anti-forensics techniques (time stomping the malware files, deleting the malware files, etc.). It's not a 100%, infallible indicator, but it's worked for me more than once.  What has also helped is when this event record was seen; in a timeline, I could see that it occurred shortly after a user logged into a laptop, and before the user connected the system to a WAP.  This helped me narrow down the persistence mechanism for the malware.

Microsoft-Windows-Security-Auditing/4720 - user account created; because the bad guys do this from time to time.

McLogEvent/257 – McAfee malware detection - McAfee AV may detect malware behaviors (i.e., run from a Temp folder, etc.) without actually detecting the EXE itself.  This can be very valuable in helping you determine how malware got onto a system.  Also, the AV product may be configured to warn only, and take no action..so, correlate the event records (UTC) to the entries in the McAfee logs (local system time)

Microsoft-Windows-Windows Defender/3004 – Windows Defender malware detection

Service Control Manager/7045 – A service was installed on the system

Service Control Manager/7030 – A service is configured to interact with the desktop

Microsoft-Windows-TaskScheduler/106 - New Scheduled Task registration

Beyond individual event records (source/ID pairs), one of the aspects of the newer versions of Windows (in particular, Windows 7) is that there are a lot of events that are being recorded by default, across multiple Event Log files.  What I mean is that when some events occur, multiple event records are recorded, often across different Event Log files.  For example, when a user logs into a system at the console, there will be an event recorded in the Security Event Log, a couple in the Microsoft-Windows-TerminalServices-LocalSessionManager/Operational.evtx log, and a couple of events will also be recorded in the Microsoft-Windows-TaskScheduler/Operational.evtx log.  Alone, each of these individual events may get little attention from an analyst, but when placed together in a timeline, they leave an indelible mark indicating that a user logged into the system.

Now, what's really great about this is that some of the Event Logs "roll over" faster than others.  As such, some of the source/ID pairs that are part of an indicator cluster may have been expired from their respective Event Logs.  However, the remaining source/ID pairs in the cluster will still provide a very good indicator that that event in question took place.  This is particular useful for infrequent events, and I've used this information more than once to demonstrate repeated activity going back weeks and even months prior to what was thought to be the date of interest.

Anti-Forensics
Event auditing is one of those things that just happens in the background on Windows systems.  This is great, because sometimes Event Log records can help us determine if anti-forensics techniques have been employed.  For example, using Event Log records, you can determine if someone has changed the system time.

During an exam, I found that a system had been infected with malware that installed as a Windows service, and during the installation process, the .exe file had been time-stomped.  Fortunately, when the malicious service was installed, an event source/ID pair of "Service Control Manager/7045" was created, indicating that a new service had been installed on the system.  I was able to correlate that information with other sources (MFT, etc.) to better determine the correct time of when the malicious .exe was created on the system, and nail down the infection vector.

Carving
If you need to carve Windows Event Log records, for any reason...from unallocated space, memory, the pagefile, whatever...the tool to use is Willi Ballentin's EVTXtract. The "tool" is really a set of Python scripts that you run consecutively against the data in order to recover Windows Event Log records.  I've used these scripts a couple of times, and even had a fellow team member use them on an engagement and quite literally recover the "smoking gun".

When carving for deleted records on a Windows XP or 2003 system, I use a custom Perl script that I wrote that's based on some of the code I've released with my books.

Timelines
When all this is said and done, a blog post on just individual Windows Event Log records isn't really all that valuable.  Yes, I've created timelines from just a handful of *.evtx files, for use in triage, etc.  This has proved to be extremely valuable to me.

Resources
WindowsIR: Timeline Analysis
SANS Reading Room: Detecting Security Events Using Windows Workstation Event Logs
NSA: Spotting the Adversary with Windows Event Log Monitoring

Publishing DFIR Books

I recently received notification that Syngress is interesting in publishing a second edition of Windows Registry Forensics.  I submitted my proposed outline, the reviews of which were apparently favorable enough to warrant a second edition.

I've blogged before regarding writing DFIR books, and that effort seems to have fizzed a bit.  I wanted to take the opportunity to give another shot and see if I couldn't resurrect this topic, or a portion of it, just a bit.  So, the purpose of this blog post is two-fold: to set expectations of the upcoming edition, as well as offer those in the community who are interested to have input into the development (what goes in it) of the book.

Based on the reviews of my proposed outline, as well as some of the online reviews (Amazon, SecurityXploded, etc.), I wanted address a few of the comments I  tend to see more frequently than most, and then allow those who read this post to make their own comments.

From the SecurityXploded review:

It would have been better if author would have put up the approach or step by step procedure one should follow while analyzing live & offline system.

...and...

Putting things straight and then discussing relevant tools at each step will be more beneficial.

This is always an interesting statement to pursue, in part because I see it pretty often in things I've written (such as the HowTo blog posts from July 2013), as well as course materials and presentations I, and others, have put together.  As I'm sure others have done, I try to write something that is general enough to apply across multiple situations, and hope that the reader is able to extrapolate what I've written so it can be used in their specific situation.  My thinking...and it may be wrong...is that analysts must be able to take what they've learned from white papers, presentations, training courses, and other sources, and apply that information and knowledge to what they have available to them.  Not everything that an analyst encounters is going to fit neatly into a training course or whitepaper; there's always going to be some twist or variation, based on the goals of the examination, the data available, etc.  As such, analysts need to be able to build on core principles and basic knowledge to be able to meet the challenges before them.

For example, an analyst should be able to review the SANS checklist for analyzing USB devices on Windows 7, read this HowTo (Correlate an attached device to a user) and this HowTo (Determine user access to files), and be able to determine the files a user may have accessed from a thumb drive that had been attached to their system.  Part of this entails that there has to be some point at which a common, baseline level of knowledge must be assumed.  For example, do you assume that most folks know what the Registry is, or how to determine the CurrentControlSet from a System hive extracted from an acquired image?

This is why I advocate that analysts must share their experiences; no one of knows everything, but together, we can know more than any one of us.  None of us is going to have the same experiences as everyone else, but we can all learn from each other's experiences.

Another comment from the SecurityXploded blog post:

However if you are expecting to cover all those important registry locations then you will be disappointed and it is not feasible in one book. 

This is exactly right, and goes back to one of the core things I learned about writing DFIR books...you're not going to make everyone happy.  Someone's always going to be disappointed about what they didn't find in the book.  But you know what...that's okay.  It has to be...if someone tried to write a book that covered everything, that book would never be completed.

I've been working directly in the DFIR field for a little more than 14 years, and I will be the first to admit, I have not seen everything there is to see.  I've done DFIR in an internal, FTE position, as well as as a consultant.  For a bit more than three years, I did PCI response while at IBM ISS.  While my work has evolved over time, there is still a great deal that I haven't seen, and when I write books or blog posts, I most often base what I write about my own direct experiences.  Now and again, someone will share data with me, and I will learn a little something from their experiences.  I like to sprinkle those indirect experiences in, as well, because they broaden the reach of the material.

In WRF 2/e, I do plan to provide examples of analysis processes I've used, based on goals I've been given, as well as things that I've seen during analysis.  However, no one should expect to pick up this book (or any other DFIR book, for that matter) and find the answer to their specific issue or question.  This is particularly true if no effort is made to contact the author while the book was being written.

From the WRF 2/e outline reviews, as well as from other sources, I've seen this little gem:

You need to provide a chapter on Windows Phone 8.

Anyone remember this blog post?  There were two important take-aways from that blog post.  One was that RegRipper does work with the Windows Phone 8 Registry, and what's needed is sample data and input into what examiners find important, so that plugins can be written.  The second is that the hive files were provided to me...I do not own a Windows Phone 8, nor do I have access to these devices, through work or any other means.  Cindy Murphy did send me some hive files extracted from a Windows Phone 8, but that's one system and a very limited amount of data.  I can't write about what I don't know and didn't experience, and can't provide screen captures illustrating data that I do not have.  Would I like to write more about the Windows Phone 8, particularly the Registry?  Sure.  Without a doubt.  But without actual data, I can't really be expected to write much of anything, can I?

Okay, those are just a few of the comments/statements I've seen in reviews, and like I said, I only wanted to address those that I see regularly.  If you have any thoughts or comments about the content that should appear in WRF 2/e, I'd be glad to hear and consider them.  Thanks.

Stuff

IR
Here's a really good...no, I take that back...a great blog post by Sean Mason on "IR muscle memory".  Take the time to give it a read, it'll be worth it, for no other reason than because it's valuable advice.  Incident response cannot be something that you talk about once and never actually do; it needs to be part of muscle memory.  Can you detect an incident, and if so, how does your organization react?  Or, if you receive an external notification of a security incident, how does your organization respond?


A couple of quotes from the blog post that I found interesting were:

...say, “Containment” without having any understanding of what is involved...

Yes, sometimes a consultant (or CISSP) will say this, and sometimes, there is that lack of understanding of how this will affect the business.  This is why having IR built into the DNA of an organization is so important...understanding how the business will be affected by some response or containment procedure is critical.

There is also a modicum of patience and discipline required when it comes to containment, particularly when it comes to targeted threats.  If the necessary instrumentation is not in place to monitor the environment, then prematurely pulling the trigger on some containment procedures rather than taking the time to prepare and conduct the containment procedures in a near-simultaneous manner will likely cause the threat actors to react, changing what they do.  When dealing with these incidents, if someone on the response team decides, "...hey, I can make that change now, so I'll go ahead and take care of it..." can lead to a lot more work.

Another comment from the blog post:

...as a leader and a technologist, you always want everyone to know everything wing-to-wing, and while this can work great in a small organization the reality is that it doesn’t scale for a number of reasons in larger orgs. 

I agree wholeheartedly with this.  For larger teams in particular, it doesn't scale well for everyone to be an expert in everything, but it does work well to have designated pockets of deep expertise.

I know that I'll never be as good a malware reverse engineer as some of the folks I've had the honor of working with.  I can put a great deal of effort into becoming good at it, but that effort would be effort that I wouldn't be spending become better at DFIR analysis.  Also, I've found that an effective approach is to gather as much as I can about the malware...OS and version it's installed on, where it was found in the file system, persistence mechanism, any artifacts or indicators associated with the malware, etc.  I provide these to the RE analyst, and continue my analysis while they dig deep into the malware itself.  When the RE analyst finds something, they provide it back to me and I continue with my analysis.

A great example of this occurred a number of years ago.  I have found some malware that was used to steal banking credentials (NOT Zeus) and shared it with the RE analyst, providing a second file and the information/intel needed to run the malware.  The malware itself was obfuscated, and in return I got a mutex (I didn't have a memory dump, but I did have a hibernation file and the pagefile), the API used for off-system communications, and other valuable information.  With that, I was able to nail down the specific user affected, the initial infection vector, when the infection occurred, etc.

On smaller teams, you won't be able to have those silos, but on larger teams, in larger organizations, it helps to pockets of deep expertise, and someone you can reach to for further assistance.  This is particularly valuable in incidents, due to the ability to perform parallel analysis; rather than having one analyst who many not, say, analyze disk images on a regular basis try to wring as much information and intel out of an acquired image as they can while working an IR engagement, have that task run in parallel by someone with a deeper expertise.  You're likely to get the info you need (and more) in a much more timely manner, while not loosing any time or focus on the engagement itself.  On smaller teams, you're likely going to have a broader base of skill sets that aren't as deep as what you will find with individuals on larger teams.  Larger teams can take advantage of pockets of skill sets, and even geographic dispersion, to keep the flow of the incident response going.

The rest of Sean's blog post is equally interesting.  Sean goes on to provide his thoughts on people, process, and metrics, all with great insight.

To further Sean's thoughts, a great follow-on to his post is this article from WSJ; in particular, the following quote from that article:

“You are going to get hacked. The bad guy will get you. Whether you are viewed as a success by your board of directors is going to depend on your response.”

IR Fail?
Here's an interesting article from Kelly Jackson Higgins (DarkReading) that talks about Fortune 500 companies having IR teams, but many being pessimistic about their team's ability to handle a data breach.  From my perspective, it's good to see that more firms are moving to having a computer security incident response plan, or CSIRP, and that these companies are actually thinking about things like, "...we need a plan...", and "...how good is our IR team?"  Even if there is pessimism about the current team's effectiveness, at least there's thought going in that direction, and a realization and admission of the team's current state.  From my perspective, this isn't really so much of a failure as it is a success that we've come this far.

From the article:

So why are aren't Target, TJ Maxx, and others sharing their war stories to help the next potential victim?

Yeah, you're not going to.  Sharing is not a natural reaction within the DFIR community.  This doesn't mean that it doesn't happen...years ago, while working an IR with a client, I heard that there was a forum in the local area where IT folks from different organizations in the same vertical came together and discussed issues and solutions.  In fact, the DLP solution that my client had in place, which proved to be extremely valuable during the IR engagement, had been purchased as a result of engaging with others in their community.  My point is, sharing can be powerful, and sharing information or intel that helps the next guy when they're attacked doesn't necessarily give away 'secret sauce' or competitive advantage.

Having an IR plan in place isn't enough, either.

No, it's not.  You can't have a plan written by consultants sitting on a shelf...that's worse than not having a plan at all, because the organization will see that binder sitting on the shelf (literally or figuratively) and think that they've checked a box and have achieved some modicum of success.  A CSIRP needs to be organic to an organization (remember Sean's blog post?); it needs to be owned and practiced by the organization.  You can get assistance in writing it, reviewing it, and practicing the processes laid out in the CSIRP.  Having an outside consulting firm come in and run an IR exercise...anything from a table top (in the military, we called this a "tactical exercise without troops", or TEWT) exercise to a full-on IR engagement...is a fantastic idea.

Over the years, I've seen a wide variety of organizations as a consultant.  I've seen those that have been caught completely by surprise by a data breach, those that have IR plans but do not employ them, and I've seen those that have a practiced plan and want someone there to help guide them.  Invariably, those organizations that have been thinking seriously about the need for incident detection and response end up faring much better than others, in a variety of metrics, including the overall cost of the incident.

RegRipper
In a few short weeks, I will be presenting at OSDFCon, talking about some changes to RegRipper that I've had in the works.  I'll say right now that the changes I've been thinking about and working on are not ones that will significantly impact the use of the tool...so come on by and give it a listen.

OSDFCon and OMFW
I've attended and presented at OSDFCon before, and this is has always been a really great conference to attend.

Whether you're going to be at OSDFCon or not, I highly recommend that you consider attending the Open Memory Forensics Workshop, or OMFW 2014.  This is the premier conference on memory analysis, put on by the top minds in memory analysis, from the Volatility Foundation.

If you're attending OSDFCon, be sure to come see Mari DeGrazia's presentation!

RegRipper Tutorial
Speaking of RegRipper, this tutorial was posted recently regarding how to set up and use RegRipper...I have say, I have somewhat mixed feelings about it.  Part of me appreciates the interest in the tool, but

In the name of full disclosure, the author did contact me and ask me to review the article after it was complete.  I responded, but to be honest, at the time that the request came in, I didn't have the cycles to focus on reviewing the article, and I definitely didn't have the cycles to address everything that I read in the article.  So what you're seeing now is what I've worked on a few minutes at a time, here and there, since the article was published.  I'm not going to address everything in the article, because I simply don't have the time to do so, so what I opted to do was pull out just a couple of comments and address them here.

For example...

I have often heard RegRipper mentioned on forums and websites and how it was supposed to make examining event logs, registry files and other similar files a breeze. 

I'm not sure which forums or websites state this, but this is not the case at all.  RegRipper is named as it is because it's intended for use against the Windows Registry...and only the Registry.  It's not intended for use against any other files, in particular the Windows Event Logs.  Right after I first released RegRipper, I did receive a request to have it parse PST files, but that simply wasn't/isn't practical.

As I wrote earlier there is a huge community out there writing plugins for RegRipper.

First off, there is no mention of "a huge community" in the tutorial, up to that point.  Second, there is not a "huge community out there writing plugins".  Yes, some plugins have been submitted over time, and some folks have suggested modifications to plugins...but there is not a "huge community" by any means.  In fact, my understanding is that the vast majority of users simply download the tool and run the GUI...and that's it.  Asking users specifically, via email or in person, what they'd like to see done to make the tool more useful does not often lead to responses such as requests for new plugins.

I could continue with a lot of the different things I found to be amiss (such as in the Downloads section), but it is not my intent to deride this effort.  Again, I greatly appreciate the interest in the tool, and I wanted to address a couple of the comments because I felt that they were wide-spread misconceptions that should be addressed.  I'm not going to do a walk-through and correct everything I find...instead, I'll refer folks to the various blog posts I've written, as well as to Windows Registry Forensics.