Using RegRipper

I've received a couple of questions about RegRipper and it's use, and I thought that I'd take the opportunity to provide some more information about the use of this free, open source tool.

First, let me say that Windows Registry Forensics (WRF) is something of a user guide for RegRipper.  I found that even though I had provided a PDF document and several blog posts that talked about how to use RegRipper, and answered a lot of questions in various lists and forums, there were still questions and some confusion.  In fact, in most cases, there seem to be the same questions again and again. In an attempt to address this situation, I thought that perhaps writing a bit more extensive user guide for RegRipper and providing it in one location, in WRF, would be useful.

An example of the questions I receive have to do with getting the UserAssist data from an NTUSER.DAT hive file collected from one of the versions of Windows.  As it says on pg. 185 of WRF, the userassist.pl plugin was written specifically for Windows XP systems, while the userassist2.pl plugin was written to work on all versions of Windows.  There is also a third RegRipper plugin, win7_ua.pl, which was written in 2008 in response to the use of Vignere encryption (vice ROT-13) of the value names in Windows 7 Beta.  So, if you want to get UserAssist information from any version of Windows, except Windows 7 Beta, you can use userassist2.pl.

Terminology
In short, RegRipper runs plugins, which are simply Perl scripts (the files that end in ".pl") located in the ".\plugins" directory of the installation.  You can run a list of plugins against a hive file by selecting a plugins file or "profile", which is a flat text file, with NO extension, that has the plugins listed in order.  Within the profile, lines that begin with "#" are treated as comment lines and skipped...this allows you do comment out specific plugins or add your own documentation.

So, again...RegRipper (both the GUI and the CLI "rip") are similar to the Nessus vulnerability scanner, in that it is simply an engine that runs plugins.  The "plugins" are Perl scripts located in the ".\plugins" directory...files that end in the ".pl" extension.  If you want to run more than one plugin against a particular hive at a time, you can create a "plugins file" or "profile", which is a file with NO extension located in the ".\plugins" directory; this file is simply a text file that contains a list of plugins to be run, in order, with one plugin (drop the ".pl" extension from the plugin name) listed on each line.  You can comment the profile using "#"...RegRipper ignores lines that start with this character.

Listing Plugins
To get a list of plugins (files with ".pl" extension located in the ".\plugins" directory), there are a couple of things you can do.  The package shipped with WRF, as well as provided online, includes the Plugin Browser, a GUI means not only for seeing details about the available plugins, but also building or editing profiles.  Or, if you like, you can run the following command from the command line:

C:\tools>rip -l

This command will provide a list of plugins right to STDOUT.  Another option, to provide you with the same information in .csv format, would be to use the following command line:

C:\tools>rip -l -c > plugins.csv

Just open the resulting file in Excel or your favorite spreadsheet application, and sort to your heart's content!

Another thing...if you have any questions about the syntax for rip.pl/.exe, simply type the following command at the command prompt:

C:\tools>rip

or

C:\tools>rip -h

Other switches ("/?") will also work, as well.  And hey, if worse comes to worse and you just don't like the command prompt, open the rip.pl file in Notepad or a text editor!  ;-)

