One of the things that really bothers me sometimes about the AV industry is the lack of information that's available with respect to a great deal of the malware that's out there.
Take Virut, for example. Microsoft's Malware Protection Center had a post here about a new variant being available, and there's information here regarding the Virut virus family (info about the latest variant, Virut.BM, is here).
Of course, the various AV vendors also provide some modicum of information about either the Virut family or a specific variant, all with varying levels of information. Some, like McAfee, provide more information than others, so that if the AV product itself isn't picking up the virus (due, in part, to its polymorphic nature) then maybe you can look for artifacts (modification to the hosts file, Registry keys/values, etc.) that may help you narrow down not only the infection, but also help you identify other infected systems.
One interesting aspect of all of this, and glaringly obvious in its absence, is any discussion of Windows File Protection, or WFP. While WFP is not mean to be a security mechanism, per se, the fact of the matter is that if Virut infects all EXEs on a system, then it would stand to reason that protected system files that are infected would be replaced by WFP...IF it were not disabled. Since there seem to be no discussions about this at all (at least not since Dec 2007), then it would stand to reason that the virus does, somehow, disable WFP.
So...does anyone have any thoughts on why Microsoft isn't letting its customers know about this?
Addendum: First, per the comments to this post, the MMPC listing for the virus was updated to include information on the method used to disable WFP/SFP while this post was being written.
Now, in yet another example of the massive disconnect between AV vendors and their customers, McAfee has a post on W32/Virut.n that refers to "Registry entries", without specifying whether the entries are Registry keys or values. Symantec, on the other hand, calls the data added to the Registry an "entry" in their W32.Virut.CF post, but provides enough information to indicate that it's a value.
How is this a disconnect? Many customers of these AV vendors have enterprise-wide infrastructures, and need to determine other systems that may be infected. MS's WMI provides a fantastic capability to quickly determine this...and yet, without clear, concise, and correct information, customers are left struggling.
Is it really that hard? I mean, you've done the analysis, and have the information. What's the issue? Also, why is MS the only vendor that I've found so far to make any mention of WFP being disabled?
Showing posts with label Microsoft. Show all posts
Showing posts with label Microsoft. Show all posts
Tuesday, February 17, 2009
Wednesday, March 28, 2007
Change Analysis Diagnostic Tool for Windows XP
Microsoft recently released this KB article, titled The Change Analysis Diagnostic Tool for Windows XP is available.
So, why is this interesting? Bear with me for just a moment. Reading the article, we see that the tool looks at programs, OS components, BHOs, drivers, ActiveX controls, and ASEPs (MS's term for autostart locations). Okay, so not entirely interesting, per se...there are tools that already do this, I know. However, the really interesting part is this:
The Change Analysis Diagnostic tool queries the System Restore data for the number of days that the user selects. The tool finds the changes to the registry and to the file system that are relevant to these categories. Then, the tool presents the changes together with contextual information.
Is that sweet or what? Tools like this generally require a baseline, such as when we're performing dynamic malware analysis (ie, snapshot the system, install malware, snapshot the system again, and compare the two). In this case, MS is using the Restore Points as the snapshots. Makes me glad that I took the time to address Restore Point analysis in my book!
So, why is this interesting? Bear with me for just a moment. Reading the article, we see that the tool looks at programs, OS components, BHOs, drivers, ActiveX controls, and ASEPs (MS's term for autostart locations). Okay, so not entirely interesting, per se...there are tools that already do this, I know. However, the really interesting part is this:
The Change Analysis Diagnostic tool queries the System Restore data for the number of days that the user selects. The tool finds the changes to the registry and to the file system that are relevant to these categories. Then, the tool presents the changes together with contextual information.
Is that sweet or what? Tools like this generally require a baseline, such as when we're performing dynamic malware analysis (ie, snapshot the system, install malware, snapshot the system again, and compare the two). In this case, MS is using the Restore Points as the snapshots. Makes me glad that I took the time to address Restore Point analysis in my book!
Tuesday, January 16, 2007
Fundamentals
MS recently posted their Fundamental Computer Investigation Guide for Windows. You can download the document or read the entire doc online.
I haven't heard too many opinions yet about this document, good or bad. It may be because most folks aren't aware of it. I will say right up front that I was involved in the editing process, so I'll have a slightly different view. I've seen this document in various forms, and read each of those iterations at least twice.
The paper is intended for IT professionals in the United States who need a general understanding of computer investigations, including many of the procedures that can be used in such investigations and protocols for reporting incidents. Okay, that's a great way to start when writing a fundamentals paper. The paper seems to be directed at folks who either don't normally respond to incidents, or haven't done so before and are now in a position where they are required to do so.
The paper consists of five chapters and an appendix. I'm not going to go through each one, but rather just mention some highlights. I do think that the paper is worth the time to read it, as anyone who reads it is going to get something out of it, positive or negative.
Chapter 1: Assess the Situation: This chapter provides some good advice and things to think about when an incident occurs; I would suggest, however, that most of those things (obtain authorization, review laws, etc.) be done before an incident occurs...that way, attention can be focused on responding to the incident. The Conduct a Thorough Assessment section is fairly comprehensive, and as you read it, keep in mind that no one will be able to list everything you need to know for every incident. Not only do incidents vary, but the same worm on two different networks will be handled differently, because each infrastructure is different, both from a technical/network perspective and a human/socio-political perspective. I would say that there's enough there to get you started, and going forward, it's better to know or not know than to make things up; many an investigation has gone down the wrong path because someone made assumptions based on too little information.
One thing I would like to see changed about the paper is how data about an incident is referred to. In the Prepare for Evidence Acquisition section, the first sentence says in part, "To prepare for the Acquire the Data phase..." So which is it...evidence or data? Given that many states are considering PI laws, it is important to differentiate between the two. Also, consistency of terminology is just a good idea.
On a positive note, the first chapter ends by referring to documentation. Documentation is very important during an investigation. Let's say that you're sweeping across servers to identify a piece of malware...if you don't document your process (what's being checked and why), you're going to have folks who go to a server and don't know what they're supposed to do. Also, you need to document which systems have been scanned and by whom, so that you don't spend a great deal of time rescanning the same server over and over again. Remember, if you didn't document it, it didn't happen.
Chapter 2: Acquire the Data: This chapter glosses over data acquisition as part of incident response. There is a reference to the Tools section in the Appendix, but the tools listed are exclusively either SysInternals tools or native commands on the system. Don't get me wrong...there are some extremely useful tools from SysInternals, but what's missing is a description of what information needs to be collected, and the best tools for doing so. For example, when responding to an incident, the first things I want to know are:
Chapter 3: Analyze the Data tells the reader what they should do with the data they've collected. In the section on analyzing host data, you'll see the following statement:
...you might use the Microsoft Windows® Sysinternals Strings tool to search the files located in the \Windows\Prefetch folder. This folder contains information such as when and where applications were launched.
Don't get me wrong...I agree with both sentences. I just don't think that the two of them should be next to each other. Why? Well, the information maintained in a .pf file regarding when the application was launched is a 64-bit FILETIME object...strings.exe won't find that for you. While using strings or BinText from FoundStone can be very useful when looking for ASCII, Unicode, or Resource strings within a file, neither will help you locate the FILETIME object.
There's more to it than that, though. When responding to an incident, how do you identify a "suspicious" file or process? Within your infrastructure, what constitutes suspicious? Some might think that running three or even four remote desktop applications is suspicous, while others may think that multiple copies of svchost.exe running on a system is suspicious.
At this point, I think that I've provided enough comments regarding what I saw to be good in the paper, as well as what, IMHO, could be improved of changed. I think that the paper is a good start, but don't expect to sit down and read it, and then be able to conduct an investigation. I still think that MS would be better off with a different structure to documents such as these, directing different versions to different audiences. For example, a high level document for incident managers, one that's a bit more technical for incident team leaders (so that they can evaluate the performance of the team members), and then separate documents for data acquisition and analysis for host- and network-based live acquisition, as well as acquiring an image.
Thoughts?
I haven't heard too many opinions yet about this document, good or bad. It may be because most folks aren't aware of it. I will say right up front that I was involved in the editing process, so I'll have a slightly different view. I've seen this document in various forms, and read each of those iterations at least twice.
The paper is intended for IT professionals in the United States who need a general understanding of computer investigations, including many of the procedures that can be used in such investigations and protocols for reporting incidents. Okay, that's a great way to start when writing a fundamentals paper. The paper seems to be directed at folks who either don't normally respond to incidents, or haven't done so before and are now in a position where they are required to do so.
The paper consists of five chapters and an appendix. I'm not going to go through each one, but rather just mention some highlights. I do think that the paper is worth the time to read it, as anyone who reads it is going to get something out of it, positive or negative.
Chapter 1: Assess the Situation: This chapter provides some good advice and things to think about when an incident occurs; I would suggest, however, that most of those things (obtain authorization, review laws, etc.) be done before an incident occurs...that way, attention can be focused on responding to the incident. The Conduct a Thorough Assessment section is fairly comprehensive, and as you read it, keep in mind that no one will be able to list everything you need to know for every incident. Not only do incidents vary, but the same worm on two different networks will be handled differently, because each infrastructure is different, both from a technical/network perspective and a human/socio-political perspective. I would say that there's enough there to get you started, and going forward, it's better to know or not know than to make things up; many an investigation has gone down the wrong path because someone made assumptions based on too little information.
One thing I would like to see changed about the paper is how data about an incident is referred to. In the Prepare for Evidence Acquisition section, the first sentence says in part, "To prepare for the Acquire the Data phase..." So which is it...evidence or data? Given that many states are considering PI laws, it is important to differentiate between the two. Also, consistency of terminology is just a good idea.
On a positive note, the first chapter ends by referring to documentation. Documentation is very important during an investigation. Let's say that you're sweeping across servers to identify a piece of malware...if you don't document your process (what's being checked and why), you're going to have folks who go to a server and don't know what they're supposed to do. Also, you need to document which systems have been scanned and by whom, so that you don't spend a great deal of time rescanning the same server over and over again. Remember, if you didn't document it, it didn't happen.
Chapter 2: Acquire the Data: This chapter glosses over data acquisition as part of incident response. There is a reference to the Tools section in the Appendix, but the tools listed are exclusively either SysInternals tools or native commands on the system. Don't get me wrong...there are some extremely useful tools from SysInternals, but what's missing is a description of what information needs to be collected, and the best tools for doing so. For example, when responding to an incident, the first things I want to know are:
- The list of active processes, with the full path to the executable image and the command line to launch each one. I'd also like to know the user context of each process.
- Network connections.
- Process-to-port mappings, so that I know which network connection is owned or used by which process.
- Who is logged into the system (NetBIOS, mapped shares, Terminal Services, etc.)
- Running services.
Chapter 3: Analyze the Data tells the reader what they should do with the data they've collected. In the section on analyzing host data, you'll see the following statement:
...you might use the Microsoft Windows® Sysinternals Strings tool to search the files located in the \Windows\Prefetch folder. This folder contains information such as when and where applications were launched.
Don't get me wrong...I agree with both sentences. I just don't think that the two of them should be next to each other. Why? Well, the information maintained in a .pf file regarding when the application was launched is a 64-bit FILETIME object...strings.exe won't find that for you. While using strings or BinText from FoundStone can be very useful when looking for ASCII, Unicode, or Resource strings within a file, neither will help you locate the FILETIME object.
There's more to it than that, though. When responding to an incident, how do you identify a "suspicious" file or process? Within your infrastructure, what constitutes suspicious? Some might think that running three or even four remote desktop applications is suspicous, while others may think that multiple copies of svchost.exe running on a system is suspicious.
At this point, I think that I've provided enough comments regarding what I saw to be good in the paper, as well as what, IMHO, could be improved of changed. I think that the paper is a good start, but don't expect to sit down and read it, and then be able to conduct an investigation. I still think that MS would be better off with a different structure to documents such as these, directing different versions to different audiences. For example, a high level document for incident managers, one that's a bit more technical for incident team leaders (so that they can evaluate the performance of the team members), and then separate documents for data acquisition and analysis for host- and network-based live acquisition, as well as acquiring an image.
Thoughts?
Thursday, November 16, 2006
Van Hensing Rides...uh, Blogs Again!
Robert Hensing, formerly of the MS PSS Security team and now with SWI, has started blogging again! This is great news, because Robert brings a wealth of experience and knowledge to the field of incident response and forensics. Also, due to his resources, he also brings a great deal of insight and detail to the things he investigates and shares with us.
For example, check out his most recent post involving web surfing activity found in the "Default User" directory (he also addressed something similar in his "Anatomy of a WINS Hack" post). What's interesting about this is that if you are using ProDiscover to examine an image, and you populate the Internet History View and find entries for "Default User", you've struck gold!
Robert tends to blog on a wide range of subjects, and his entries about Windows issues tend to be more technical and comprehensive than what you'll find on most sites. So, check it out and leave a comment...
For example, check out his most recent post involving web surfing activity found in the "Default User" directory (he also addressed something similar in his "Anatomy of a WINS Hack" post). What's interesting about this is that if you are using ProDiscover to examine an image, and you populate the Internet History View and find entries for "Default User", you've struck gold!
Robert tends to blog on a wide range of subjects, and his entries about Windows issues tend to be more technical and comprehensive than what you'll find on most sites. So, check it out and leave a comment...
Subscribe to:
Posts (Atom)