Who  is  Exabeam?  A  security  analy.cs  company  founded  in  2013.  We  provide  user  behavior  intelligence  by  leveraging  exis.ng  SIEM  and  log  management  data  repositories.  Our  technology  detects  modern  cyber  aDacks  and  simplifies  security  opera.ons.  

Sylvain  Gil  Co-­‐founder  and  VP  Products  

1

56  Million  customers  3  Million  customers   4.5  Million  customers   215  Employees  

83+  Million   1,000  Stores   3.6  Million  Employees  

What  do  nearly  all  of  the  worst  data  breaches  have  in  common?  

100,000  customers  1.1  Million  customers   SHll  Unknown  40  Million  customers  

Stolen  user  credenHals  were  involved  in  every  case  •  ADackers  impersonate  employees  

using  stolen  creden.als  

•  Able  to  move  throughout  the  network  avoiding  detec.on  

•  The  vic.ms  learned  about  their  breach  through  outside  sources  

Most  companies,  if  not  all,  had  made  significant  investments  in  SIEM,  firewall,  anH-­‐malware  and  IPS.  

ATTACK  

STOLEN  CREDENTIALS  

COMMAND  &  CONTROL  

LATERAL  MOVEMENT  

EXTENT  OF  IMPACT  

4  Sou r ce :   F i r eEye  Mand ian t  APT1   r epo r t   ( F eb   2013 )  

IniHal  Recon  

IniHal  Compromise  

Establish  Foothold  

Escalate  Privileges  

Internal  Recon  

Move  Laterally  Maintain  

Presence  

Complete  Mission  

Hours   Weeks  or  Months   Hours  

The  Typical  A`ack  Chain  

5  Sou r ce :   F i r eEye  Mand ian t  APT1   r epo r t   ( F eb   2013 )  

POSSIBLE  CREDENTIAL  USE  

IniHal  Recon  

IniHal  Compromise  

Establish  Foothold  

Escalate  Privileges  

Internal  Recon  

Move  Laterally  Maintain  

Presence  

Complete  Mission  

Hours   Weeks  or  Months   Hours  

Use  of  Stolen  CredenHals  

Undetected  A`ack:  South  Carolina  IRS  At  various  stages  of  this  aDack,  important  anomalies  went  unno.ced:  

•  VPN  access  off  hours  •  VPN  access  from  new  device  

•  Unusual  access  to  servers  •  Crawling  of  sensi.ve  servers  •  Copy  of  large  DB  backups    

Spear  Phishing  

VPN  in  with  stolen  creden.als  

Server  &  App  Recon  

File  Data  TheZ  

Exfiltra.on  

13  AUGUST  

27  AUGUST  

29-­‐11  AUG/SEPT  

12  SEPTEMBER  

13-­‐14  SEPTEMBER  

6  

Undetected  A`ack:  South  Carolina  IRS  At  various  stages  of  this  aDack,  important  anomalies  went  unno.ced:  

•  VPN  access  off  hours  •  VPN  access  from  new  device  

•  Unusual  access  to  servers  •  Crawling  of  sensi.ve  servers  •  Copy  of  large  DB  backups    

Spear  Phishing  

VPN  in  with  stolen  credenHals  

Server  &  App  Recon  

File  Data  TheZ  

Exfiltra.on  

13  AUGUST  

27  AUGUST  

29-­‐11  AUG/SEPT  

12  SEPTEMBER  

13-­‐14  SEPTEMBER  

7  

Undetected  A`ack:  South  Carolina  IRS  At  various  stages  of  this  aDack,  important  anomalies  went  unno.ced:  

•  VPN  access  off  hours  •  VPN  access  from  new  device  

•  Unusual  access  to  servers  •  Crawling  of  sensi.ve  servers  •  Copy  of  large  DB  backups    

Spear  Phishing  

VPN  in  with  stolen  creden.als  

Server  &  App  Recon  

File  Data  TheZ  

Exfiltra.on  

13  AUGUST  

27  AUGUST  

29-­‐11  AUG/SEPT  

12  SEPTEMBER  

13-­‐14  SEPTEMBER  

8  

Undetected  A`ack:  South  Carolina  IRS  At  various  stages  of  this  aDack,  important  anomalies  went  unno.ced:  

•  VPN  access  off  hours  •  VPN  access  from  new  device  

•  Unusual  access  to  servers  •  Crawling  of  sensi.ve  servers  •  Copy  of  large  DB  backups    

Spear  Phishing  

VPN  in  with  stolen  creden.als  

Server  &  App  Recon  

File  Data  Thee  

Exfiltra.on  

13  AUGUST  

27  AUGUST  

29-­‐11  AUG/SEPT  

12  SEPTEMBER  

13-­‐14  SEPTEMBER  

9  

Undetected  A`ack:  South  Carolina  IRS  At  various  stages  of  this  aDack,  important  anomalies  went  unno.ced:  

