Detecting Intraenterprise Scanning Worms based on Address Resolution

1

• Detecting Intra-enterprise Scanning Worms based
  on Address Resolution
• David Whyte, Paul van Oorschot, Evangelos Kranakis

2
Outline

• Internet Environment
• Scanning Worm Propagation Characteristics
• Address Resolution (ARP) Approach
• Results
• Limitations
• Conclusions

3
Dsheild Report - December 6, 2005
Top Attacker 216.81.35.172
Most Attacked Port 445
4
Worm Outbreaks

• Sapphire/Slammer worm Jan 25, 2003
• Fastest spreading worm yet
• 90 compromised in first 10 minutes
• August 2003 the Month of Worms
• SoBig.F 1 mass mailing virus of all time
• Blaster/LovSan/Welchia/Nachi
• Witty worm March 2004
• Buffer overflow in a suite of security products
• Use of a hit-list?

5
Countermeasure Challenges

• Propagation speed renders human-based defensive
  strategies non-effective
• Security patches frequent, large and sometimes
  broken
• Slammer fix SQL Server 2000 SP2 three parts 26MB
  to 506MB
• sql2kdeskfullsp2.exe 390 MB

6
Countermeasure Challenges

• Active response (i.e. containment and
  suppression)
• risky (self imposed DoS)
• The IDS that cried Worm!!
• (Snort) alert UDP any any -gt any 1434 (msg"SQL
  Slammer Worm" rev1 content"726e51686f
  756e746869636b43684765")
• (Dragon) NAMESMBDCOM-OVERFLOW SIGNATURET D A B
  2 0 135 SMBDCOM-OVERFLOW /5c/00/43/00/24/00/5c/00
  /00/00/00/00/00/00/00/00/00/00/00/00/
  00/00 , /01/10/08/00/cc/c c/cc/cc

7
Solution/Problem

• Automated countermeasures are required for worm
  containment and suppression
• Worm propagation detection methods need to
• Detect propagation quickly
• Detect propagation accurately
• Detect propagation of varying rates
• Detect zero-day worms

8
Scanning Worm Characteristics

• Scanning worms can employ a variety of strategies
  to infect systems
• Topological scanning
• Slow scanning
• Fast scanning
• Topological scanning
• Use of local information to find victims
• Potential to be very fast

9
Enterprise Network
10
ARP-based Scanning Worm Detection Approach

• Focus on protecting the internal network
• Network 'hard crunchy' exterior 'soft gooey'
  middle
• Limit damage within network cell
• Behavioral 'signature'
• Based on anomalous behavior
• ARP request is a 'scan'
• Premise measurable changes in amount/pattern ARP
  activity
• 3-factor anomaly score

11
3-Factor Anomaly Score

• Peer-list previous connection activity
• ARP activity 'expected' amount of ARP activity
  vs. observed ARP activity (mean sd)
• Internal network dark space ARP requests to
  non-existent systems
• Factor weighting is configurable
• When aggregate score from three factors exceeds
  threshold in specified time window ALERT!!

12
Set-up and Training Period

• Divide network into cells (broadcast domains)
• Training period
• Gather ARP broadcast requests
• Construct peer-list
• Calculate expected ARP activity for each system
• Identify internal network address darkspace

13
Software Developed

• Prototype uses Perl modules and libpcap
• High-level design
• Packet Processing Engine (PPE)
• Extract features from ARP broadcast traffic
• ARP Correlation Engine (ACE)
• Create individual system ARP statistics
• Create peer-list
• Observe ARP request activity to generate 3-factor
  anomaly score
• Generate alerts

14
Testing Environment

• Two-week training period
• Two-week test run
• Lab/production network
• One quarter Class C network
• DNS/mail/web
• Small user population
• Linux OS
• Closed network

15
ARP Statistics (Training Period)
16
Alert Thresholds

• Common threshold
• Function-specific threshold
• Server/workstation
• Threshold as well as anomaly factor weighting is
  configurable
• Prototype can give default threshold based on
  training period
• (r3) 3 scans within a 3 minute window

17
Testing Results (Alerts) 2-week Period
18
False Positive Analysis

• Increasing scan threshold reduces false positives
  (our network r 3 only 5 false positives in a
  two week period)
• Function-specific vs. common threshold approach
  reduced false positive rate
• All false positives were caused by a 'burst' in
  server activity

19
Worm Simulation Results

• Not practical to infect network
• Nmap scanning
• Sequential scanning
• Random scanning
• Detected all scan activity scenarios within 3
  scans
• Internal network darkspace a factor

20
Limitations

• Test network size
• Simulation vs. actual infection
• Exclusive observation of broadcast traffic may
  lead to underestimation of dark space
• DHCP
• P2 P, highly distributed network 'your mileage
  may vary'

21
Conclusions

• An approach to protect the internal network
  (topological worms)
• Analysis provides evidence that the approach has
  merit
• Full prototype developed
• Anomaly-based
• ability to detect emerging worms

22

• Questions?
• dlwhyte_at_scs.carleton.ca