Journey Into Incident Response

“You do intrusion and malware investigations, we do CP and fraud cases” is a phrase I saw Harlan mention a few times on his blog. To me the phrase is more about how different the casework is; about how different the techniques are for each type of case. Having worked both fraud and malware cases I prefer to focus on what each technique has to offer as opposed to their differences. How parts of one technique can be beneficial to different types of cases. How learning just a little bit about a different technique can pay big dividends by improving your knowledge, skills, and process that you can use on your current cases. To illustrate I wanted to contrast techniques for malware and fraud cases to show how they help one another.

Program Execution

Malware eventually has to run and when it does execute then there may be traces left on a system. Understanding program execution and where these artifacts are located is a valuable technique for malware cases. Examining artifacts containing program execution information is a quick way to find suspicious programs. One such artifact is prefetch files. To show their significance I’m parsing them with Harlan’s updated pref.pl script. Typically I start examining prefetch files by first looking at what executables ran on a system and where they executed from. I saw the following suspicious programs looking at the output from the command “pref.exe -e -d Prefetch-Folder”.

TMP77E.EXE-02781D7C.pf Last run: Fri Mar 12 16:29:05 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\TMP77E.EXE

TMPDC7.EXE-2240CBB3.pf Last run: Fri Mar 12 16:29:07 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\TMPDC7.EXE

UPDATE.EXE-0825DC41.pf Last run: Fri Mar 12 16:28:57 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\DESKTOP\UPDATE.EXE

ASD3.TMP.EXE-26CA54B1.pf Last run: Fri Mar 12 16:34:49 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\ASD3.TMP.EXE

ASD4.TMP.EXE-2740C04A.pf Last run: Fri Mar 12 16:34:50 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\ASD4.TMP.EXE

DRGUARD.EXE-23A7FB3B.pf Last run: Fri Mar 12 16:35:26 2010 (2)
\DEVICE\HARDDISKVOLUME1\PROGRAM FILES\DR. GUARD\DRGUARD.EXE

ASD2.TMP.EXE-2653E918.pf Last run: Fri Mar 12 16:34:27 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\ASD2.TMP.EXE

ASR64_LDM.EXE-3944C1CE.pf Last run: Fri Mar 12 16:29:06 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\ASR64_LDM.EXE

These programs stood out for a few different reasons. First I noticed the path they executed from was a temporary folder in a user’s profile. Unusual file paths are one way to spot malware on a system. The other thing I noticed is that some of the programs only executed once. This behavior resembles how downloaders and droppers work. Their sole purpose is to execute once to either download additional malware or install malware. The last dead giveaway is they all executed within a few minutes of each other. The first sweep across the prefetch files netted some interesting programs that appear to be malicious. The next thing to look at is the individual prefetch files to see what file handles were open when the program ran. The TMP77E.EXE-02781D7C.pf prefetch file showed something interesting as shown below (the command used was “pref.pl -p -i -f TMP77E.EXE-02781D7C.pf”).

EXE Name : TMP77E.EXE
Volume Path : \DEVICE\HARDDISKVOLUME1
Volume Creation Date: Fri Nov 2 08:56:57 2007 Z
Volume Serial Number: 6456-B1FD

\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\NTDLL.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\KERNEL32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\UNICODE.NLS
*****snippet*****


EXEs found:

\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\TMP77E.EXE
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\NET.EXE
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SC.EXE
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\ASR64_LDM.EXE

DAT files found:

\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMPORARY INTERNET FILES\CONTENT.IE5\INDEX.DAT
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\COOKIES\INDEX.DAT
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\HISTORY\HISTORY.IE5\INDEX.DAT

Temp paths found:

\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\TMP77E.EXE
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMPORARY INTERNET FILES\CONTENT.IE5\INDEX.DAT
\DEVICE\HARDDISKVOLUME1\DOCUMENTS AND SETTINGS\ADMINISTRATOR\LOCAL SETTINGS\TEMPORARY INTERNET FILES\CONTENT.IE5\M20M2OXX\READDATAGATEWAY[1].HTM
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\ASR64_LDM.EXE

The pref.pl file handle portion to the output was trimmed to make it easier to read but I left in the intelligence provided by the script through its filters. The filters highlight file handles containing exes, dats, and temporary folders. The exe filter shows in additional to a handle to the TMP77E.EXE file there were handles to SC.EXE, NET.EXE, and ASR64_LDM.EXE. SC.EXE is a Windows program for managing services including creating new services while NET.EXE is a Windows program for doing various tasks including starting services. ASR64_LDM.EXE was another suspicious program that ran on the system after TMP77E.EXE. The file handles inside each prefetch file of interest provided additional information which is useful during a malware case.