Reporting Issues
When you do have what appears to be an issue, sometimes it's very helpful to look at a couple of things first.  You can actually do a bit of troubleshooting on your own, and it doesn't require any programming ability to do so.  When I first released RegRipper back in 2008, several people I knew ran it against the live NTUSER.DAT on their system.  Don't do that...RegRipper is intended for "dead box analysis", meaning that it's designed to be run against hive files extracted from other systems, not against the hives from the system you're currently logged into.  Others ran it against hive files from the systemprofile directory, and one person even ran it across a file named "NTUSER.DAT" that was 256K of zeros.  So, if you have an issue...try looking at the file in a viewer (there's an excellent free one listed in WRF).  Maybe the reason the plugin is telling you that a key or value doesn't exist is because...well...it doesn't exist (or RegRipper can't find it in the provided path).  Also, look at the version of Windows you're running the plugin against.  Where this can be important is, for example, the UserAssist data, as the UserAssist subkeys (those listed between the UserAssist and Count keys) are different from XP to Windows 7.  Another one is the ACMru key...running the acmru.pl plugin against a Windows 7 NTUSER.DAT won't reveal any information, as that key isn't used on Windows 7.

If, at this point, you still can't figure out what the problem is, please feel free to contact me, and include a concise, thorough description of the issue.  For example, please be sure to include the version of Windows from with the hive was acquired, which hive you're working with, and which plugin you used.  If possible, please provide a copy of the hive.  Also, there are several plugins that are now available that I didn't write, so it might also be a good idea to provide the plugin itself.

Finally, remember...RegRipper is free, and open source.  This means that you can write your own plugins (WRF explains how...) and you can see what various plugins do simply by opening them in a text editor.  Many of the plugins I wrote and provided with the distribution contain links to references in the comments of the plugin, which can be very useful for validation, and even just as general interest.  I know a lot of folks are going to say, "...but I don't program, nor do I understand Perl...", and that's okay...in many cases, there is some plain English in the comments of the plugin that tell you what it's trying to do.

A great big THANKS to Brett Shavers for setting up and maintaining the RegRipper.net site.

Links and Stuff

Digital Forensic Search
Corey Harrell's done some pretty interesting things lately...most recently, he set up a search mechanism that targets a specific subset of Internet resources that are specific to the digital forensics community.  Sometimes when we're searching for something, we head off to our favorite search engine and cast a wide net...and we may not get that many hits initially that are pertinent to what we're looking for; by narrowing the field a bit, more relevant hits may be returned.

One of the issues with the community is that there's a lot of good information out there, but it's out there.  Many analysts have expressed a bit of frustration that they can't seem to find what they're looking for when they need it, and that they don't know that they need it until...well...they need it.  I've also talked to people who've done hours of research but not documented any of it, so when the issue they were working on comes up again, they have to go back and redo all of that research again.

Rootkit Evolution
Greg Hoglund posted to his Fast Horizon blog recently, and the title...Rootkit Evolution...sparked my curiosity.  Sadly, when I read the post, it wasn't really anything more than a sales pitch for Digital DNA, whereas I had expected...well...something about the evolution of rootkits.  I mean, that's kind of what the title suggested.  Anyway, one statement from the blog caught my interest, however:

...we are still ahead of the threat.

While I don't disagree with this, I would suggest that attackers may find that it isn't necessary to employ rootkit technology.  Now, don't get me wrong...I'm sure that this does happen.  But for the most part, is it really necessary?  Look at many of the available annual reports, such the Verizon Business Security report, M-Trends, or TrustWave's Global Security Report...some of the commonalities you may see across the board include considerable persistence without the need to deploy rootkits.

So...is the research important?  Yes, it is.  They're still being used (see the Chinese bootkit).  Now and then, these thing pop up (well, not really...someone finds one...) during an incident as a well-designed rootkit can be very effective.  It's just like NTFS alternate data streams...as soon as the security community considers them passe and stops looking for them, that's when they'll make a resurgence and be used more and more by the bad guys.

What a Tweet Looks Like
Ever wondered what a tweet looks like?  I'm sure you have!  ;-)  By way of a couple of different links comes a very interesting write-up of what a tweet looks like from a developer's standpoint...click on the big picture in the middle of the post to enlarge the map-of-a-tweet (or "Twitter Status Object").  Most forensic analysts will likely look at the map and see the value right away.

Okay, so how would you get at this?  This sort of information would likely be in some unstructured area of the disk, right...the pagefile or unallocated space.  So, if you were to run strings or BinText against the pagefile or unallocated space extracted from an image via blkls, you would end up with a list of strings along with their offsets within the data.  What I've done is write a Perl script that goes into the data at the offset that I'm interested in, and extracts however many bytes on either side of the offset that I specify.  I've used this methodology to extract not only URIs and server responses from the pagefile, but also Windows XP/2003 Event Log records from unallocated space, translating them directly to timeline/TLN format.  Doing this provided me with a capability that went beyond simply carving for files, as I needed to carve for specific, perhaps well-defined data structures.

Something like this could be used to quickly and easily extract tweets from unallocated space or the pagefile.  Run strings/BinText, then search the output to see if you have any unique search terms, such as a user name or screen name.  Then, run the script that goes to the offset of each search term and extracts the appropriate amount of data.  This can be extremely valuable functionality to an examiner, and can be added to an overall data extraction process using free and open source tools.

Writing Open Source Tools
The above section, the imminent publication of Digital Forensics with Open Source Tools (the book was Cory Altheide's idea and he was the primary author, as is due to be published on 15 April), and the upcoming Open Source Forensics Conference (at which Cory and I will both be speaking...), all combine to make a good transition to some comments on writing open source tools.  Also, this is a topic that Cory and I had considered addressing in the book, but had decided that it was too big for a sidebar, and didn't quite fit in anywhere in particular.  After all, with all of the open source tools discussed in the book, we would really need to get input from others to really do the topic justice.  As such, I thought I could post a few comments here...

For me, writing open source tools starts as a way to serve my own needs when conducting analysis.  Throughout my career, I  have had access to commercial forensic analysis applications, and each has served their purpose.  However, as with any tool, these applications have their strengths and weaknesses.  When conducting PCI forensic investigations, a commercial application made it easy to set up a process that all of the analysts could employ, but we also found out that some of the built-in functions were not exactly accurate, and that affected our results.  The result of that was to seek outside assistance to rewrite the built-in functions, in order to get something that was more accurate and better suited to our needs.  We would then export the results and run them through an open-source process to prepare an accurate count of unique numbers, etc.

So, sometimes I'd write an open source tool in order to massage some data into a format that is better suited to presentation or dissemination.  However, there have been other times when no commercial application had the functionality I needed, so I wroted something to meet my needs.  A great example of this is the MBR infector detector script.  Another is the script I wrote to carve Windows XP/2003 Event Log records from unallocated space.

I can guess that one response to all this is going to be, "...but I don't know how to program...", and my response to that is, you don't have to...you just have to know someone who does.  Not every analyst needs needs to know how to program, although many analysts out there can tell you that understanding programming (anything from batch files all the way to assembly...) can be extremely beneficial.  However, having someone who understands what you do and can program can be extremely beneficial when it comes to DFIR work.

Too many times, when it comes to DFIR work, analysts are sort of left on their own.  Business models of dictate the necessity for this...but having a support mechanism for engagements of all kinds can be an extremely effective means of extending your team's capabilities, as well as preserving corporate intellectual property. 

Even if you aren't part of a DFIR team, you can still develop and take advantage of this sort of relationship.  If you know someone within the community with programming skills, what does it hurt to seek their assistance?  If they, in turn, provide you with effective, timely support, then you have a great opportunity to further the relationship by supporting them in some manner...even if that's just a "thank you" for their efforts.  Many folks with some programming capabilities are simply seeking new challenges and new opportunities to learn, or employ their skills in new ways.  So when it comes to writing open source tools, many times, the only real "cost" involved is a "thank you" and acknowledgement of someone's efforts to support you.

Scanners
Lenny's got a post up that lists three tools for scanning the file system for malware with custom signatures.  these are all excellent tools; in fact, if you remember that I had provided instructions (from MHL) regarding how to install pescanner.py on Windows systems, two of the tools that Lenny mentions (ClamAV, Yara) can be included in the setup for pescanner.py and the signatures used to locate suspicious files.

Signatures are one way to locate malware and other suspicious files on a system.  However, signatures change, and they must be kept up to date.  You can also use signatures to locate all packed files, as well as files "hidden" using other obfuscation methods.

Keep in mind, however, that this is only part of the solution.  Because signatures within malware files do change, we also need to consider the network, memory, and other parts of the system (i.e., Registry, etc.) to look for indicators of malware.  In fact, many times, this may be our first indicator of malware.  I've found previous infection attempts were malware has been loaded on a system, only to be detected and quarantined by the installed AV product.  I could see the names of the files within the AV and Application Event Logs.  Interestingly enough, files of the same name were created a couple of weeks later, indicating that the bad guy had obfuscated his malware so that the AV wouldn't detected it, and was able to get it successfully installed.

There's more to malware detection than just scanning files for signatures.  If all you have is an acquired image from a system, and a malware infection was suspected, there are a number of other things you can look at in order to find ancillary indicators of an infection.  Scanners should be part of the malware detection process.

Links

Digital Forensics Framework
The guys over at DFF have an open-source framework used as both a digital investigation and development platform.  As this is an open-source tool, Cory did discuss a previous version of this tool in the Digital Forensics with Open Source Tools book.

The DFF guys recently posted on Time Filtering, using DFF to filter the image based on time stamp information.

While I think that this is a great step forward, I also think at the same time that this sort of data visualization is of limited value.  As I've been creating timelines, I've been looking at ways to potentially present the information in a visual manner that would make analysis easier and more efficient; to be honest, I have yet to find something like this.  Others have talked about such presentation methods as a histogram showing volumes of activity, but in the same breath, they'll also talk about malware following the Least Frequency of Occurrence (LFO) on systems; I'm not sure that showing spikes in activity necessarily lends itself to finding those things that occur least frequently on a system.

AntiForensics
Craig Ball wrote this article for Law Technology News, on the use of antiforensics.  Many times, measures taken to foil the work of forensic analysts were originally intended as a privacy measure, but even if those actions are intended specifically to hide the user's activities from the analyst, they are often not even a speed bump in the road to analysis.

During an investigation I determined that an "evidence eliminator" application had been used.  This analysis was of an older case, and the image was from a system that had been acquired several years prior to my analysis.  When I did some research on the version of the application, I found that it deleted specific Registry keys...but I was able to recover the most recently deleted keys from unallocated space within the hive file itself.  Previous subkeys and values were recovered via the hives found in the System Restore Points.

Antiforensics techniques target the training of the analyst...that's pretty much it.  For more information, see the Parsing EVT Records section below.

Images
The DFF guys also included a link to the Digital Corpora site, from which the NTFS image described in the DFF blog post was downloaded.  This is a great place to go to get access to some images, one of which is of a Vista system, apparently.

Hacking
One issue that continues to be a threat is disgruntled former employees.  Gucci was recently confronted with this issue.  What's interesting about the post to the Sophos NakedSecurity blog is that the fired former employee reportedly gained access to the network by first having created an account for a fictional employee, and then after being fired, social engineered the helpdesk and convincing them that he was that fictional employee.  After that, he was able to return time and time again.  This is just an example of how someone can use an organization's process against itself, taking full advantage of that process to perform a wide range of malicious actions. 

Using RegRipper
I recently received the following quote from someone who used RegRipper and the regtime.pl plugin recently, but asked to remain anonymous (permission was given to post the quote, however):

I have the date and time in which an IDS caught a piece of malware being downloaded on the network to a user's machine. I need/needed to look for clues to see if the exe actually executed or not. I was using FTK's registry viewer to create a timeline of last write times for Keys but Registry Viewer doesn't let you export in a format other than HTML, which is just not helpful.

RegRipper gives me a nice line by line way to see the time and date stamps in a way in which they are much more viewable, WHICH IS GREAT. 

Now, I'm not posting this to poke fun at nor admonish AccessData...not at all.  I'm also not saying that one tool is any better or worse than another...all tools have their strengths and weaknesses, and the real power of a tool is in who uses it.  I wanted to post this publicly to demonstrate to some who may not have used RegRipper or be familiar with it to see that, even though it's not a commercial tool, it can still be very useful.  I tend to think that a number of folks in the DFIR community use specific tools because they feel that they have to...their employer purchased a tool or set of tools, based on some ancillary knowledge of the industry or due to a customer requirement.  As such, there's considerable reticence toward trying or incorporating new tools, and rather than seeking the best tool to solve the problem, the problem is redefined to conform to the tools being used.

Open Source Conference
Speaking of tools, Brian Carrier sent out an email recently announcing the Sleuth Kit and Open Source Digital Forensics Conference on 14 June 2011 in McLean, VA.  The day before the conference, there will be "two half-day workshops that will allow you to get hands-on experience with analyzing web browser artifacts and making timelines with open source tools."

Speakers at the conference will include Cory Altheide, Brian Carrier and Jon Stewart.  You had me at "Cory Altheide".  ;-)  While remaining a fairly brief conference, this still looks as if it will be a good one, and I'm hoping that Cory and I will have copies of Digital Forensics with Open Source Tools available.

Chinese Bootkit
There's a new post over on the ThreatPost blog that discusses a Chinese bootkit.  There's some interesting information available, and a graphic that demonstrates the process by which systems are infected.  Part of that process includes an MBR infector, something for which I'd written a Perl script to help me detect during forensic analysis.  Unfortunately, there isn't a great deal of information available in the blog post about the MBR infector, but I will say that it appears that these sorts of malware are popping up more frequently, so this is definitely something you would want to include in your malware detection process.  After all, with the right tools, it only takes a few seconds to check for the possibility of an MBR infector, so we're not talking about extending your process by a day or more.  This Net-Security article indicates that the MBR infector copies the original MBR to the third sector, so the MBR infector detector would work very well in helping you find indications of this bit of malware.

Parsing EVT Records
Lance recently posted about an EnScript he provided to help parse "classic" Windows Event Log (.evt) records from unallocated space.  This is very similar to my recent post about the same thing, albeit the fact that the approach I took uses only free and open-source tools; however, if you're a heavy EnCase user, you'll probably want to go with Lance's solution.  More than anything else, I think that what this shows is that there's a need for these sorts of things within the community...many times, there simply isn't one, single way to accomplish something, and having multiple tools is a good thing.

I've recently received a number of requests to share this code and technique, and the first time I did so, I sent the script within 10-15 min of receiving the request.  And then didn't hear a thing back until I followed up three days later.  Really...is it so hard to thank someone for sending you something that you asked for, and just acknowledging that you received it?

Presentations
I was over reviewing the offerings on the "What's New" page at the e-Evidence.info web site, and found Nick Klein's presentation from RuxCon. Interestingly, slide 9 includes the bullet, "Be specific in defining the objectives and what evidence might assist in determining the facts."  Slide 11 of that presentation is all about documenting what you do.  This is interesting to me because it's very similar to what Chris talks about in his Sniper Forensics presentations.

Malware Analysis
MalwareAnalyzer 2.9 was released recently.  This project is written in Python, but provided as a Windows executable.  I haven't seen too much out there about this one, but projects like this are always worth a look.

Readin' and Writin'

Richard Bejtlich recently wrote an interesting blog post on reading, and followed that up with some answers to questions posted as comments to the first post.  In his first post, Richard discusses several types of reading; I tend to find myself reading mostly for information or entertainment, but when I'm writing a report or book, I will most often resort to a proofreading style of reading as I go back over what I've written.  Right now, my entertainment reading consists of a book on the life of George Washington and the ebook version of William Gibson's Zero History.

Many times, when I read for information, thoughts and ideas marinate and percolate, not just with respect to what I'm currently reading, but also including other sources...stuff heard in podcasts, other books or whitepapers read, etc.  For example, when I was reading Will Gragido and John Pirc's Cybercrime and Espionage, something that I read combined with work I'd done in the past...PCI breach investigations, and the QSA certification/re-cert classes I was required to pass...to ignite some interesting ideas.  So while I was reading, I would write down some notes, and then revisit those notes later after I'd finished reading, or even a day or two later.

Now, this a good place to transition from types of reading to types of writing.  One type of writing, such as note taking, is meant for personal information retention.  Often, we'll take notes and jot down little missives as a way to remind ourselves of something, or simply to document what we might have thought was a good idea at the time.  Another type of writing (documenting case notes, report writing, book writing, etc.) is meant more for transmitting information to others.  This style of writing will encompass a variety of forms, but for the most part the overall goal is to preserve and transfer information for others to use.

One method of writing I made great use of while I was in the military is illustrated in how I would write fitness reports ("fitreps"), the military term for "personnel evaluations".  I would start the fitreps several weeks out by consulting my platoon commander's notebook, and jotting down some notes to myself with respect to key elements I would like to highlight in the report.  Then I would set aside specific time for myself to revisit these notes over the next couple of days or weeks, allowing my thoughts to "marinate" and crystallize a bit.  By focusing for an hour or two each week, I could get the reports completed in a manner that I was very comfortable with, rather than rushing at the last minute and submitting something that I wasn't comfortable with and wasn't complete, and might have a detrimental effect on the Marine's career at some point in the future.  I'd actually seen the effect that poor planning and writing had on a Marine's career; one of my Staff Sergeant's was applying for the Warrant Officer program, and the selection committee had found a fitrep written on the SSgt in which the reviewing officer, a Marine Captain, had stated that the SSgt deserved to be awarded a medal...but never submitted a write-up for the medal.  In short, poor planning and execution could have a negative impact on someone's career later on down the road.

As a community, I don't think that we do enough reading or writing.  By reading, I mean really reading for comprehension, and by writing, I mean really writing to convey some sort of information.  Too many times, I see questions being asked in online forums, and the response that is received has no correlation to the question; it's as if whomever had read the question had only read every third or fifth word, and just answered another question all together.  Also, we all see emails and posts to list servs and forums that would benefit greatly from spellcheck or just a review for grammar.

It all comes down to thought processes.  One simple way to expand our horizons is to read something, and when we do, put more thought than just "neat!" into what we're reading.  Another way to expand and develop ourselves professionally is to write more for public consumption.  When you read something, do you think critically about what you're reading?  Or do you simply accept it without question because the person writing it is someone that you or others consider to be an "expert"? 

If you think that something you've read is a good idea, why do you think that?  Is it because it would be (or would have been) useful to you in some way?  How so?  Can you articulate that?

Ultimately, what we do ends up in some sort of written form.  When we perform analysis, many times the end result is a report to someone...our boss, a customer, etc.  The way we provide value through the reporting process is to think critically, and provide a clear, concise description of our findings to the customer, in a manner that they can understand and use. 

So how do we go about doing this?  A lot of us read...even it's 140 characters or less at a time, we tend to read stuff, right?  So what do you do at that point?  Do you simply retweet, or do you use that as the beginning of a blog post?  If you are writing a blog post, are you simply providing a link to what you read, or are you writing a description of how the information was impactful or meaningful to you?

There a lot of opportunities out there.  For example, look at what Corey's done over at the Journey into IR blog, with his exploit artifacts posts.  This is just one example of what can be done.  Regardless of the route you choose to take, or the path you choose to follow, reading something within the community (book, tweet, blog post, etc.) and not taking the opportunity to think critically about what was read and to open a discussion on the topic, sharing your thoughts with others...all of this is simply a missed opportunity.

More on Breaches...

Sorry...no pun intended.  No...wait.  I totally meant it.

I was reading through some news items recently, and came across an article on Yahoo! news that refers to the recent Epsilon breach, (also read about it on KrebsonSecurity.com) in which, it appears, a number of email addresses were exposed.  However, some things about the article I read caught my attention...

From the article:
Epsilon said that while hackers had stolen customer email addresses, a rigorous assessment determined that no other personal information was compromised. By itself, without passwords and other sensitive data, email addresses are of little use to criminals. But they can be used to craft dangerous online attacks.

Okay, is it just me, or are the last two sentences contradictory?  I mean, without other information, email addresses are useless to criminals...except when they are used to "craft dangerous online attacks."  What are "dangerous online attacks"?  Well, Uri Rivner, the Head of the Security Division at EMC, recently posted "Anatomy of an Attack" on the RSA blog, and states in that post that the breach to their systems started with a phishing attack...specifically crafted emails were sent to specific individuals, knowing that at least some of them would be likely to click on the attachment.

Now, dear reader, please do not assume that these two incidents are tied together in any way, as that's not what I'm saying, nor am I suggesting it.  But what I am saying is that there is a considerable disconnect between what some think online criminals want or need, and what they actually end up going after.  For example, what does the second sentence in the above quoted paragraph sound like to you?  To me, it sounds like a justification to NOT have to notify, based on state notification laws (the first of which was California's SB 1386).  Think about it.  By specifically stating that all of this other personally identifiable information (PII) was not exposed along with the email addresses, there's now justification that the breach laws don't come into play, and by extension/implication, neither do any compliance regulations.

Okay, but someone still accessed your systems and took this information.  And by "took", I'm referring to the fact that while you still "have" the information, so do they.  So this isn't like real-world theft where someone steals your car and you no longer have possession...this is an instance where the confidentiality of the information on which your business runs has been compromised.

In addition, the article goes on to indicate that more than just the email addresses themselves were exposed...the businesses (banks, hotels, etc.) that the owners of those email addresses frequent were also exposed.

Do you know what this reminds me of?  The designer drug trade.  Apparently, designer drugs are outlawed based on chemical structure, so once one drug is outlawed, a chemist comes up with a new, potentially more powerful drug, with a different chemical structure, which is therefore legal until it's discovered by law enforcement and broken down enough to be uniquely identified.  The reason this breach reminds me of this sort of thing is that an organization was breached, and the critical information on which that organization's business relies was compromised...but not enough information to require notification by state breach laws, based on the specific definition of PII.  However, the information that was compromised...this email address is for someone who uses CitiBank, etc...can still be employed to devastating effect (refer back to the RSA breach).

So, Epsilon is notifying its customers...and folks like @briankrebs on Twitter are tracking notifications, and even receiving responses from individuals who are receiving five or more notifications...so that's a good thing.  We see in the media all the time where those who get out in front of an incident and are very open about it fare much better in the long run than those who cover it up in legalese or just flat out deny that it happened.  But I wonder how things would have worked out had the organization taken a proactive approach and done a better job of preparing for an incident.  For example, I wonder what the effect of having Carbon Black installed on systems would have had on the overall incident detection, and ultimately, response.

Folks, the fact is that the instant you think that you don't have anything anyone would want or could use, you've lost..it's a total Sun Tzu thing.  Even if you can not possibly imagine how someone would use or profit from the data that you process or store, someone else likely already has.  At the very minimum, you've likely got CPU cycles, RAM, and storage space that can be used as a staging area or jumping-off point.

So, what do you do about this?  One way to address the situation of the inevitable security incident or breach...after all, the last couple of months should have clearly demonstrated to all that NO ONE is immune...is to be ready for it to happen.  So why not seek out a trusted adviser, someone who has dealt with breaches and incidents across a wide range of clients, and cultivate a relationship?  Incident preparation is more about a change to your corporate culture than it is about purchasing devices and software; a great deal of preparation can be done without purchasing a single device.  However, the lack of visibility that most organizations have will likely be addressed by some sort of purchase, but we're not talking about dropping a truck-load of gear off at your doorstep.  There's a great deal that can be done, and you're going to likely be sold whatever solution is provided by the vendor that you call.

Breaches, Links, and other stuff...

Breaches
As many of you know, I am (quite thankfully) no longer involved in Visa PCI breach investigations.  However, something I saw in the news recently did attract my attention; specifically, Briar Group LLC is the first restaurant chain fined under the Massachusetts data breach law (here).

So why is this interesting?  Well, most of the time I was doing this PCI work, I was rarely aware that any of the organizations I encountered got fined.  Yes, there were one or two that I heard about later, but like I said, it was rare.  Mostly, I'd go on-site, scope the incident, collect data, return to the lab to analyze the data and submit my report...and that was it.  Now, I didn't really need to know what happened, to be honest, but after the first year, organizations that had been breached would ask me, "What happens after you submit your report?", and I really didn't have much of an answer.  As far as I could tell, QIRA firms had only two functions with respect to PCI breaches...pay to keep their analysts certified, and submit reports within the timeframe specified.

This article provides a good deal of information, and for me, a bit of deja vu.  For example, while the actual issue isn't described in any detail, the incident itself is described as having first occurred in April 2009, and went undetected until December 2009.  If you have reviewed any of the cumulative annual reports that have come out over the years, and in particular the Verizon Business Security report, you'll notice that this sort of thing isn't unusual at all; organizations rarely detect an intrusion while it's in progress, but rather get notified by an external third party, well after the incident occurred.  I think that this is in part due to a lack of visibility into their networks, but I also think that there is a lack of intelligence provided by the oversight organization (collects up all reports), and then acted upon by those organizations who fall victim to these breaches.

Restaurants aren't the only organizations affected by these breaches.  Other businesses, such as credit unions, are being breached, as well.  While it may appear that credit unions are subject to a different set of compliance measures, these measures really aren't all that different from what's been mandated for other organizations.

With respect to the RSA breach, Federal News Radio 1500 AM has an interview with Gene Spafford, Executive Director, CERIAS, that is well worth a listen.

Getting Help
I'm not going to pick on LE for this one, because this same sort of thing applies to others, as well...but even with "simple" customer service stuff, I tend to get names, titles, and such when talking to folks.  In this particular case, it appears that the information on the cell phone was thought to be important, so one would think that all due care in handling the device would be the order of the day.

I recently had an issue I was attempting to address and wanted to get some credible information before proceeding.  As such, I reached out to Eoghan and Terrence at cmdLabs, and I have to say that their response and support was very greatly appreciated.

The point of all this is something that I think has its roots in the community fragmentation discussion that took place recently.  For my money, if the situation were more than just idle curiosity, I'd seek credible assistance.  However, having observed the industry for a number of years, I still believe that many analysts are simply afraid (for whatever reason) to ask for or seek out assistance, and others are simply asking the wrong questions to begin with.

What are your thoughts?

APT Tabletop Exercise
This recent post (link above) over on the SANS ISC blog caught my attention.  One statement in particular that caught my eye was:

If you're not on the obvious-targets list already...

Kevin goes on in the post to point out that every organization has its secrets, and he's absolutely right.  More importantly, I would suggest that it's the height of folly to think that you don't have something someone wants, whether that something is intellectual property, or simply storage space and CPU cycles.  I mean, here in the US, it's getting close to tax time, so if you were to survey a wide range of systems, you would probably find tax-related software (TurboTax, etc.) and information on many of these systems.  Also, loading a key logger or 'data jacker' on a system will often result in online banking or shopping credentials being revealed.  Ultimately, a compromise may come down to simply the connectivity and processor power, as the compromised system is part of a botnet.

Speaking of APT and preparing, it would probably be a good idea to take a look at the RSA blog, and specifically the Anatomy of an Attack post, written by Uri Rivner.  The post does a very good job of covering the general methodology of how these attacks occur, and even provides information about the specific details regarding the spear phishing attack that led to the initial entry.

For folks who are more detailed oriented, such as myself, the rest of the post is light on actual details, with the exception of some domains used by the attackers.  There are some details, such as the use of FTP to transfer files, but in other cases, the methodology is discussed without details.  That being said, there is enough information there to infer the nature of what occurs on systems compromised by these actors.

Looking at the details that were provided, I have to wonder what that post would look like had Carbon Black been installed on critical systems within the infrastructure.  Speaking of which, the early release of Carbon Black starts today...drop on by the Kyrus web page and check it out!


Blog
Brad Garnett moved his blog recently...it's now the Digital Forensic Source blog.  Brad hasn't been terribly prolific, but if you follow the Case Leads posts on the SANS Forensics Blog, you'll find Brad's posts to be similar, providing links to items you might otherwise have missed.  Sometimes you may run across something that will lead to another blog or blog post or media article that's of interest.



Reading
Speaking of blogs, Richard took the time to answer some questions from a previous post (on Reading) over on the TaoSecurity blog.  I thought that the previous post was interesting, but found the questions that Richard chose to respond to even more so.


Over the years, I've found Richard's reviews of various books to be very insightful, and it has been clear that he's put some considerable effort into the reviews.  I have always suspected that he does this because he puts his name on the review (ie, doesn't post it under Anonymous), and realizes that the entire review reflects upon him and his position.  I've seen quite a number of reviews of digital forensics that have amounted to "It was good" or simply "It sucked."  I've seen other reviews that were really nothing more than a listing of chapters and a regurgitation of the content in each.  As such, I tend to put a lot of value in reviews such as those that Richard writes, as they are very insightful.

I especially enjoyed the first question (and response) in the blog post.  I won't copy-paste it here, as you really should head on over to Richard's blog and check it out.  Regardless, I have to say that the question is pretty typical; like others, Richard is doing something that he enjoys doing, and he's doing it entirely for free.  Yet, there's always going to be someone who will ask for something more, many times without offering anything of their own. 

With respect to the final question on the blog, I pretty much followed what Richard mentioned when I did a recent review of the ebook edition of Cybercrime and Espionage; while I took notes directly in the material using the Kindle functionality, I also took notes in a notebook.  I know that some will probably look at that as extra work, but I usually find when I read books such as the one from Gragido and Pirc that I not only get ideas and insights about the material presented, but I will also sometimes find tie-ins to other books or online materials, so having handwritten notes is a great way of solidifying those thoughts in my mind, and having something right in front of me to review later.

Windows 8
Finally, I caught an article on CNNMoney this morning that indicates that Microsoft is getting ready to release Windows 8.  I love job security.

More Links...

Carbon Black
Every now and again, I talk about incident preparation.  For the most part, as a responder, this is something of a fantasy, because most folks that call people like me are simply not prepared for a computer security incident.  However, every once in a while, responders do get a chance to work with a customer who was either prepared for an incident, or in the process of getting there, and it's a whole different world!

So when I talk about incident preparation, many times those things that I talk about, like network segmentation, VLANs, enabling more appropriate logging, etc., are all things that require a good bit of work because, to be honest, well, they do.  They require changes to how the organization has been doing business for some time.  However, many of the changes are just the first step; for example, increased logging requires additional storage space, as well as someone to collect and possibly even review the logs.

Well, the folks at Kyrus Technology have a solution called Carbon Black.  Cool name, I know...but what is it?  Here's a description from the FAQ:

Carbon Black is a software sensor we created that monitors key points on the operating system and gathers data that is useful to intrusion responders and system administrators for security and compliance functions.

Carbon Black is less than 100 KB and runs on 32- and 64-bit Windows systems, from XP through Windows 7. Given sufficient demand, Linux and OS X versions may be warranted in the future.

I've had an opportunity to install a standalone version of the sensor on a Windows XP SP3 VM, and so far, it's proven to be very valuable.  The sensor monitors execution on systems, watching what's being run, and and logs this in a couple of different formats.  The full version logs to a remote system, either within the organization's infrastructure or to a designated SOC. When a new executable is detected, CB will make a copy of it, which in itself is pretty cool.  Right now, the sensor has execution monitoring, but an update due out on 4 April will include file system modifications, socket creation, and a new UI. 

Another update planned for this summer will include monitoring for Registry modifications, as well as a schema and API.

So, what can you do with Carbon Black?  Well, quite a bit...and not just IR.  One of the case studies that the Kyrus guys have involves cost reduction by looking out across an enterprise to determine the overall use of an office suite of applications; by determining that not all of the applications included in the suite were being used by all employees, the CIO was able to reduce the license costs and save the organization a good bit of money.

But what does all this mean to IR?  Well, CB is pretty lightweight...I'm running a standalone sensor in an XP SP 3 VM with 1GB RAM, and there are no noticeable hitches or slow downs.  As an analyst, there are a number of places that I look on systems for information.  For example, I will look to the Application Event Log for indications of running AV, and possibly any detections.  However, Event Logs (particularly on XP and Windows 2003) tend to "roll over", so I will also look for the text-based AV logs on the system, which tend to contain more historical information.  Sometimes, there is no AV installed on the system.  Other times, I will find that the infrastructure has Process Tracking enabled, so I see the corresponding events in the Event Logs...most times, this isn't the case.  Another option for getting some information about programs run on a system includes Prefetch files, but application prefetching is not enabled by default on Windows 2003 and 2008.

CB would be useful in a variety of environments.  The first that comes to mind is a large data center; such systems usually have a small set of processes that actually run all the time on the servers, so finding new things being run on systems would, after a familiarization period, actually be pretty simple.  Remember the Least Frequency of Occurrence?  But this would also apply to SMB infrastructures; if you follow Brian Krebs blog at all, you likely have seen that a pretty significant number of SMBs have contacted him over the years to say that they got hit with Zeus and funds were stolen from their bank, transferred to money mules.  While Carbon Black isn't a preventative measure (it doesn't block stuff), having something like this in place, reporting to a SOC would significantly improve detection, as well as response by law enforcement.

