Malware Detection
Jamie posted an MBR Parser recently. You're probably thinking, "Yeah...and???" Well, in her post regarding the code that she released, she does reference Chad's graphic regarding MBR malware, which illustrates the increase of MBR infectors over time. Jamie's code not only disassembles the instructions, but parses the partition table, as well. Yes, I know that there are other tools out there that parse the partition table, but I think that what Jamie provided is a means for gathering more information about systems when conducting analysis.
For example, let's assume that you're given a system and told, "We think this system was infected with malware", and nothing else. What do you do at that point? In most cases, I'm sure that an AV scan (or three) is run against the required image, but what else? As an analyst, do you specifically look for MBR infectors?
I've posted several times regarding the need to check for MBR infectors when you're working a "we think this system may be infected with malware" engagement. Mebroot can infect a system as a result of a browser drive-by; often times, I tend to think that we don't hear more about this sort of malware simply because analysis of infected systems isn't being done, or the MBR infectors aren't being effectively considered during analysis.
The code I wrote to help me detect MBR infectors parses the initial sectors of the acquired image; many time (albeit not always...), the first sector (sector 0) of a physical image contains the MBR, and sector 63 may be where the first partition is located. What the script does is read through the intermediate sectors and identify those that do not contain all zeros; many (again...not all) MBR infectors will copy the original MBR to one or more sectors before laying down the infection.
Note: I did, at one point, release the MBR infector detection script publicly, but I took it down, as I don't think that some of the analysts who were running the code really understood what they were doing. I was told by one person that they didn't understand why the code wasn't parsing MFT records, and another person ran the script against a Windows memory dump. It just got too time consuming to provide support for analysts who weren't using the code properly; however, I still use it as part of my malware detection process.
Where Jamie's code can be extremely valuable is when collecting information in preparation for your analysis. Let's say that you're collecting this information as part of your regular analysis, and you find that a system is, in fact, infected with an MBR infector. Now you have a means for identifying artifacts (or "IoCs") associated with that infection. This is another piece of information you can provide, another bit of intel that you can share, particularly when you're able to compare it not only to other systems you've examine before, but if the particular MBR infector is one of the variants that makes a copy of the original MBR, you can use that as a comparison. This can, in turn, help you and others more quickly identify indications of similar infections in the future.
I really think that the code that Jamie provided is not only very useful in and of itself (and as previously described), but also serves to illustrate the power of open source. Someone with some skill and interest sits down and provides a capability that previously didn't exist, or wasn't easily accessible to the majority of the community. Jamie produced this code of her own accord; another great example of how new capabilities come about was illustrated when Corey had an idea, and this guy brought it to life.
Resources
MBR Reference
WikiPedia: MBR
"The Standard MBR"
Malware Analysis
Speaking of malware (or "mall-wear"), there is an excellent analysis of malware over on the System Forensics blog. It's so nice sometimes to see analysis of malware that involves something more than just running strings on the file; in this case, a number of tools are used, including Dependency Walker, PeID, Resource Hacker, and CaptureBAT. If this is your kind of thing, take a look...it's a great walk-through on how to get some good intelligence about a malware sample, as well as an excellent example of what you can discover about an executable file beyond running strings on it.
Breaches and Sharing Intel
BankInfoSecurity recently posted an interview with the Heartland CEO, where breach response was the topic of discussion. Very early in the interview, Carr says that "information sharing is key", and he's right...some bad guys might be in other people's systems. Even if it isn't the same group or individual, techniques and tools may be similar, and sharing of information and intel may lead to a much more effective response, because you're not starting over, or starting completely from square 1...you've got something of a leg up.
Not long ago, I blogged about the Need for Analysis in an Intel-Driven Defense. That post referenced Dan Guido's paper on the same topic, and what I was pushing for in my post was the need to look at the analysis function within organizations, and how actually performing analysis would lead to more intel being available.
Something that Dan mentioned in his paper...specifically, the number of possible vulnerabilities versus those that are actually exploited...recently came up again, this time via the MMPC site; specifically, via a post about analysis of the Eleonore exploit pack shellcode. Remember, Dan had said that there were over 8000 vulnerabilities tracked last year...and it appears that the exploit pack in questions uses a grand total of...seven. Understanding and sharing this kind of information, as well as the indicators of a compromise, will provide responders and analysts with a means for a more effective response. Now all that needs to happen is that we need more posts like Corey's great exploit artifact posts.
As Dan pointed out in his paper, looking at the hard numbers (how very Deming-esque of him to say that...), we see where we need to focus our efforts. Within a large organization, would it be more advantageous to staff for the 8000+ possible vulnerabilities, or to beef up the analysis capability, so that (a) analysis actually gets done, and (b) it gets done in a timely (timely enough to be useful) and accurate manner?
In order to get the intel we need to defend our infrastructure, we need to conduct analysis. If this isn't being done, we need to take a hard look at why it isn't being done? Do we not have sufficient staff? Is our staff not sufficiently trained or do they not have sufficient capability? What can we do to improve that? If we're not collecting intel, then what can we share with others, so that everyone can better protect themselves?
I'd suggest that the single biggest thing you can do is get senior management recognition and support for the need for intel.
Showing posts sorted by relevance for query mbr infector. Sort by date Show all posts
Showing posts sorted by relevance for query mbr infector. Sort by date Show all posts
Monday, April 23, 2012
Thursday, April 07, 2011
Links
Digital Forensics Framework
The guys over at DFF have an open-source framework used as both a digital investigation and development platform. As this is an open-source tool, Cory did discuss a previous version of this tool in the Digital Forensics with Open Source Tools book.
The DFF guys recently posted on Time Filtering, using DFF to filter the image based on time stamp information.
While I think that this is a great step forward, I also think at the same time that this sort of data visualization is of limited value. As I've been creating timelines, I've been looking at ways to potentially present the information in a visual manner that would make analysis easier and more efficient; to be honest, I have yet to find something like this. Others have talked about such presentation methods as a histogram showing volumes of activity, but in the same breath, they'll also talk about malware following the Least Frequency of Occurrence (LFO) on systems; I'm not sure that showing spikes in activity necessarily lends itself to finding those things that occur least frequently on a system.
AntiForensics
Craig Ball wrote this article for Law Technology News, on the use of antiforensics. Many times, measures taken to foil the work of forensic analysts were originally intended as a privacy measure, but even if those actions are intended specifically to hide the user's activities from the analyst, they are often not even a speed bump in the road to analysis.
During an investigation I determined that an "evidence eliminator" application had been used. This analysis was of an older case, and the image was from a system that had been acquired several years prior to my analysis. When I did some research on the version of the application, I found that it deleted specific Registry keys...but I was able to recover the most recently deleted keys from unallocated space within the hive file itself. Previous subkeys and values were recovered via the hives found in the System Restore Points.
Antiforensics techniques target the training of the analyst...that's pretty much it. For more information, see the Parsing EVT Records section below.
Images
The DFF guys also included a link to the Digital Corpora site, from which the NTFS image described in the DFF blog post was downloaded. This is a great place to go to get access to some images, one of which is of a Vista system, apparently.
Hacking
One issue that continues to be a threat is disgruntled former employees. Gucci was recently confronted with this issue. What's interesting about the post to the Sophos NakedSecurity blog is that the fired former employee reportedly gained access to the network by first having created an account for a fictional employee, and then after being fired, social engineered the helpdesk and convincing them that he was that fictional employee. After that, he was able to return time and time again. This is just an example of how someone can use an organization's process against itself, taking full advantage of that process to perform a wide range of malicious actions.
Using RegRipper
I recently received the following quote from someone who used RegRipper and the regtime.pl plugin recently, but asked to remain anonymous (permission was given to post the quote, however):
I have the date and time in which an IDS caught a piece of malware being downloaded on the network to a user's machine. I need/needed to look for clues to see if the exe actually executed or not. I was using FTK's registry viewer to create a timeline of last write times for Keys but Registry Viewer doesn't let you export in a format other than HTML, which is just not helpful.
RegRipper gives me a nice line by line way to see the time and date stamps in a way in which they are much more viewable, WHICH IS GREAT.
Now, I'm not posting this to poke fun at nor admonish AccessData...not at all. I'm also not saying that one tool is any better or worse than another...all tools have their strengths and weaknesses, and the real power of a tool is in who uses it. I wanted to post this publicly to demonstrate to some who may not have used RegRipper or be familiar with it to see that, even though it's not a commercial tool, it can still be very useful. I tend to think that a number of folks in the DFIR community use specific tools because they feel that they have to...their employer purchased a tool or set of tools, based on some ancillary knowledge of the industry or due to a customer requirement. As such, there's considerable reticence toward trying or incorporating new tools, and rather than seeking the best tool to solve the problem, the problem is redefined to conform to the tools being used.
Open Source Conference
Speaking of tools, Brian Carrier sent out an email recently announcing the Sleuth Kit and Open Source Digital Forensics Conference on 14 June 2011 in McLean, VA. The day before the conference, there will be "two half-day workshops that will allow you to get hands-on experience with analyzing web browser artifacts and making timelines with open source tools."
Speakers at the conference will include Cory Altheide, Brian Carrier and Jon Stewart. You had me at "Cory Altheide". ;-) While remaining a fairly brief conference, this still looks as if it will be a good one, and I'm hoping that Cory and I will have copies of Digital Forensics with Open Source Tools available.
Chinese Bootkit
There's a new post over on the ThreatPost blog that discusses a Chinese bootkit. There's some interesting information available, and a graphic that demonstrates the process by which systems are infected. Part of that process includes an MBR infector, something for which I'd written a Perl script to help me detect during forensic analysis. Unfortunately, there isn't a great deal of information available in the blog post about the MBR infector, but I will say that it appears that these sorts of malware are popping up more frequently, so this is definitely something you would want to include in your malware detection process. After all, with the right tools, it only takes a few seconds to check for the possibility of an MBR infector, so we're not talking about extending your process by a day or more. This Net-Security article indicates that the MBR infector copies the original MBR to the third sector, so the MBR infector detector would work very well in helping you find indications of this bit of malware.
Parsing EVT Records
Lance recently posted about an EnScript he provided to help parse "classic" Windows Event Log (.evt) records from unallocated space. This is very similar to my recent post about the same thing, albeit the fact that the approach I took uses only free and open-source tools; however, if you're a heavy EnCase user, you'll probably want to go with Lance's solution. More than anything else, I think that what this shows is that there's a need for these sorts of things within the community...many times, there simply isn't one, single way to accomplish something, and having multiple tools is a good thing.
I've recently received a number of requests to share this code and technique, and the first time I did so, I sent the script within 10-15 min of receiving the request. And then didn't hear a thing back until I followed up three days later. Really...is it so hard to thank someone for sending you something that you asked for, and just acknowledging that you received it?
Presentations
I was over reviewing the offerings on the "What's New" page at the e-Evidence.info web site, and found Nick Klein's presentation from RuxCon. Interestingly, slide 9 includes the bullet, "Be specific in defining the objectives and what evidence might assist in determining the facts." Slide 11 of that presentation is all about documenting what you do. This is interesting to me because it's very similar to what Chris talks about in his Sniper Forensics presentations.
Malware Analysis
MalwareAnalyzer 2.9 was released recently. This project is written in Python, but provided as a Windows executable. I haven't seen too much out there about this one, but projects like this are always worth a look.
The guys over at DFF have an open-source framework used as both a digital investigation and development platform. As this is an open-source tool, Cory did discuss a previous version of this tool in the Digital Forensics with Open Source Tools book.
The DFF guys recently posted on Time Filtering, using DFF to filter the image based on time stamp information.
While I think that this is a great step forward, I also think at the same time that this sort of data visualization is of limited value. As I've been creating timelines, I've been looking at ways to potentially present the information in a visual manner that would make analysis easier and more efficient; to be honest, I have yet to find something like this. Others have talked about such presentation methods as a histogram showing volumes of activity, but in the same breath, they'll also talk about malware following the Least Frequency of Occurrence (LFO) on systems; I'm not sure that showing spikes in activity necessarily lends itself to finding those things that occur least frequently on a system.
AntiForensics
Craig Ball wrote this article for Law Technology News, on the use of antiforensics. Many times, measures taken to foil the work of forensic analysts were originally intended as a privacy measure, but even if those actions are intended specifically to hide the user's activities from the analyst, they are often not even a speed bump in the road to analysis.
During an investigation I determined that an "evidence eliminator" application had been used. This analysis was of an older case, and the image was from a system that had been acquired several years prior to my analysis. When I did some research on the version of the application, I found that it deleted specific Registry keys...but I was able to recover the most recently deleted keys from unallocated space within the hive file itself. Previous subkeys and values were recovered via the hives found in the System Restore Points.
Antiforensics techniques target the training of the analyst...that's pretty much it. For more information, see the Parsing EVT Records section below.
Images
The DFF guys also included a link to the Digital Corpora site, from which the NTFS image described in the DFF blog post was downloaded. This is a great place to go to get access to some images, one of which is of a Vista system, apparently.
Hacking
One issue that continues to be a threat is disgruntled former employees. Gucci was recently confronted with this issue. What's interesting about the post to the Sophos NakedSecurity blog is that the fired former employee reportedly gained access to the network by first having created an account for a fictional employee, and then after being fired, social engineered the helpdesk and convincing them that he was that fictional employee. After that, he was able to return time and time again. This is just an example of how someone can use an organization's process against itself, taking full advantage of that process to perform a wide range of malicious actions.
Using RegRipper
I recently received the following quote from someone who used RegRipper and the regtime.pl plugin recently, but asked to remain anonymous (permission was given to post the quote, however):
I have the date and time in which an IDS caught a piece of malware being downloaded on the network to a user's machine. I need/needed to look for clues to see if the exe actually executed or not. I was using FTK's registry viewer to create a timeline of last write times for Keys but Registry Viewer doesn't let you export in a format other than HTML, which is just not helpful.
RegRipper gives me a nice line by line way to see the time and date stamps in a way in which they are much more viewable, WHICH IS GREAT.
Now, I'm not posting this to poke fun at nor admonish AccessData...not at all. I'm also not saying that one tool is any better or worse than another...all tools have their strengths and weaknesses, and the real power of a tool is in who uses it. I wanted to post this publicly to demonstrate to some who may not have used RegRipper or be familiar with it to see that, even though it's not a commercial tool, it can still be very useful. I tend to think that a number of folks in the DFIR community use specific tools because they feel that they have to...their employer purchased a tool or set of tools, based on some ancillary knowledge of the industry or due to a customer requirement. As such, there's considerable reticence toward trying or incorporating new tools, and rather than seeking the best tool to solve the problem, the problem is redefined to conform to the tools being used.
Open Source Conference
Speaking of tools, Brian Carrier sent out an email recently announcing the Sleuth Kit and Open Source Digital Forensics Conference on 14 June 2011 in McLean, VA. The day before the conference, there will be "two half-day workshops that will allow you to get hands-on experience with analyzing web browser artifacts and making timelines with open source tools."
Speakers at the conference will include Cory Altheide, Brian Carrier and Jon Stewart. You had me at "Cory Altheide". ;-) While remaining a fairly brief conference, this still looks as if it will be a good one, and I'm hoping that Cory and I will have copies of Digital Forensics with Open Source Tools available.
Chinese Bootkit
There's a new post over on the ThreatPost blog that discusses a Chinese bootkit. There's some interesting information available, and a graphic that demonstrates the process by which systems are infected. Part of that process includes an MBR infector, something for which I'd written a Perl script to help me detect during forensic analysis. Unfortunately, there isn't a great deal of information available in the blog post about the MBR infector, but I will say that it appears that these sorts of malware are popping up more frequently, so this is definitely something you would want to include in your malware detection process. After all, with the right tools, it only takes a few seconds to check for the possibility of an MBR infector, so we're not talking about extending your process by a day or more. This Net-Security article indicates that the MBR infector copies the original MBR to the third sector, so the MBR infector detector would work very well in helping you find indications of this bit of malware.
Parsing EVT Records
Lance recently posted about an EnScript he provided to help parse "classic" Windows Event Log (.evt) records from unallocated space. This is very similar to my recent post about the same thing, albeit the fact that the approach I took uses only free and open-source tools; however, if you're a heavy EnCase user, you'll probably want to go with Lance's solution. More than anything else, I think that what this shows is that there's a need for these sorts of things within the community...many times, there simply isn't one, single way to accomplish something, and having multiple tools is a good thing.
I've recently received a number of requests to share this code and technique, and the first time I did so, I sent the script within 10-15 min of receiving the request. And then didn't hear a thing back until I followed up three days later. Really...is it so hard to thank someone for sending you something that you asked for, and just acknowledging that you received it?
Presentations
I was over reviewing the offerings on the "What's New" page at the e-Evidence.info web site, and found Nick Klein's presentation from RuxCon. Interestingly, slide 9 includes the bullet, "Be specific in defining the objectives and what evidence might assist in determining the facts." Slide 11 of that presentation is all about documenting what you do. This is interesting to me because it's very similar to what Chris talks about in his Sniper Forensics presentations.
Malware Analysis
MalwareAnalyzer 2.9 was released recently. This project is written in Python, but provided as a Windows executable. I haven't seen too much out there about this one, but projects like this are always worth a look.
Tuesday, June 28, 2011
Meetup, Tools and other stuff
Meetup
Just a reminder about our next NoVA Forensic Meetup, scheduled for 6 July. Tom Harper will be presenting, and he's posted his slides on his site. Take a look at his slides, and download them if you want to bring them along. Also, taking a look at them ahead of time will make the presentation itself go a bit more smooth, and leave more time for questions and interaction.
Location: ReverseSpace, 13505 Dulles Technology Drive, Herndon, VA.
Time: 7:00 - 8:30pm
Review
Corey Harrell posted his review of DFwOST. Thanks for the review, Corey, and for taking the time to put your thoughts out there for others to see.
MBR
I've mentioned previously that I include a check for MBR infectors in my malware detection process, and I even have it on my checklist. I discussed this recently with Chris Pogue ("@cpbeefcake" on Twitter), and he pointed me to the mbrparser.pl Perl script that Gary Kessler makes available via his site (the script can be found in the Boot Record Parsers archive). Gary's mbrparser.pl script does more than just display the MBR; it also parses the partition table in a very readable manner, providing a bit more information than mmls from the TSK tools.
My own Perl script is used for something other than just displaying the MBR, and it doesn't parse the partition table...instead, it looks for sectors that are not all zeros, and will either list those sectors (in summary mode) or display them. The thought process behind this approach is that many of the identified MBR infectors will modify the MBR with a jmp instruction, and copy the original MBR to another sector. Some may even include executable code within sectors. This is particularly useful when you have an image acquired from a physical disk and the first active partition is located at sector 63; usually, I will see sector 0 and 63 as non-zero, and maybe one or two other sectors. Running the script in summary mode gives me an idea of how many of the sectors I will need to look at, and then running it in full mode allows me to have something that I can redirect to a file and even include in my report, should the need arise. Even if nothing is found, that's useful, too...because now my malware detection process includes an additional step beyond simply, "I ran an AV scanner against the mounted image...".
Here are some links to disassembling the MBR:
Links
MBR disassembly
More MBR disassembly
Also be sure to check out Gary's page for other utilities, particularly if you're into SCUBA.
Speaking of MBR infectors, a recent MS Technet blog post mentioned a new MBR infector/bootkit called "Trojan:Win32/Popureb.E", which is apparently an update to previous versions of the identified malware, in that it infects the MBR. Unfortunately, MS's recommendation is to fix your MBR using your recovery disk - I say "unfortunately" because without a root cause analysis, what is the likelihood that you "fix" the system, and the bad guy is then able to un-fix your fix? Pretty high. I've seen other MBR infectors get delivered via Java exploits...so if you don't figure out how the MBR got infected, how are you going to protect your infrastructure? I'd suggest that the steps should be more along the lines of acquiring memory and an image of the physical disk, and then if you must re-provision the system, clean the MBR as suggested, but tag the system as such, and put a high priority on determining an overall fix.
Tools
Nick Harbour of Mandiant maintains a page with a couple of interesting tools, including nstrings and pestat. Nick's also posted some FileInsight plugins, as well as interesting presentations, on that same page.
The Malicious Streams site includes a Python-based LNK file parser (as well as some interesting MacOSX-specific tools).
David Kovar has moved his analyzeMFT tool to a new location; take note, and keep an eye out for new tools/libraries...
What is "APT"?
Jason Andress published an article for ISSA about APT, what it is, and what the threat really means. While I do think that the article gets a little too mired down in the origins and meaning of the term "APT", it does make a very valid point...regardless of what side of the fence you're on, APT is a very real threat. Jason does point out some very important points with respect to defending against this threat, but he does mention tools without specifically identifying any particular tools to use. I think that in doing this, he makes a point...that is, there is no security silver bullet, and one tool (or combination of tools) may work very well for one organization, but not at all for another.
I think that the most important point that Jason makes regarding defense is the idea of "defense-in-depth". Now, I've seen where some have suggested that this doesn't work...but the fact of the matter is that you can't deem something a failure if it was never employed.
Jason mentions "security awareness"...this is important, but it has to begin at the top. If you spend the time and effort to train your employees and raise security awareness, but your C-level executives aren't in attendance, how effective do you think that training will be? If it's really that important, wouldn't the boss be there? I attended two days of manager-and-above training for an employer, which was kicked off with a message from the CEO. And guess what...every time I looked around throughout the two days, I saw the CEO there. More than anything else, that told me that this stuff was important. Security has to be top-down.
Something to point out that wasn't mentioned in Jason's article is that many of the things he mentions are either directly or indirectly covered in most of the legal and regulatory compliance standards. Testing...training...having the right tools in place...many of these map directly to the PCI DSS. Even defense-in-depth, when you include the computer security incident response team (CSIRT), maps to chapter 12.9 of the DSS.
Jump List DestList Structure
Jump lists are one of those new things in Windows 7 that many analysts are trying to wrap their heads around. Jump lists provide similar functionality to the user as shortcuts in the Recents folder, as well as the RecentDocs Registry key, albeit in a different manner. First, jump lists come in two flavors; Automatic and Custom destinations. I'm not going to be really prolific about jump lists, but from a binary point of view, custom destinations are apparently SHLLNK structures run to together consecutively, one after another, where as Automatic destinations are streams within an OLE container (that is, each *.automaticdestination-ms file is an OLE container). Each of the streams within the contain is numbered (with the exception of one called "DestList"), and follows the SHLLNK structure. You can open the automatic destinations jump list using the MiTeC Structured Storage Viewer, extract each numbered stream, and view the contents of the stream in your favorite LNK viewer.
There is very little (i.e., "none") information available regarding the structure of the "DestList" stream, but looking at it in a hex editor seems to indicate that it may serve as a most recently used (MRU) or most frequently used (MFU) list. We know that the SHLLNK structure in the numbered streams contains time stamps, but from the structure definition we know that those are the MAC times of the target file. So how does Windows 7 know how to go about ordering the entries in the jump list?
Well, I spent some time with some jump lists, a hex editor and a number of colored pens and highlighters, and I think I may have figured out a portion of the DestList structure. First, each DestList structure starts with a 32 byte header, which contains (at offsets 0x03 and 0x18) an 8 byte number that corresponds to the number of numbered streams within the jump list.
Following the header, each element of the structure is 114 bytes, plus a variable length Unicode string. The table below presents those items within each element that I've been able to extract on a consistent basis, albeit via limited testing.
While the information represented in the above table clearly isn't all that's available, I do think that it's a good start. Once further testing is able to determine what the FILETIME object represents, this is enough information to allow for inclusion of jump lists into timelines.
Just a reminder about our next NoVA Forensic Meetup, scheduled for 6 July. Tom Harper will be presenting, and he's posted his slides on his site. Take a look at his slides, and download them if you want to bring them along. Also, taking a look at them ahead of time will make the presentation itself go a bit more smooth, and leave more time for questions and interaction.
Location: ReverseSpace, 13505 Dulles Technology Drive, Herndon, VA.
Time: 7:00 - 8:30pm
Review
Corey Harrell posted his review of DFwOST. Thanks for the review, Corey, and for taking the time to put your thoughts out there for others to see.
MBR
My own Perl script is used for something other than just displaying the MBR, and it doesn't parse the partition table...instead, it looks for sectors that are not all zeros, and will either list those sectors (in summary mode) or display them. The thought process behind this approach is that many of the identified MBR infectors will modify the MBR with a jmp instruction, and copy the original MBR to another sector. Some may even include executable code within sectors. This is particularly useful when you have an image acquired from a physical disk and the first active partition is located at sector 63; usually, I will see sector 0 and 63 as non-zero, and maybe one or two other sectors. Running the script in summary mode gives me an idea of how many of the sectors I will need to look at, and then running it in full mode allows me to have something that I can redirect to a file and even include in my report, should the need arise. Even if nothing is found, that's useful, too...because now my malware detection process includes an additional step beyond simply, "I ran an AV scanner against the mounted image...".
Here are some links to disassembling the MBR:
Links
MBR disassembly
More MBR disassembly
Also be sure to check out Gary's page for other utilities, particularly if you're into SCUBA.
Speaking of MBR infectors, a recent MS Technet blog post mentioned a new MBR infector/bootkit called "Trojan:Win32/Popureb.E", which is apparently an update to previous versions of the identified malware, in that it infects the MBR. Unfortunately, MS's recommendation is to fix your MBR using your recovery disk - I say "unfortunately" because without a root cause analysis, what is the likelihood that you "fix" the system, and the bad guy is then able to un-fix your fix? Pretty high. I've seen other MBR infectors get delivered via Java exploits...so if you don't figure out how the MBR got infected, how are you going to protect your infrastructure? I'd suggest that the steps should be more along the lines of acquiring memory and an image of the physical disk, and then if you must re-provision the system, clean the MBR as suggested, but tag the system as such, and put a high priority on determining an overall fix.
Tools
Nick Harbour of Mandiant maintains a page with a couple of interesting tools, including nstrings and pestat. Nick's also posted some FileInsight plugins, as well as interesting presentations, on that same page.
The Malicious Streams site includes a Python-based LNK file parser (as well as some interesting MacOSX-specific tools).
David Kovar has moved his analyzeMFT tool to a new location; take note, and keep an eye out for new tools/libraries...
What is "APT"?
Jason Andress published an article for ISSA about APT, what it is, and what the threat really means. While I do think that the article gets a little too mired down in the origins and meaning of the term "APT", it does make a very valid point...regardless of what side of the fence you're on, APT is a very real threat. Jason does point out some very important points with respect to defending against this threat, but he does mention tools without specifically identifying any particular tools to use. I think that in doing this, he makes a point...that is, there is no security silver bullet, and one tool (or combination of tools) may work very well for one organization, but not at all for another.
I think that the most important point that Jason makes regarding defense is the idea of "defense-in-depth". Now, I've seen where some have suggested that this doesn't work...but the fact of the matter is that you can't deem something a failure if it was never employed.
Jason mentions "security awareness"...this is important, but it has to begin at the top. If you spend the time and effort to train your employees and raise security awareness, but your C-level executives aren't in attendance, how effective do you think that training will be? If it's really that important, wouldn't the boss be there? I attended two days of manager-and-above training for an employer, which was kicked off with a message from the CEO. And guess what...every time I looked around throughout the two days, I saw the CEO there. More than anything else, that told me that this stuff was important. Security has to be top-down.
Something to point out that wasn't mentioned in Jason's article is that many of the things he mentions are either directly or indirectly covered in most of the legal and regulatory compliance standards. Testing...training...having the right tools in place...many of these map directly to the PCI DSS. Even defense-in-depth, when you include the computer security incident response team (CSIRT), maps to chapter 12.9 of the DSS.
Jump List DestList Structure
Jump lists are one of those new things in Windows 7 that many analysts are trying to wrap their heads around. Jump lists provide similar functionality to the user as shortcuts in the Recents folder, as well as the RecentDocs Registry key, albeit in a different manner. First, jump lists come in two flavors; Automatic and Custom destinations. I'm not going to be really prolific about jump lists, but from a binary point of view, custom destinations are apparently SHLLNK structures run to together consecutively, one after another, where as Automatic destinations are streams within an OLE container (that is, each *.automaticdestination-ms file is an OLE container). Each of the streams within the contain is numbered (with the exception of one called "DestList"), and follows the SHLLNK structure. You can open the automatic destinations jump list using the MiTeC Structured Storage Viewer, extract each numbered stream, and view the contents of the stream in your favorite LNK viewer.
There is very little (i.e., "none") information available regarding the structure of the "DestList" stream, but looking at it in a hex editor seems to indicate that it may serve as a most recently used (MRU) or most frequently used (MFU) list. We know that the SHLLNK structure in the numbered streams contains time stamps, but from the structure definition we know that those are the MAC times of the target file. So how does Windows 7 know how to go about ordering the entries in the jump list?
Well, I spent some time with some jump lists, a hex editor and a number of colored pens and highlighters, and I think I may have figured out a portion of the DestList structure. First, each DestList structure starts with a 32 byte header, which contains (at offsets 0x03 and 0x18) an 8 byte number that corresponds to the number of numbered streams within the jump list.
Following the header, each element of the structure is 114 bytes, plus a variable length Unicode string. The table below presents those items within each element that I've been able to extract on a consistent basis, albeit via limited testing.
| Offset | Size | Description |
|---|---|---|
| 0x48 | 16 bytes | NetBIOS name of the system; padded with zeros to 16 bytes |
| 0x58 | 8 bytes | Stream number; corresponds to the numbered stream within the jump list |
| 0x64 | 8 bytes | FILETIME object |
| 0x70 | 2 bytes | Number of Unicode characters in the string that follows |
While the information represented in the above table clearly isn't all that's available, I do think that it's a good start. Once further testing is able to determine what the FILETIME object represents, this is enough information to allow for inclusion of jump lists into timelines.
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, 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, April 11, 2011
Links and Stuff
Digital Forensic Search
Corey Harrell's done some pretty interesting things lately...most recently, he set up a search mechanism that targets a specific subset of Internet resources that are specific to the digital forensics community. Sometimes when we're searching for something, we head off to our favorite search engine and cast a wide net...and we may not get that many hits initially that are pertinent to what we're looking for; by narrowing the field a bit, more relevant hits may be returned.
One of the issues with the community is that there's a lot of good information out there, but it's out there. Many analysts have expressed a bit of frustration that they can't seem to find what they're looking for when they need it, and that they don't know that they need it until...well...they need it. I've also talked to people who've done hours of research but not documented any of it, so when the issue they were working on comes up again, they have to go back and redo all of that research again.
Rootkit Evolution
Greg Hoglund posted to his Fast Horizon blog recently, and the title...Rootkit Evolution...sparked my curiosity. Sadly, when I read the post, it wasn't really anything more than a sales pitch for Digital DNA, whereas I had expected...well...something about the evolution of rootkits. I mean, that's kind of what the title suggested. Anyway, one statement from the blog caught my interest, however:
...we are still ahead of the threat.
While I don't disagree with this, I would suggest that attackers may find that it isn't necessary to employ rootkit technology. Now, don't get me wrong...I'm sure that this does happen. But for the most part, is it really necessary? Look at many of the available annual reports, such the Verizon Business Security report, M-Trends, or TrustWave's Global Security Report...some of the commonalities you may see across the board include considerable persistence without the need to deploy rootkits.
So...is the research important? Yes, it is. They're still being used (see the Chinese bootkit). Now and then, these thing pop up (well, not really...someone finds one...) during an incident as a well-designed rootkit can be very effective. It's just like NTFS alternate data streams...as soon as the security community considers them passe and stops looking for them, that's when they'll make a resurgence and be used more and more by the bad guys.
What a Tweet Looks Like
Ever wondered what a tweet looks like? I'm sure you have! ;-) By way of a couple of different links comes a very interesting write-up of what a tweet looks like from a developer's standpoint...click on the big picture in the middle of the post to enlarge the map-of-a-tweet (or "Twitter Status Object"). Most forensic analysts will likely look at the map and see the value right away.
Okay, so how would you get at this? This sort of information would likely be in some unstructured area of the disk, right...the pagefile or unallocated space. So, if you were to run strings or BinText against the pagefile or unallocated space extracted from an image via blkls, you would end up with a list of strings along with their offsets within the data. What I've done is write a Perl script that goes into the data at the offset that I'm interested in, and extracts however many bytes on either side of the offset that I specify. I've used this methodology to extract not only URIs and server responses from the pagefile, but also Windows XP/2003 Event Log records from unallocated space, translating them directly to timeline/TLN format. Doing this provided me with a capability that went beyond simply carving for files, as I needed to carve for specific, perhaps well-defined data structures.
Something like this could be used to quickly and easily extract tweets from unallocated space or the pagefile. Run strings/BinText, then search the output to see if you have any unique search terms, such as a user name or screen name. Then, run the script that goes to the offset of each search term and extracts the appropriate amount of data. This can be extremely valuable functionality to an examiner, and can be added to an overall data extraction process using free and open source tools.
Writing Open Source Tools
The above section, the imminent publication of Digital Forensics with Open Source Tools (the book was Cory Altheide's idea and he was the primary author, as is due to be published on 15 April), and the upcoming Open Source Forensics Conference (at which Cory and I will both be speaking...), all combine to make a good transition to some comments on writing open source tools. Also, this is a topic that Cory and I had considered addressing in the book, but had decided that it was too big for a sidebar, and didn't quite fit in anywhere in particular. After all, with all of the open source tools discussed in the book, we would really need to get input from others to really do the topic justice. As such, I thought I could post a few comments here...
For me, writing open source tools starts as a way to serve my own needs when conducting analysis. Throughout my career, I have had access to commercial forensic analysis applications, and each has served their purpose. However, as with any tool, these applications have their strengths and weaknesses. When conducting PCI forensic investigations, a commercial application made it easy to set up a process that all of the analysts could employ, but we also found out that some of the built-in functions were not exactly accurate, and that affected our results. The result of that was to seek outside assistance to rewrite the built-in functions, in order to get something that was more accurate and better suited to our needs. We would then export the results and run them through an open-source process to prepare an accurate count of unique numbers, etc.
So, sometimes I'd write an open source tool in order to massage some data into a format that is better suited to presentation or dissemination. However, there have been other times when no commercial application had the functionality I needed, so I wroted something to meet my needs. A great example of this is the MBR infector detector script. Another is the script I wrote to carve Windows XP/2003 Event Log records from unallocated space.
I can guess that one response to all this is going to be, "...but I don't know how to program...", and my response to that is, you don't have to...you just have to know someone who does. Not every analyst needs needs to know how to program, although many analysts out there can tell you that understanding programming (anything from batch files all the way to assembly...) can be extremely beneficial. However, having someone who understands what you do and can program can be extremely beneficial when it comes to DFIR work.
Too many times, when it comes to DFIR work, analysts are sort of left on their own. Business models of dictate the necessity for this...but having a support mechanism for engagements of all kinds can be an extremely effective means of extending your team's capabilities, as well as preserving corporate intellectual property.
Even if you aren't part of a DFIR team, you can still develop and take advantage of this sort of relationship. If you know someone within the community with programming skills, what does it hurt to seek their assistance? If they, in turn, provide you with effective, timely support, then you have a great opportunity to further the relationship by supporting them in some manner...even if that's just a "thank you" for their efforts. Many folks with some programming capabilities are simply seeking new challenges and new opportunities to learn, or employ their skills in new ways. So when it comes to writing open source tools, many times, the only real "cost" involved is a "thank you" and acknowledgement of someone's efforts to support you.
Scanners
Lenny's got a post up that lists three tools for scanning the file system for malware with custom signatures. these are all excellent tools; in fact, if you remember that I had provided instructions (from MHL) regarding how to install pescanner.py on Windows systems, two of the tools that Lenny mentions (ClamAV, Yara) can be included in the setup for pescanner.py and the signatures used to locate suspicious files.
Signatures are one way to locate malware and other suspicious files on a system. However, signatures change, and they must be kept up to date. You can also use signatures to locate all packed files, as well as files "hidden" using other obfuscation methods.
Keep in mind, however, that this is only part of the solution. Because signatures within malware files do change, we also need to consider the network, memory, and other parts of the system (i.e., Registry, etc.) to look for indicators of malware. In fact, many times, this may be our first indicator of malware. I've found previous infection attempts were malware has been loaded on a system, only to be detected and quarantined by the installed AV product. I could see the names of the files within the AV and Application Event Logs. Interestingly enough, files of the same name were created a couple of weeks later, indicating that the bad guy had obfuscated his malware so that the AV wouldn't detected it, and was able to get it successfully installed.
There's more to malware detection than just scanning files for signatures. If all you have is an acquired image from a system, and a malware infection was suspected, there are a number of other things you can look at in order to find ancillary indicators of an infection. Scanners should be part of the malware detection process.
Corey Harrell's done some pretty interesting things lately...most recently, he set up a search mechanism that targets a specific subset of Internet resources that are specific to the digital forensics community. Sometimes when we're searching for something, we head off to our favorite search engine and cast a wide net...and we may not get that many hits initially that are pertinent to what we're looking for; by narrowing the field a bit, more relevant hits may be returned.
One of the issues with the community is that there's a lot of good information out there, but it's out there. Many analysts have expressed a bit of frustration that they can't seem to find what they're looking for when they need it, and that they don't know that they need it until...well...they need it. I've also talked to people who've done hours of research but not documented any of it, so when the issue they were working on comes up again, they have to go back and redo all of that research again.
Rootkit Evolution
Greg Hoglund posted to his Fast Horizon blog recently, and the title...Rootkit Evolution...sparked my curiosity. Sadly, when I read the post, it wasn't really anything more than a sales pitch for Digital DNA, whereas I had expected...well...something about the evolution of rootkits. I mean, that's kind of what the title suggested. Anyway, one statement from the blog caught my interest, however:
...we are still ahead of the threat.
While I don't disagree with this, I would suggest that attackers may find that it isn't necessary to employ rootkit technology. Now, don't get me wrong...I'm sure that this does happen. But for the most part, is it really necessary? Look at many of the available annual reports, such the Verizon Business Security report, M-Trends, or TrustWave's Global Security Report...some of the commonalities you may see across the board include considerable persistence without the need to deploy rootkits.
So...is the research important? Yes, it is. They're still being used (see the Chinese bootkit). Now and then, these thing pop up (well, not really...someone finds one...) during an incident as a well-designed rootkit can be very effective. It's just like NTFS alternate data streams...as soon as the security community considers them passe and stops looking for them, that's when they'll make a resurgence and be used more and more by the bad guys.
What a Tweet Looks Like
Ever wondered what a tweet looks like? I'm sure you have! ;-) By way of a couple of different links comes a very interesting write-up of what a tweet looks like from a developer's standpoint...click on the big picture in the middle of the post to enlarge the map-of-a-tweet (or "Twitter Status Object"). Most forensic analysts will likely look at the map and see the value right away.
Okay, so how would you get at this? This sort of information would likely be in some unstructured area of the disk, right...the pagefile or unallocated space. So, if you were to run strings or BinText against the pagefile or unallocated space extracted from an image via blkls, you would end up with a list of strings along with their offsets within the data. What I've done is write a Perl script that goes into the data at the offset that I'm interested in, and extracts however many bytes on either side of the offset that I specify. I've used this methodology to extract not only URIs and server responses from the pagefile, but also Windows XP/2003 Event Log records from unallocated space, translating them directly to timeline/TLN format. Doing this provided me with a capability that went beyond simply carving for files, as I needed to carve for specific, perhaps well-defined data structures.
Something like this could be used to quickly and easily extract tweets from unallocated space or the pagefile. Run strings/BinText, then search the output to see if you have any unique search terms, such as a user name or screen name. Then, run the script that goes to the offset of each search term and extracts the appropriate amount of data. This can be extremely valuable functionality to an examiner, and can be added to an overall data extraction process using free and open source tools.
Writing Open Source Tools
The above section, the imminent publication of Digital Forensics with Open Source Tools (the book was Cory Altheide's idea and he was the primary author, as is due to be published on 15 April), and the upcoming Open Source Forensics Conference (at which Cory and I will both be speaking...), all combine to make a good transition to some comments on writing open source tools. Also, this is a topic that Cory and I had considered addressing in the book, but had decided that it was too big for a sidebar, and didn't quite fit in anywhere in particular. After all, with all of the open source tools discussed in the book, we would really need to get input from others to really do the topic justice. As such, I thought I could post a few comments here...
For me, writing open source tools starts as a way to serve my own needs when conducting analysis. Throughout my career, I have had access to commercial forensic analysis applications, and each has served their purpose. However, as with any tool, these applications have their strengths and weaknesses. When conducting PCI forensic investigations, a commercial application made it easy to set up a process that all of the analysts could employ, but we also found out that some of the built-in functions were not exactly accurate, and that affected our results. The result of that was to seek outside assistance to rewrite the built-in functions, in order to get something that was more accurate and better suited to our needs. We would then export the results and run them through an open-source process to prepare an accurate count of unique numbers, etc.
So, sometimes I'd write an open source tool in order to massage some data into a format that is better suited to presentation or dissemination. However, there have been other times when no commercial application had the functionality I needed, so I wroted something to meet my needs. A great example of this is the MBR infector detector script. Another is the script I wrote to carve Windows XP/2003 Event Log records from unallocated space.
I can guess that one response to all this is going to be, "...but I don't know how to program...", and my response to that is, you don't have to...you just have to know someone who does. Not every analyst needs needs to know how to program, although many analysts out there can tell you that understanding programming (anything from batch files all the way to assembly...) can be extremely beneficial. However, having someone who understands what you do and can program can be extremely beneficial when it comes to DFIR work.
Too many times, when it comes to DFIR work, analysts are sort of left on their own. Business models of dictate the necessity for this...but having a support mechanism for engagements of all kinds can be an extremely effective means of extending your team's capabilities, as well as preserving corporate intellectual property.
Even if you aren't part of a DFIR team, you can still develop and take advantage of this sort of relationship. If you know someone within the community with programming skills, what does it hurt to seek their assistance? If they, in turn, provide you with effective, timely support, then you have a great opportunity to further the relationship by supporting them in some manner...even if that's just a "thank you" for their efforts. Many folks with some programming capabilities are simply seeking new challenges and new opportunities to learn, or employ their skills in new ways. So when it comes to writing open source tools, many times, the only real "cost" involved is a "thank you" and acknowledgement of someone's efforts to support you.
Scanners
Lenny's got a post up that lists three tools for scanning the file system for malware with custom signatures. these are all excellent tools; in fact, if you remember that I had provided instructions (from MHL) regarding how to install pescanner.py on Windows systems, two of the tools that Lenny mentions (ClamAV, Yara) can be included in the setup for pescanner.py and the signatures used to locate suspicious files.
Signatures are one way to locate malware and other suspicious files on a system. However, signatures change, and they must be kept up to date. You can also use signatures to locate all packed files, as well as files "hidden" using other obfuscation methods.
Keep in mind, however, that this is only part of the solution. Because signatures within malware files do change, we also need to consider the network, memory, and other parts of the system (i.e., Registry, etc.) to look for indicators of malware. In fact, many times, this may be our first indicator of malware. I've found previous infection attempts were malware has been loaded on a system, only to be detected and quarantined by the installed AV product. I could see the names of the files within the AV and Application Event Logs. Interestingly enough, files of the same name were created a couple of weeks later, indicating that the bad guy had obfuscated his malware so that the AV wouldn't detected it, and was able to get it successfully installed.
There's more to malware detection than just scanning files for signatures. If all you have is an acquired image from a system, and a malware infection was suspected, there are a number of other things you can look at in order to find ancillary indicators of an infection. Scanners should be part of the malware detection process.
Subscribe to:
Posts (Atom)