Leveraging  Splunk  for  finding  needle  in  the  haystack  

twi%er.com/abhaythehero  

Introduc5on    

•  What  is  it  ?  Tool.  For  searching  and  exploring  data  -­‐>  Extrac5ng  informa5on  #LikeABoss  

•  Who  uses  it  ?  Sysadmins,  Network  admins,  Infosec  people.  

•  Why  use  it  ?  Because  you  want  to  find  needle  in  the  haystack.  #LikeABoss  

Features    

•  Free  if  you  index  upto  500MB  daily  •  Easy  to  install.    •  Powerful  Web  interface.  Excellent  UI.  •  Capability  to  accept  data  over  network  from  mul5ple  sensors  

•  Almost  real-­‐5me  genera5on  of  alerts  •  Teaming  up.  Access  controls.  Etc  ..  •  Reports  with  great  visuals  !!  •  And  much  more  …..    

How  it  manages  to  do  stuff  ?  

•  Index  Time  Processing  (when  splunk  is  accep5ng  data):  Read  data  from  source.  Extract  5mestamp.  Break  stuffs  into  ‘events’  based  on  5mestamp  

•  Search  Time  Processing  (when  you  search):  Events  which  have  matching  ‘even&ype’  to  the  search  term,  are  retrieved  from  index.    

             -­‐  Image  taken  from  the  book  Exploring  Splunk  

SPL  Search  commands  are  used  to  take  indexed  data  and  filter  unwanted  informa5on,  extract  more  informa5on,  calculate  values,  transform  them,  and  sta5s5cally  analyze  results.  

   

Enough  Theory  already….?  

Lets  inspect  some    real  world  scenario  

 

Someone  got  hacked  K  

By  some  0  –  day  vulnerability  

Payback  5me  bitchezz!!  

Payback  ini5al  goal  set.  Targets  locked  :      •  ‘Check  your  6’  aka  Log  analysis  •  1  months  worth  of  apache,  mysql,  bp  logs  obtained  by  our  hos5ng  provider  

•  Find  the  vulnerability  PoC.    •  Find  the  a%acker  methodology.  

Lets  take  the  apache  logs  here..    

1.  garage4hackers.com  was  redirec5ng  to  garage4hackers.com/ac5vity.php  

           Inference  :  Defacement  page  was  uploaded              by  manipula5ng  clean  version  of  ac5vity.php    Lets  do  a  à  index=”<index  name>”  uri_path="*/ac5vity.php*"  

2.  The  defacement  page  was  sta5c.  While  the                earlier  clean  ac5vity.php  would  return                different  results  each  5me.  And  that  result              page  won’t  be  of  same  size  every5me  ;)              Inference:  We  should  check  the  response              bytes  which  the  server  sends  each  5me  for  a                request.    Lets  do  a  à  index=”<index  name>"  uri_path="*/ac5vity.php*"  |  top  bytes  

3.  25424  is  definitely  the  size  of  defaced  page            returned  by  server.  Because  of  sta5c  value  for          each  response.  Also  we  saved  the  defaced          page  on  disk  and  checked  it  size.  (which          enforced  the  theory)                    Inference:  The  first  5me  25424  bytes  are            returned,  it  could  be  the  a%acker  wan5ng  to              test  the  result  aber  uploading  the  defacement          page              

4.          25424  bytes  are  returned  for  the                          defacement  page  by  the  server.  Lets  find                    out  who  1st  got  it  !      Lets  do  a  à  index=”<index  name>"  bytes=25424  |  reverse    And  note  the  first  5mestamp.  Start  digging  near  the  5mestamp  ;)      

Conclusions  

•  We  got  the  defacer  IP  •  We  enforced  the  fact  with  co  –  rela5ons  with  MySQL  logs  (  can’t  show  you  that  :P)  

•  We  also  dug  out  more  to  find  the  fact  that  the  defacer  IP  !=  the  IP  which  first  exploited  the  vulnerability    

•  We  got  an  idea  in  which  module  the  vulnerability  was.  

                                               Of  course  payback  was  much  more  !                      But  that  is  the  story  for  another  5me  J    

Till  then  w00t  w00t