But again, Carbon Black isn't just about IR...IR is one of the uses of a sensor like this.  If any of this sounds interesting to you at all, get in touch with the Kyrus guys and ask them about their case studies.

Tools
The Malware Analyst's Cookbook tools are now online.  This is an extremely well-written and valuable book for analysts to have available, and the "recipes" that demonstrate the use of the tools really do a lot to show folks what can be done.  I have found that a lot of analysts really look to this sort of thing; "show me how it's used" really does a great deal more to get them to actually use it than just posting the tool to the web.  The Cookbook is an excellent and invaluable resource, not just to malware analysts, but also to a wide range of infosec professionals, offering a great deal of insight into the nature of malware.

I have a blog post here that describes how to get pescanner.py running on Windows.

Registry Stuff
The folks over at the DFS blog have an interesting post about Registry backups on Vista, Win2008, and Win7.  Apparently, the backed-up copies of the Registry hives on Win7 are the result of the RegIdleBackup Scheduled Task.

This is definitely something to keep in mind when analyzing these systems.  For example, I have used regslack on a number of engagements, and found some pretty valuable information.  Running a 'diff' on the current, active hives and the backed up versions might provide some useful insight, as well.  So this is yet another analysis technique to add to your bag of tricks.

Links and Stuff

VMWare Tip
Jimmy Weg shared a tip over on the Win4n6 group that may be useful to others.  Jimmy pointed out that on a sidebar on pg. 102 of Windows Registry Forensics, I mention trying several times to interrupt the VMWare boot process so that I can access the BIOS.  Jimmy suggests making this a bit easier by adding bios.bootDelay="4000" to the settings.ini file in order to create a 4 second delay. 

