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.
Monday, April 04, 2011
Thursday, March 31, 2011
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:
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.
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.
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.
Sunday, March 27, 2011
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.
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.
Monday, March 21, 2011
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.
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.
Sunday, March 20, 2011
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.
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.
Friday, March 11, 2011
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.
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.
Wednesday, March 09, 2011
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.
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.
Monday, March 07, 2011
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.
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.
Thursday, March 03, 2011
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.
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.
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.
Thursday, February 24, 2011
Webcheck.dll
I saw via Twitter today that a new post had gone up on the TrustWave SpiderLabs Anterior blog, regarding some malware that the TW folks (by that, I mean Chris Pogue) had detected during some engagements.
I think it's great when analysts and organizations share this kind of information, so that the rest of us can see what others are seeing. So, a big thanks goes out to TrustWave, and the next time you see Chris at a conference, be sure to say hi and buy him a beer...or better yet, treat him some bread pudding!
What I'd like to do is take a moment to go through the post and discuss some things that might add something of a different perspective or view to the issue, or perhaps something .
As you can see from the post, Chris uses timeline analysis to locate the malware in question, and he's got some really good information in the post about creating the timeline for analysis (Chris uses the log2timeline tools). I'm sure that there's quite a bit about the engagement and the analysis that weren't mentioned in the post, as Chris jumps right to the target date within his timeline and locates the malware.
I like the fact that Chris uses multiple analysis techniques to corroborate and check his findings. For example, in the post, Chris mentions looking at the file's $STANDARD_INFORMATION and $FILE_NAME attributes in the MFT, and confirming that there were no indications of "time stomping" going on. This is a great example that demonstrates that anti-forensics techniques target the analyst and their training, and that a knowledgeable analyst isn't slowed down by these techniques. I think that the post also demonstrates how timelines can be used to add context to what you're looking at, as well as increase the level of confidence that the analyst has in that data.
One of the things that kind of struck me as odd in the post is that there's mention of the "regedit/1" entry in the RunMRU key, and then the post jumps right to discussing the InProcServer32 key, based on the timeline. The RunMRU information (ie, key LastWrite time) is from a user's hive, so another key of interest to check might be the following:
As you'd think, this key contains information about the key that had focus when the user closed RegEdit. Specifically, the LastKey value (mentioned in MS KB 244004) contains the name of that key. This value might be used to make a bit of a transition between the RunMRU data and the changes to the InProcServer32 key that's mentioned in the post, and possible provide insight into how the malware was actually deployed on the system.
As Chris points out in the post, the value type being changed from "REG_SZ" (string value) to "REG_EXPAND_SZ" does allow for the use of unexpanded references to environment variables, such as %SystemRoot%. One statement that I don't really follow is:
So now the threading for webcheck.dll is no longer pointing to the legitimate file, but to the malware!
The threading model listed doesn't have anything to do with the path...I'm going to have to reach to Chris and find out what he was referring to in that statement. He follows that up with this statement later in the post:
So not only did the attackers use a legitimate threading, but they made sure to use a shell extension that was trusted by Windows.
Again, I'm not clear on the "threading" part of that statement, but Chris is quite correct about the shell extension issue. Basically, the Windows shell (Explorer.exe), which is launched when a user logs into the system, will load the approved shell extensions, which includes this particular malware. Trust seems to be implicit, as there are no checks run when Explorer goes to load a shell extension DLL. This is a bit different from the shell extension issue I'd mentioned last August, in part because it doesn't use the DLL Search Order issue. Instead, it simply points Explorer directly to the malware through the use of an explicit path.
All in all, I'm glad to see that Chris and the TrustWave folks sharing this kind of thing with the community. I do think that there's more that isn't being said, like how the malware actually got on the system (ie, how it was deployed), but hey, we all know that there are some things that can't be said about engagements. And that's okay.
I think it's great when analysts and organizations share this kind of information, so that the rest of us can see what others are seeing. So, a big thanks goes out to TrustWave, and the next time you see Chris at a conference, be sure to say hi and buy him a beer...or better yet, treat him some bread pudding!
What I'd like to do is take a moment to go through the post and discuss some things that might add something of a different perspective or view to the issue, or perhaps something .As you can see from the post, Chris uses timeline analysis to locate the malware in question, and he's got some really good information in the post about creating the timeline for analysis (Chris uses the log2timeline tools). I'm sure that there's quite a bit about the engagement and the analysis that weren't mentioned in the post, as Chris jumps right to the target date within his timeline and locates the malware.
I like the fact that Chris uses multiple analysis techniques to corroborate and check his findings. For example, in the post, Chris mentions looking at the file's $STANDARD_INFORMATION and $FILE_NAME attributes in the MFT, and confirming that there were no indications of "time stomping" going on. This is a great example that demonstrates that anti-forensics techniques target the analyst and their training, and that a knowledgeable analyst isn't slowed down by these techniques. I think that the post also demonstrates how timelines can be used to add context to what you're looking at, as well as increase the level of confidence that the analyst has in that data.
One of the things that kind of struck me as odd in the post is that there's mention of the "regedit/1" entry in the RunMRU key, and then the post jumps right to discussing the InProcServer32 key, based on the timeline. The RunMRU information (ie, key LastWrite time) is from a user's hive, so another key of interest to check might be the following:
Software\Microsoft\Windows\CurrentVersion\Applets\Regedit
As you'd think, this key contains information about the key that had focus when the user closed RegEdit. Specifically, the LastKey value (mentioned in MS KB 244004) contains the name of that key. This value might be used to make a bit of a transition between the RunMRU data and the changes to the InProcServer32 key that's mentioned in the post, and possible provide insight into how the malware was actually deployed on the system.
As Chris points out in the post, the value type being changed from "REG_SZ" (string value) to "REG_EXPAND_SZ" does allow for the use of unexpanded references to environment variables, such as %SystemRoot%. One statement that I don't really follow is:
So now the threading for webcheck.dll is no longer pointing to the legitimate file, but to the malware!
The threading model listed doesn't have anything to do with the path...I'm going to have to reach to Chris and find out what he was referring to in that statement. He follows that up with this statement later in the post:
So not only did the attackers use a legitimate threading, but they made sure to use a shell extension that was trusted by Windows.
Again, I'm not clear on the "threading" part of that statement, but Chris is quite correct about the shell extension issue. Basically, the Windows shell (Explorer.exe), which is launched when a user logs into the system, will load the approved shell extensions, which includes this particular malware. Trust seems to be implicit, as there are no checks run when Explorer goes to load a shell extension DLL. This is a bit different from the shell extension issue I'd mentioned last August, in part because it doesn't use the DLL Search Order issue. Instead, it simply points Explorer directly to the malware through the use of an explicit path.
All in all, I'm glad to see that Chris and the TrustWave folks sharing this kind of thing with the community. I do think that there's more that isn't being said, like how the malware actually got on the system (ie, how it was deployed), but hey, we all know that there are some things that can't be said about engagements. And that's okay.
Tuesday, February 22, 2011
Links
WFA Translations Thanks to the great folks at Elsevier and BJ Public, Windows Forensic Analysis 2/e is now available in Korean! Very cool! A copy of this goes on my shelf right next to the French translation, as well as the Chinese translation of WFA 1/e. I have to say, this is very, very cool...to look up at my bookshelf and see that someone thought enough of something I wrote to translate it. I have no idea what it says, but it's cool, just the same!
Security Ripcord
After a lengthy absence, Don is finally back blogging again...and he returns with a bang! Don's latest post, It will never be too expensive, takes a shot at the statement made by security "professionals" and "experts" to their customers for years...that one should employ/deploy enough "security" to make it too expensive for an attacker to get in, and they'll go away. It's pretty clear from Don's comments and reasoning that this is clearly a statement that has been made over and over for years, without folks really thinking about what's being said, and how the threat itself has evolved. This statement may have been true in the early days of the Internet, but the Internet and cybercrime have changed and developed...but apparently, the thinking behind the statement hasn't. Don does a great job of pointing this out, and with all the talk about advanced persistent and subversive multi-vector threats, doesn't it stand to reason that for some folks, for the really dedicated folks, they're just gonna laugh at your expensive security as they blow right on through it? Much like he did when he was in the Corps, Don takes a shot at this statement and hits it squarely, center of mass.
Sniper Forensics
Speaking of snipers, Part 3 of Chris's Sniper Forensics series has been posted to the SpiderLabs Anterior blog, be sure to check it out. I think that one of the biggest things that Chris points out in this segment is defining the target...with respect to IR, why are you there? What are you there to do? When it comes to digital forensic analysis, the same thing applies; if someone where to ship me a drive (or image), with clearly defined goals of what they were looking for, I might usually estimate an analysis time of 24 hrs or less. However, if you were to ship me a drive and say, "...find all bad stuff...", I could spend several weeks looking and never find why you define as "bad"...in part, because you never defined it. I've seen analysts leave site with a drive, having been told to find "bad stuff"; some initial searching found clear indications of the existence and use of "hacker" tools. However, upon reporting that to the customer, the analyst was told that the former employee's job was to hack stuff, so the existence of hacking tools wasn't "bad". Hey, who knew.
Defining the goals of an engagement, and the parameters for success, are critical to that engagement. Having a contract that just says "do analysis" without any defined goals of that analysis leave the analyst or the team with...what? Once the hours in the contract have been consumed, a report is delivered to the customer who then says, "no, this isn't what we wanted."
This isn't just an important point for consultants, it's equally important (or perhaps even more so) for the customer. If you're seeking IR or DF services, ensure that you clearly define what you're looking for, and ensure that this is stated clearly in the contract before you sign it.
MFT Slack
Lance posted an Enscript recently that was written to extract the slack space from MFT records. This isn't something that I've had a need to do before, but it is interesting and worth taking a look at. I'm not entirely sure what context you can get from items found in MFT slack, as MFT records are 1024 bytes long; however, Lance thought enough of this to write an Enscript for it, so there must be something there!
On that note, I recently updated the online repository for the Windows Registry Forensics tools, to include Jolanta's regslack tool for locating deleted keys and values in hive files. For usage and examples of how this tool has been used, check out the book.
Thursday, February 17, 2011
Links
WRF Book Reviews
Thanks to everyone who's purchased a copy of Windows Registry Forensics, and in particular to those who've taken the opportunity to post their thoughts, or more formally write a review. Paul Sanderson (@sandersonforens on Twitter), from across the pond, posted a review of the book to his blog recently. Paul has the Kindle version of the book, as that's all that's available over there at the moment.
Speaking of the book, it seems to be doing well, if the Amazon ranking is any indicator. There are a couple pretty helpful things to point out about this book that might be helpful in understanding why it might be useful for you.
First, this is the first book of it's kind. Ever.
Seriously...there are no books out there that come at the topic from the perspective of a forensic analyst. There are a number of books that include discussion of some Registry keys that are of use to an analyst, but none that discusses the Registry at the depth and breadth of WRF. My primary motivation for writing the book was to fill that gap, because I really feel that the Registry is a critical and too-often-overlooked source of forensic artifacts on a system.
Second, the book makes use of primarily free and open-source tools. This can be very important to smaller organizations, such as LE, professors and students at local community colleges, and even just to those learning or looking to develop new skills, as it puts the described capability within reach. I know that not everyone can (or wants to) learn Perl, but the tools are there...and to make it even easier, many of the tools I've written have been provided as standalone EXEs (compiled with Perl2Exe).
SPoE
I was bopping around the TwitterVerse recently and ran across a link to Mike Murr's blog, and from there found a two year old post on the Single Piece of Evidence (SPoE) myth. Mike's always been good for some well-thought-out opinions and comments, and this one is no different. What he mentions with regards to anti-forensics techniques is similar to the reactions surrounding the release of XP and then Windows 7..."OMG! What is this going to do to my investigations!" The fact is that, while each brings it's own nuances and inherent anti-forensics, each also brings with it a whole bunch of new artifacts. As Mike points out, when a user interacts with a Windows system, there are a lot of artifacts...and the same is true, albeit to a somewhat lesser degree, for malware, as well.
Hacking
If you've been watching the news lately, you're probably aware that no one seems to be immune to being compromised. Even small boroughs in PA are susceptible. While the linked article doesn't have a great deal of supporting information (no mention of the use of online banking, did the bank see a legit login from a different IP address, what the independent consultant determined, etc.). In the past, a lot of these types of issues have been attributed to the Zeus bot, and in some cases, there haven't been any indications of Zeus on what were thought to be the affected systems.
Mayor Mowen was just being a mayor when he said, "You guard against it by increasing your firewall, which is what we are in the process of doing."
Analysis
F-Secure recently posted this analysis of an MBR infector. The analysis includes a good number of hex views and listings of code in assembly language and lots of detail. It would be a good idea to read through this carefully and take note of what's said. For example, this baddy infects the MBR, and appears to make a copy (like Mebroot, here, and here) of the original MBR, placing it in sector 5.
The analysis includes the following:
Why an MBR File System Infector? Probably because it can bypass Windows File Protection (WFP). As WFP is running in protected mode, any WFP-protected file will be restored immediately if the file is replaced.
I'm not entirely sure that this is a good line of reasoning in and of itself, in part because the bad guys have done a good job at shutting WFP off for a minute, and installing their malware. WFP is not a polling service, so when it wakes back up, it has no way of knowing that a protected file was modified or replaced. However, it appears from the write-up that the malware infects userinit.exe at startup, possibly prior to WFP starting up, which may be the entire reason for infecting the MBR first.
I'm curious as to which version of Windows this malware was executed on, as the version of userinit.exe on my XP system, as well as a Windows XP VM I have, is 26Kb in size, slightly larger than what's shown in the write-up. However, the write-up does provide a couple of good tips that an analyst can use to detect the presence of this malware.
If you're a responder or forensic analyst, and this one is tough for you to read and follow, keep something in mind that Cory posted to Twitter today (17 Feb), which included (in part), "...you shouldn't rely on malware fetishists for incident response advice." Excellent point.
FakeAV
Another interesting analysis popped up...thanks to Ken for posting his analysis of a FakeAV bit of malware. In his write-up, Ken does a pretty thorough job of documenting what he did, how he did it, and what he found. For example, one of the Registry key that were modified is:
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations
According to Ken, the "LowRiskFileTypes" value was added with the data ".exe". This is interesting, but how does it apply to the malware infection. MS KB article 883260 provides some hints to this. This same KB article provides a hint about why the following key might also be updated:
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments
In Ken's write-up, this key had the "SaveZoneInformation" value added, with "1" as the data. Remember how back with Windows XP SP2, files downloaded via Outlook or IE had a "zoneid" Alternate Data Stream (ADS) attached to the file (this is described on pg. 314 of WFA 2/e)? When analyzing a system with ADS on it, it's usually pretty easy to see them at a glance, as some of the commercial forensic analysis applications list them in red. However, this setting appears to tell the system to not create the ADS.
Finally, Ken mentions that there was a change to the following key:
HKCU\Software\Microsoft\Internet Explorer\Download
In this case, the CheckExeSignatures value was changed from 'yes' to 'no'. TechNet has some information about the value (maybe...the path is a little different,using "Main" in the key path, rather than "Download") and what effect it may have on the system. Other malware seems to modify the same set of keys, as seen here, and with this FakeAV write-up from Sophos.
There are a couple of interesting take-aways from this write-up, I think. First of all, it's great that Ken took the time not only to run this analysis, but to share it with others. I think one of the biggest mistakes analysts make when it comes to sharing and collaboration is assuming that everyone else has already seen everything. I tried to shoot this one down at the WACCI conference last year, where I actually met Ken. I don't see many FakeAV issues at all, to be honest.
Another take-away is that publicly available information provided by the vendor is utilized to take some steps towards not only allowing the malware to run, but also towards anti-forensics. Think about it...by telling the system to not create the ADS for downloaded files, that removes one of the indicators that analysts could use to identify the malware's propagation mechanism.
Finally, this clearly demonstrates that there are steps analysts can use to detect malware on a system beyond running an AV scanner. For example, there are number of Registry keys that Ken identified, as well as what's listed in other write-ups, that could be used to detect the potential presence of malware, even if the malware itself is not detected by AV. The rather odd value in the user's Run key is something of a give-away, but RegRipper already has a plugin that dumps the contents of that key. Now we have other keys that can be used with RegRipper or a forensic scanner to comb through the appropriate hives and check for the possible existence of malware.
IR
Last, but certainly not least, Chris posted today regarding IR activities; in particular, using a batch file to dump Registry hives from a live system for analysis. Chris actually posted the batch file he used...take a look. This one shows that Chris's command line kung fu is very good!
Thanks to everyone who's purchased a copy of Windows Registry Forensics, and in particular to those who've taken the opportunity to post their thoughts, or more formally write a review. Paul Sanderson (@sandersonforens on Twitter), from across the pond, posted a review of the book to his blog recently. Paul has the Kindle version of the book, as that's all that's available over there at the moment.
First, this is the first book of it's kind. Ever.
Seriously...there are no books out there that come at the topic from the perspective of a forensic analyst. There are a number of books that include discussion of some Registry keys that are of use to an analyst, but none that discusses the Registry at the depth and breadth of WRF. My primary motivation for writing the book was to fill that gap, because I really feel that the Registry is a critical and too-often-overlooked source of forensic artifacts on a system.
Second, the book makes use of primarily free and open-source tools. This can be very important to smaller organizations, such as LE, professors and students at local community colleges, and even just to those learning or looking to develop new skills, as it puts the described capability within reach. I know that not everyone can (or wants to) learn Perl, but the tools are there...and to make it even easier, many of the tools I've written have been provided as standalone EXEs (compiled with Perl2Exe).
SPoE
I was bopping around the TwitterVerse recently and ran across a link to Mike Murr's blog, and from there found a two year old post on the Single Piece of Evidence (SPoE) myth. Mike's always been good for some well-thought-out opinions and comments, and this one is no different. What he mentions with regards to anti-forensics techniques is similar to the reactions surrounding the release of XP and then Windows 7..."OMG! What is this going to do to my investigations!" The fact is that, while each brings it's own nuances and inherent anti-forensics, each also brings with it a whole bunch of new artifacts. As Mike points out, when a user interacts with a Windows system, there are a lot of artifacts...and the same is true, albeit to a somewhat lesser degree, for malware, as well.
Hacking
If you've been watching the news lately, you're probably aware that no one seems to be immune to being compromised. Even small boroughs in PA are susceptible. While the linked article doesn't have a great deal of supporting information (no mention of the use of online banking, did the bank see a legit login from a different IP address, what the independent consultant determined, etc.). In the past, a lot of these types of issues have been attributed to the Zeus bot, and in some cases, there haven't been any indications of Zeus on what were thought to be the affected systems.
Mayor Mowen was just being a mayor when he said, "You guard against it by increasing your firewall, which is what we are in the process of doing."
Analysis
F-Secure recently posted this analysis of an MBR infector. The analysis includes a good number of hex views and listings of code in assembly language and lots of detail. It would be a good idea to read through this carefully and take note of what's said. For example, this baddy infects the MBR, and appears to make a copy (like Mebroot, here, and here) of the original MBR, placing it in sector 5.
The analysis includes the following:
Why an MBR File System Infector? Probably because it can bypass Windows File Protection (WFP). As WFP is running in protected mode, any WFP-protected file will be restored immediately if the file is replaced.
I'm not entirely sure that this is a good line of reasoning in and of itself, in part because the bad guys have done a good job at shutting WFP off for a minute, and installing their malware. WFP is not a polling service, so when it wakes back up, it has no way of knowing that a protected file was modified or replaced. However, it appears from the write-up that the malware infects userinit.exe at startup, possibly prior to WFP starting up, which may be the entire reason for infecting the MBR first.
I'm curious as to which version of Windows this malware was executed on, as the version of userinit.exe on my XP system, as well as a Windows XP VM I have, is 26Kb in size, slightly larger than what's shown in the write-up. However, the write-up does provide a couple of good tips that an analyst can use to detect the presence of this malware.
If you're a responder or forensic analyst, and this one is tough for you to read and follow, keep something in mind that Cory posted to Twitter today (17 Feb), which included (in part), "...you shouldn't rely on malware fetishists for incident response advice." Excellent point.
FakeAV
Another interesting analysis popped up...thanks to Ken for posting his analysis of a FakeAV bit of malware. In his write-up, Ken does a pretty thorough job of documenting what he did, how he did it, and what he found. For example, one of the Registry key that were modified is:
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations
According to Ken, the "LowRiskFileTypes" value was added with the data ".exe". This is interesting, but how does it apply to the malware infection. MS KB article 883260 provides some hints to this. This same KB article provides a hint about why the following key might also be updated:
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments
In Ken's write-up, this key had the "SaveZoneInformation" value added, with "1" as the data. Remember how back with Windows XP SP2, files downloaded via Outlook or IE had a "zoneid" Alternate Data Stream (ADS) attached to the file (this is described on pg. 314 of WFA 2/e)? When analyzing a system with ADS on it, it's usually pretty easy to see them at a glance, as some of the commercial forensic analysis applications list them in red. However, this setting appears to tell the system to not create the ADS.
Finally, Ken mentions that there was a change to the following key:
HKCU\Software\Microsoft\Internet Explorer\Download
In this case, the CheckExeSignatures value was changed from 'yes' to 'no'. TechNet has some information about the value (maybe...the path is a little different,using "Main" in the key path, rather than "Download") and what effect it may have on the system. Other malware seems to modify the same set of keys, as seen here, and with this FakeAV write-up from Sophos.
There are a couple of interesting take-aways from this write-up, I think. First of all, it's great that Ken took the time not only to run this analysis, but to share it with others. I think one of the biggest mistakes analysts make when it comes to sharing and collaboration is assuming that everyone else has already seen everything. I tried to shoot this one down at the WACCI conference last year, where I actually met Ken. I don't see many FakeAV issues at all, to be honest.
Another take-away is that publicly available information provided by the vendor is utilized to take some steps towards not only allowing the malware to run, but also towards anti-forensics. Think about it...by telling the system to not create the ADS for downloaded files, that removes one of the indicators that analysts could use to identify the malware's propagation mechanism.
Finally, this clearly demonstrates that there are steps analysts can use to detect malware on a system beyond running an AV scanner. For example, there are number of Registry keys that Ken identified, as well as what's listed in other write-ups, that could be used to detect the potential presence of malware, even if the malware itself is not detected by AV. The rather odd value in the user's Run key is something of a give-away, but RegRipper already has a plugin that dumps the contents of that key. Now we have other keys that can be used with RegRipper or a forensic scanner to comb through the appropriate hives and check for the possible existence of malware.
IR
Last, but certainly not least, Chris posted today regarding IR activities; in particular, using a batch file to dump Registry hives from a live system for analysis. Chris actually posted the batch file he used...take a look. This one shows that Chris's command line kung fu is very good!
Monday, February 14, 2011
Links, Tools and Stuff
PDF Stream Dumper
From over at RE Corner comes the PDF Stream Dumper tool; actually, this one has been out for some time now. This tool was written in VB6, and comes with a number of automation scripts. Swing on by Lenny's blog for some create examples of how to use it, or check out this KernelMode page for some other examples of the dumper being used.
If you're not too put off by CLI tools, you might consider using this in conjunction with Didier's PDF tools. Didier's stuff is also in use by VirusTotal. That's not to say that one's better to use than the other...it's good to have both available.
While we're on the subject of document metadata, it's a good idea to mention Kristinn Gudjonsson, creator of log2timeline, also created the read_open_xml.pl Perl script for extracting metadata from MS Word 2007 documents (use and output described at the SANS Forensic Blog).
TechRadar
There's an interesting article up on TechRadar about how to perform a forensic PC investigation, and it references using OSForensics, available from PassMark Software. I have to say, I'm a bit concerned about articles like this, even when they suggest early in the article that performing the actions described in the article can be "a little morally dubious".
The beta of OSForensics was recently made available for a limited time, for free. However, that offer was originally made as "LE only", but seems to have changed recently.
OSForensics
It looks like the folks at PassMark Software removed the LE-only restriction for downloading the OSForensics beta, so I downloaded the 32-bit version to my XP system this morning.
After installing OSForensics and looking around (noticed the nice icons and graphics), I created a new case, and then began looking for a way to load a test image into the tool. I didn't have much luck, so I went immediately to the Help, which is provided online, in HTML format. I went through the index and found the word "Image", and from there found this:
In many cases it may be desirable to work with data from a disk image rather than the physical disk itself. Whilst OSForensics does not deal with disk images directly itself Passmark provides a set of free external tools in order to support working with disk images.
So, it appears that OSForensics is not intended for dead-box/post-mortem analysis. Some of the available tools, such as System Information and Memory Viewer, pertain to the system on which OSForensics is running. PassMark does offer the OSMount program, which allows you to mount a raw/dd image as a drive letter, and from there you can use OSForensics in the intended fashion. As such, I'd guess that there'd be no issues using any of the various other mounting techniques and tools, including accessing VSCs.
Of all of the functionality, the one that really jumps out is the hash set comparison tools. PassMark provides a number of hash sets for known-good OS files at their download site; however, as with any similar functionality based on hash sets, I can easily see how this can become cumbersome very quickly. You either scan for all of the hashes, or you run into issues with analysts deciding which hash sets to run, and (more importantly) documenting those that they do run.
OSForensics also provides string and file name search functionality, logging of activity, and the ability to install OSForensics to a USB drive. I'm sure that this tool will be useful to examiners; for my own uses, however, it simply does not provide enough of the core functionality that I tend to use during my examinations. As a test, I mounted a test image as a read-only F:\ drive and opened OSForensics, and I have to say, moving through the interface wasn't the most intuitive, or easy to use. However, I may be somewhat biased, given my experience and usual work processes.
No Alternative
Eric's got a rather insightful post over at the AFoD blog. More and more folks are getting into the cell phone and smart phone market, and those little buggers are really very powerful when you take a look at them. They also tend to contain more and more storage space. Of course, we need to keep in mind that the tablet market is still there in that space between the smart phone and the laptop, as well.
I can see where Eric's going with the post, but I have to say from the private/corporate perspective, this isn't such a huge issue. I would expect that if it ever does become and issue, it'll be an emergency (for legal/compliance purposes) and one-off, not something that gets done on a regular basis, with the cost of applications and training being amortized across multiple customers. However, from a public perspective, I can definitely see how this is going to be more and more of an issue...after all, how "gangsta" can you really be lugging around a Dell Latitude laptop?
Reading/Education
There are some great new resources over at the e-Evidence site, including stuff about MacOSX artifacts, iPhone and smart devices, Windows artifacts, etc. This site is always a great place to go and find lots of new and interesting stuff.
Network and Wireless
A question popped up on a list this morning regarding wireless assessments and tools. The original question asked about an alternative to NetStumbler, that supported a specific NIC, and the first response was for ViStumbler. ViStumbler is open-source and was originally written to be supported by Vista, but apparently runs on Windows 7, as well.
If you're doing any network forensics, you might also consider NetworkMiner as a viable resource, and something to add to your toolkit right alongside Wireshark.
Tool Sites
ForensicCtrl had a listing of free computer forensics tools available.
List of Windows open source tools
Check out the Collaborative RCE Tools library for a wide range of tools.
From over at RE Corner comes the PDF Stream Dumper tool; actually, this one has been out for some time now. This tool was written in VB6, and comes with a number of automation scripts. Swing on by Lenny's blog for some create examples of how to use it, or check out this KernelMode page for some other examples of the dumper being used.
If you're not too put off by CLI tools, you might consider using this in conjunction with Didier's PDF tools. Didier's stuff is also in use by VirusTotal. That's not to say that one's better to use than the other...it's good to have both available.
While we're on the subject of document metadata, it's a good idea to mention Kristinn Gudjonsson, creator of log2timeline, also created the read_open_xml.pl Perl script for extracting metadata from MS Word 2007 documents (use and output described at the SANS Forensic Blog).
TechRadar
There's an interesting article up on TechRadar about how to perform a forensic PC investigation, and it references using OSForensics, available from PassMark Software. I have to say, I'm a bit concerned about articles like this, even when they suggest early in the article that performing the actions described in the article can be "a little morally dubious".
The beta of OSForensics was recently made available for a limited time, for free. However, that offer was originally made as "LE only", but seems to have changed recently.
OSForensics
It looks like the folks at PassMark Software removed the LE-only restriction for downloading the OSForensics beta, so I downloaded the 32-bit version to my XP system this morning.
After installing OSForensics and looking around (noticed the nice icons and graphics), I created a new case, and then began looking for a way to load a test image into the tool. I didn't have much luck, so I went immediately to the Help, which is provided online, in HTML format. I went through the index and found the word "Image", and from there found this:
In many cases it may be desirable to work with data from a disk image rather than the physical disk itself. Whilst OSForensics does not deal with disk images directly itself Passmark provides a set of free external tools in order to support working with disk images.
So, it appears that OSForensics is not intended for dead-box/post-mortem analysis. Some of the available tools, such as System Information and Memory Viewer, pertain to the system on which OSForensics is running. PassMark does offer the OSMount program, which allows you to mount a raw/dd image as a drive letter, and from there you can use OSForensics in the intended fashion. As such, I'd guess that there'd be no issues using any of the various other mounting techniques and tools, including accessing VSCs.
Of all of the functionality, the one that really jumps out is the hash set comparison tools. PassMark provides a number of hash sets for known-good OS files at their download site; however, as with any similar functionality based on hash sets, I can easily see how this can become cumbersome very quickly. You either scan for all of the hashes, or you run into issues with analysts deciding which hash sets to run, and (more importantly) documenting those that they do run.
OSForensics also provides string and file name search functionality, logging of activity, and the ability to install OSForensics to a USB drive. I'm sure that this tool will be useful to examiners; for my own uses, however, it simply does not provide enough of the core functionality that I tend to use during my examinations. As a test, I mounted a test image as a read-only F:\ drive and opened OSForensics, and I have to say, moving through the interface wasn't the most intuitive, or easy to use. However, I may be somewhat biased, given my experience and usual work processes.
No Alternative
Eric's got a rather insightful post over at the AFoD blog. More and more folks are getting into the cell phone and smart phone market, and those little buggers are really very powerful when you take a look at them. They also tend to contain more and more storage space. Of course, we need to keep in mind that the tablet market is still there in that space between the smart phone and the laptop, as well.
I can see where Eric's going with the post, but I have to say from the private/corporate perspective, this isn't such a huge issue. I would expect that if it ever does become and issue, it'll be an emergency (for legal/compliance purposes) and one-off, not something that gets done on a regular basis, with the cost of applications and training being amortized across multiple customers. However, from a public perspective, I can definitely see how this is going to be more and more of an issue...after all, how "gangsta" can you really be lugging around a Dell Latitude laptop?
Reading/Education
There are some great new resources over at the e-Evidence site, including stuff about MacOSX artifacts, iPhone and smart devices, Windows artifacts, etc. This site is always a great place to go and find lots of new and interesting stuff.
Network and Wireless
A question popped up on a list this morning regarding wireless assessments and tools. The original question asked about an alternative to NetStumbler, that supported a specific NIC, and the first response was for ViStumbler. ViStumbler is open-source and was originally written to be supported by Vista, but apparently runs on Windows 7, as well.
If you're doing any network forensics, you might also consider NetworkMiner as a viable resource, and something to add to your toolkit right alongside Wireshark.
Tool Sites
ForensicCtrl had a listing of free computer forensics tools available.
List of Windows open source tools
Check out the Collaborative RCE Tools library for a wide range of tools.
Tuesday, February 08, 2011
Carving
I was looking at a Windows 2003 system, and found that I was somewhat short on Event Log entries, with respect to the incident window. As I looked and used my evtrpt.pl Perl script to get statistics on the Sec, Sys, and App Event Logs, I noticed that Sec and Sys Event Logs only contained a few days of event records. The Application Event Logs actually went back a while past the incident window. I looked a bit closer to the output of evtrpt.pl and noticed that the Security Event Log had an event ID 517 record, indicating that the Event Log had been cleared.
So the first thing I did was run TSK blkls against the image to extract the unallocated space from the image file. I then ran MS's strings.exe (with the "-o" and "-n 4" switches), and then had two files to work with...the unallocated space, and a list of strings found in unallocated space, along with the offset of each string. So I then wrote a Perl script that would go through the strings output and find each line the contained "LfLe", the "magic number" for Windows 2000/XP/2003 event records.
With this list, the script would then run through the unallocated space by first going to the offset of the "LfLe" string, and backing up 4 bytes (DWORD). According to the well-documented event record structure, this DWORD should be the size of the record. As values can vary, and there is no one specific value that is correct, the way to check for a valid event record is to advance through unallocated space for the length provided by the DWORD, and the last DWORD in this blob should be the same as the size of the record. For example, if the initial size DWORD is 124 bytes, you should be able to advance through the file 120 bytes, and the next DWORD should also be 124.
Using this approach, I was able to extract over 330 deleted event records. I've used similar techniques in the past, to extract 100 bytes on either side of a keyword from the pagefile. This is an excellent way to gather additional information that you wouldn't normally be able to 'see' through most tools, as well as to look for and carve well-defined structures from unstructured data.
So the first thing I did was run TSK blkls against the image to extract the unallocated space from the image file. I then ran MS's strings.exe (with the "-o" and "-n 4" switches), and then had two files to work with...the unallocated space, and a list of strings found in unallocated space, along with the offset of each string. So I then wrote a Perl script that would go through the strings output and find each line the contained "LfLe", the "magic number" for Windows 2000/XP/2003 event records.
With this list, the script would then run through the unallocated space by first going to the offset of the "LfLe" string, and backing up 4 bytes (DWORD). According to the well-documented event record structure, this DWORD should be the size of the record. As values can vary, and there is no one specific value that is correct, the way to check for a valid event record is to advance through unallocated space for the length provided by the DWORD, and the last DWORD in this blob should be the same as the size of the record. For example, if the initial size DWORD is 124 bytes, you should be able to advance through the file 120 bytes, and the next DWORD should also be 124.
Using this approach, I was able to extract over 330 deleted event records. I've used similar techniques in the past, to extract 100 bytes on either side of a keyword from the pagefile. This is an excellent way to gather additional information that you wouldn't normally be able to 'see' through most tools, as well as to look for and carve well-defined structures from unstructured data.
Tools and Stuff
RegRipper
Brett Shavers, who maintains the RegRipper site, has compiled an archive of new plugins and posted them for download. Brett's done a fantastic service for the DF community, in not only setting up the site for RegRipper, but maintaining it, and posting this archive of plugins. A huge thanks to Brett...and if you see him at a conference, be sure to buy him a beer!
As a side note, along with the release of Windows Registry Forensics, I had posted the DVD contents here, as well. The archive contains what's on the DVD, so while you can get it, it's really most helpful when used in conjunction with the book.
El Jefe
Over at the HolisticInfoSec blog, Russ shared a little El Jefe love recently. Russ says that El Jefe is a Windows-based process monitoring tool that "intercepts native Windows API process creation calls, allowing you to track, monitor, and correlate process creation events. " Very cool. The tool is in version 1.1 and is available from the good folks at Immunity, and runs on Windows 2000/XP through Windows 7, reportedly in both 32- and 64-bit versions. This looks like a great tool not only for dynamic malware analysis, but perhaps also for incident preparation. I mean, wouldn't you like to know what ran on a system?
Anti-Rootkit
I haven't been doing a lot of live box forensics/IR work, but I ran across the Tuluka kernel inspector recently, and it caught my eye. If you've read my books, you know that I've used GMER in the past. I can't say that I've really had issues with rootkits, and many times I just get to do "dead box" forensics, but this looks like another tool that folks may find useful.
NetworkMiner
Erik sent out an email recently to say that NetworkMiner had gone to version 1.0. Congrats to Erik and all the folks who've worked on or used NetworkMiner! NM is an excellent compliment to other network data analysis tool such as Wireshark. Per Erik, some of the new features include:
Here are some new features in NetworkMiner since the previous version:
* Support for Per-Packet Information header (WTAP_ENCAP_PPI) as used by Kismet and sometimes Wireshark WiFi sniffing.
* Extraction of Facebook as well as Twitter messages into the message tab. Added support to extract emails sent with Microsoft Hotmail (I.e. Windows Live) into Messages tab.
* Extraction of twitter passwords from when settings are changed. Facebook user account names are also extracted (but not Facebook passwords).
* Extraction of gmailchat parameter from cookies in order to identify users through their Google account logins.
* Protocol parser for Syslog. Syslog messages are displayed on the Parameter tab.
Pretty cool stuff! Check it out, and be sure to check out the NM Wiki if you have any questions! Along with tools like Wireshark and NetWitness Investigator, NetworkMiner can be extremely useful for IR from a network perspective.
EvtxParser
Andreas has released v1.0.7 of his EvtxParser, a Perl-based approach for parsing Vista and Windows 7 Windows Event Log/EVTX files.
Highlighter
Mandiant has released a new version of Highlighter. Not much else to say, really...if you use this tool, take a look at the updates. I know several folks who find Highlighter to be very useful.
PointSec
More of a process than a tool, the folks over at Digital Forensic Solutions have posted to their blog about how to go about examining PointSec-encrypted drives. I can't say that I've had issues with encrypted drives...I've either had the admin boot the system and we'd image it live, or I acquired images of the drives with the customer knowing full well that the images would be encrypted (imaging job, no analysis). However, DFS's post provides some great information.
Java
Also not a tool, but really kind of cool...Corey's written up a nice post about some analysis he did that involved looking into the Java cache folder. Corey walks through identification of the issue, going so far as to demonstrate decompiling a Java .jar file. What I really like about Corey's posts is how complete they are, without giving away any case specific information. This isn't something that you see very often in the IR/DF community...but Corey clearly demonstrates how easy it is to do this and provide a valuable teaching moment. Great job, Corey...thanks!
Brett Shavers, who maintains the RegRipper site, has compiled an archive of new plugins and posted them for download. Brett's done a fantastic service for the DF community, in not only setting up the site for RegRipper, but maintaining it, and posting this archive of plugins. A huge thanks to Brett...and if you see him at a conference, be sure to buy him a beer!
As a side note, along with the release of Windows Registry Forensics, I had posted the DVD contents here, as well. The archive contains what's on the DVD, so while you can get it, it's really most helpful when used in conjunction with the book.
El Jefe
Over at the HolisticInfoSec blog, Russ shared a little El Jefe love recently. Russ says that El Jefe is a Windows-based process monitoring tool that "intercepts native Windows API process creation calls, allowing you to track, monitor, and correlate process creation events. " Very cool. The tool is in version 1.1 and is available from the good folks at Immunity, and runs on Windows 2000/XP through Windows 7, reportedly in both 32- and 64-bit versions. This looks like a great tool not only for dynamic malware analysis, but perhaps also for incident preparation. I mean, wouldn't you like to know what ran on a system?
Anti-Rootkit
I haven't been doing a lot of live box forensics/IR work, but I ran across the Tuluka kernel inspector recently, and it caught my eye. If you've read my books, you know that I've used GMER in the past. I can't say that I've really had issues with rootkits, and many times I just get to do "dead box" forensics, but this looks like another tool that folks may find useful.
NetworkMiner
Erik sent out an email recently to say that NetworkMiner had gone to version 1.0. Congrats to Erik and all the folks who've worked on or used NetworkMiner! NM is an excellent compliment to other network data analysis tool such as Wireshark. Per Erik, some of the new features include:
Here are some new features in NetworkMiner since the previous version:
* Support for Per-Packet Information header (WTAP_ENCAP_PPI) as used by Kismet and sometimes Wireshark WiFi sniffing.
* Extraction of Facebook as well as Twitter messages into the message tab. Added support to extract emails sent with Microsoft Hotmail (I.e. Windows Live) into Messages tab.
* Extraction of twitter passwords from when settings are changed. Facebook user account names are also extracted (but not Facebook passwords).
* Extraction of gmailchat parameter from cookies in order to identify users through their Google account logins.
* Protocol parser for Syslog. Syslog messages are displayed on the Parameter tab.
Pretty cool stuff! Check it out, and be sure to check out the NM Wiki if you have any questions! Along with tools like Wireshark and NetWitness Investigator, NetworkMiner can be extremely useful for IR from a network perspective.
EvtxParser
Andreas has released v1.0.7 of his EvtxParser, a Perl-based approach for parsing Vista and Windows 7 Windows Event Log/EVTX files.
Highlighter
Mandiant has released a new version of Highlighter. Not much else to say, really...if you use this tool, take a look at the updates. I know several folks who find Highlighter to be very useful.
PointSec
More of a process than a tool, the folks over at Digital Forensic Solutions have posted to their blog about how to go about examining PointSec-encrypted drives. I can't say that I've had issues with encrypted drives...I've either had the admin boot the system and we'd image it live, or I acquired images of the drives with the customer knowing full well that the images would be encrypted (imaging job, no analysis). However, DFS's post provides some great information.
Java
Also not a tool, but really kind of cool...Corey's written up a nice post about some analysis he did that involved looking into the Java cache folder. Corey walks through identification of the issue, going so far as to demonstrate decompiling a Java .jar file. What I really like about Corey's posts is how complete they are, without giving away any case specific information. This isn't something that you see very often in the IR/DF community...but Corey clearly demonstrates how easy it is to do this and provide a valuable teaching moment. Great job, Corey...thanks!
Subscribe to:
Posts (Atom)