Building Timelines – Thought Process Behind It
Saturday, September 17, 2011
Timelines are a valuable technique to have at your disposal when processing a case. They can reveal activity on a system that may not be readily apparent or show the lack of certain activity helping rule theories out. Timelines can be used on case ranging from human resource policy violations to financial investigations to malware infections to even auditing. Before the technique can be used one must first know how to build them.
This is the first post in my two part series on building timelines. Part 1 discusses the thought process behind building timelines while Part 2 demonstrates different tools and methods to build them.
Things to Consider
There are two well known approaches to building timelines. On the one hand is the minimalist approach; only include the exact data needed. On the other hand is the kitchen sink approach; include all data that is available. My approach falls somewhere in the middle. I put the data I definitely need into timelines and some data I think I may need. The things I take into consideration when selecting data is:
- Examination’s Purpose
- Identify Data Needed
- Understand Tools’ Capabilities
- Tailor Data List to System
Examination’s Purpose
The first thing I consider when building timelines is what is the examination’s purpose. Every case should have a specific purpose or purposes the DF analyst needs to accomplish. For example, did an employee violate an acceptable usage policy, how was a system infected, how long was a web server compromised, or locate all Word documents on a hard drive?
Identify Data Needed
The next area to consider is what data is needed to accomplish the purpose(s). This is where I make a judgment about the artifacts I think will contain relevant information and the artifacts that could contain information of interest. A few potential data sources and their artifacts are:
- Hard drives: file system, web browsing history, registry hives, Windows short cut files, firewall logs, restore points, volume shadow copies, prefetch files, email files, or Office documents
- Memory: network connections, processes, loaded dlls, or loaded drivers
- Network shares: email files (including archives), office documents, or PDFs
- Network logs: firewall logs, IDS logs, proxy server logs, web server logs, print/file server logs, or authentication server logs
I take into account the case type and examination's purpose(s) when picking the artifacts I want. To illustrate the affect case type has on my choice I'll use a malware infected system and Internet usage policy violation as examples. The malware infected system would definitely be interested in the artifacts showing program execution, firewall logs, antivirus logs, and file system metadata. The additional items I'd throw into a timeline would be the user's web browsing history, removable media usage, and registry keys last write times since those artifacts might show information about the initial infection vector and persistence mechanism. For an Internet usage policy violation I'd only include the file system metadata and web browsing history since my initial interest is limited to the person’s web browsing activities.
The examination purpose(s) will point to other artifacts of interest. Let's say if the Internet usage policy violation's purpose was to determine if an employee was surfing pornographic websites and if they were saving pornographic images to the company issued thumb drive. In addition to file system metadata and web history, I’d now want to include artifacts showing recent user activity such as Windows shortcut files or the userassist registry key.
I try to find a balance between the data I know I'll need and the data that may contain relevant information. I don't want to put everything into the timeline (kitchen sink approach) but I'm trying to avoid frequently adding more data to the timeline (minimalist approach). Finding a balance between the two lets me create one main timeline with the ability to create mini timelines using spreadsheet filters. Making the call about what data to select is not going to be perfect initially. Some data may not contain any information related to the examination while other left out data is going to be important. The important thing to remember is building timelines is a process. Data can be added or removed at later times which means thinking about data to incorporate into a timeline should occur continuously. This is especially true as more things are learned while processing the case.
Understand Tools’ Capabilities
After the examination’s purpose(s) are understood and the potential data required to accomplish it is identified then the next consideration is understanding my tools’ capabilities. Timeline tools provide different support for the artifacts they can parse. I review the items I want to put into my timeline against the artifacts supported by my tools to identify what in my list I can’t parse. If any items are not supported then I decide if the item is really needed and is there a different tool that will work. Another benefit to making this comparison is that helps to identify artifacts I might not have thought about. The picture below shows some artifacts supported by the tools I’ll discuss in the post Building Timelines – Tools Usage.
Some may be wondering why I don’t think about the tools’ capability before I consider the data I need to accomplish the examination’s purpose(s). My reason is because I don’t want to restrict myself to the capability provided by my tools. For example, none of my commercial tools are able to create the timelines I’m talking about. If I based my decision on how to accomplish what I need to do solely on my commercial tools then timelines wouldn’t even be an option. I’d rather first identify the data I want to examine then determine if my tools can parse it. This helps me see the shortcomings in my tools and lets me find other tools to get the job done.
Tailor Data List to System
At this point in the thought process potential data has been identified to put into a timeline. A timeline could be built now even though the artifact list is pretty broad. My preference is to tailor the list to the system under examination. To see what I mean I’ll discuss a common occurrence I encounter when building timelines which is including a user account’s web browser history. Based on my tools supported artifacts, the web browsing artifacts could be from: Google Chrome, Firefox 2, Firefox 3, Internet Explorer, Opera, or Safari. Is it really necessary to have my tools search for all these artifacts? If the system only has Internet Explorer (IE) installed then why spend time looking for the other items. If the same system has 12 loaded user profiles but the examination is only looking at one user account then why parse the IE history for all 12 user profiles? To minimize the time building timelines and reduce the amount of data in them the artifact list needs to be tailored to the system. A few examination checks will be enough narrow down the list. The exact checks will vary by case but one step that holds across all cases is obtaining information about the operating system (OS) and its configuration.
I previously discussed this examination step in the post Obtaining Information about the Operating System and it covers the three different information categories impacting the artifact list. The first category is the General Operating System Information and it shows the operating system version. The version will dictate whether certain artifacts are actually in the system since some are OS specific. The second category is the User Account Information which shows the user accounts (local accounts as well as accounts that logged on) associated with the system. When building a timeline it’s important to narrow the focus for the user accounts under examination; this is even more so on computers shared by multiple people. Identifying the user accounts can be done by confirming the account assigned to person, looking at the user account names, or looking at when the user accounts were last used. The third and final category is the Software Information. The category shows information about programs installed and executed on the system. The software on a system will dictate what artifacts are present. Quickly review the artifacts supported by my tools (picture above) to see how many are associated with specific applications. This one examination step can take a broad list and make it more focused to the environment where the artifacts are coming from.
Select Data for the Timeline
I reflect on the things I considered when coming up with a plan on how to build the timeline The examination's purpose outlined what I need to accomplish, potential data I want to examine was identified, my tool's capabilities were reviewed to see what artifacts can be parsed, and then checks were made to tailor the artifact list to the system I’m looking at. The list I’m left with afterwards is what gets incorporated into my first timeline. Working my way through this thought process reduces the amount of artifacts going into a timeline; thus reducing the amount of data I’ll need to weed through.
Thought Process Example
The thought process I described may appear to be pretty extensive but that is really not the case. The length is because I wanted to do a good job explaining it since I feel it’s important. The process only takes a little time to complete and most of it is already done when processing a case. Follow along a DF analyst on a hypothetic case to see how the thought process works in coming up with a plan to build the timeline. Please note, the case only mentions a few artifacts to get my point across but an actual case may use more.
Friend: “Damm … Some program keeps saying I’m infected and won’t go away. Let me call the DF analyst since he does something with computers for a living. He can fix it”
Phone rings and DF analyst picks up
Friend: “DF analyst … Some program keeps saying I’m infected with viruses and blocks me from doing anything.”
DF analyst: “Do you have any security programs installed such as antivirus software, and if so is that what you’re seeing”
Friend: “I think I have Norton installed but I’ve never seen this program before. Wait … hold on … Oh man, now pornographic sites are popping up on my screen”
DF analyst: “Yup, sounds like you’re infected”
Friend: “I know I’m infected. That’s what I told you this program has been telling me”
DF analyst: “Umm .. The program saying you are infected is actually the virus.”
Friend: “Hmmmm….”
DF analyst: “Just power down the computer and I’ll take a look at later today.”
Computer powering down
DF analyst: “When did you start noticing the program?”
Friend: “Today when I was using the computer.”
DF analyst: “What were you doing?”
Friend: “Stuff… Surfing the web, checking email, and working on some documents. I really need my computer. Can you just get rid of the virus and let me know if my wife or kids did this to my computer?”
Later that day
DF analyst has the system back in the lab. He thinks about what he needs to do which is to remove the malware from the system and determine how it got there. The potential data list he came up with to accomplish those tasks was: known malware files, system’s autostart locations, programs executed (prefetch, userassist, and muicache), file system metadata, registry hives, event logs, web browser history, AV logs, and restore points/volume shadow copies.
Wanting to know what launches when his friend logs onto the computer the DF analyst uses the Sysinternals autorun utility in offline mode to find out. Sitting in one run key was an executable with a folder path to his friend’s user profile. A Google search using the file’s MD5 hash confirmed the file was malicious and his friend’s system was infected. DF analyst decided to leverage a timeline to see what else was dropped onto the system and what caused it to get dropped in the first place.
DF analyst pulls out his reference showing the various artifacts supported by his timeline tools. He confirms that all the potential data he identified is supported. Then he moves on to his first examination step which is examining the hard drive’s layout. Two partitions, one is the Dell recovery formatted with Fat32 while the other is for the operating system formatted with NTFS. DF analysts just added NTFS artifacts ($MFT) to his potential data list. To get a better idea about the system he uses Regripper to rip out the general operating system information. Things he learned from the Regripper reports and the decisions he made based on the information:
- OS version is XP (restore points are in play while shadow copies are out. Need to parse event logs with evt file extensions)
- Three user accounts were used in the past week (initial focus for certain artifacts will be from friend’s user account since malware was located there. The two other user accounts may be analyzed depending on what the file system metadata shows)
- Internet Explorer was only web browser installed (all other web browser artifacts won’t be parsed at this time)
- Kaspersky antivirus software was installed (tools don’t support this log format. AV log will be reviewed and entries will be put into the timeline manually)
DF analyst performs a few other checks. Prefetch folder has files in it and his friend’s user account recycle bin has numerous files in it. Both were added to the timeline artifact list. The final list contains items from the system and one user account. The system data has: prefetch files, event logs (evt), system restore points, Master file Table. The artifacts from one user account are: userassist registry key, muicache registry key, IE history, and the Recycle bin contents. DF analyst is ready to build his timeline …. Stay tuned for the post "Building Timelines – Tools Usage" to see one possbile way to do it.
I'd like to hear feedback about how other's approach building timelines; especially if it's different than what I wrote. It's helpful to see how other analysts are building timelines.
This is the first post in my two part series on building timelines. Part 1 discusses the thought process behind building timelines while Part 2 demonstrates different tools and methods to build them.
Things to Consider
There are two well known approaches to building timelines. On the one hand is the minimalist approach; only include the exact data needed. On the other hand is the kitchen sink approach; include all data that is available. My approach falls somewhere in the middle. I put the data I definitely need into timelines and some data I think I may need. The things I take into consideration when selecting data is:
- Examination’s Purpose
- Identify Data Needed
- Understand Tools’ Capabilities
- Tailor Data List to System
Examination’s Purpose
The first thing I consider when building timelines is what is the examination’s purpose. Every case should have a specific purpose or purposes the DF analyst needs to accomplish. For example, did an employee violate an acceptable usage policy, how was a system infected, how long was a web server compromised, or locate all Word documents on a hard drive?
Identify Data Needed
The next area to consider is what data is needed to accomplish the purpose(s). This is where I make a judgment about the artifacts I think will contain relevant information and the artifacts that could contain information of interest. A few potential data sources and their artifacts are:
- Hard drives: file system, web browsing history, registry hives, Windows short cut files, firewall logs, restore points, volume shadow copies, prefetch files, email files, or Office documents
- Memory: network connections, processes, loaded dlls, or loaded drivers
- Network shares: email files (including archives), office documents, or PDFs
- Network logs: firewall logs, IDS logs, proxy server logs, web server logs, print/file server logs, or authentication server logs
I take into account the case type and examination's purpose(s) when picking the artifacts I want. To illustrate the affect case type has on my choice I'll use a malware infected system and Internet usage policy violation as examples. The malware infected system would definitely be interested in the artifacts showing program execution, firewall logs, antivirus logs, and file system metadata. The additional items I'd throw into a timeline would be the user's web browsing history, removable media usage, and registry keys last write times since those artifacts might show information about the initial infection vector and persistence mechanism. For an Internet usage policy violation I'd only include the file system metadata and web browsing history since my initial interest is limited to the person’s web browsing activities.
The examination purpose(s) will point to other artifacts of interest. Let's say if the Internet usage policy violation's purpose was to determine if an employee was surfing pornographic websites and if they were saving pornographic images to the company issued thumb drive. In addition to file system metadata and web history, I’d now want to include artifacts showing recent user activity such as Windows shortcut files or the userassist registry key.
I try to find a balance between the data I know I'll need and the data that may contain relevant information. I don't want to put everything into the timeline (kitchen sink approach) but I'm trying to avoid frequently adding more data to the timeline (minimalist approach). Finding a balance between the two lets me create one main timeline with the ability to create mini timelines using spreadsheet filters. Making the call about what data to select is not going to be perfect initially. Some data may not contain any information related to the examination while other left out data is going to be important. The important thing to remember is building timelines is a process. Data can be added or removed at later times which means thinking about data to incorporate into a timeline should occur continuously. This is especially true as more things are learned while processing the case.
Understand Tools’ Capabilities
After the examination’s purpose(s) are understood and the potential data required to accomplish it is identified then the next consideration is understanding my tools’ capabilities. Timeline tools provide different support for the artifacts they can parse. I review the items I want to put into my timeline against the artifacts supported by my tools to identify what in my list I can’t parse. If any items are not supported then I decide if the item is really needed and is there a different tool that will work. Another benefit to making this comparison is that helps to identify artifacts I might not have thought about. The picture below shows some artifacts supported by the tools I’ll discuss in the post Building Timelines – Tools Usage.
Some may be wondering why I don’t think about the tools’ capability before I consider the data I need to accomplish the examination’s purpose(s). My reason is because I don’t want to restrict myself to the capability provided by my tools. For example, none of my commercial tools are able to create the timelines I’m talking about. If I based my decision on how to accomplish what I need to do solely on my commercial tools then timelines wouldn’t even be an option. I’d rather first identify the data I want to examine then determine if my tools can parse it. This helps me see the shortcomings in my tools and lets me find other tools to get the job done.
Tailor Data List to System
At this point in the thought process potential data has been identified to put into a timeline. A timeline could be built now even though the artifact list is pretty broad. My preference is to tailor the list to the system under examination. To see what I mean I’ll discuss a common occurrence I encounter when building timelines which is including a user account’s web browser history. Based on my tools supported artifacts, the web browsing artifacts could be from: Google Chrome, Firefox 2, Firefox 3, Internet Explorer, Opera, or Safari. Is it really necessary to have my tools search for all these artifacts? If the system only has Internet Explorer (IE) installed then why spend time looking for the other items. If the same system has 12 loaded user profiles but the examination is only looking at one user account then why parse the IE history for all 12 user profiles? To minimize the time building timelines and reduce the amount of data in them the artifact list needs to be tailored to the system. A few examination checks will be enough narrow down the list. The exact checks will vary by case but one step that holds across all cases is obtaining information about the operating system (OS) and its configuration.
I previously discussed this examination step in the post Obtaining Information about the Operating System and it covers the three different information categories impacting the artifact list. The first category is the General Operating System Information and it shows the operating system version. The version will dictate whether certain artifacts are actually in the system since some are OS specific. The second category is the User Account Information which shows the user accounts (local accounts as well as accounts that logged on) associated with the system. When building a timeline it’s important to narrow the focus for the user accounts under examination; this is even more so on computers shared by multiple people. Identifying the user accounts can be done by confirming the account assigned to person, looking at the user account names, or looking at when the user accounts were last used. The third and final category is the Software Information. The category shows information about programs installed and executed on the system. The software on a system will dictate what artifacts are present. Quickly review the artifacts supported by my tools (picture above) to see how many are associated with specific applications. This one examination step can take a broad list and make it more focused to the environment where the artifacts are coming from.
Select Data for the Timeline
I reflect on the things I considered when coming up with a plan on how to build the timeline The examination's purpose outlined what I need to accomplish, potential data I want to examine was identified, my tool's capabilities were reviewed to see what artifacts can be parsed, and then checks were made to tailor the artifact list to the system I’m looking at. The list I’m left with afterwards is what gets incorporated into my first timeline. Working my way through this thought process reduces the amount of artifacts going into a timeline; thus reducing the amount of data I’ll need to weed through.
Thought Process Example
The thought process I described may appear to be pretty extensive but that is really not the case. The length is because I wanted to do a good job explaining it since I feel it’s important. The process only takes a little time to complete and most of it is already done when processing a case. Follow along a DF analyst on a hypothetic case to see how the thought process works in coming up with a plan to build the timeline. Please note, the case only mentions a few artifacts to get my point across but an actual case may use more.
Friend: “Damm … Some program keeps saying I’m infected and won’t go away. Let me call the DF analyst since he does something with computers for a living. He can fix it”
Phone rings and DF analyst picks up
Friend: “DF analyst … Some program keeps saying I’m infected with viruses and blocks me from doing anything.”
DF analyst: “Do you have any security programs installed such as antivirus software, and if so is that what you’re seeing”
Friend: “I think I have Norton installed but I’ve never seen this program before. Wait … hold on … Oh man, now pornographic sites are popping up on my screen”
DF analyst: “Yup, sounds like you’re infected”
Friend: “I know I’m infected. That’s what I told you this program has been telling me”
DF analyst: “Umm .. The program saying you are infected is actually the virus.”
Friend: “Hmmmm….”
DF analyst: “Just power down the computer and I’ll take a look at later today.”
Computer powering down
DF analyst: “When did you start noticing the program?”
Friend: “Today when I was using the computer.”
DF analyst: “What were you doing?”
Friend: “Stuff… Surfing the web, checking email, and working on some documents. I really need my computer. Can you just get rid of the virus and let me know if my wife or kids did this to my computer?”
Later that day
DF analyst has the system back in the lab. He thinks about what he needs to do which is to remove the malware from the system and determine how it got there. The potential data list he came up with to accomplish those tasks was: known malware files, system’s autostart locations, programs executed (prefetch, userassist, and muicache), file system metadata, registry hives, event logs, web browser history, AV logs, and restore points/volume shadow copies.
Wanting to know what launches when his friend logs onto the computer the DF analyst uses the Sysinternals autorun utility in offline mode to find out. Sitting in one run key was an executable with a folder path to his friend’s user profile. A Google search using the file’s MD5 hash confirmed the file was malicious and his friend’s system was infected. DF analyst decided to leverage a timeline to see what else was dropped onto the system and what caused it to get dropped in the first place.
DF analyst pulls out his reference showing the various artifacts supported by his timeline tools. He confirms that all the potential data he identified is supported. Then he moves on to his first examination step which is examining the hard drive’s layout. Two partitions, one is the Dell recovery formatted with Fat32 while the other is for the operating system formatted with NTFS. DF analysts just added NTFS artifacts ($MFT) to his potential data list. To get a better idea about the system he uses Regripper to rip out the general operating system information. Things he learned from the Regripper reports and the decisions he made based on the information:
- OS version is XP (restore points are in play while shadow copies are out. Need to parse event logs with evt file extensions)
- Three user accounts were used in the past week (initial focus for certain artifacts will be from friend’s user account since malware was located there. The two other user accounts may be analyzed depending on what the file system metadata shows)
- Internet Explorer was only web browser installed (all other web browser artifacts won’t be parsed at this time)
- Kaspersky antivirus software was installed (tools don’t support this log format. AV log will be reviewed and entries will be put into the timeline manually)
DF analyst performs a few other checks. Prefetch folder has files in it and his friend’s user account recycle bin has numerous files in it. Both were added to the timeline artifact list. The final list contains items from the system and one user account. The system data has: prefetch files, event logs (evt), system restore points, Master file Table. The artifacts from one user account are: userassist registry key, muicache registry key, IE history, and the Recycle bin contents. DF analyst is ready to build his timeline …. Stay tuned for the post "Building Timelines – Tools Usage" to see one possbile way to do it.
I'd like to hear feedback about how other's approach building timelines; especially if it's different than what I wrote. It's helpful to see how other analysts are building timelines.
Labels:
timeline
Posts