MarkG added a suggestion for using the VMWare host menu to select Power on to BIOS rather than simply booting the VM.

Thanks to both Jimmy and Mark...these tips may be very helpful to someone performing research, or attempting to use the techniques described near pg. 102 in WRF.

Sniper Forensics
Chris has posted another installment of his Sniper Forensics series over on the SpiderLabs Anterior blog.  This one is called Part IV: Finding Evil.

Chris and I worked together on the IBM team a while ago.  Chris moved on to TrustWave, and before I left IBM, the team submitted a letter to Visa and dropped off of the PCI QIRA list.  So, while I worked PCI response engagements for about 3 yrs (which included the associated certification and annual re-certification), I haven't worked these engagements in a while, and Chris and his team continue to work them on a pretty regular basis.  As such, there's a good deal that Chris and his team sees on a regular basis that I no longer see.

In this installment of the Sniper Forensics series, Chris discussed looking at systems which were part of a payment processing system; however, it appears that while the systems processed card holder data (CHD), they were apparently known (or thought) to NOT have been breached when Chris was called in to "investigate".  As Chris said in his post, we all tend to get analysis engagements like this..."I think this system may have malware or may have been breached, but I'm not sure".  In many cases, there are no definitive facts to point at, like a pop-up on the Desktop, AV detecting something, etc., and as such, it behooves us to have a thorough, documented process for addressing these types of engagements.

