Researching Artifacts
One of the things I really like about this industry is that there's always something new...a new challenge, a new twist to old questions, etc. This is fun, because I like to see about approaching these issues with a novel approach.
Here's an example; I recently found this article discussing an issue with web cams on laptops issued to high school students having been allegedly turned on remotely and used to monitor students in their homes. More and more laptops are available with built-in web cams, and web cams are relatively inexpensive. How long before there are stalking cases or civil suits in which the victim's web cam is enabled? The "Trojan Defense" (ie, the malware did it, not me) has been around for a while, so how long before we can expect to see other devices (web cams, in particular) being recognized as a source for illicit images, or somehow involved in other issues or crimes? Not long afterward, we're going to hear, "hey, I didn't do it...it was the virus."
So the novel approach comes in when you start to consider, what are the artifacts of the use of a web cam on a system? How do you tell if a web cam (or any other device) has been used, and more importantly, how do you address attribution? Was it the local user that started the web cam, was it malware, or was the web cam activated remotely by a legitimate user (or, activated remotely by someone with access to a legitimate user account)?
So what happens when this sort of issue lands on an analysts desk? This may be an example of one of those new, we haven't seen this kind of thing before issues. There very likely isn't a public repository of data, artifacts, and analysis plans somewhere, is there? Maybe there's a private one, but how does that help folks who don't have access to it, particularly if it's only accessible by a very small group of individuals? Where do folks go to start developing answers to questions like those in the previous paragraph, and once they determine those answers, what do they then do with the information? Is it available to the next analyst who runs into this sort of thing, or do we have to start all over again?
There's a good deal of research that goes on in a number of areas within the IR/DF community...file carving, for example. However, a lot of new issues that land on an analyst's desk are just that...new. New issue, new device, new operating system. Most of use are intimately familiar with the fact that the automated analysis approach we used in XP systems was, in some cases, broken when we got our first Vista system in for analysis. Oh, and hey...guess what? Windows 7 is out...in some ways, we need to start all over again.
So what happens when something new...some new issue, operating system, or application...comes out? Sometimes, someone puts forth the effort to conduct analysis and document the process and the findings, and then make that available, like what was done with Limewire examinations, for example.
Speaking of artifacts, I've posted before about browser stuff to look at beyond the traditional TypedURLs key and index.dat files. Well, as it happens, there appears to be data that indicates that it's not so much the browser that's being targeted...it's the stuff running in support of the browser. Brian Krebs posted recently about BLADE (no, not this Blade); the point of the post is that it isn't the browser that's the issue, it's the stuff running behind the scenes; the plugins, the add-ons, etc.
Consider this...someone gets an email or IM with a link to a PDF or other file format, and they click on it. Their default browser is opened, but it isn't the browser that's popped...it's the old/unpatched version of Adobe Reader (or some other unpatched add-on) that results in the system being compromised. Ultimately, a compromise like this could lead to significant losses. So while there will be artifacts in the browser history, this tells us that we need to look beyond that artifact if we're going to attribute an incident to the correct root cause; finding the first artifact and attributing the issue to a browser drive-by may not be correct, and in the long run, may hurt both your employer's reputation, and most certainly your customer. What happens if your customer reads your report and updates or changes the browser used throughout their infrastructure, only to get hit again?
Here's an example; I recently found this article discussing an issue with web cams on laptops issued to high school students having been allegedly turned on remotely and used to monitor students in their homes. More and more laptops are available with built-in web cams, and web cams are relatively inexpensive. How long before there are stalking cases or civil suits in which the victim's web cam is enabled? The "Trojan Defense" (ie, the malware did it, not me) has been around for a while, so how long before we can expect to see other devices (web cams, in particular) being recognized as a source for illicit images, or somehow involved in other issues or crimes? Not long afterward, we're going to hear, "hey, I didn't do it...it was the virus."
So the novel approach comes in when you start to consider, what are the artifacts of the use of a web cam on a system? How do you tell if a web cam (or any other device) has been used, and more importantly, how do you address attribution? Was it the local user that started the web cam, was it malware, or was the web cam activated remotely by a legitimate user (or, activated remotely by someone with access to a legitimate user account)?
So what happens when this sort of issue lands on an analysts desk? This may be an example of one of those new, we haven't seen this kind of thing before issues. There very likely isn't a public repository of data, artifacts, and analysis plans somewhere, is there? Maybe there's a private one, but how does that help folks who don't have access to it, particularly if it's only accessible by a very small group of individuals? Where do folks go to start developing answers to questions like those in the previous paragraph, and once they determine those answers, what do they then do with the information? Is it available to the next analyst who runs into this sort of thing, or do we have to start all over again?
There's a good deal of research that goes on in a number of areas within the IR/DF community...file carving, for example. However, a lot of new issues that land on an analyst's desk are just that...new. New issue, new device, new operating system. Most of use are intimately familiar with the fact that the automated analysis approach we used in XP systems was, in some cases, broken when we got our first Vista system in for analysis. Oh, and hey...guess what? Windows 7 is out...in some ways, we need to start all over again.
So what happens when something new...some new issue, operating system, or application...comes out? Sometimes, someone puts forth the effort to conduct analysis and document the process and the findings, and then make that available, like what was done with Limewire examinations, for example.
Speaking of artifacts, I've posted before about browser stuff to look at beyond the traditional TypedURLs key and index.dat files. Well, as it happens, there appears to be data that indicates that it's not so much the browser that's being targeted...it's the stuff running in support of the browser. Brian Krebs posted recently about BLADE (no, not this Blade); the point of the post is that it isn't the browser that's the issue, it's the stuff running behind the scenes; the plugins, the add-ons, etc.
Consider this...someone gets an email or IM with a link to a PDF or other file format, and they click on it. Their default browser is opened, but it isn't the browser that's popped...it's the old/unpatched version of Adobe Reader (or some other unpatched add-on) that results in the system being compromised. Ultimately, a compromise like this could lead to significant losses. So while there will be artifacts in the browser history, this tells us that we need to look beyond that artifact if we're going to attribute an incident to the correct root cause; finding the first artifact and attributing the issue to a browser drive-by may not be correct, and in the long run, may hurt both your employer's reputation, and most certainly your customer. What happens if your customer reads your report and updates or changes the browser used throughout their infrastructure, only to get hit again?