Reading Group Presentation: The Power of Procrastination


Published on

This presentation exposes the current threat model of execution stalling malicious code, and multiple pointers to relevant academic research in analysis. I presented these works to a weekly Security and Privacy reading group.

The academic proceeding can be found here:

Published in: Education
  • Be the first to comment

  • Be the first to like this

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

No notes for slide

Reading Group Presentation: The Power of Procrastination

  1. 1. The  Power  of  Procras-na-on   Detec-on  and  Mi-ga-on  of   Execu-on-­‐Stalling  Malicious  Code  
  2. 2. WARNING  •  The  views  presented  in  this  presenta-on  are  my  own  and   do  not  express  the  views  of  the  Johns  Hopkins  University.  •  The  content  presented  in  this  presenta-on  was  extracted   from  mul-ple  academic  conference  proceedings.  •  Most  pictorial  references  were  shamelessly  collected  from   the  internet  and  presented  without  reference.  If  you  find   your  image  and  wish  to  request  that  I  provide  a  reference,   please  email  me  at  the  address  provided  on  my  website:  
  3. 3. Selec-on  Purpose  •  Why  did  I  select  this  paper  to  present?   –  It’s  an  arms  race…  sort  of.      
  4. 4. Stall-code?! Totally ingenious, I have no idea what sort of beautiful mind could have thought this up to thwart our dynamic analysis!!!!At  a  very  well  known  security  lab…  
  5. 5. I hope no one notices my 10klines of copied and pasted GetTickCountcalls… no one taught me about thoseloop thingies. GetTickCount() GetTickCount() GetTickCount() GetTickCount() Meanwhile,  at  the  evil  malware  lair…  
  6. 6. Selec-on  Purpose  •  Proverbial,  “Catch  me  if  you  can…  and  publish!”   –  I  am  very  interested  in  this  sort  of  work  and  it’s   placement  as  security  research.   –  The  analysis  of  malware,  the  mi-ga-on  of  analysis,   the  improvement  of  both.   –  The  economical  model  of  malware  and  security,  but   that’s  my  least  favorite  ;).  
  7. 7. Talk  Outline  1.  50-­‐  View  of  Paper.  2.  Background;  to  include  Previous  Work,   History.  3.  Summary;  to  include  Key  Points  of  the  Paper.  4.  Conclusion  and  Thoughts.  
  8. 8. 50-­‐  View  of  Paper  •  Malware  is  not  going  anywhere.   –  To  maintain  profitability,  directly  dependent  upon   survivability.   –   To  increase  the  probability  of  malware   survivability,  malware  authors  need  to  introduce:     •  Addi-onal  techniques  for  iden-fying  emulated  and   virtual  environments.   •  Crea-ng  non-­‐malicious  branches  of  computa-on  that   obfuscate  the  intent.   •  Complicate  everything!  
  9. 9. 50-­‐  View  of  Paper  •  Dynamic  Analysis,  thus,  is  not  going   anywhere!   –   To  face  the  increasing  complexity  of  malware,  we   must  rely  on  dynamic  behavior-­‐based  analysis   techniques.   •  Execute.   •  Monitor.   •  Record  and  Report.  
  10. 10. Background  •  What  is  malware?   –  Prefix  mal  =  bad.   –  Malicious  soware…  the  kind  you  try  and  talk  your  mom   into  not  downloading.   –  Profitable  incen-ve  for  the  bad  guys.  •  What  is  malware  used  for?   –  [Botnets]  Spam;  the  number  one  being  erec-le   dysfunc-on.   –  [Click  Fraud]  Perpetrate  web  fraud.     –  [Trojans]  Steal  personal  informa-on.     –  “Nefarious  tasks”  …  e.g.,  ANNOY  YOU.  
  11. 11. Background  •  What  protects  you  from  malware?   –  An--­‐virus  scanners.  •  Problem  with  the  tradi-onal  an--­‐virus  scanners?   –  Sta-c  implementa-on;  implementa-on  as  follows:   •  Discover  new  binary  in  the  wild,  test  for  malicious  intent.   •  If  malicious,  create  a  signature  on  the  malware.   •  Push  to  a  networked  database.   •  Clients  update  their  local  signature  database,  scans  for   malware  matching  signature.  
  12. 12. Background  •  Signature-­‐based  An--­‐Virus  Scanners:   AV Start Input New Binary Is binary yes Make Signature malicious? no Push to Net DB Net Client Updates Local DB Local Client Scan on Signature AV Stop
  13. 13. Background  •  What  about  Dynamic  Analysis?   –  Malware  authors  got  smart…  use  encryp-on  and   obfusca-on  (<  crypto  cool)  to  thwart  the  above.   –  Shi  to  run-me  behavior  analysis  of  malware.  •  How  is  this  analysis  possible?   –  Dynamic  Analysis  Systems  (e.g.,  Anubis  in  this  paper).   –  Sandboxing,  Emula-on/Virtualiza-on  (Qemu,   Vmware).  
  14. 14. Background  •  If  I  were  malware,  what  would  I  want  to  do  to   thwart  dynamic  analysis?   1.  Determine  if  I  were  in  a  sandbox  or  emulated   environment.  
  15. 15. Background:  Emulator?  “Anacks  on  Virtual  Machine  Emulators”  
  16. 16. Emulator?  •  EASY  malware  anack  on  vm’s:  refuse  to   operate  maliciously  ;).  •  MODERATE  malware  causes  the  VM  to  fail.  •  RESEARCH  WORTHY  breakout  of  the  VM  and   do  some  damage!  
  17. 17. Emulator?  •  VM’s  not  fully  transparent  as  it’s  not  their   intended  use.  •  Detec-ng  VMWare:     –  B/C  Vmware  relies  on  underlying  hardware  of   execu-on  of  instruc-ons,  it  relocates  sensi-ve   data  structures  such  as  the  Global  Descriptor   Table  while  making  a  Local  Descriptor  Table   (which  Windows  doesn’t  usually  do).    So  look  for   non-­‐zero  LDT.  
  18. 18. Background:  Red  or  Blue  Pill?   “A  fispul  of  red-­‐pills:  How  to  automa-cally   generate  procedures  to  detect  CPU  emulators”    
  19. 19. Red  or  Blue  Pill?  Red-­‐pill  =    1.  One  or  more  machine  instruc-ons  that  return   par-cular  informa-on  about  the  system.   –  E.g.,  the  address  of  the  interrupt  descriptor  table.  2.  Machine  instruc-ons  that  behave  differently  when   executed  in  a  real  system  vs  emulated  system.   –  E.g.,  Under  IA-­‐32  Architecture,  the  x86  instruc-on  for  or  of   the  value  in  register  %bh  with  value  in  memory   0x04(%ebx)  stores  result  in  the  wrong  mem  address  while   being  emluated  in  Qemu.  
  20. 20. Red  or  Blue  Pill?  •  High  Level  of  how  Red-­‐Pill  Genera-on  is  done:   –  Access  to  both  physical  and  emulated   environment.   –  Some  sampling  of  the  input  space  over  all  possible   CPU  start  states.   –  On  random  data  (though  same  for  both   environments),  run  input  on  our  CPU  states  (think   finite  state  automaton).   –  Compare  successful  paths  to  one  another,  return   1  if  emulated  0  if  not  emulated.    
  21. 21. Red  or  Blue  Pill?  
  22. 22. Red  or  Blue  Pill?  •  Obvious  heuris-cs  to  this  model:   –  While  genera-ng  poten-al  red-­‐pills,  you’ll  want  to   discard  unreliable  pills  that  do  not   determinis-cally  report  the  same  output  on  a   repeat  itera-on.   –  Your  CPU  is  an  oracle,  it  will  be  used  to  determine   if  some  sequence  of  bytes  (the  input)  is  a  valid   instruc-on.   –  The  en-re  model  is  trial  based,  so  you  may  feed   invalid  bytes  into  the  model.    
  23. 23. Red  or  Blue  Pill?  •  Actual  Data  reported  in  the  paper:   –  2973  (29k?)  red  pills  detected  for  Qemu.   –  Tested  red  pill  implementa-ons  against  online   malware  scanners  such  as  Anubis.   –  Exci-ng  because  Anubis  is  a  product  of  the  paper,   as  Hasten  is  an  extension  of  it.    
  24. 24. Background:  Anubis   “A  View  on  Current  Malware  Behaviors”    •  Anubis  is  a  dynamic  malware  analysis  plaporm   that  executes  submined  binaries  in  a   controlled  environment.  
  25. 25. Anubis  •  Keeping  Anubis  simple:   –  To  perform  analysis:     •  Public  web  interface  to  submit  binary.   •  Emulated  environment  to  observe:   –  Window  API  calls.   –  File  System  ac-vity.   –  Registry  ac-vity.   –  Network  Traffic.   •  Outputs  a  report  that  compiles  analy-cs  captured  from   the  above.  
  26. 26. Background:  Inspector  “Inspector  Gadget:  Automated  Extrac-on  of  Proprietary  Gadges  from  Malware  Binaries”  
  27. 27. Inspector  •  Purpose:  automa-cally  extract,  from  a  given   binary  executable,  the  algorithm  related  to  a   certain  ac-vity  of  the  sample.  •  Define:  Gadget   –  “stand-­‐alone  component  that  encapsulates  a   specific  behavior;  specifically  an  algorithm  within   a  malware  binary.  
  28. 28. Inspector  
  29. 29. Background  [REMEMBER  THIS  SLIDE?]  •  If  I  were  malware,  what  would  I  want  to  do  to   thwart  dynamic  analysis?   1.  Determine  if  I  were  in  a  sandbox  or  emulated   environment.   2.  Implement  Execu-on-­‐Stalling  Code;  or  stall-­‐ code.  
  30. 30. Summary:  Stalling  Code  Now  we  have  come  full  circle,  back  to  The  Power  of  Procras-na-on.    The  problem  in  this  paper  is  as  follows:  Malware  authors  have  caught  on  to  dynamic  analysis,  and  are  ac-vely  working  to  evade  it.    Such  evasion  techniques  include  the  technique  of  stalling  code.      
  31. 31. Stalling  Code  •  What  do  anackers  want  to  exploit?     1.  Time.    The  -me  that  a  system  can  spend  to   execute  a  single  sample  is  limited.     Malware  authors  know  this,  and  as  such  they  can   cra  their  code  so  that  execu-on  takes  much  longer   inside  the  analysis  (emulated)  environment.     Even  Bener  –  that  same  code  will  execute  quickly  on   a  host  system  that  is  not  emulated!    
  32. 32. Stalling  Code  •  Contribu-ons:   –  First  approach  to  detect  and  mi-gate  stalling   code.   –  Real-­‐world  system  implementa-on  (Hasten  which   is  an  extension  to  the  dynamic  analysis  tool   Anubis).  
  33. 33. Stalling  Code  This  is  horrid  in  the  emulated  environment  because  GetTickCount  is  monitored,  thus  invoking  a  pair  of  log  func-ons  for  each  call.    Thus  logging  called  60  million  -mes  ~  10  hours  stall.  
  34. 34. Stalling  Code  •  Hasten  Modes  of  Opera-on:   –  Monitor  Mode:  lightweight  observa-on  of  all  threads  of  the   process.    Measure  the  progress  of  each  thread,  and  id  execu-on   in  stall  region.   –  Passive  Mode:  Detects  slow  progress;  record  informa-on  about   the  code  blocks  in  ques-on;  build  par-al  control  flow  graph   (CFG)  of  the  non-­‐progressing  thread;  whitelist  code  in  the   stalling  region  (to  include  all  code  in  the  loop  body),  and;  turn   off  detailed  malware  introspec-on  for  these  regions.   –  Ac-ve  Mode:  Interfere  with  malware  execu-on  by  using  CFG  to   id  all  nodes  associated  with  condi-onal  jumps  that  are  part  of   the  stalling  loop  and  have  one  successor  node  that  is  not  part  of   the  whitelisted  region,  and;  flips  the  condi-onal  equality  and   exits  the  loop  (inconsistencies  can  and  will  occur).  
  35. 35. Stalling  Code  Monitoring  Mode  Specifics    •  Monitor  the  progress  of  a  running  program  by   inspec-ng  the  system  calls  that  it  invokes.      •  Aer  a  thread  has  been  scheduled  for  -me  t,  the   system  employs  five  detectors  to  evaluate  the  system   calls  that  have  been  observed.      •  If  >  1,  then  switch  to  passive  mode.  *  This  is  dependent  on  your   selected  t  value;  large  t  are  more  resistant  to  short  repeated  behavior  and  small  t  is  faster   detec-on  of  abnormal  ac-vity.  
  36. 36. Stalling  Code  1.  Too  few  successful  system  calls.  (insufficient   progress)  2.  Too  many  successful  system  calls.  (overhead)  3.  To  many  failed  system  calls.  (overload  b/c  full  logging)  4.  Too  many  iden-cal  system  calls.  (GetTickCount)  5.  Too  diverse  system  calls.  (Randomized  system  calls)  
  37. 37. Stalling  Code  •  Passive  Mode  
  38. 38. Stalling  Code  •  Ac-ve  Mode   –  Men-on  tain-ng.  
  39. 39. References  •  Clemens  Kolbitsch,  Engin  Kirda,  Christopher  Kruegel.  The  Power  of  Procras-na-on:  Detec-on   and  Mi-ga-on  of  Execu-on-­‐Stalling  Malicious  Code.  •  Ulrich  Bayer,  Imam  Habibi,  Davide  Balzaro},  Engin  Kirda,  and  Christopher  Kruegel.    A  View   on  Current  Malware  Behaviors.  •  Roberto  Paleari,  Lorenzo  Mar-gnoni,  Giampaolo  Fresi  Roglia,  Danilo  Bruschi.    A  fispul  of  red-­‐ pills:  How  to  automa-cally  generate  procedures  to  detect  CPU  emulators.  •  Clemens  Kolbitsch,  Engin  Kirda,  Christopher  Kruegel,  Thorsten  Holz.    Inspector  Gadget:   Automated  Extrac-on  of  Proprietary  Gadgets  from  Malware  Binaries.  •  Peter  Ferrie.  Anacks  on  Virtual  Machine  Emualtors.  •  Min  Gyung  Kang,  Heng  Yin,  Steve  Hanna.    Emula-ng  Emula-on-­‐Resistant  Malware.  
  40. 40. Thanks!    Ques-ons?