Investigating Cooridinated Data Exfiltration

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


26

SAM file

What user accounts are on the machine?


27

SYSTEM file

Which &mezone does the

computer use?


28

NTUSER.dat file

Which files were recently

accessed by a par&cular user?


29

NTUSER.dat file

Which URLS were typed recently by a par&cular user?


30

SOFTWARE file

Which programs are installed on the machine? Which license keys are in

use?


31

NTUSER.dat file

Which programs run automa&cally when a par&cular user logs in?


32

SOFTWARE file

Which programs run automa&cally when ANY user

logs in?


33

750GB USB hard drives (same type)

Two Jumpdrive Elite thumbdrives

SYSTEM file

What has been plugged in?


34

SYSTEM file Networking info


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

Investigating Cooridinated Data Exfiltration

Technology

Transcript of Investigating Cooridinated Data Exfiltration