Triaging My Way
Tuesday, May 17, 2011
Your onsite performing a collection or you are in your lab when a computer is given to you and you don’t have a lot of time to answer a few initial questions. How would you quickly determine someone’s activity on the computer? What pictures were viewed, programs ran, files accessed, or removable devices used? Quickly assessing the computer will not only provide information to answer these questions but will also reveal relevant data storage locations for an investigation. This post describes a process – including tools usage – where a few initial questions can be answered in a matter of minutes by examining the user activity on a computer.
Approaching the Triage
I know I promised to write about how to answer questions in less than two minutes by examining user activity on a computer. Before I dive into the land of ones and zeros I wanted to take a step back to talk about the thought process of how to approach the triage. Goals need to be established and a plan needs to be developed on how those goals can be obtained. To accomplish this, the first three questions of the Alexiou Principle can be used:
* What question are you trying to answer?
* What data do you need to answer the question?
* How do you extract that data?
The Alexiou Principle is very versatile since it can be to create analysis design plans, assist with DFIR training (as I described in the Forensicator Readiness post), and guide the thought process for triaging. The first Alexiou Principle question is what question you are trying to answer and this question is pretty self explanatory. As it relates to triage, what are the initial questions to determine if “something” is relevant to the digital forensic examination? The initial questions will vary based on the type of DFIR case and customer needs but the opening paragraph provided a few example questions.
The second Alexiou Principle question is what data do you need to answer the question? The data not only includes data sources such as computers, servers, and people but it also includes what information in those data sources can help answer the questions. Take for example the question was someone accessing the jIIr blog and the only data source available is the person’s computer. What data in the computer can help determine if the person visited my blog? A few areas to check could be the installed software (what web browser are installed), web browser artifacts (history, cookies, or favorites/bookmarks), and maybe the TypedURLs key in the user account’s NTUSER.DAT hive.
The third Alexiou Principle question is how do you extract that data? The tools selected to perform the triage need to be able to extract the data that is required to answer the initial questions. This means the selection of tools should not occur before the data is identified since this may force people to have to work within the confines of the tools. Instead, the selection of tools should be one of the last things completed since the tools to use will be dependent on the goal(s) of the assessment. I wanted to mention this point because I’ve seen numerous times where discussions are started with “should I use this tool” when the discussion should start with this is what I’m trying/need to accomplish.
Triaging User Activity in Under Two Minutes
Now that I’ve explained the thought process of how to approach the assessment of user activity on a computer I’ll walk through an issue I had at one point. I work in corporate environments and as expected the majority of the networks are running Windows domains. A Windows domain can have a significant impact on digital forensic examination because the computer being collected may not contain all of the data relevant to an investigation. The IT department may have assigned home folders to employees using company computers to make it easier for the IT department to back up people’s files. If an organization is using home folders then most likely the organization is encouraging users to store all of their data in their home folders instead of the computers’ My Documents folders. In addition to home folders, the person may be accessing and storing data in network shares. One of the initial questions I need to answer in this type of environment is what data sources - besides the person’s computer – do I need to collect?
Two options to determine what data sources - besides the person’s computer – need to be collected is speaking with the IT department or quickly triaging the computer. IT departments are not known for their great documentation skills so the better option is to triage the computer to find the answer. What data is needed to determine the network shares a person accessed? The data to answer the question could be located in the person’s activity on the computer. Three locations containing user activity are the registry, system restore points/volume shadow copies’ registry files, and the link files in the user account’s profile. For additional references on the evidentiary value of the registry check out the book Windows Registry Forensics while the Digitial Forensic Search custom Google query for link files can be used to learn more about them.
How do you extract data stored in registry and link files? I took into account the following for my tool selection: had to extract the data, had to be fast, had to be command line tools (you’ll see why), and my preference was for tools already in my toolbox. Harlan Carvey’s Regripper was chosen to parse the registry files, Harlan’s RipXP (included in the Regripper downloaded) was chosen to parse the registry files in system restore points, a modified version of Harlan’s lslnk.pl script to parse the link files and FTK Imager to mount the hard drive/image.
The example I’m using is to determine the network shares accessed but keep in mind this will work for other types of user activity since the registry and link files store the information. I promised to write about how to answer a few initial questions in less than two minutes by assessing the user activity on the computer. Here goes ………..
Mount the Image/Hard Drive
The situation will dictate if the computer’s hard drive will be examined using a write blocker or if the forensic image of the computer’s hard drive will be examined. The triage will work the same regardless if the hard drive or image is being examined. When quickly triaging a system my preference is to parse the data of interest where it’s located instead of copying the data to my forensic computer. The image/hard drive has to be mounted to the forensic computer in order for the registry and link files to be parsed in their storage locations and this can be accomplished using FTK Imager version 3.0 with the “File System / Read Only” mount option (allows access to system restore points). F:\[root]\ is the path to the root of the volume I’m examining and the commands below will reflect the path.
User Activity Stored in Registry
A user account’s NTUSER.DAT registry hive stores configuration information and the user account activity on the system. A quick way to identify registry keys of interest (in addition to the Windows Registry Forensics book) is to reference registry checklists like AccessData’s Registry Quick Find Chart or review the Regripper’s plugin files. The three registry keys of interest are: Map Network Drive MRU since it lists the recently mapped network drives, MountPoints2 since it lists devices accessed, and RunMRU since one way to access network shares is using the run dialog box. Regripper has plugins to parse all three registry keys and the commands for running the command-line version of Regripper with the output being redirected to a text file is below.
rip.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -p mndmru >> rip-drives.txt
rip.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -p mp2 >> rip-drives.txt
rip.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -p runmru >> rip-drives.txt
The first command uses -p mndmru to specify the plugin for the Map Network Drive MRU registry key. The output of this command identifies four network shares that were mapped to the user account of interest as shown below.
Map Network Drive MRU
Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
LastWrite Time Sat May 14 18:13:18 2011 (UTC)
MRUList = dcba
c \\192.168.1.80\Map Drive 2
a \\192.168.1.80\Map Drive D
b \\192.168.1.80\Map Drive 1
d \\192.168.1.80\Map Drive 3
The second command uses -p mp2 to specify the plugin for the MountPoints2 registry key. The output of this command also identifies the same four network shares. A portion of the output is shown below.
MountPoints2
Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
LastWrite Time Sat May 14 18:19:16 2011 (UTC)
Remote Drives:
Sat May 14 18:13:18 2011 (UTC)
##192.168.1.80#Map Drive 3
Sat May 14 18:04:37 2011 (UTC)
##192.168.1.80#Map Drive 2
Sat May 14 17:59:27 2011 (UTC)
##192.168.1.80#Map Drive 1
Sat May 14 17:56:10 2011 (UTC)
##192.168.1.80#Map Drive D
The third and last command uses -p runmru to specify the plugin for the RunMRU registry key. The output of this command shows the same device with the four network shares (192.168.1.80) as well as a new device (192.168.2.50). The output doesn’t show any network shares being accessed but it does attempts were made to access the devices in a method that will display the network shares (\\IP-Address). The runmru output is shown below.
RunMru
Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
LastWrite Time Sat May 14 18:22:00 2011 (UTC)
MRUList = bca
a cmd\1
b \\192.168.2.50\1
c \\192.168.1.80\1
User Activity Stored in System Restore Points (or Volume Shadow Copies) Registry Files
Windows system restore uses restore points to return system files and settings to an earlier point in time for computers running Windows 2000 or XP. Windows Vista and 7 uses volume shadow copies instead of restore points. Registry files covering different points of time in the past are located the restore points and volume shadow copies, and these files may contain additional information about user account activity. To parse the registry hives in the volume shadow copies a simple batch file using the command-line version of Regripper can be used. RipXP.exe can be used to parse a key in the current registry hive and the registry hives in the restore points (RipXP.exe parses the current registry hive so the rip.exe commands can be skipped when using RipXP.exe in this triage method). RipXP.exe requires three switches: -r specifies the current registry hive, -d specifies the restore point directory, and –p specifies the plug to use. The commands to parse the three registry keys of interest with the output being redirected to a text file are below.
ripxp.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -d "F:\[root]\System Volume Information\_restore{3F806DB1-464B-46B0-B724-4376EC868222}" -p mndmru >> rip-rp-mndmru.txt
ripxp.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -d "F:\[root]\System Volume Information\_restore{3F806DB1-464B-46B0-B724-4376EC868222}" -p runmru >> rip-rp-runmru.txt
ripxp.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -d "F:\[root]\System Volume Information\_restore{3F806DB1-464B-46B0-B724-4376EC868222}" -p mp2 >> rip-rp-mp2.txt
The output of all three commands will be similar to the Regripper output I showed before with the exception the registry keys in all of the restore points being displayed. I'm only showing a portion of the Map Drive MRU registry key output since it demonstrates how the output will look. As can be seen below, RipXP.exe output first displays the registry data from the current registry hive before the restore point registry data. The current Map Drive MRU key has four mapped network drives while the restore point shown only has three.
RipXP v.20090818
Launched Sat May 14 19:46:12 2011 Z
F:\[root]\Documents and Settings\Administrator\NTUSER.DAT
Map Network Drive MRU
Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
LastWrite Time Sat May 14 18:13:18 2011 (UTC)
MRUList = dcba
c \\192.168.1.80\Map Drive 2
a \\192.168.1.80\Map Drive D
b \\192.168.1.80\Map Drive 1
d \\192.168.1.80\Map Drive 3
----------------------------------------
Restore Point Info
Description : access share files
Type : System CheckPoint
Creation Time : Sat May 14 18:08:38 2011
F:\[root]\System Volume Information\_restore{3F806DB1-464B-46B0-B724-4376EC868222}\RP10\snapshot\_REGISTRY_USER_NTUSER_S-1-5-21-1214440339-1708537768-725345543-500
Map Network Drive MRU
Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
LastWrite Time Sat May 14 18:04:37 2011 (UTC)
MRUList = cba
c \\192.168.1.80\Map Drive 2
a \\192.168.1.80\Map Drive D
b \\192.168.1.80\Map Drive 1
User Activity Stored in Link Files
The registry provides a wealth of information but link files is another location containing information about a user account activity on a computer. A link file is created when a person accesses a file on their computer's hard drive, removable media, or a network share. The link file contains information about the file including its storage location which will show someone accessing network shares. A few locations containing link files are:
Windows XP: C:\Documents and Settings\username\Recent and C:\Documents and Settings\\Application Data\Microsoft\Office\Recent
Windows Vista and 7: C:\Users\username\AppData\Roaming\Microsoft\Windows\Recent and C:\Users\\AppData\Roaming\Microsoft\Office\Recent
One of my requirements for a tool to parse link files was it had to be a command line tool. My reasoning is command-line tools can be used in scripts but more importantly command-line tools can be used in batch files to parse artifacts in volume shadow copies. I couldn't find a tool to meet my needs. Harlan provided the lslnk.pl script in WFA 2nd edition and it displays the information contained in link files. However, lslnk.pl only works against individual files when I needed a tool to parse an entire directory of link files. I'm not a programmer and I don't know Perl but I can use search engines so I decided to try to modified lslnk.pl. The first modification I made was to enable lsnk.pl to parse all of the link files in a directory with the output being in report format. The modified script - lslnk-directory-parse.pl - worked fine but the output wasn't the best for filtering data. I needed the output to display all of the information from a link file on one line so I perform a search I can see all information for a specific link file. I made another change to make the output contain one link file per line in comma delimited format and this resulted in the lslnk-directory-parse2.pl script. Both modified scripts can be found in the Yahoo Win4n6 group's tools folder. The only parameter required by the script is the directory to parse as shown below.
C:\Perl>lslnk-directory-parse2.pl "F:\[root]\Documents and Settings\Administrator\Recent" > lsnk-parse2-output.txt
The output is a comma delimited text file and this means it can be opened in Excel/Calc (to see how to import a text file in Excel check out my posts Reviewing Timelines with Excel or Reviewing Timelines in Calc). Opening the text file at this point will show the information from all of the link files instead of the information specific to the question at hand which is what network shares did an account access. The text file can be searched prior to it being reviewed in Excel/Calc and I use Grep (available in UnxUtils) to do this. There are numerous characteristics to search on such as filenames, directory paths, file extensions, removable media, and network shares. That's right, link files indicate if person accessed a file on a network share. The lslnk-directory-parse2.pl can be redirected to Grep for searching prior to the creation of the text file. The command below shows the lslnk-directory-parse2.pl output being searched for the word "network share" (the binary-file=text switch forces Grep to see the output as text).
C:\Perl>lslnk-directory-parse2.pl "F:\[root]\Documents and Settings\Administrator\Recent" | grep.exe -i --binary-files=text "network share" > lsnk-parse2-output.txt
The output file is still a comma delimited file but the only link files present will be the ones with the phrase "network share" in its information. Reviewing a portion of the output not only shows files accessed on the network shares identified previously with Regripper and RipXP but it also identifies files accessed in a new share (\\192.168.2.50\Share) as shown below.
Summary
The triage extracted data from registry and link files to answer the question of what network shares a person accessed. There was some redundancy in the extracted data since both locations showed the same user account activity (same network share access). However, at times one location may reveal information that is not present in the other. I promised to write about how to answer a few initial questions in less than two minutes by examining the activity on the computer. It took me less than one minute to run Regripper, RipXP, and lslnk-directory-parse2.pl, and to examine the output from the three tools. Within this one minute I was able to determine the network shares a user account had readily available access to (mapped drives) and network shares accessed. The process can be even quicker by creating a batch file with all of the commands since a batch file can just be executed. I answered a question network share access but the process I described should not be limited to only this activity. Different registry keys in combination with information contained in link files can be used to quickly determine someone’s activity on a computer.
Approaching the Triage
I know I promised to write about how to answer questions in less than two minutes by examining user activity on a computer. Before I dive into the land of ones and zeros I wanted to take a step back to talk about the thought process of how to approach the triage. Goals need to be established and a plan needs to be developed on how those goals can be obtained. To accomplish this, the first three questions of the Alexiou Principle can be used:
* What question are you trying to answer?
* What data do you need to answer the question?
* How do you extract that data?
The Alexiou Principle is very versatile since it can be to create analysis design plans, assist with DFIR training (as I described in the Forensicator Readiness post), and guide the thought process for triaging. The first Alexiou Principle question is what question you are trying to answer and this question is pretty self explanatory. As it relates to triage, what are the initial questions to determine if “something” is relevant to the digital forensic examination? The initial questions will vary based on the type of DFIR case and customer needs but the opening paragraph provided a few example questions.
The second Alexiou Principle question is what data do you need to answer the question? The data not only includes data sources such as computers, servers, and people but it also includes what information in those data sources can help answer the questions. Take for example the question was someone accessing the jIIr blog and the only data source available is the person’s computer. What data in the computer can help determine if the person visited my blog? A few areas to check could be the installed software (what web browser are installed), web browser artifacts (history, cookies, or favorites/bookmarks), and maybe the TypedURLs key in the user account’s NTUSER.DAT hive.
The third Alexiou Principle question is how do you extract that data? The tools selected to perform the triage need to be able to extract the data that is required to answer the initial questions. This means the selection of tools should not occur before the data is identified since this may force people to have to work within the confines of the tools. Instead, the selection of tools should be one of the last things completed since the tools to use will be dependent on the goal(s) of the assessment. I wanted to mention this point because I’ve seen numerous times where discussions are started with “should I use this tool” when the discussion should start with this is what I’m trying/need to accomplish.
Triaging User Activity in Under Two Minutes
Now that I’ve explained the thought process of how to approach the assessment of user activity on a computer I’ll walk through an issue I had at one point. I work in corporate environments and as expected the majority of the networks are running Windows domains. A Windows domain can have a significant impact on digital forensic examination because the computer being collected may not contain all of the data relevant to an investigation. The IT department may have assigned home folders to employees using company computers to make it easier for the IT department to back up people’s files. If an organization is using home folders then most likely the organization is encouraging users to store all of their data in their home folders instead of the computers’ My Documents folders. In addition to home folders, the person may be accessing and storing data in network shares. One of the initial questions I need to answer in this type of environment is what data sources - besides the person’s computer – do I need to collect?
Two options to determine what data sources - besides the person’s computer – need to be collected is speaking with the IT department or quickly triaging the computer. IT departments are not known for their great documentation skills so the better option is to triage the computer to find the answer. What data is needed to determine the network shares a person accessed? The data to answer the question could be located in the person’s activity on the computer. Three locations containing user activity are the registry, system restore points/volume shadow copies’ registry files, and the link files in the user account’s profile. For additional references on the evidentiary value of the registry check out the book Windows Registry Forensics while the Digitial Forensic Search custom Google query for link files can be used to learn more about them.
How do you extract data stored in registry and link files? I took into account the following for my tool selection: had to extract the data, had to be fast, had to be command line tools (you’ll see why), and my preference was for tools already in my toolbox. Harlan Carvey’s Regripper was chosen to parse the registry files, Harlan’s RipXP (included in the Regripper downloaded) was chosen to parse the registry files in system restore points, a modified version of Harlan’s lslnk.pl script to parse the link files and FTK Imager to mount the hard drive/image.
The example I’m using is to determine the network shares accessed but keep in mind this will work for other types of user activity since the registry and link files store the information. I promised to write about how to answer a few initial questions in less than two minutes by assessing the user activity on the computer. Here goes ………..
Mount the Image/Hard Drive
The situation will dictate if the computer’s hard drive will be examined using a write blocker or if the forensic image of the computer’s hard drive will be examined. The triage will work the same regardless if the hard drive or image is being examined. When quickly triaging a system my preference is to parse the data of interest where it’s located instead of copying the data to my forensic computer. The image/hard drive has to be mounted to the forensic computer in order for the registry and link files to be parsed in their storage locations and this can be accomplished using FTK Imager version 3.0 with the “File System / Read Only” mount option (allows access to system restore points). F:\[root]\ is the path to the root of the volume I’m examining and the commands below will reflect the path.
User Activity Stored in Registry
A user account’s NTUSER.DAT registry hive stores configuration information and the user account activity on the system. A quick way to identify registry keys of interest (in addition to the Windows Registry Forensics book) is to reference registry checklists like AccessData’s Registry Quick Find Chart or review the Regripper’s plugin files. The three registry keys of interest are: Map Network Drive MRU since it lists the recently mapped network drives, MountPoints2 since it lists devices accessed, and RunMRU since one way to access network shares is using the run dialog box. Regripper has plugins to parse all three registry keys and the commands for running the command-line version of Regripper with the output being redirected to a text file is below.
rip.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -p mndmru >> rip-drives.txt
rip.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -p mp2 >> rip-drives.txt
rip.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -p runmru >> rip-drives.txt
The first command uses -p mndmru to specify the plugin for the Map Network Drive MRU registry key. The output of this command identifies four network shares that were mapped to the user account of interest as shown below.
Map Network Drive MRU
Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
LastWrite Time Sat May 14 18:13:18 2011 (UTC)
MRUList = dcba
c \\192.168.1.80\Map Drive 2
a \\192.168.1.80\Map Drive D
b \\192.168.1.80\Map Drive 1
d \\192.168.1.80\Map Drive 3
The second command uses -p mp2 to specify the plugin for the MountPoints2 registry key. The output of this command also identifies the same four network shares. A portion of the output is shown below.
MountPoints2
Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
LastWrite Time Sat May 14 18:19:16 2011 (UTC)
Remote Drives:
Sat May 14 18:13:18 2011 (UTC)
##192.168.1.80#Map Drive 3
Sat May 14 18:04:37 2011 (UTC)
##192.168.1.80#Map Drive 2
Sat May 14 17:59:27 2011 (UTC)
##192.168.1.80#Map Drive 1
Sat May 14 17:56:10 2011 (UTC)
##192.168.1.80#Map Drive D
The third and last command uses -p runmru to specify the plugin for the RunMRU registry key. The output of this command shows the same device with the four network shares (192.168.1.80) as well as a new device (192.168.2.50). The output doesn’t show any network shares being accessed but it does attempts were made to access the devices in a method that will display the network shares (\\IP-Address). The runmru output is shown below.
RunMru
Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
LastWrite Time Sat May 14 18:22:00 2011 (UTC)
MRUList = bca
a cmd\1
b \\192.168.2.50\1
c \\192.168.1.80\1
User Activity Stored in System Restore Points (or Volume Shadow Copies) Registry Files
Windows system restore uses restore points to return system files and settings to an earlier point in time for computers running Windows 2000 or XP. Windows Vista and 7 uses volume shadow copies instead of restore points. Registry files covering different points of time in the past are located the restore points and volume shadow copies, and these files may contain additional information about user account activity. To parse the registry hives in the volume shadow copies a simple batch file using the command-line version of Regripper can be used. RipXP.exe can be used to parse a key in the current registry hive and the registry hives in the restore points (RipXP.exe parses the current registry hive so the rip.exe commands can be skipped when using RipXP.exe in this triage method). RipXP.exe requires three switches: -r specifies the current registry hive, -d specifies the restore point directory, and –p specifies the plug to use. The commands to parse the three registry keys of interest with the output being redirected to a text file are below.
ripxp.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -d "F:\[root]\System Volume Information\_restore{3F806DB1-464B-46B0-B724-4376EC868222}" -p mndmru >> rip-rp-mndmru.txt
ripxp.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -d "F:\[root]\System Volume Information\_restore{3F806DB1-464B-46B0-B724-4376EC868222}" -p runmru >> rip-rp-runmru.txt
ripxp.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -d "F:\[root]\System Volume Information\_restore{3F806DB1-464B-46B0-B724-4376EC868222}" -p mp2 >> rip-rp-mp2.txt
The output of all three commands will be similar to the Regripper output I showed before with the exception the registry keys in all of the restore points being displayed. I'm only showing a portion of the Map Drive MRU registry key output since it demonstrates how the output will look. As can be seen below, RipXP.exe output first displays the registry data from the current registry hive before the restore point registry data. The current Map Drive MRU key has four mapped network drives while the restore point shown only has three.
RipXP v.20090818
Launched Sat May 14 19:46:12 2011 Z
F:\[root]\Documents and Settings\Administrator\NTUSER.DAT
Map Network Drive MRU
Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
LastWrite Time Sat May 14 18:13:18 2011 (UTC)
MRUList = dcba
c \\192.168.1.80\Map Drive 2
a \\192.168.1.80\Map Drive D
b \\192.168.1.80\Map Drive 1
d \\192.168.1.80\Map Drive 3
----------------------------------------
Restore Point Info
Description : access share files
Type : System CheckPoint
Creation Time : Sat May 14 18:08:38 2011
F:\[root]\System Volume Information\_restore{3F806DB1-464B-46B0-B724-4376EC868222}\RP10\snapshot\_REGISTRY_USER_NTUSER_S-1-5-21-1214440339-1708537768-725345543-500
Map Network Drive MRU
Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
LastWrite Time Sat May 14 18:04:37 2011 (UTC)
MRUList = cba
c \\192.168.1.80\Map Drive 2
a \\192.168.1.80\Map Drive D
b \\192.168.1.80\Map Drive 1
User Activity Stored in Link Files
The registry provides a wealth of information but link files is another location containing information about a user account activity on a computer. A link file is created when a person accesses a file on their computer's hard drive, removable media, or a network share. The link file contains information about the file including its storage location which will show someone accessing network shares. A few locations containing link files are:
Windows XP: C:\Documents and Settings\username\Recent and C:\Documents and Settings\
Windows Vista and 7: C:\Users\username\AppData\Roaming\Microsoft\Windows\Recent and C:\Users\
One of my requirements for a tool to parse link files was it had to be a command line tool. My reasoning is command-line tools can be used in scripts but more importantly command-line tools can be used in batch files to parse artifacts in volume shadow copies. I couldn't find a tool to meet my needs. Harlan provided the lslnk.pl script in WFA 2nd edition and it displays the information contained in link files. However, lslnk.pl only works against individual files when I needed a tool to parse an entire directory of link files. I'm not a programmer and I don't know Perl but I can use search engines so I decided to try to modified lslnk.pl. The first modification I made was to enable lsnk.pl to parse all of the link files in a directory with the output being in report format. The modified script - lslnk-directory-parse.pl - worked fine but the output wasn't the best for filtering data. I needed the output to display all of the information from a link file on one line so I perform a search I can see all information for a specific link file. I made another change to make the output contain one link file per line in comma delimited format and this resulted in the lslnk-directory-parse2.pl script. Both modified scripts can be found in the Yahoo Win4n6 group's tools folder. The only parameter required by the script is the directory to parse as shown below.
C:\Perl>lslnk-directory-parse2.pl "F:\[root]\Documents and Settings\Administrator\Recent" > lsnk-parse2-output.txt
The output is a comma delimited text file and this means it can be opened in Excel/Calc (to see how to import a text file in Excel check out my posts Reviewing Timelines with Excel or Reviewing Timelines in Calc). Opening the text file at this point will show the information from all of the link files instead of the information specific to the question at hand which is what network shares did an account access. The text file can be searched prior to it being reviewed in Excel/Calc and I use Grep (available in UnxUtils) to do this. There are numerous characteristics to search on such as filenames, directory paths, file extensions, removable media, and network shares. That's right, link files indicate if person accessed a file on a network share. The lslnk-directory-parse2.pl can be redirected to Grep for searching prior to the creation of the text file. The command below shows the lslnk-directory-parse2.pl output being searched for the word "network share" (the binary-file=text switch forces Grep to see the output as text).
C:\Perl>lslnk-directory-parse2.pl "F:\[root]\Documents and Settings\Administrator\Recent" | grep.exe -i --binary-files=text "network share" > lsnk-parse2-output.txt
The output file is still a comma delimited file but the only link files present will be the ones with the phrase "network share" in its information. Reviewing a portion of the output not only shows files accessed on the network shares identified previously with Regripper and RipXP but it also identifies files accessed in a new share (\\192.168.2.50\Share) as shown below.
The triage extracted data from registry and link files to answer the question of what network shares a person accessed. There was some redundancy in the extracted data since both locations showed the same user account activity (same network share access). However, at times one location may reveal information that is not present in the other. I promised to write about how to answer a few initial questions in less than two minutes by examining the activity on the computer. It took me less than one minute to run Regripper, RipXP, and lslnk-directory-parse2.pl, and to examine the output from the three tools. Within this one minute I was able to determine the network shares a user account had readily available access to (mapped drives) and network shares accessed. The process can be even quicker by creating a batch file with all of the commands since a batch file can just be executed. I answered a question network share access but the process I described should not be limited to only this activity. Different registry keys in combination with information contained in link files can be used to quickly determine someone’s activity on a computer.
Posts
Excellent write-up. Thanks for sharing your knowledge and experience.
Excellent post, Corey.
I tend to think that the biggest issue with triage is the second question...what data do you need to answer the question? Many analysts cannot translate the customer's requests into a compartmentalized, discreet, achievable goal, and they lack the knowledge of available data sources (and by extension, the confidence to perform triage).
I also think that this is an off-shoot of the phenomenon where the vast majority of analysts do not like to share their thoughts with others; they also do not like people to ask questions about their work. There seems to be this issue or school of thought that any question is second guessing, rather than simply what it is...an attempt to share information.
And yes, I still hear comments along the lines of, "...a good defense attorney could tear that apart." This seems to be more of an obstacle for folks gaining and using new knowledge or skills.
Again, great post. I like it when these sorts of topics are addressed and presented. Keep it up!
Great post, Corey!
From working with and talking to other analysts, I think that the biggest issue is that most simply are not able to compartmentalize the customer's requests into discreet, achievable goals. From there, many are not familiar with the available data sources...we still see, to this day, questions of where file copy operations are recorded in the Windows Registry. If you don't know what you need or what it should look like, how do you go about determining the tools you should use?
Another issue I've seen is that many analysts do not have the knowledge, or confidence in their abilities, to ask questions ("I don't want to look stupid...") or share their experiences with others. As such, questions like, "...how did you do X?" sound to them like, "What are you...stoopit?" It's really unfortunate, but you're one of the few who posts this sort of information out sharing with those who refuse to share.
Great work! Keep it up!
Harlan, thanks for the comments.
I think it is unfortunate as well that more analysts don’t share their thoughts, knowledge, or even ask questions. I’m a forensic team of one (not counting my witness) in my organization and one of the most helpful things I find is when other analysts share information. It helps me develop into a better DF practitioner and at times helps me work smarter and faster so I can provide results to my customers sooner.
I never understood the hesitancy of sharing information whether if it was in IT, InfoSec, or DFIR. The lack of knowledge sharing serves no purpose since no one benefits from it. The other day I was reading the Assuming The Breach blog when the author made a reference to the Dunning-Kruger effect in relation to how people view their skills (reference was made in Reason 6 in the 6 Reasons Why InfoSec Shouldn't Report to IT post). I never heard of this effect before so I was reading about it and one of the conclusions is that competent individuals may falsely assume that others have an equivalent understanding.
I haven’t read the full study yet but I can see how this plays out in DFIR. People assume everyone else has an equivalent or better understanding about something which results in them being hesitant about sharing their thoughts or asking questions. There may be a few individuals who already know or have a better understanding about something but there may be many individuals who will benefit from the information being shared. The more I’m sharing information I can see how I fall into this cycle of assuming others in the community already knew what I was trying to do. I'm now trying to remember the people who may benefit from me sharing information or asking a question since I'm more aware about falling into the cycle.
Corey - You rock. I've been using Harlan's lslnk.pl in a for loop in Linux for years and just came across your version of his script.
For those interested in using it on Linux, a slight modification may be required, at least it was on my Ubuntu 64 box. I believe it's line 85, I changed mine to this:
open(FH,$dirname . "/" . $file) || die "Could not open $dirname\\$file: $!\n";
and it works beautifully. Did you make any other changes to the script?
I ported it to Ruby as a Meterpreter script a couple years ago and seem to recall there may have been an error in the parsing, but it's been a long time ago. One of these days I'll dig up my notes or revisit the issue.
Thanks for your work on this. Great stuff.
Dave,
Thanks for the feedback and I'm glad you found the changes helpful. Harlan deserves all the credit for writing the script; I just made a minor mod to parse more than one file at a time.
> Did you make any other changes to the script?
I uploaded the two modified scripts to the Win4n6 group about a week and half ago (comment in script says version 1.1). These scripts contain two changes since I wrote this post in May. The first change was to add a check for the LNK file extension - in addition to lnk - to account for the naming convention used in the Office Recent folder. The second change was to add a few lines to check the file header when the link file is opened in binary mode. This addressed the script stopping when it encountered an empty link file.