Is anyone doing timeline analysis??
Apparently, someone is...the Illustrious Don Weber, the inspiration behind the ITB, to be specific. In a recent SecRipcord blog post, he talks about finding the details of a Hydraq infection via timeline creation and analysis.
In his post, Don also illustrates some information from a malicious service that includes a ServiceDllUnloadOnStop value. I hadn't seen this value before, and it appears that Geoff Chappell has a very detailed explanation of that value, as well as some others that are also part of the service keys. This can add a good deal of context to the information, particularly since this isn't often seen in legitimate Windows services. Sometimes searching or sorting by service Registry key LastWrite times isn't all that fruitful, as many seem to be updated when the system boots. So add something else to your "what's unusual or suspicious" checks for services...lack of descriptions, apparently random names, and some of these values.
Don then goes on to talk about what an APT-style manual compromise "looks like" via timeline analysis. Don includes the contents of a Task Scheduler log file in his timeline, and also shows what would appear to be a remote intruder interacting with the system via a remote shell...running native tools allows the intruder to conduct recon without installing additional tools. After all, if the system already has everything you need on it...nbtstat, net commands, etc., why deposit other tools on the system that will essentially provide the same information?
What Don's posts illustrate are great examples of the immense value of timeline analysis, and how it can be used to provide a greater level of confidence in, as well as context to, your data.
Addendum: I had a conversation via IM with Chris yesterday...with over 2 feet of snow, what else am I going to do, right? We were exchanging ideas about timeline analysis and how things could be represented graphically for analysis purposes, particularly give the nature of the data (LOTS of it) and the nature of malware and intrusions (LFO). I think we came up with some pretty good ideas, and there's still some thinking and looking around to do...the problem is that neither one of us is a graphics programmer, so there's going to be a good deal of trial and error using currently available tools. We'll just have to see how that goes.
I think that the major obstacle to moving forward is going to be a lack of a standard. While I applaud the work that Don's done and admire his initiative and sense of innovation, looking at his posts, it's clear that he's decided to sort of take things in his own direction. Don't get me wrong...there's nothing wrong with that at all. Where it does come into play is that if there's a particular next step tool that relies on a particular format or structure for data, then it's going to be difficult to transition other 'branches' to that tool.
Log2timeline is another, more comprehensive framework for developing timelines, and great piece of work from Kristinn. It's very automated, and uses some of the code in my tools, and provides other output formats in addition to TLN.
So, overall, I'm seeing that there's quite a bit of interest in helping responders, analysts, and examiners move beyond the manual spreadsheet approach to timeline analysis, but perhaps its time to come together and find some common ground that we can all stand on.
In his post, Don also illustrates some information from a malicious service that includes a ServiceDllUnloadOnStop value. I hadn't seen this value before, and it appears that Geoff Chappell has a very detailed explanation of that value, as well as some others that are also part of the service keys. This can add a good deal of context to the information, particularly since this isn't often seen in legitimate Windows services. Sometimes searching or sorting by service Registry key LastWrite times isn't all that fruitful, as many seem to be updated when the system boots. So add something else to your "what's unusual or suspicious" checks for services...lack of descriptions, apparently random names, and some of these values.
Don then goes on to talk about what an APT-style manual compromise "looks like" via timeline analysis. Don includes the contents of a Task Scheduler log file in his timeline, and also shows what would appear to be a remote intruder interacting with the system via a remote shell...running native tools allows the intruder to conduct recon without installing additional tools. After all, if the system already has everything you need on it...nbtstat, net commands, etc., why deposit other tools on the system that will essentially provide the same information?
What Don's posts illustrate are great examples of the immense value of timeline analysis, and how it can be used to provide a greater level of confidence in, as well as context to, your data.
Addendum: I had a conversation via IM with Chris yesterday...with over 2 feet of snow, what else am I going to do, right? We were exchanging ideas about timeline analysis and how things could be represented graphically for analysis purposes, particularly give the nature of the data (LOTS of it) and the nature of malware and intrusions (LFO). I think we came up with some pretty good ideas, and there's still some thinking and looking around to do...the problem is that neither one of us is a graphics programmer, so there's going to be a good deal of trial and error using currently available tools. We'll just have to see how that goes.
I think that the major obstacle to moving forward is going to be a lack of a standard. While I applaud the work that Don's done and admire his initiative and sense of innovation, looking at his posts, it's clear that he's decided to sort of take things in his own direction. Don't get me wrong...there's nothing wrong with that at all. Where it does come into play is that if there's a particular next step tool that relies on a particular format or structure for data, then it's going to be difficult to transition other 'branches' to that tool.
Log2timeline is another, more comprehensive framework for developing timelines, and great piece of work from Kristinn. It's very automated, and uses some of the code in my tools, and provides other output formats in addition to TLN.
So, overall, I'm seeing that there's quite a bit of interest in helping responders, analysts, and examiners move beyond the manual spreadsheet approach to timeline analysis, but perhaps its time to come together and find some common ground that we can all stand on.