Program execution is vital for malware cases and I saw how the same technique can apply to fraud cases. On fraud cases a typical activity is to identify and locate financial data. At times this can be done by running keyword searches but most of the time (at least for me) the actual financial data is unknown. What I mean by this is a system is provided and it’s up to you to determine what data is financial. This is where the program execution technique comes into play. The programs that ran on the system can be reviewed to provide leads about what kind of financial data may be present on the system. Using the first sweep across the prefetch files I located these interesting programs (command used was “pref.exe -e -d Prefetch-Folder”). Note: the system being looked at is not from a fraud case but it still demonstrates how the data appears.

WINWORD.EXE-C91725A1.pf Last run: Tue Jul 10 16:42:26 2012 (42)
\DEVICE\HARDDISKVOLUME2\PROGRAM FILES\MICROSOFT OFFICE\OFFICE12\WINWORD.EXE

ACROBAT_SL.EXE-DC4293F2.pf Last run: Fri Jun 22 18:14:12 2012 (1)
\DEVICE\HARDDISKVOLUME2\PROGRAM FILES\ADOBE\ACROBAT 9.0\ACROBAT\ACROBAT_SL.EXE

EXCEL.EXE-C6BEF51C.pf Last run: Tue Jul 10 16:30:18 2012 (22)
\DEVICE\HARDDISKVOLUME2\PROGRAM FILES\MICROSOFT OFFICE\OFFICE12\EXCEL.EXE

POWERPNT.EXE-1404AEAA.pf Last run: Thu Jun 21 20:14:52 2012 (22)
\DEVICE\HARDDISKVOLUME2\PROGRAM FILES\MICROSOFT OFFICE\OFFICE12\POWERPNT.EXE

When I look at program execution for fraud cases I look for financial applications, applications that can create financial data, and programs associated with data spoliation. The system didn’t have any financial or data spoliation programs but there were office productivity applications capable of creating financial documents such as invoices, receipts, proposals, etc. These programs were Microsoft Office and Adobe Acrobat and this means the data created on the system is most likely Word, Excel, Powerpoint, or PDFs. The number of executions for each program is also interesting. I look to see what applications are heavily used since it’s a strong indication about what program the subject uses. Notice Adobe only ran once while Word was ran 42 times. Looking at the file handles inside individual prefetch file also contains information relevant to a fraud case. Below are a few sanitized handles I found in the WINWORD.EXE-C91725A1.pf prefetch file (the command used was “pref.pl -p -i -f WINWORD.EXE-C91725A1.pf”).

EXE Name : WINWORD.EXE
Volume Path : \DEVICE\HARDDISKVOLUME2
Volume Creation Date: Fri Aug 26 18:13:26 2011 Z
Volume Serial Number: E4DD-S23A

\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\NTDLL.DLL
\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\KERNEL32.DLL
\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\APISETSCHEMA.DLL
*****snippet*****
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\SANTIZED.DOCX
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\~$SANTIZED.DOCX
\DEVICE\HARDDISKVOLUME2\USERS\USERNAME\APPDATA\LOCAL\TEMP\MSO4F30.TMP
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\SANTIZED 2.DOCX
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\~$SANTIZED 2.DOCX
\DEVICE\HARDDISKVOLUME2\USERS\USERNAME\APPDATA\LOCAL\TEMP\MSO7CF3.TMP
\DEVICE\HARDDISKVOLUME2\USERS\USERNAME\APPDATA\LOCAL\TEMP\20517251.OD
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\SANTIZED 3.DOCX
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\~$SANTIZED 3.DOCX
\DEVICE\HARDDISKVOLUME4\$MFT
\DEVICE\HARDDISKVOLUME2\USERS\USERNAME\APPDATA\LOCAL\MICROSOFT\WINDOWS\TEMPORARY INTERNET FILES\CONTENT.MSO\SANTIZED.JPEG
\DEVICE\HARDDISKVOLUME4\FORENSICS\RESEARCH\Folder\SANTIZED 3.DOCX:ZONE.IDENTIFIER
*****snippet*****