•  VPN  access  off  hours  •  VPN  access  from  new  device  

•  Unusual  access  to  servers  •  Crawling  of  sensi.ve  servers  •  Copy  of  large  DB  backups    

Spear  Phishing  

VPN  in  with  stolen  creden.als  

Server  &  App  Recon  

File  Data  TheZ  

ExfiltraHon  

13  AUGUST  

27  AUGUST  

29-­‐11  AUG/SEPT  

12  SEPTEMBER  

13-­‐14  SEPTEMBER  

10  

Challenges  in  DetecHng  Stolen  CredenHal  Use  

Million  ways  to  

compromise  

ADack  may  not  use  malware  

We  don’t  know  what’s  good  or  bad  

11  

Using  Splunk  for  Behavior  Profiling  

12  

Define  Characteris.cs  of  User  Behavior  

Create  a  Baseline  

Detect  and  Score  Anomalies  

1   2   3  

Splunk  Benefits  

1.  Access  to  historical  log  data  =  immediate  ability  to  baseline  

2.  Log  data  spans  en.re  stack  from  network  to  app  transac.ons  

3.  Unstructured  data:  collect  first,  get  insight  later  

4.  Powerful  search  and  sta.s.c  func.ons  

5.  You  already  own  it!  

13  

Defining  User  Behavior  CharacterisHcs  

•  Challenge  fundamentals  of  aDack  chain  •  How many assets accessed •  When do activities take place •  What accounts connect to what machines •  Did user ever connect from this country

•  Rely  on  likely  available  log  sources  •  Windows Domain Controllers •  Windows Servers •  SSH logins •  Remote Access VPN •  Single Sign-On

14  

1  

Windows  DC  and  Server  logs  

•  Use  Splunk  Universal  Forwarder  for  out-­‐of-­‐the-­‐box  fields  extrac.on  h"p://docs.splunk.com/Documenta4on/Splunk/6.1.3/Data/Monitorwindowsdata  

•  Domain  Controllers  event  codes  

•  Other  Windows  Servers  or  Worksta.ons  

•  Make  sure  to  log  successful  logins:  GPO  >  Audit  Logon  Events  

15  

(EventCode=4769 OR EventCode=673)

(EventCode=4624 OR EventCode=528)

Fields  of  Interest  in  a  Windows  DC  Logon  Log  Name:            Security  Source:                MicrosoZ-­‐Windows-­‐Security-­‐Audi.ng  Date:                    10/27/2009  9:58:02  PM  Event  ID:            4769  Task  Category:  Kerberos  Service  Ticket  Opera.ons  Level:                  Informa.on  Keywords:            Audit  Success  User:                    N/A  Computer:            dcc1.Logis.cs.corp  Descrip.on:        A  Kerberos  service  .cket  was  requested.  Account  Informa.on:  

 Account  Name:    johndoe@LOGISTICS.CORP    Account  Domain:    LOGISTICS.CORP    Logon  GUID:    {9A6EBA7B-­‐42EE-­‐E3E3-­‐EC65-­‐5DD3DD4C77A9}  

Service  Informa.on:    Service  Name:    TERMSERV1$    Service  ID:    S-­‐1-­‐5-­‐21-­‐1135140816-­‐2109348461-­‐2107143693-­‐1000  

Network  Informa.on:    Client  Address:    192.168.23.189    Client  Port:    0  

Addi.onal  Informa.on:    Ticket  Op.ons:    0x40810000    Ticket  Encryp.on  Type:  0x12    Failure  Code:    0x0    Transited  Services:  -­‐   16  

•  _Hme    

•  AccountName    Look  for  non  $  values  to  filter  out  computer  logons  

•  ServiceName  Computer  being  accessed  

•  ClientAddress  Misleading,  oZen  IP  of  des.na.on  

CreaHng  a  Baseline  

•  We  want  to  gather  daily  usage  stats  per  user  •  We  cannot  afford  to  search  over  en.re  history  everyday  

•  Solu.on  à  Splunk  Summary  Indexing  •  Similar to Map Reduce concept

17  

Search  logs  daily  

Calculate  stats  

Save  stats  to  index  

Search  index  

2  

Demo:  Storing  daily  user  stats  in  summary  index  

18  

EventCode=4769| bin _time span=1d| stats dc(ServiceName) by _time user| rename dc(ServiceName) as count| collect index=userstats