In short, the process used in this engagement appeared to be to acquire the necessary data (memory, volatile data, images, logs) based on scoping, and then perform analysis based on this data.  Rightly so, Chris draws on his past experience, as well as the customer specifications ("2.  What are you hoping that I don't find?") to determine what to look for in memory (as well as on the disk), which appears to have consisted of four specific types or artifacts of processes, and the checks are based on known items that the team had seen on previous engagements (process name variations, etc.).

Chris also described examining his timeline, going back 6 months to look at file "birth" dates ("B" in the "MACB" timeline listing) on files.  In his post, Chris didn't mention where the 6 month time frame originated, but he does say that the installation date for the system was in 2009.

One thing I wasn't clear on is this statement...

Searching the timeline also helped me to identify potential dump files.  I know most modern RAM dumpers obfuscate the output files by either using some basic encryption or even just encoding (like with an XOR).  It doesn't have to be fancy – just put the stolen data in some format that a regex won't identify.

I think it would be interesting to know (if it's not TrustWave company proprietary IP...) how someone would go about searching their timeline for files that Chris describes in that statement.  I think it's great that company's such as TrustWave are sharing information in the manner that they are, and my hope would be that, in cases such as this, that sharing would go just a bit further.

Some thoughts...
Reading through the post, it's clear that the scope was rather limited...and to be honest, this is often the case, as the customer will many times limit the scope.  This seems to have been the case here, as one of the scoping questions appears to have been, "2.  What are you hoping that I don't find?"  However, limiting the analysis in this manner can potentially be very dangerous, as the analyst may miss things that are different from those specifications.

One example that comes to mind is a RAM dumper, which is something Chris mentioned (item 1 in his list) in the post.  I have seen these before...the ones I saw were a combination of tools what would be run by a service, and that service would have a random sleep() time (some had a specific time that they slept after system start); what this means is that the back-office point of sale (POS) payment processing system would be booted, and the "bad stuff" would sit and wait for a specific process's virtual memory to accumulate CHD.  At some point, it would "wake up", dump process virtual memory, and "scrape" track data out.  Due to some very specific artifacts associated with the variant I was familiar with, we were able to easily determine the window of exposure, or how long the system had been actively breached.

However, what this means is that you're not likely to find the processes for this stuff running in memory.  You should, of course, find the service that is waiting, but the other, ancillary processes will run based on a specific trigger, and they tend to run very quickly, so if you're not dumping memory during the exact time that those processes run, you won't "see" them in a memory dump.  And it's relatively simple to "hide" the service in a memory dump, or "hide" the file on the system using time stomping techniques.

Overall, the post discussed looking for some very specific items in the data that was collected; it's probably safe to assume that the overall documented process that Chris and his team uses in instances like this wasn't completely listed in the blog post, simply due to space and brevity.  There are a lot of other checks that could have been done quite easily and efficiently to provide a more thorough, comprehensive result, and I'm sure that in order to save space and not loose the reader, most of these process steps simply weren't mentioned.

Chris was exactly right in the post; "...as professionals, sometimes we have to improvise."  I agree.  I'm sure that like other professionals, Chris and his team have a documented checklist of items to look for, and tools to use, when they encounter customer requests such as this, and I'm sure that it wasn't discussed in detail for brevity's sake. 

Reaching back into the dark recesses of my memory, Chris and I worked a case together where someone had broken into a company in a specific industry (not banking) and the intruder activity that we observed included searching for files that contained the word "banking"; so, sometimes a breach doesn't necessarily start out as being about CHD, or whatever critical data is maintained and processed by the customer.  However, a breach is a breach, and considerable work may need to be done to determine whether or not the intruder accessed that data.

So, I'm sure that a much more comprehensive, documented process was used in "finding evil", as there is a great deal of analysis that could have been done quickly and efficiently, but it simply wasn't included in the post to keep the post from growing too large to be read.

Be sure to catch Chris at the SANS Forensic IR Summit this summer in Austin! 

WRF Review
Grayson posted his review of WRF on his An Eye on Forensics blog.  I would like to give a big THANKS to Grayson and others who've taken the time to read through the book and posted their thoughts.

Community
There have been a couple of posts recently regarding "community" that have garnered a bit of attention.  First is David Kovar's Fragmentation of the digital forensics community post, and the second is this one on Belonging and Community from David Sullivan.

Having viewed the infosec "community" for about 14 years and the DFIR community for about 10 of those years, I've experienced and seen a good deal of what David Kovar talks about in his post, and I have to agree wholeheartedly with many of his points.  Also, like David, I have written programs (Perl scripts) that I have freely provided to the community, and many of you may know that one of my pet peeves is responding to someone who says that they have an emergency need for a particular script or update to a current script, only to not acknowledge receipt of that script and not provide so much as a thank you for the effort.  So much for "community", eh?

Mr. Sullivan starts his post off with the question, "...unless you are an established forensics professional is there even such thing as a community?"  I would suggest to Mr. Sullivan that a "community" is where you make it, and like other communities, some within the community create their own subcommunity.  By this, I don't mean an offshoot or tangential community, I mean that some simply create a community of trusted advisers that they reach to and support through various means.


One of Mr. Sullivan's questions bears a response:  I wonder if people on the inside realise how tough it is for newcomers to the area to gain any foothold into whatever community does exist.  Is it the nature of the business that makes professionals wary of new faces?

I really don't think it's a matter of "new faces" as much as it is, what are you willing to do, most particularly for yourself?  How many times have you gone into a forum or seen a post to a listserv, and you become immediately and acutely aware that the original poster (OP) made no discernible effort to search either the forum or Google for any information pertaining to their question?  Sure, there are a number of posts where the OP is looking for the solution to a homework assignment...those are pretty clear.  However, a community is about sharing, and dropping into a forum to post a question, rather than doing the research yourself and then posting your findings, does little to further the community.  I don't know for sure, but this may be what David Kovar was referring to when he mentioned bad behavior persists in his post.  Some communities advertise themselves as being "noob friendly" and oriented toward learning, but do little to support that role.

Links

Exploit Artifacts
The Journey into IR blog has an interesting post regarding exploit artifacts.  This one is specific to CVE 2010-0094, and provides information with respect to exploit artifacts for Admin and non-admin users.  The post lists some excellent file system and Registry artifacts, and they're worth taking a look at and cataloging. One of the things I do in my malware detection process is look for PE files (with .tmp or .exe/.dll extensions) in the user %TEMP% directory (based on the operating system version)...this blog post mentions several file system artifacts in that directory that would be of interest and worth checking out during a wide range of exams (CP/Trojan Defense, intrusion, malware detection, etc.).

One thing I would say about the post is that the Registry artifact posted is confusing...it says that the path to the Registry key affected is "HKLM-Admin", but it should say "HKCU-Admin" for the admin user.

Be sure to take a look at the follow-on post, as well...

Addendum: Plugin complete...

SOP
One of the issues faced in corporate environments is that when something is detected, it's simply quicker to take the box offline, "nuke it from orbit", and reinstall the OS, apps and data.  This was noted in a recent SANS ISC post.  The age-old issue with this approach is that if a thorough exam isn't performed, and the infection or compromise vector isn't determined (based on fact and not speculation) then the system remains open to exploitation and compromise all over again.  So, while the argument appears to be that "it's quicker" to just nuke the box and move on, is it really quicker to keep doing it over and over again?

I completely understand the need to quickly reprovision systems and get them back into service.  But there's such a thing as moving too quickly...to keep with the movie references from the SANS ISC post, consider Arnold S. in "Twins"; "You move too soon."

Anyway, there are a couple of things that you should consider adding to your standard operating procedures (SOP) for these situations.  The SANS ISC post mentions using disk2vhd, which is free and is a good option to consider.  Another is to download FTK Imager (free) and acquire a copy of the drive before reprovisioning.  If you need to mount the image as a VHD file, MS provides the free vhdtool.exe.

The point is that "nuking from orbit" is indeed a quicker response...the first time.  However, not understanding the overall issue of how the system became infected/compromised in the first place quickly reduces the value of this approach, as the system becomes re-infected.  Consider the situation where the compromise is NOT a result of out-of-date patches...what good is setting the system up all over again with up-to-date patches?

If you still find yourself without time to pursue more than simply making a copy/image of the system, why not outsource the analysis?  Contact someone you know and trust within the DFIR community and ask for assistance.  If you're addressing this from a corporate perspective, consider establishing a retainer-based setup with a trusted advisor.

APIMonitor
Ever want a tool similar to strace, for Windows?  Did you ever want to see more about what an application is doing, and how it's doing it?  Check out APIMonitor.  While this tool does appear similar to ProcessMonitor, there are some interesting differences, such as the buffer view, and the ability to monitor services.

Review
Eric J. Huber, of the AFoD blog, posted a review of Windows Registry Forensics on Amazon a bit ago, but I wanted to mention it again here, as this is what helps get the word about the book (and its potential value) out to the community.

Thanks again to Eric and the others who've posted reviews on Amazon, or on other publicly-accessible sites!

One thing I'd like to mention with respect to the content of the review is that the tools from the DVD that accompanies WRF are available online, and the link is continually available from the Books page associated with this blog.

Using RegRipper

Sometimes I'll receive or see questions in a forum about RegRipper...does it to this, does it do that?  Sometimes I get the sense from these questions that there's tire-kicking going on, and that's fine...but I've always thought that it's been pretty clear what RegRipper does...what problem does it try to solve.

RegRipper is an open-source tool that allows the user (usually an analyst or responder) to extract specific information (keys, key LastWrite times, values, etc.) from the Registry.

As a side effect, RegRipper is also an excellent facility for retention of institutional knowledge.  Let's say an analyst finds something that she hasn't seen before through Registry analysis, as a result of 10 hours of dedicated analysis.  She can write a plugin, documenting everything, and then provide that plugin to other team members.  Now, without having her knowledge or expertise, or having spent that same 10 hours digging, everyone of the other analysts on her team can "find" and extract that same information.  Two years later, after some analysts have left and new ones have been hired, we have the same effect, again without the new analysts having to spend 10 or more hours to find the same thing.  And the data is extracted every time.

RegRipper is NOT a search tool, although there are plugins that will parse through binary data to retrieve information that would not be found via any of the usual search tools.  You can program the ability to do some searching into a plugin, sure...but RegRipper is not a tool you would use to perform general searches of Registry hives.

Below are some of the more popular questions I get:

Does RegRipper work with Windows 7?

This is one of those questions that I'm not sure I know how to answer.  If I say, "yes", I'm afraid that there's an expectation that every possible plugin for Windows 7 that could ever be written has been written and is included with the distribution.  If I say, "yes, but...", anything after the comma will get lost, and we're back at the last answer.

The fact of the matter is that RegRipper works with all versions of Windows from NT up through and including Windows 7.  I've used it on everything from Windows 2000 through XP and on to Vista and Windows 7 systems.  It works because the Registry structure, on a binary and data structure level, remains the same across all versions.  Where things go haywire a bit is when a key or value has been added, moved or deleted...which happens quite often between Windows versions.

So, the long answer is that yes, RegRipper works on Windows 7, but the caveat is that it must have the plugin for the data in which you're interested.

Sometimes, the above question is more often asked as, Why doesn't RegRipper do X?  The answer to that is usually, Because you haven't written the plugin yet, my friend.  ;-)  Folks, RegRipper is open-source, and free.  It comes with a great deal of documentation on how to use it.  For example, if you want to know what rip.exe can do, just type "rip -?" or "rip -h" at the command prompt.