The file handles shows documents stored in the folder FORENSICS\RESEARCH\Folder\ on a different volume were accessed with Word. I think this is significant because not only does it provide filenames to look for but it also shows another storage location the subject may have used. Where ever there is storage accessible to the subject then there’s a chance that is where they are storing some financial data. Also, notice in the output how the last line shows one of the documents was downloaded from the Internet (zone identified alternate data stream).

User Activity

The program execution showed how fraud cases benefited from a technique used in malware cases. Now let’s turn the tables to see how malware cases can benefit from fraud. As I mentioned before most of the times I have to find where financial data is located whether if it’s on the system or in network shares. The best approach I found was to look at artifacts associated with user activity; specifically file, folder, and network share access. My reasoning is if someone is being looked at for committing a fraud and they are suspected of using the computer to commit the fraud then they will be accessing financial data from the computer to carry out the fraud. Basically, I let their user activity show me where the financial data is located and this approach works regardless if the data is in a hidden folder or stored on a network. There are numerous artifacts containing file, folder, and network share access and one of them is link files. To show their significance I’m parsing them with TZWorks LNK Parser Utility. When I examine link files I parse both the Recent and Office/Recent folders. This results in some duplicates but it catches link files found in one folder and not the other. I’ve seen people delete everything in the Recent folder while not realizing the Office\Recent folder exists. I saw some interesting target files, folders, and network shares by running the command “dir C:\Users\Username\AppData\Roaming\Microsoft\Windows\Recent\*.lnk /b /s | lp -pipe -csv > fraud_recent.txt”.

{CLSID_MyComputer}\E:\Forensics\Research\Folder\sanatized.doc
{CLSID_MyComputer}\E:\Forensics\Research\Folder\sanitized 2.doc
{CLSID_MyComputer}\E:\Forensics\Research\Folder\sanitized 3.doc
{CLSID_MyComputer}\C:\Atad\material\sanitized 1.pdf
{CLSID_MyComputer}\F:\Book1.xls
\\192.168.200.55\ share\TR3Secure

The output has been trimmed (only shows target file column) and sanitized since it’s from one of my systems. The link files show files and folders on removable media and a network share has been accessed in addition to a folder not inside the user profile. I’ve used this same technique on fraud cases to figure out where financial data was stored. One time it was some obscure folder on the system while the next time it was a share on a server located on the network.

Tracking user activity is a great way to locate financial data on fraud cases and I saw how this same technique can apply to malware cases. On malware cases it can help answer the question how did the computer become infected. Looking at the user activity around the time of the initial infection can help shed light on what attack vector was used to compromise the system. Did the user access a network share, malicious website, removable media, email attachment, or peer to peer application? The user activity provides indications about what the account was doing that contributed to the infection. On the malware infected system there were only two link files in the Recent folder shown below is the target create time and target name (command used was “dir "F:\Malware_Recent\*.lnk" /b /s | lp -pipe -csv > malware_recent.txt”).

3/12/2010 16:17:04.640 {CLSID_MyComputer}\C:\downloads
3/12/2010 16:18:59.609 {CLSID_MyComputer}\C:\downloads\link.txt

These link files show the user account accessed the downloads folder and the link text file just before the suspicious programs started executing on the system. Looking at this user activity jogged my memory about how the infection occurred. I was researching a link from a SPAM email and I purposely clicked the link from a system. I just never got around to actually examining the system. However, even though the system was infected on purpose examining the user activity on the malware cases I worked has helped answer the question how did the system become infected.

Closing Thoughts

DFIR has a lot of different techniques to deal with the casework we face. Too many times we tend to focus on the differences; the different tools, different processes, and different meanings of artifacts. Focusing on the differences distracts from seeing what the techniques have to offer. What parts of the techniques can strengthen our processes and make us better regardless of what case we are up against. If I didn’t focus on what the techniques had to offer then I would have missed an opportunity. A chance to develop a better DFIR process by combining malware and fraud techniques; a process that I think is far better than if each technique stood on their own.

For the past few months I have been discussing a different approach to examining Volume Shadow Copies (VSCs). I’m referring to the approach as Ripping VSCs and the two different methods to implement the approach are the Practitioner and Developer Methods. The multipart Ripping VSCs series is outlined in the Introduction post. On Thursday (03/15/2012) I’m doing a presentation for a DFIROnline Meet-up about tracking user activity through VSCs using the practitioner method. The presentation is titled Ripping VSCs – Tracking User Activity and the slide deck can be found on my Google sites page.