We  store  a  daily  count  of  servers  per  user  and  save  this  info  in  the  userstats  index  

DetecHng  and  Scoring  Anomalies  

•  Run  sta.s.cal  analysis  on  daily  stats  stored  in  summary  index  

•  Splunk  offers  several  possibili.es:  •  Xth percentile analysis – percX(Y)

•  Standard deviation analysis – stdev

•  Build your own with lookups

19  

3  

PercenHle  analysis  

20  

index=UserStats AccountName=bob| eventstats p95(AssetCount) as threshold| where AssetCount>threshold

•  Returns  days  where  bob  accessed  more  than  his  95th  percen.le  number  of  assets  •  Runs  in  seconds  even  for  several  months  of  data  

Standard  DeviaHon  

21  

msgType=juniper-vpn-*| transaction user startswith="msgType=*start" endswith="msgType=*end"| eval type="VpnDuration"| table type,_time,user,duration| collect userstats

index=userstats type="VpnDuration”| eventstats mean(duration) as avgdur, stdev(duration) as stdevdur by user| eval threshold=tonumber(avgdur)+3*tonumber(stdevdur)| where duration>threshold| table user,duration,threshold

VPN  session  dura.on  

First  occurrence  with  Lookups  

22  

eventtype=vpn-login| eval key=user+"-"+src_host | eval value=1| dedup key | table key,value| outputlookup UserVpnHosts.csv

eventtype=vpn-login earliest=-2d@d latest=-1d@d| eval key=user+"-"+src_host | lookup UserVpnHosts.csv key OUTPUT value as result| where isnull(result) | table user,host

Known  VPN  endpoints.  We  store  all  past  endpoints  of  each  user  in  a  lookup.  We  then  filter  for  endpoints  that  are  not  found  in  that  lookup.  

AggregaHng  Anomalies  and  Scoring  

•  We  want  to  sum  up  anomalies  and  create  a  daily  score  per  user  •  Each  anomaly  detec.on  search  will  increment  the  daily  score  

•  Solu.on  à  Splunk  Summary  Indexing    

23  

Run  detec.on  searches  on  

index  

Assign  score  and  reason  

Collect  in  UserScores  index  

Roll  up  daily  score  with  |  stats  sum()  

Keeping  Score  and  Reasons  

24  

index=UserStats AccountName=bob| eventstats p95(AssetCount) as threshold| where AssetCount>threshold| eval Reason="Asset count exceeded threshold of $threshold”| eval Score="20”| fields _time,AccountName,AssetCount,Score,Reason| collect index=userscores

•  Comments  

Demo:  Aggregate  and  Trend  User  Score  

25  

index=userscores| bin _time span=1d| stats sum(Score) as Score, values(Reason) as Reasons by _time,user| table user,_time,Score,Reasons

We  sum  up  the  scores  per  user  per  day  and  collect  the  associated  reasons  

Possible  Caveats  

•  There  may  not  be  enough  data  for  the  baseline  to  be  valid  •  New users, new machines

•  Exabeam uses a proprietary Confidence Factor algorithm

•  Session  Tracking  •  Logs are stateless by nature, hard to track identity switches

•  User  Interface  •  Representing log events of diff. nature alongside anomalies can be tricky

•  Peer  analysis  •  New behaviors should be compared to the users’ peers (lookups?)

26  

The  Exabeam  Approach  IT SECURITY  

MACHINE  DATA  

LOG  MANAGEMENT  

ERP   CMDB  

ACTIVE  DIRECTORY  

HRMS   ITMS  

Log  ExtracHon  &  Context  

User  Session  Tracking  

Behavior    Analysis  

Risk    Engine  

+   +   +  

Research  &  Community  Insights  

SCORE

75  Risk  Scoring  Incident  Ranking  A`ack  DetecHon   27  

Exabeam  Tracking  of  User  Sessions  

28  

•  Context  on  who  the  user  is  •  Peer  group  and  manager  info  

•  Risk  trend  over  .me  

•  Quick  view  of  risk  reasons  

Session  Timeline  

29  

•  Lists  user  ac.vi.es  from  logon  to  logoff  

•  Track  reasons  per  event  and  associated  score  

•  Transfers  risk  from  one  day  to  the  next  

Takeaways  

•  Add  user  behavior  and  anomaly  detec.on  to  your  rules  

•  Start  simple  with  logs  you  have  and  basic  analysis  

•  Use  a  scoring  approach  to  rank  risk  

30  

Ques.ons?      

Visit  our  booth  for  a  demo  www.exabeam.com  

31  

Thank You

Questions

CONFIDENTIAL