1. HoneyStat: Local Worm Detection Using Honeypots David Dagon, Xinzhou Qin, Guofei Gu, Wenke Lee, et al from Georgia Institute of Technology Authors: The 7th International Symposium on Recent Advances in Intrusion Detection (RAID 2004). Publish: 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 Shell command sftp get Transfer egg Additional attack Memory Event Network Event Disk Event 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 PaPa PbPb PcPc Who trigger the event? Honeypot a Event PfPf PbPb PePe Honeypot b 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 64*32 = 2 11 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 PaPa PbPb PcPc Do we need another? PaPa PbPb PcPc PbPb PdPd yes PaPa PbPb PfPf Do we need another? yes PePe

20. Error  Not every event is a worm Other type of intrusion It ’ s 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 2 11 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/t r as variable  Simulation is not convincing Using traffic log as background, add synthetic honeypot events Event PaPa PbPb PcPc trtr

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 Event PaPa PbPb PcPc Abnormal?

32. Possible Extension 4  Packet replay Send recent packets to another similar honeypot See which one crash the honeypot Event PaPa PbPb PcPc Send P a Send P b Crash replay

33. Question