Does RegRipper do X?

Much like Nessus, RegRipper is an engine that runs plugins.  If you want it to do something, you can make it do it.  The tool is open source, and is written in Perl. 

One of the tools I included with RegRipper is "rip", either with the .pl or .exe extension, which is simply the command line version of RegRipper.  Rip has some cool features.  For example, you can run either single plugins or entire profiles from the command line, and capture the information to files using DOS redirection.  The output from rip goes to STDERR and STDOUT, so use the appropriate redirection to capture everything.

If you want to know what plugins you have, use rip -l -c > plugins.csv, and open the resulting file in Excel.  When the Registry forensics book was released, I included a GUI tool called "Plugin Browser" that lets you browse through the plugins one at a time.

Can you make RegRipper do X?

Yes.  And so can you.  RegRipper is open-source, based on Perl.  There's very little in the way of a "proprietary" API...in fact, there isn't any at all.  RegRipper encapsulates some regular Perl APIs, such as the print() function, but that's it...it's just encapsulated.  RegRipper is based on the Parse::Win32Registry module by James McFarlane, which is easily installed into ActiveState Perl using the Perl Package Manager (PPM).

Need some help?  No problem.  There are a number of plugins available, and you can open any of these in an editor (or even NotePad) and use them as a basis.  In fact, this is exactly how I do it.

