Investigating Cooridinated Data Exfiltration


Published on

My presentation on investigating coordinated data exfiltration with Dr. Golden Richard at GFIRST 2011.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Investigating Cooridinated Data Exfiltration

  1. 1. 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    
  2. 2. 2   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)      
  3. 3. 3   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  
  4. 4. 4   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  
  5. 5. 5   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  
  6. 6. 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  
  7. 7. 7   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]  
  8. 8. 8   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  
  9. 9. 9   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.)  
  10. 10. 10   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  
  11. 11. 11           Our  Scenario  
  12. 12. 12   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  
  13. 13. 13   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  
  14. 14. 14           Inves&ga&on    
  15. 15. 15   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  
  16. 16. 16   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  
  17. 17. 17   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  
  18. 18. 18         Inves&ga&ng     Removable  Media    
  19. 19. 19   First  Steps  •  USB  history  analysis  typically  requires   analyzing  two  sources:   –  USBSTOR  registry  informa9on   –  The  setupapi.log    file   –  Renamed  and  split  under  Win7:   •  and  •  Details  aber  a  brief  discussion  of  the  Windows   registry  
  20. 20. 20           Briefly:  Windows  Registry    
  21. 21. 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  
  22. 22. 22   Registry:  Windows  9x  •  On  Windows  95/98:  •  “system.dat”  and  “user.dat”  files  •  If  mul9ple  users,  look  in  Windowsprofiles<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. 23. 23   Registry:  NT/Win2K/XP  •  “ntuser.dat”   –  List  of  most  recently  used  files   –  Each  user  has  a  separate  “ntuser.dat”  file   –  documents  and  sesngsuser  •  “default”  in  <windowsdir>system32config   –  Ini9al  system  sesngs  •  “SAM”   –  User  account  sesngs,  security  sesngs  •  “security”   –  Security-­‐related  sesngs  •  “sobware”   –  Installed  programs,  sesngs,  usernames,  passwords  •  “system”   –  Misc.  system  sesngs  
  24. 24. 24  Last  Write  Times  for  Registry  Keys  
  25. 25. 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. 26. 26   What  user   accounts  are  on   the  machine?   SAM  file  Copyright  2004-­‐2011  by  Golden  G.  Richard  III.  
  27. 27. 27   Which  &mezone   does  the   computer  use?   SYSTEM  file  Copyright  2004-­‐2011  by  Golden  G.  Richard  III.  
  28. 28. 28   Which  files  were   recently     accessed  by  a   par&cular    user?   NTUSER.dat  file  Copyright  2004-­‐2011  by  Golden  G.  Richard  III.  
  29. 29. 29   Which  URLS  were   typed  recently  by   a  par&cular  user?   NTUSER.dat  file  Copyright  2004-­‐2011  by  Golden  G.  Richard  III.  
  30. 30. 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. 31. 31   Which  programs  run   automa&cally  when  a   par&cular  user  logs  in?   NTUSER.dat  file  Copyright  2004-­‐2011  by  Golden  G.  Richard  III.  
  32. 32. 32   Which  programs   run  automa&cally   when  ANY  user   SOFTWARE  file   logs  in?  Copyright  2004-­‐2011  by  Golden  G.  Richard  III.  
  33. 33. 33   Two  Jumpdrive   Elite  thumbdrives   750GB  USB  hard   drives  (same  type)   What  has  been     plugged  in?   SYSTEM  file  Copyright  2004-­‐2011  by  Golden  G.  Richard  III.  
  34. 34. 34   Networking  info   SYSTEM  file  Copyright  2004-­‐2011  by  Golden  G.  Richard  III.  
  35. 35. 35   Disk  info   SYSTEM  file  Copyright  2004-­‐2011  by  Golden  G.  Richard  III.  
  36. 36. 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  
  37. 37. 37   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   CurrentControlSetEnumUSBSTOR  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!  
  38. 38. 38   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    
  39. 39.   39   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  
  40. 40. 40   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    
  41. 41. 41   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  
  42. 42. 42   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  
  43. 43. 43  USB  Analysis  Process  [4][5][11]  
  44. 44. 44         Inves&ga&ng     Network-­‐Based  Exfiltra&on  
  45. 45. 45   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  
  46. 46. 46   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?  
  47. 47. 47   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  
  48. 48. 48   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  
  49. 49. 49   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  
  50. 50. 50   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)  
  51. 51. 51   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  
  52. 52. 52   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!  
  53. 53. 53   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  
  54. 54. 54    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)  
  55. 55. 55         Inves9ga9ng     Web  Browser  Ac9vity  
  56. 56. 56   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  
  57. 57. 57  Analyzing  Browser  History  Using  IEHistoryView  
  58. 58. 58  Analyzing  Cache  Contents  Using  IECacheView  
  59. 59. 59  Analyzing  HTTP  Cookies  
  60. 60. 60   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.  
  61. 61. 61   Analyzing  Flash  Cookies  •  The  loca9on  of  the  files  is  opera9ng  system   dependent:   – hap:// Local_Shared_Object#File_loca9ons  •  A  few  tools  exist  for  analysis,  but  none  seem   completely  stable:   – Minerva              -­‐  hap:// minerva   – SOLReader    -­‐  hap:// solreader.php  
  62. 62. 62   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  
  63. 63. 63  END  OF  HOUR  1:  Ques&ons  /  Comments?   •  Contact  Golden:   –   –   –  @nolaforensix   •  Contact  Andrew:   –   –  @aarc   •  Digital  Forensics  Solu9ons:   –  Daryl  Pfeif  (CEO)   –   –  504-­‐874-­‐0787     –  hap://   –  hap://   –  @dfsforensics      
  64. 64. 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    
  65. 65. 65           Inves&ga&ng  Files  Transferred   During  the  Exfiltra&on  
  66. 66. 66   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  
  67. 67. 67   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    
  68. 68. 68   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  
  69. 69. 69           LNK  File  Analysis  
  70. 70. 70   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)  
  71. 71. 71  lnk-­‐parse  [10]  on  a  Local  File   MAC  Times  of  Target  File   Target  Hard  Drive   Target  File  
  72. 72. 72  parse-­‐lnk  Output  for  Network  Share   MAC  Time  of  Target  File   Size  of  File   The  network  share  related  to   the  file,  including  path  
  73. 73. 73   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…  
  74. 74. 74   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  
  75. 75. 75   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]  
  76. 76. 76           Analyzing  MRU  Lists  
  77. 77. 77   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  
  78. 78. 78   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]  
  79. 79. 79   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  
  80. 80. 80   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  
  81. 81. 81           More  on  Browsing  History  
  82. 82. 82   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)  
  83. 83. 83   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  
  84. 84. 84   “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  
  85. 85. 85         Inves&ga&ng     Recycle  Bin  Ac&vity  
  86. 86. 86   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]  
  87. 87. 87   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  
  88. 88. 88         Inves&ga&ng     Network  Share  Access  
  89. 89. 89   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  
  90. 90. 90   Analyzing  Network  Shares  •  CurrentControlSetServicesLanManagerShares   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  
  91. 91. 91   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    
  92. 92. 92           Piecing  the  Evidence  Together  
  93. 93. 93   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  
  94. 94. 94   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)  
  95. 95. 95   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  
  96. 96. 96   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  
  97. 97. 97         Inves&ga&ng  Collusion     with  Other  Employees  
  98. 98. 98   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…  
  99. 99. 99   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…  
  100. 100. 100   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  
  101. 101. 101   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  
  102. 102. 102   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  
  103. 103. 103           Wri&ng  a  Usable  Report  
  104. 104. 104   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    
  105. 105. 105   Report  Outline  •  Every  report  should  contain  at  least  these   sec9ons:   –  Execu9ve  Summary   –  Evidence  Catalogue   –  Findings  Sec9ons   –  Conclusion   –  Aaachments  
  106. 106. 106   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?  
  107. 107. 107   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  
  108. 108. 108   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  
  109. 109. 109   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    
  110. 110. 110   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  
  111. 111. 111   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  
  112. 112. 112  END  OF  HOUR  2:  Ques&ons  /  Comments?   •  Contact  Golden:   –   –   –  @nolaforensix   •  Contact  Andrew:   –   –  @aarc   •  Digital  Forensics  Solu9ons:   –  Daryl  Pfeif  (CEO)   –   –  504-­‐874-­‐0787     –  hap://   –  hap://   –  @dfsforensics      
  113. 113. 113   References  (Click  Through)  [1]  hap://  [2]  hap://­‐sleuthkits-­‐new-­‐tskloaddb.html  [3]  hap://  [4]  hap://  [5]  haps://­‐forensics/files/2009/08/usb_device_forensics_xp_guide.pdf  [6]  hap://  [7]  hap://  [8]  hap://­‐file-­‐eviden9ary-­‐value  [9]  hap://  [10]  hap://­‐parse/  [11]  haps://­‐forensics/files/2009/08/usb_device_forensics_vista_win7_guide.pdf  [12]  hap://  [13]  hap://  [14]  hap://cdnetworks-­‐us-­‐  [15]  hap://