I wanted to briefly mention a few things about the slides. The presentation is meant to compliment the information I’ve been blogging about in regards to Ripping VSCs. In my Ripping VSCs posts I outlined why the approach is important, how it works, and examples showing anyone can start applying the technique to their casework. I now want to put the technique into context by showing how it might apply to an examination. Numerous types of examinations are interested in what a user was doing on a computer so talking about tracking someone’s activities should be applicable to a wider audience. To help explain put the approach into context I created a fake fraud case study to demonstrate how VSCs provide a more complete picture about what someone did on a computer. The presentation will be a mixture of slides with live demos against a live Windows 7 system. Below are the demos I have lined up (if I am short on time then the last demo is getting axed):

        - Previewing VSCs with Shadow Explorer
        - Listing VSCs and creating symbolic links to VSCs using vsc-parser
        - Parsing the link files in a user profile across VSCs using lslnk-directory-parse2.pl
        - Parsing Jump Lists in a user profile across VSCs using Harlan’s jl.pl
        - Extracting a Word document’s metadata across VSCs using Exiftool
        - Extracting and viewing a Word document from numerous VSCs using vsc-parser and Microsoft Word

I’m not covering everything in the slides but I purposely added additional information so the slides could be used as a reference. One example is the code for the batch scripts. Lastly, I’m working on my presentation skills so please lower your expectations. :)

In this edition of Links I think there is a little bit of something for everyone regardless if your interest is forensics, malware, InfoSec, security auditing or even good a rant ….

Digital Forensic Search Updates

The Digital Forensic Search index has been slowly growing since it was put together four months ago. Last Sunday’s update brought the sites in the index to: 103 DFIR blogs, 38 DFIR websites, 13 DFIR web pages, and 2 DFIR groups. The initial focus of DFS was to locate information related to specific artifacts as opposed to locating tools to parse those artifacts. My reasoning was because I didn’t want to weed through a lot of irrelevant search hits. Most tools’ websites only provided a high level overview of an artifact the tool parses instead of in-depth information. It made sense to leave out tool specific sites to reduce the amount of noise but things change.

A question I ask myself at times is what tool can parse artifact XFZ. I’m not alone asking the question because I see others asking the same thing. To make things easier in locating tools I’m now adding tool specific sites to the Digital Forensic Search. So far 15 websites and 7 web pages are indexed. I ran a few tests and the search results seem to be a good mixture of hits for information and tools. My testing was limited so if anyone sees too much noise then just shoot me an email telling me who the culprit is.

Let me know of any links missing from DFS

Windows Shortcut File Parser Update

My post Triaging My Way mentions a need I had for a command line tool to parse Windows Shortcut files. In my quest for a tool I modified the lslnk.pl perl script to produce the output I wanted. One of the modifications I made to the script was to examine all of the files in a folder and to only parse files with the lnk file extension. I was running lslnk-directory-parse.pl (modified script) against some shortcut files when the script would abruptly stop. The parsed information from the last file only contained the file system timestamps. Examination of the file showed that it was empty and this was what caused lslnk-directory-parse.pl to die. I made a slight modification to lslnk-directory-parse.pl so the script checks each files’ header to confirm it is indeed a Windows shortcut file. I uploaded the new scripts (lslnk-directory-parse.pl and lslnk-directory-parse2.pl) to the Yahoo Win4n6 group and added a version number (v1.1) in the comments.

There are always different ways to accomplish something. When faced with trying to parse all of the Window shortcut files in a folder I opted to modify an existing script to meet my needs. The Linux Sleuthing blog took a different approach in the post Windows Link Files / Using While Loops. The author uses a while loop with an existing script to parse all of the shortcut files in a folder. Their approach is definitely simpler and quicker than what I tried to do. I learned a lot from the approach I took since I had to understand what modifications to make to an existing script in order to get the output I wanted.

How to Mount a Split Image

Speaking of the Linux Sleuthing blog. They provided another useful tip in the post Mounting Split Raw Images. As the name of the post implies it is about how to mount a split image in a Linux environment. I can’t remember the last time I dealt with a split image since I no longer break up images. However, when I used to create split images I remember asking myself how to mount it in Linux. To others the question may be simple but I didn’t have a clue besides concatenating to make a single image. The Mounting Split Raw Images post shows that sharing information – no matter how simple it may appear – will benefit someone at some point in time.

$UsnJrnl Goodness

