Upload
andrew-case
View
1.760
Download
5
Embed Size (px)
DESCRIPTION
My presentation on investigating coordinated data exfiltration with Dr. Golden Richard at GFIRST 2011.
Citation preview
Inves&ga&ng Coordinated Data Exfiltra&on
Golden G. Richard III University of New Orleans and Digital Forensics Solu9ons, LLC
& Andrew Case
Digital Forensics Solu9ons, LLC
Speaker’s Introduc&on (1) Golden G. Richard III • Professor of Computer Science and University Research Professor @ University of New Orleans
• Director, Greater New Orleans Center for Informa9on Assurance (GNOCIA)
• Co-‐founder, Digital Forensics Solu9ons, LLC • GCFA cert • United States Secret Service Cybercrime Taskforce
• Member of the American Academy of Forensic Sciences (AAFS)
2
Speaker’s Introduc&on (2)
Andrew Case • Senior Security Analyst • GCFA cert • Blackhat, DFRWS, and SOURCE speaker • Experienced digital forensics inves9gator, penetra9on tester, and reverse engineer
3
Digital Forensics Solu&ons / UNO • Digital Forensics Solu9ons, LLC
– New Orleans company with offices in the Garden District – Full service digital forensics, data recovery – Rela9onships for seamless digital forensics / e-‐discovery – Security assessment, secure erasure of media, security training – Research: new tools and techniques
• GNOCIA / University of New Orleans – Pioneering curriculum in digital forensics and reverse engineering
– Digital forensics research: new tools and techniques – Educa9on: Crea9ng a strong local tech workforce – Liaison with local, state, federal law enforcement to solve difficult cases
4
The Purpose of This Talk • Provide some basic background on digital forensics techniques applicable to data exfiltra9on cases
• Illustrate the extent to which data exfiltra9on can be performed in a straighZorward manner on a normal computer
• And how data exfiltra9on can be inves9gated • A recent case we inves9gated required analyzing almost every common data exfiltra9on technique
• We believe this case serves as a great learning example for other inves9gators
5
Digital Forensics? ★★
• (Benevolently) prey on mechanisms designed with performance (not privacy) in mind
• Crea9ve uses of data intended mostly for other things • Correla9on of simplis9c data sources to create richer
context • In some cases: logs, etc. actually meant to be used for
forensic purposes
Agenda
• Introduc9on to Data Exfiltra9on Issues • Overview of our Recent Case • How to Inves9gate Exfiltra9on • Wri9ng a Proper Case Report • Conclusion
[Some brief background on various digital forensics
issues and techniques as we go—please feel free to ask ques&ons to clarify anything that isn’t clear]
7
Data Exfiltra&on Introduc&on • Data exfiltra9on is the removal of sensi9ve informa9on from an owner’s control
• Common examples include: – A rogue employee removing informa9on from a company’s computer systems
– Aaackers stealing data aber they have gained access to an internal network
– Malware stealing and expor9ng sensi9ve data
8
How Exfiltra&on Occurs 1. A malicious user (or program) gets access to
sensi9ve data 2. The data is then gathered and moved outside
of the owner’s network 3. Commonly used methods
• Removable Media (USB, CD/DVD, Smartphones) • Internet-‐Based (Email, File Uploads, Dropbox, FTP, SCP, etc.)
• Malware (transmission via email, TCP, UDP, etc.)
9
Consequences of Exfiltra&on • Consequences can be severe • Immediate effect: – Loss of intellectual property and other sensi9ve informa9on
– Expensive incident response process must begin – Possible requirements for disclosure to be made and compensa9on of affected par9es
• Long term effect: – Loss of trust by clients – Liability / Lawsuits / Other legal issues
10
Our Scenario
11
Preliminary Informa&on • A former employee of a financial ins9tu9on (our client) was suspected of stealing sensi9ve informa9on and using it to bring business to his new employer
• We were to inves9gate: 1. Was data stolen? 2. If so, how? 3. What data was taken 4. If other people were involved in the incident
12
Data/Equipment to Inves&gate
• We were given the suspected user’s laptop • The user’s Blackberry was remote wiped upon his leaving the company as per-‐policy – No backups made before wiping – Never got access to this informa9on
• We were supposed to receive a copy of the user’s archived Outlook email (PST file) – This was never provided
13
Inves&ga&on
14
Ini&al Analysis
• Imaged hard drive of laptop • The suspect’s laptop was running XP SP2 • Internet Explorer only browser installed • The user was not a local administrator • The machine had over 20 System Restore Points – We will be discussing the importance of this throughout
15
System Restore Points
• System Restore Points are created to backup cri9cal files when de-‐stabilizing opera9ons are performed on the OS – System updates – 3rd Party sobware installa9ons – Installa9on of unsigned drivers – …
• Good source for historical copies of the Windows registry
• In our case, System Restore Points allowed orderly examina9on of data over five months old
16
Inves&ga&on Flow • Inves9gate Removable Media – Determine which removable media was used, which files were moved, when they moved, and to where
• Inves9gate Web Based Ac9vity – Determine if files were transferred over network
• Inves9gate Accessed Files – Find any files that were inappropriately accessed
• Determine if other people were involved – Look for emails and other communica9on
17
Inves&ga&ng Removable Media
18
First Steps
• USB history analysis typically requires analyzing two sources: – USBSTOR registry informa9on – The setupapi.log file – Renamed and split under Win7:
• setupapi.app.log and setupapi.dev.log
• Details aber a brief discussion of the Windows registry
19
Briefly: Windows Registry
20
21
Windows Registry
• Can be a forensics goldmine • Lots of informa9on, fairly difficult to “clean” • Usernames • Internet history • Program installa9on informa9on • Recently accessed files • Devices (USB, et al) • Network configura9on
21
22
Registry: Windows 9x
• On Windows 95/98: • “system.dat” and “user.dat” files • If mul9ple users, look in \Windows\profiles\<acct> for
individual user.dat files • “system.dat”
– System-‐wide informa9on • “user.dat” (one “original” one, then others as users are
created) – User informa9on
• Careful, because on Windows 9x, new user profiles are oben based on previously created profiles!
23
Registry: NT/Win2K/XP • “ntuser.dat”
– List of most recently used files – Each user has a separate “ntuser.dat” file – \documents and sesngs\user
• “default” in \<windowsdir>\system32\config – Ini9al system sesngs
• “SAM” – User account sesngs, security sesngs
• “security” – Security-‐related sesngs
• “sobware” – Installed programs, sesngs, usernames, passwords
• “system” – Misc. system sesngs
24
Last Write Times for Registry Keys
Copyright 2004-‐2011 by Golden G. Richard III.
25
** VERY IMPORTANT ** “Select” key chooses which control set is current, which is “last known good” configura9on
SYSTEM file
Copyright 2004-‐2011 by Golden G. Richard III.
26
SAM file
What user accounts are on the machine?
Copyright 2004-‐2011 by Golden G. Richard III.
27
SYSTEM file
Which &mezone does the
computer use?
Copyright 2004-‐2011 by Golden G. Richard III.
28
NTUSER.dat file
Which files were recently
accessed by a par&cular user?
Copyright 2004-‐2011 by Golden G. Richard III.
29
NTUSER.dat file
Which URLS were typed recently by a par&cular user?
Copyright 2004-‐2011 by Golden G. Richard III.
30
SOFTWARE file
Which programs are installed on the machine? Which license keys are in
use?
Copyright 2004-‐2011 by Golden G. Richard III.
31
NTUSER.dat file
Which programs run automa&cally when a par&cular user logs in?
Copyright 2004-‐2011 by Golden G. Richard III.
32
SOFTWARE file
Which programs run automa&cally when ANY user
logs in?
Copyright 2004-‐2011 by Golden G. Richard III.
33
750GB USB hard drives (same type)
Two Jumpdrive Elite thumbdrives
SYSTEM file
What has been plugged in?
Copyright 2004-‐2011 by Golden G. Richard III.
34
SYSTEM file Networking info
Copyright 2004-‐2011 by Golden G. Richard III.
35
SYSTEM file
Disk info
36
Summary: Registry Forensics
• Last write 9mes for individual registry keys can be used to infer useful informa9on
• Overall, lots of informa9on, some of which can’t be obtained elsewhere
• Extreme care is needed during analysis • Lots of mysterious data • Much of the informa&on is essen&ally undocumented and meaning is determined experimentally
USBSTOR
• The SYSTEM registry hive contains a history of connected USB devices – Registry files backed up by System Restore Point facility
• All of this informa9on is stored under the CurrentControlSet\Enum\USBSTOR key • Contains an entry for each USB device that was
connected to the machine • Also contains the “Friendly Name” and serial number of
each aaached device • The only 9mestamp informa9on available is last
wriaen 9me for key corresponding to par9cular USB device!
37
Analyzing the Registry Files
• Aber gathering all of the SYSTEM files… – Current – Historical (via System Restore Points)
• …Used Regripper [6] USBSTOR plugin to enumerate previously aaached USB devices
• Then wrote a wrapper script to dump this informa9on into Excel
• Now we had informa9on on connected USB devices going back many months
38
Results of USBSTOR Analysis
• Eight USB drives were used during the target 9me range – Six were thumb drives with capacity ranging from 2 to 8GB
– One USB device was the previously men9oned user’s Blackberry smartphone
– Last was a digital camera
• Next step was to determine the extent of use for the six thumb drives
39
Analyzing setupapi.log
• Text file in c:\Windows (under XP) • Tracks device installa9on, service-‐pack installa9on, hoZix installa9on, etc. for the setup applica9on
• Reveals the first 9me each device was plugged in, as Windows selects appropriate device drivers
• USBSTOR registry key tells us the last 9me a device was connected
• We used SetupAPI Extractor [15] to analyze the file rather than simply viewing it as a text file
40
Using setupapi.log Informa&on
• Using the first and last connect 9mes gives us a 9me range for each device
• Use this informa9on to assign drive leaers to specific thumb drives – Discussed next
• Also helped build a clearer 9meline of the suspected user’s ac9vity
41
Inves&ga&ng Individual Drives
• Used procedure illustrated on next slide to determine: – Drive leaer mapped to a USB device – The first and last 9me each device was connected
• Have to be careful when assigning drive leaers – Mul9ple drives can be mapped to same leaer over 9me
– Need to correlate 9me informa9on between drive and files accessed to substan9ate
42
USB Analysis Process [4][5][11] 43
Inves&ga&ng Network-‐Based Exfiltra&on
44
Email Examina&on: Overview • Two email services were used to exfiltrate files: – Gmail – Company Email (Exchange)
• We were told during the pre-‐inves9ga9on phase that the IT team knew of a Gmail account for the user under inves9ga9on
• Needed to find all contact with suspect’s new employer while s9ll employed by our client
• We didn’t have PST access, our only hope was web-‐based email
• Knew that only fragments would be recovered from Gmail
45
Inves&ga&ng Gmail • Two pieces of evidence were discovered from Gmail: – A number of file exfiltra9on instances – Evidence of contact between suspect and new employer well before our client suspected
• How did we find this informa9on?
46
Gmail: Technical Details
• Gmail makes a number of efforts to avoid disk forensics of messages read and sent – Puts messages in separate iframes – Uses SSL and no-‐cache browser direc&ves
• Uses similar techniques for other parts of the Gmail interface – Contacts, labels, searches, etc.
• Essen9ally, simple examina9on of browser cache isn’t going to yield much
47
Scalpel Overview • File carving is typically used to recover deleted files, based on the structure of file types
• Scalpel is a file carver [3], but can also be used as a very efficient indexer for specific search terms – Latest version is mul9threaded and can use GPUs (CUDA) for high performance opera9on
• The audit file created by Scalpel (audit.txt) contains loca9ons of every discovered instance of every search term
48
Using Scalpel • We ran Scalpel to find all instances of the new employer’s email domain
• We then used the Sleuthkit to quickly map these offsets to files within the filesystem – See [2] for an updated method on how to do this
• Produced hits in both web cache files and pagefile.sys, the Windows swap file
49
pagefile.sys Analysis • Hits in pagefile are on previously viewed Gmail Inbox indices (illustrated on the next slide)
• These indices contain a number of useful ar9facts about email messages: – Time received – Message fragment – Sender – Aaachment names (if any)
50
Gmail Inbox View
• The image above is a screenshot of the Inbox view
• The default view shows 50 messages • We were able to recover a number of instances of these using Scalpel on the pagefile
51
U&lizing Message Fragments • Aber gathering all message indices discovered in the pagefile…
• …We created a new Scalpel config file and carved again on the pagefile to try to recover message fragments
• This produced fragments of en9re message bodies sent through Gmail by the rogue employee – This is where it got interes9ng!
52
Message Fragments: Gold Mine • The recovered message bodies revealed the employee under inves9ga9on had contacted his new employer a number of months before leaving the company
• Well before our client had suspected • The uncovered messages were par9cularly damaging
• Revealed precise details of plan to steal and later u9lize our client’s data
53
Gmail Aeachments • Aber discovering aaachment names in the fragments, we used this data to discover which files were transferred
• Analysis revealed a number of files were emailed from the user’s local Outlook installa9on to his Gmail account
• Filenames were matched to those in LNK files and MRU lists (discussed later)
54
Inves9ga9ng Web Browser Ac9vity
55
Three Components of Browser Ac&vity
• History – Gives a list of sites visited, including when and specific URLs
• Cache – Copies of files downloaded from webservers (HTML, javascript, images, etc)
– MAC 9mes can be used in 9meline analysis • Cookies – Provide addi9onal informa9on about user’s interac9on with a web site
56
Analyzing Browser History Using IEHistoryView
57
Analyzing Cache Contents Using IECacheView 58
Analyzing HTTP Cookies 59
Flash Cookies • Flash applica9ons are provided client storage through local shared objects (LSOs)
• Browsers are only recently giving users the ability to delete them – Previously had to find LSOs within the filesystem and manually delete
• Stored outside of the normal cookie/cache storage subsystem – “Private” browsing modes DO NOT affect flash cookies!
• Analysis leads to informa9on about websites visited, when they were visited, etc.
60
Analyzing Flash Cookies • The loca9on of the files is opera9ng system dependent: – hap://en.wikipedia.org/wiki/Local_Shared_Object#File_loca9ons
• A few tools exist for analysis, but none seem completely stable: – Minerva -‐ hap://blog.coursevector.com/minerva – SOLReader -‐ hap://www.sephiroth.it/python/solreader.php
61
Using Browser Analysis • Browser analysis revealed many accesses to Gmail as well as informa9on related to the new employer
• “9tle” and other URL informa9on recorded in the history file helped in analysis discussed later
62
END OF HOUR 1: Ques&ons / Comments?
• Contact Golden: – [email protected] – [email protected] – @nolaforensix
• Contact Andrew: – [email protected] – @aarc
• Digital Forensics Solu9ons: – Daryl Pfeif (CEO) – [email protected] – 504-‐874-‐0787 – hap://www.digitalforensicssolu9ons.com – hap://dfsforensics.blogspot.com – @dfsforensics
63
Inves&ga&ng Coordinated Data Exfiltra&on (2nd Hour)
Golden G. Richard III
University of New Orleans and Digital Forensics Solu9ons, LLC
& Andrew Case
Digital Forensics Solu9ons, LLC
Inves&ga&ng Files Transferred During the Exfiltra&on
65
Recap • At this point in the inves9ga9on we have: – Shown that a number of thumb drives were previously aaached to the computer under inves9ga9on
– That files were sent to an external Gmail address from a company Email address
– That the target employee had contacted his new employer many months before leaving our client
66
Updated Workflow • We now had two goals: – Find out which files were accessed by the user – Find out which were then transferred onto USB drives
– Determine the loca9on of the files sent via Gmail
67
Finding Accessed Files • Windows provides a number of forensics ar9facts related to historical file access
• Three main ones were used in this inves9ga9on: – LNK Files – MRU Lists – File Access History
68
LNK File Analysis
69
LNK Files • Link files (.lnk) are Windows shortcut files • Similar to symbolic links under Unix • The metadata contained in these files is very useful during forensics inves9ga9ons – MAC 9mes of target file – Full path to target file – Whether target is/was local or on the network – Network share informa9on – Volume serial number (used to match to specific drive)
70
lnk-‐parse [10] on a Local File
MAC Times of Target File
Target Hard Drive
Target File
71
parse-‐lnk Output for Network Share
MAC Time of Target File
The network share related to the file, including path
Size of File
72
Using LNK Files • The target computer had a large number of relevant LNK files
• (Some) LNK files are backed up within System Restore Points!
• These files were helpful for two purposes: 1. Iden9fying which files were moved to which USB
drives 2. Iden9fying which files were downloaded from
which network shares • More on this in a minute…
73
Automa&ng LNK File Analysis • Since there were so many LNK files, we needed to automate the process
• Wrote a script to parse lnk-‐parse output and write contents to an Excel sheet
• Could then quickly determine which files, network shares, and 9mes were involved in the exfiltra9on
74
LNK File Research • There a few very good resources on LNK file analysis: – “The Meaning of Life” [9]
• 21 page research paper on analysis with LNK files – Forensics Wiki Page [7] – Forensics Focus Ar9cle [8]
75
Analyzing MRU Lists
76
Most Recently Used (MRU) Lists • MRU lists store informa9on about the documents most recently accessed by a user for a par9cular applica9on
• Stored in the Windows Registry – Again, System Restore Points give us access to historical MRU lists as well as current ones
• Common examples are when you click ‘File’ in an applica9on’s menu and see a list of previously opened documents
77
Popular MRU Lists • Microsob Office – For all applica9ons (Word, Excel, PPT, etc)
• Internet Explorer – Recently typed URLS (The URL dropdown)
• Adobe – Recently accessed PDF files
• An extensive list of over 30 MRU loca9ons and associated applica9ons can be found at [12]
78
Using MRU Lists • Gathered the current and historical SOFTWARE registry files
• Used Regripper to acquire all of the relevant MRU lists – Most important were Office and Adobe
• (Again) we wrote a script to parse output and write to an Excel sheet
79
Analyzing the MRU lists • The combined MRU lists provided filenames and paths to numerous files of interest to the case – Spread out across the local drive, thumb drives, and network shares
• A number of these files were also duplicates of those found in the LNK files – Great for correla9on and soundness of findings
80
More on Browsing History
81
More File Accesses • Web browser history also revealed access to a number of internal web applica9ons that create reports
• The filename of these reports contained the parameters (date, search, etc) used to create them – This was visible in the URL (GET parameter)
82
Web Applica&on Reports
• We then found copies of these reports on the local machine
• Contained informa9on on other employees that the target user was not officially authorized to view
83
“File” Accesses • The “browser” history files also keep records of access to specific files (file:///) – Including full path name and MAC 9me type informa9on
• Analysis of these files on the target machine revealed access to more unauthorized files – Beyond what was found through LNK and MRU analysis
84
Inves&ga&ng Recycle Bin Ac&vity
85
Recycle Bin Forensics • Windows trash can facility for dele9ng files • Files maintained in a hidden directory un9l the user emp9es the Recycle Bin, then insecurely deleted
• The Recycle Bin maintains a history of files deleted within INFO2 files
• INFO2 files contain: – The fullpath of the deleted file – The date the file was moved to the recycle bin – The sequence in which files were moved to the recycle bin
• A great resource on INFO2 analysis can be found at [14]
86
Analyzing the Recycle Bin • Analysis of INFO2 files found on the target machine revealed that many of the files found through previous analysis had been deleted by the user
• The 9mestamps of the dele9on were very close to the exfiltra9on 9mes
• Very damaging evidence
87
Inves&ga&ng Network Share Access
88
Network Share Access • In many corporate environments, including the one in this case, departments store all informa9on on network shares
• Employees should technically only have access to specific files, but implemen9ng this properly is painful
• This makes inves9ga9ng network share access a must in data exfiltra9on cases
89
Analyzing Network Shares
• CurrentControlSet\Services\LanManager\Shares contains informa9on about network shares on the computer – Again, historical records were also available through restore points
– Allowed quick mapping of drive names to places on the network
90
Using Network Shares
• Aber determining which drive leaers corresponded to which network shares, we gathered the filenames that were accessed
• We then sent this informa9on to the IT security team – They were able to find all these files and we subsequently used this informa9on in our report
91
Piecing the Evidence Together
92
Results So Far
• At this point we had a wealth of informa9on: – We knew exfiltra9on occurred over USB devices and Gmail
– We knew which files were transferred and the 9me/date of transfer for some of them
– We knew that contact was made with the future employer and exact details
93
Data to Correlate • We had drive leaers, filenames, and access 9mes from our evidence sources
• Needed to create a 9meline of user ac9vity for each file of interest – File Access – File Transfer (if any) – File Dele9on (if deleted)
94
Performing the Correla&on
• Used access 9mes from LNK files, browser history, etc. to determine when interac9on with a file started
• Used LNK files related to USB drives to determine when copied
• Used browser history and Gmail view index to determine when a file was emailed
• Used INFO2/Recycle Bin to determine if/when a file was deleted
95
Correla&on Results • For many files of interest, we could show that, within a 5 minute 9me period, the file was accessed, exfiltrated, and then deleted
• We could also which files were simply viewed and then discarded
• Made for compelling (and hard to refute) evidence
96
Inves&ga&ng Collusion with Other Employees
97
Next Steps • Our last step was to determine if other employees were involved
• We requested a list of first and last names, user logins, and email addresses from IT security for: – Close co-‐workers of the target – Other people who recently leb the company
• We used this informa9on as our star9ng point…
98
Inves&ga&on Process
• We took the informa9on given from IT to build a Scalpel configura9on file as previously described
• This would (hopefully) find all informa9on related to these other employees…
99
First Clue • Emails were found between the suspect and his secretary, related to the new company
• We then requested the computer of the secretary
• Analysis of her computer revealed sharing of USB thumb drives – Based on USB serial numbers and inves9ga9on of USBSTOR in the registries
100
Further Analysis of the Second PC
• Similar evidence was found on the secretary’s PC as on the ini9al targets – Use of removable media – Downloading of unauthorized files from fileservers
– Emailing of files to outside accounts
• Also found emails to a third person within the organiza9on
101
101
Analyzing Employee Three • Aber finding emails from secretary to employee three, we requested his computer as well
• Analysis of this computer revealed sharing of USB drives by all three employees
• Also revealed contact by employee three to new company
102
Wri&ng a Usable Report
103
Mortal Sins of Repor&ng
• Do NOT: • Include opinions (especially legal ones) – You weren’t asked to be a lawyer – Will hurt your credibility
• Include informa9on you could not verify – Will come up in tes9mony and can hurt your credibility
104
Report Outline
• Every report should contain at least these sec9ons: – Execu9ve Summary – Evidence Catalogue – Findings Sec9ons – Conclusion – Aaachments
105
Report -‐ Execu&ve Summary
• Should contain a high level overview of the case results and be less than one page
• Purpose is to allow execu9ves to quickly understand the outcome of the inves9ga9on
• Should answer three ques9ons: – Was data exfiltrated? – If so, were you able to conclude who was responsible for the exfiltra9on?
– If so, what data was taken and how much of it?
106
Report -‐ Evidence Catalogue
• The rest of the report should be for managers and IT staff who need technical details
• The evidence catalogue should contain these: – A descrip9on of all evidence analyzed – A picture of each piece of evidence – Any unique informa9on (serial numbers) – Hashes of the data, if applicable – How copies of the evidence was acquired
107
Report -‐ Findings Sec&ons
• The bulk of the report should be your findings • Should be broken into logical sec9ons – Similar to how this presenta9on flowed
• Needs to include: – Your exact inves9ga9on methodology – A lis9ng of tool(s) used – The relevance of each finding to the case
108
Report -‐ Conclusion
• The conclusion should be a factual summary of the case – Again -‐ NO opinions
• Can include recommenda9ons for further inves9ga9on – For example, our ini9al report recommended acquiring the computer of the secretary
109
Report -‐ Aeachments
• All processed data from the case, such as the Excel sheets we men9oned, should be included as aaachments to the report – On digital media (CDs, DVDs, etc.) – Or printed, as appropriate
• This makes handling the files (prin9ng, searching, etc) much easier for everyone involved
110
Conclusions • Data exfiltra9on inves9ga9on is a labor-‐intensive process
• Requires a wide range of skills on part of the inves9gator – We only inves9gated Windows machines during this case, and s9ll needed a number of tools and skillsets
• The resul9ng report must be carefully wriaen
111
END OF HOUR 2: Ques&ons / Comments?
• Contact Golden: – [email protected] – [email protected] – @nolaforensix
• Contact Andrew: – [email protected] – @aarc
• Digital Forensics Solu9ons: – Daryl Pfeif (CEO) – [email protected] – 504-‐874-‐0787 – hap://www.digitalforensicssolu9ons.com – hap://dfsforensics.blogspot.com – @dfsforensics
112
References (Click Through) [1] hap://www.digdeeply.com/Scalpel/ [2] hap://dfsforensics.blogspot.com/2011/01/exploring-‐sleuthkits-‐new-‐tskloaddb.html [3] hap://www.forensicswiki.org/wiki/File_Carving [4] hap://www.forensicswiki.org/wiki/USB_History_Viewing [5] haps://blogs.sans.org/computer-‐forensics/files/2009/08/usb_device_forensics_xp_guide.pdf [6] hap://regripper.wordpress.com/ [7] hap://www.forensicswiki.org/wiki/LNK [8] hap://www.forensicfocus.com/link-‐file-‐eviden9ary-‐value [9] hap://computerforensics.parsonage.co.uk/downloads/TheMeaningofLIFE.pdf [10] hap://sourceforge.net/projects/jafat/files/lnk-‐parse/ [11] haps://blogs.sans.org/computer-‐forensics/files/2009/08/usb_device_forensics_vista_win7_guide.pdf [12] hap://www.forensicswiki.org/wiki/List_of_Windows_MRU_Loca9ons [13] hap://www.nirsob.net/u9ls/iehv.html [14] hap://cdnetworks-‐us-‐1.dl.sourceforge.net/project/odessa/ODESSA/White%20Papers/Recycler_Bin_Record_Reconstruc9on.pdf [15] hap://www.argen.org/downloads/files/SAEX.zip
113