Leveragong splunk for finding needle in the Haystack
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
13,691
On Slideshare
13,188
From Embeds
503
Number of Embeds
3

Actions

Shares
Downloads
6
Comments
0
Likes
1

Embeds 503

http://null.co.in 489
https://twitter.com 9
http://staging.null.co.in 5

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Leveraging  Splunk  for  finding   needle  in  the  haystack   twi%er.com/abhaythehero  
  • 2. 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  
  • 3. 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  …..    
  • 4. 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.    
  • 5.              -­‐  Image  taken  from  the  book  Exploring  Splunk  
  • 6. SPL   Search  commands  are  used  to  take  indexed  data  and  filter   unwanted  informa5on,  extract  more  informa5on,  calculate   values,  transform  them,  and  sta5s5cally  analyze  results.      
  • 7. Enough  Theory  already….?   Lets  inspect  some     real  world  scenario    
  • 8. Someone  got  hacked  K  
  • 9. By  some  0  –  day  vulnerability  
  • 10. 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.  
  • 11. 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*"  
  • 12. 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  
  • 13. 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    
  • 14. 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  ;)      
  • 15. 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.  
  • 16.                                                Of  course  payback  was  much  more  !                      But  that  is  the  story  for  another  5me  J     Till  then  w00t  w00t