HoneyStat: Local Worm Detection Using Honeypots

1
HoneyStat Local Worm Detection Using Honeypots
The 7th International Symposium on Recent
Advances in Intrusion Detection (RAID 2004).
Publish

• David Dagon, Xinzhou Qin, Guofei Gu, Wenke Lee,
  et al from Georgia Institute of Technology

Authors
Presenter
Jianyong Dai
2
Contribution

• A sample for automatic detecting worm using high
  interactive Honeypots
• A local network approach to detect worm explosion

3
The rest of presentation

• Background
• Honeystat Approach
• Strength Weakness Possible Extension

4
Outline

• Background
• Worm detection
• Honeypots
• Worm infection cycle
• Honeystat Approach
• Strength Weakness Possible Extension

5
Worm Detection

• Worm detection based on scan rate
• Abnormal quick increase in scan rate
• Large volume of data is required to achieve
  statistical stable
• So, the need for global monitoring is obvious
• Not suitable for a small local network

6
Honeypots

• Configured inactive, non-public
• Almost no false positive in detecting network
  intrusion
• Every event in honeypots is important
• Traditionally, honeypots require labor-intensive
  management and review
• 40 hours to analyze 1 hour traffic log for an
  expert

7
High interaction honeypots

• Install real application, not a simulator
• Let worm get through
• Be able to capture all activity of a worm
• Prevent malicious action
• Prevent honeypots infect other computer

8
Worm Infection Cycle

• Blaster worm illustration

Attacker
Victim
Port 135 exploit
ACK
Shell command
sftp get
Transfer egg
Additional attack
9
Worm Infection Cycle

• Worm events within victim machine
• Memory event
• Memory crash
• Failed buffer-overflow attack
• Disk event
• Write a file into file system
• Network event
• Outbound traffic

10
Blaster Worm Revisit
Attacker
Victim
Port 135 exploit
ACK
Memory Event
Shell command
Network Event
sftp get
Transfer egg
Disk Event
Additional attack
Network Event
11
Worm Infection Cycle

• Any of memory event, disk event or network event
  in Honeypots is due to Intrusion
• It is one of the previous inbound packet cause
  the event for sure

12
Outline

• Background
• Honeystat Approach
• Idea
• Event Correlation
• Modeling
• Strength Weakness Possible Extension

13
General Idea

• Every honeypot event is due to intrusion
• Memory crash
• Disk write
• Outbound traffic
• Not every incoming traffic is worm
• Network administration tool
• Web robots
• Old worm scan
• Real hacker attack

14
General Idea
Event
Event
Pa
Pb
Pc
Pf
Pb
Pe
Honeypot a
Honeypot b
Who trigger the event?
Check other honeypots to find more evidence
15
General Idea

• Use logistic regression to find out who make the
  trouble
• Can specify a confidence level

16
Honeystat

• Array of full functional honeypots
• Use VMWare to create 64 virtual machines in one
  physical machine
• Every WinNT VM can bind 32 IP addresses
• Every VM with 32M RAM and 770M disk
• It ends up one machine cover 6432 211 IP
  address

17
Honeystat

• Wait for event, send these information when event
  occurs
• OS/patch level
• Type of event
• Incoming network traffic right before the event
  (within range t)

18
Honeystat

• When memory or disk event happens
• Wait for other interesting things
• When a network event happens
• Reset the VM, restore disk image
• Switch other VM to the OS of the exploited VM
  (optional)
• Increase the chance to capture the same event in
  other honeypots

19
Logistic Regression

• Assumption
• Only one worm attack
• The closer packet, the better
• Empirically, 5 events are needed to
  confidently(95) identify the cause

Pb
Pd
Pa
Pb
Pf
Pe
yes
yes
Do we need another?
Do we need another?
20
Error

• Not every event is a worm
• Other type of intrusion
• Its nice because we can further identify other
  intrusion
• True worm, but we get wrong cause
• Need more instance
• Usually 5 events are required to identify the
  cause

21
Modeling

• How quick can we detect worm
• IP coverage
• Number of victims needed

Worm
22
Outline

• Background
• Honeystat Approach
• Strength Weakness Possible Extension

23
Strength

• Comparing to signature based approach
• Do not need signature
• Can detect unknown worm

24
Strength

• Compare to low interactive honeypots (honeyd)
• Can get more worm behavior
• Can detect worm confidently

25
Strength

• Comparing to scan based detection
• Works in small network which is statistically
  unstable
• Can also identify the causing packet

26
Strength

• Comparing to other behavior based approach
• Can capture more types of worms
• Only one simple assumption has been made take
  one packet, and trigger one event

27
Limitation

• Can not detect slow worm
• What if the worm idled for a long time after
  initial exploit
• A large IP space needed
• 211 means 8 class C network
• Can only detect random scan worm
• Santy find host using google

28
Weakness

• Not so strong in data manipulation
• Only logistic regression has been tried
• Only use 1/tr as variable
• Simulation is not convincing
• Using traffic log as background, add synthetic
  honeypot events

Event
Pa
Pb
Pc
tr
29
Possible Extension 1

• Collaborate or global approach
• A large IP space coverage

30
Possible Extension 2

• Automatic fingerprint generation
• We can identify port
• Actually we also have the intrusion packet
• Sometimes we can not block a port
• Generate fingerprint
• Is 5 event enough to generate a fingerprint

31
Possible Extension 3

• Using abnormal detection instead of correlation
• By instinct, in most case, one event is enough to
  identify the causing packet, that is, the
  preceding abnormal packet

Abnormal?
Event
Pa
Pb
Pc
32
Possible Extension 4

• Packet replay
• Send recent packets to another similar honeypot
• See which one crash the honeypot

Send Pa
Event
Pa
Pb
Pc
Send Pb
Crash
replay
33
Question