If you need even more help, and would like me to write a plugin for you, all I need is a clear, concise description of what you want, and a sample hive that contains the data.  That's it.  If you give me those, and I have the time available, I can usually turn around a working plugin in very short order.

If you have any questions, or don't understand something, the best thing to do is ask.  RegRipper is a powerful and very useful tool...I'm not saying this because I wrote it; I'm saying it because I wrote it and use it on every engagement.  I use RegRipper to look at specific keys and values to provide insight into the system under analysis, as well as provide some context about the engagement overall.  I also use it locate malware that wasn't detected by AV.  I've use RegRipper to catalogue new intrusion artifacts, as well as demonstrate that a user account was used to view (or in one instance, not view) specific files.

If you're using RegRipper, a new distribution of plugins (not so much new plugins as more...) was included along with Windows Registry Forensics, as well as online.  I've updated a couple of the plugins, added a few more, and Brett's provided others via RegRipper.net.

Links and Notes

Forensic Meet-up
There are plans afoot for a forensics meet-up in the Northern VA area (Chantilly - Centreville - Herndon - Reston) on 31 Mar 2011.  The meet-up will likely start around 6:30pm - 7pm, and the location is TBD for the moment...keep an eye here, or on the Win4n6 group.  This first meet-up will be free-form, and I'll work up something of an informal agenda. 

As more folks become aware of this meet-up, I guess my initial concern would be where to meet.  I'd like this to be informal, and everyone to relax and have a beer.  If the interest is for something a bit more formal, then we may move to a different agenda later.  Eventually, my hope is that this becomes something useful to folks, as we can discuss and implement innovation in the DF and IR fields...

F-Response Patent
On Fri, 11 Mar 2011, Matt announced that F-Response had received a patent for remote forensic innovation!  Congrats, Matt...this is very well deserved!

Of specific note is that F-Response provides, "...forensic grade write-protection..." for remote forensics and raw access to systems.

This is fantastic news for Matt, and for the community as a whole!  Matt's contributions to the field have been phenomenal, to say the least. 

RegRipper Plugins
I recently wrote up some new plugins (and updated the samparse.pl plugin)...

notify.pl - Parses the Notify subkeys within the Software hive for registered Winlogon Notification DLLs, based on Mark's Case of the SysInternals-Blocking Malware post

init_dlls.pl - Checks for keys similar to the one mentioned in Mark's Case of the Malicious AutoStart post

renocide.pl - Checks for an artifact key mentioned on the MMPC site for the Win32/Renocide malware

These plugins are meant to demonstrate a couple of things...first, that Registry analysis can be used in conjunction with other analysis methods to detect malware within acquired images, where AV scanners might fail.  I've run AV scans before where two commercial and three free AV scanners didn't find anything, but the fourth free scanner found something.  I've also seen where AV used by customers has failed due not to having the incorrect DAT file, but to having the incorrect scanning engine.  We're all susceptible to this, and if you use AV as part of your malware detection process for when you examine acquired images, then this is something that you'll need to be aware of, as well.

Second, all three of these plugins took me less than 30 minutes...total...to write and test.  In fact, the only real slow-down was deciding how to make the output a bit more useful...for the notify.pl plugin, I copied code from the userassist.pl plugin to list all of registered DLLs sorted based on their key LastWrite times.  This means that if I want to deploy any of these plugins as part of my timeline creation toolkit, it's simply a matter of minutes for me to modify them.  So in less than 30 minutes, I was able to add three new plugins to the library, and saved everyone who uses those plugins the time for researching and writing those plugins themselves.  This serves not only as a force multiplier, but also as a library for institutional knowledge within the community as a whole.

You can get copies of these plugins from Brett's RegRipper.net site.

As a side note, running RegRipper is just part of the malware detection process that I use regularly, and what I'm writing about and detailing for my next book.  Part of the supporting materials for this book will include a checklist, as well.

More Malware Detection

Given my last post which mentioned part of my malware detection process, I thought it would be a good idea to mention a couple of bits of malware that I've seen described online recently.

First, from Mark's blog comes The Case of the SysInternals-Blocking Malware; as the title would lead you to believe, the responder working on this one had some issues troubleshooting the malware, as it kept blocking his use of SysInternals tools.  The malware was eventually identified as Swimnag, which apparently uses the Notify key as it's persistence mechanism.

All told last night, it took me less than 10 minutes to write, test, and modify a RegRipper plugin to display the name, LastWrite time, and DLLName values of the Notify subkeys.  I could put a few more minutes into manipulating the output a bit.  Speaking of which, has anyone taken a shot at writing a plugin for the type of malware described in The Case of the Malicious AutoStart?

Addendum: Took me about 10-15 min, but I wrote up init_dlls.pl to locate value names (for the Malicious AutoStart issue) that end in Init_DLLs.

Another bit of joy mentioned on the MMPC this morning is Win32/Renocide.  The write-up for this one is an interesting bit of reading, in that it spreads not just via local, removable and network drives (on a network, it can spread via NetBIOS), but it also looks for specific file sharing applications, and uses those to spread, as well.  The persistence mechanisms are nothing new, but what I did notice is that one of the artifacts of an infection is a change to the firewall settings...this is one of those things that I encapsulate in "Registry analysis" when attempting to detect the presence of malware in an acquired image.  Interestingly enough, this malware also maintains its configuration in a Registry key (Software\Microsoft\DRM\amty); if you locate this key in the Registry, the LastWrite time should give you an approximate time that the system was infected.