Bugbear over at Security Braindump put together a great post Dear Diary: AntiMalwareLab.exe File_Created. I recommend anyone who will be encountering a Windows Vista or 7 system to read the post even if malware is not typically encountered during examinations. The $UsnJrnl record is an NTFS file system artifact which is turned on by default in Vista and 7. Bugbear discusses what the $UsnJrnl record is and how to manually examine it before discussing tools to automate the examination.

What I really like about the post is the way he presented the information. He explains an artifact, how to parse the artifact, a tool to automate the parsing and then shares an experience of how the artifact factored into one of his cases. I think the last part is important since sharing his experience provides context to why the artifact is important. His experience involved files created/deleted on the system as a result of a malware infection. Providing context makes it easier to see the impact of $UsnJrnl on other types of investigations. For example, a reoccurring activity I need to determine on cases is what files were deleted from a system around a certain time. Data in the $UsnJrnl record may not only show when the files of interest were deleted but could highlight what other files were deleted around the same time.

Memory Forensic Image for Training

While I’m on the topic of malware I wanted to pass along a gem I found in my RSS feeds and seen others mention. The MNIN Security Blog published the Stuxnet's Footprint in Memory with Volatility 2.0 back in June but I didn’t read it until recently. The post demonstrates Volatility 2.0’s usage by examining a memory image of a system infected with Stuxnet. A cool thing about the write-up is the author makes available the memory image they used. This means the write-up and the memory image can be used as a guide to better understand how to use Volatility. Just download Volatility, download the memory image, read the post, and follow along by running the same commands against the memory image. Not bad for a free way to improve your Volatility skills.

Easier Way to Generate Reports from Vulnerability Scans

Different methods are used to identify known vulnerabilities on systems. Running various vulnerability scanners, web application scanners, and port scanners are all options. One of the more tedious but important steps in the process is to correlate all of the tools’ outputs to identify: what vulnerabilities are present, their severity, and their exposure on the network. Obtaining this kind of information from the scans was a manual process since there wasn’t a way to automate it. James Edge over at Information Systems Auditing is trying to address this issue in something he calls the RF Project (Reporting Framework Project). RF Project is able to take scans from Nessus, Eeye Retina, Nmap, HP WebInpect, AppScan AppDetective, Kismet, and GFI Languard so custom reports can be created. Want to know the potential vulnerabilities detected by Nessus, Retina, and Nmap against server XYZ? Upload the scans to the reporting framework and create a custom report showing the answer instead of manually going through each report to identify the vulnerabilities. I tested an earlier version of the framework when it only supported Nessus and Retina a few years ago. It’s great to see he continued with the project and added support for more scans.

Jame’s site has some useful stuff besides the RF project. He has a few hacking tutorials and some technical assessment plans for external enumeration, Windows operating system enumeration, and Windows passwords.

Good InfoSec Rant

I like a good rant ever once in awhile. Assuming the Breach’s I do it for the Lulz explains the reason the author works in security. It’s not about the money, job security, or prestige; he works in security because it’s a calling. The post was directed at the InfoSec field but I think the same thing applies to Digital Forensics. Take the following quote:

“Technology, and especially information security has always been more than a job to me. More than even a career. It's a calling. Don't tell my boss, but I'd do this even if they didn't pay me. It's what I do. I can't help it.”

I can’t speak for others but digital forensics is the most changing field I’ve ever worked in. Technology (hardware and software) is constantly changing in how it stores data and the tools I use to extract information are also evolving. Digital forensics can’t be treated as a normal 8 to 4 job with any chance of being successful. Five days a week and eight hours each day is not enough time for me to keep my knowledge and skills current about the latest technology, tool update, threat, or analysis technique. It’s not a job; it’s my passion. My passion enables me to immerse myself in DFIR so I can learn constantly and apply my skills in different ways outside of work for my employer.

I wouldn’t last if digital forensics was only a day job. Seriously, how could I put myself through some of the things we do if there is no passion? We read whitepapers dissecting artifacts and spend countless hours researching and testing to improve our skills. Doing either of these things would be brutal to someone who lacks passion for the topic. For example, I couldn’t hack it being a dentist because I lack the passion for dentistry. I wouldn’t have the will power to read a whitepaper explaining some gum disease or spend hours studying different diagnosis. Dentistry would just be an 8 to 4 day job that pays the bills until I could find something else. DFIR on the other hand is another story as I spend my evening blogging about it after spending the day working on a case.

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.