MBR Infector Detector

Now and again, I get those analysis gigs where someone suspects that a system may have been infected with some sort of malware, but they aren't sure, and don't really have anything specific (Event Log entry, AV alert, etc.) to point to.  I know that others get these sorts of gigs as well, and like them, I have a process that I go through when examining images of these systems.  This usually starts with checking for installed AV products (MRT, etc.) to review their logs, as well as checking for AV having been run before the system was taken offline...if logs are available, they can tell you a lot, particularly the product and version run.  From there, I also mount the image and scan it with other AV tools.

One of the steps on my list is to also look for MBR infectors.  What's an "MBR infector", you ask?  Read on...
F-Secure "Hippie" Description (1996)
SecurityVibes - Mebroot (2008)
F-Secure - Mebroot (3 Mar 2008)
Symantec - Mebroot (30 July 2010)
Sunbelt - TDSS/TDL4 (15 Nov 2010)
F-Secure, 17 Feb 2011
MMPC - Sinowal, aka Mbroot, Mebroot (8 Feb 2011)
MMPC - Win32/Fibebol.A (7 Mar 2011)

If you read through the above links, particularly those that are AV vendor descriptions of MBR infectors, you'll notice some commonalities...in particular, when the MBR is infected, other sectors prior to the first partition (usually, sector 63) contain something...a copy of the MBR, code to be injected into the system, something.  Now, this doesn't mean that this is the case for ALL MBR infectors, just those that have been mentioned publicly.

Usually, what I would do is load the image into FTK Imager, and scan through the sectors manually...but why to do that, when you make the computer do it?  That's right...I wrote a (wait for it!) Perl script (mbr.pl) to do this for me!

So, what the script does is scan through a range of sectors from an image file; by default, it will scan through sectors 0 through 63 inclusive, but the analyst can set different sectors to be scanned.  When a sector that does NOT contain all zeros is found, the script will flag it.  By "flag it", in summary mode, the script will just list the sector number.  In a more detailed mode (which is the default), the script will print out the contents of the sector to STDOUT, in a hex viewer-like format.  This way, it's real easy for the analyst to see, "hey, this sector just contains some strings associated with Dell installs", or "Hey, this sector is the start of a PE file!"  Because the output goes to STDOUT, you can pipe it through "more" or redirect the output to a file.

Also, using another switch, the analyst can dump the raw sectors to disk.  This allows you to generate MD5 or ssdeep hashes, run ssdeep hash comparisons, submit the raw dump to VirusTotal, etc.

Overall, it's pretty cool.  I usually run mmls against the image anyway, and many times I'll see that the first partition starts at sector 63.  Other times, I've found the starting sector for the first partition by searching the image via FTK Imager for "NTFS".  Regardless, with the output of mmls, I can then run mbr.pl as part of my malware detection process, and just like other parts of the process, if nothing unusual is found, that's okay.  If something is found, it's usually correlated against the output of other steps in the process.  The overall goal is to as thorough a job as possible.

Cybercrime and Espionage

I recently finished reading through Cybercrime and Espionage: An Analysis of Subversive Multi-Vector Threats, by John Pirc and Will Gragido, and wanted to share my thoughts on the book.

First, a couple of points of clarification.  For one, I'm reading the ebook on a Kindle.  I don't have the book-book version, so I can't compare the formatting...but I do have a copy of Windows Registry Forensics on the Kindle, so I can make something of a comparison there.  Also, I wasn't sent a copy of the book to review...I'm writing this review entirely on my own accord, and because I think that are some very interesting statements in and thoughts generated by this book.  Having a new book out myself right now, I think that this is something of a distinction.

The authors do a very good job of laying the groundwork early in the book, in particular pointing out that there is a lot about cybercrime that isn't new, but has instead been around for centuries.  Wanting what others have, and securing it for one's own profit are age-old desires/motivators, and bits and bytes are simply the new medium.

I am somewhat familiar with most of the compliance standards that the authors discuss, such as the PCI Data Security Standard (I spent three years as a QSA-certified PCI examiner, part of a QIRA team), HIPAA, and others (the credit union NCUA wasn't mentioned by the authors, but would have fit within the chapter nicely).

The authors also spend considerable time in the cyber-realm, particularly in developing and describing their Subversive Multi-Vector Threat (SMT) taxonomy, in which they include the APT and even Spc. Manning.  The authors build up to their taxonomy and provide examples, and then take the time to go beyond that and provide descriptions of intelligence gathering processes, as well as means that can be used to attempt to protect organizations.

Throughout the book, the authors provide considerable background and definitions; I think that this is helpful, as it provides both the uninitiated reader, as well as the more experienced (in the subject matter being addressed) with a common, level playing field.  Through this development of background and supporting definitions, the reader should easily see where things such as insider threats come from, for example.  In chapter 6, the authors spend considerable time explaining different avenues for gathering information and developing intelligence.  At one point, the issue of "trust" is brought up; wouldn't it be easy for an operative (in search of, say, corporate intelligence) to single out a disgruntled employee and earn their "trust"?

This is not a technical book, but it's definitely something that will get you to think about what's really going on in the world around you.  This should apply to the CIO, CISO, IT Director, even to the IT admin who's wondering if they've been "hacked".  Books that provide solutions are good, but so are books that challenge your thinking and (as the authors describe in the MOSAIC process) base assumptions about your surroundings.

Thoughts
What I really liked about the book, in addition to what the authors presented, was the thoughts that reading that material generated.  The following are thoughts that I had based on my reading, and viewing that material through the lens of my own experience, and are not things that you'll necessarily find stated specifically in the book.

What is deemed "adequate and reasonable" security is often decided by those with budgeting concerns/constraints, but with little understanding of the risk or the threat.

Compliance comes down to the auditor versus the attacker, with the target infrastructure as the stage.  The attacker is not constrained a specific compliance "standard"; in fact, the attacker may actually use that "standard" and compliance to it against the infrastructure itself.

Auditors are often not technical, and they do not see across the various domains of the "standard" to which they are auditing, and are not able to bring other factors into consideration (i.e., corporate culture, economics, business models, etc.).  Auditing is a point-in-time assessment and usually based on a checklist of some kind; do you have a firewall, yes/no; do you have IDS/IPS, yes/no.  While requiring an organization to meet a compliance standard will likely raise their level of "security", it's often a small step that's coming too late.  "Compliance" is more of a band-aid, and an attempt to modify the corporate culture to take the threats seriously.

Good IR Work

Mark Russinovich recently posted The Case of the Malicious Autostart to his blog.  I have to say, I think we are all very fortunate that Mark decided to post this; besides providing a very good demonstration of the use of the tools that Mark has written and made available, but it also demonstrates what others within the community are seeing.  Chris Pogue recently did something similar with his Webcheck.dll post to the Spiderlabs Anterior blog, and it's good to see these kinds of things posted publicly.

Mark's post provides some really good information about what was found during a support call, and the tools and techniques used to find it, as well as to dig deeper.  One thing that's interesting to point out is that the infection of the system may have included subversion of Windows File Protection (not that that's not trivial...), as it's mentioned that  the user32.dll files in the system32 and dllcache directories were modified.

Posts like this give the rest of us an opportunity to see what others are facing and how they're addressing those challenges.  Being the tech support in my household, I'm somewhat familiar with these tools and their use, but I can't say that I've seen something like this.  What I like to do is see how this methodology fits into my own processes.

In the comments to the post, a user ("Mihailik") asks about determining the infection vector, to which Mark responds:

Unfortunately, that's a question just about anyone fighting a new malware infection will have a near impossible time of determining. Unless you actually see the infection as it takes place, you can't know - it could have been someone executing a malicious email attachment, opening an infected document, or via a network-spreading worm. 

I would suggest that by using timeline analysis, many of us have been able to determine infection vectors.  I know that folks using timelines have nailed down the original infection vector in some cases to phishing emails, attachments, browser drive-bys, etc. The timeline may give an indication of where you should look, and examination of the actual files (PDF or Word document, Java .jar file, etc.) will illuminate the issue further.  Determining the infection vector may not have been something that could be easily done on this system, during this support engagement, but for more IR-specific engagements, this is often a question that analysts are asked to address.