HoneyStat: Local Worm Detection Using HoneypotsDavid Dagon, Xinzhou Qin, Guofei Gu, Wenke Lee, et al from Georgia Institute of TechnologyAuthors:

The 7th International Symposium on Recent Advances in Intrusion Detection (RAID 2004).Publish:

Presenter:

Jianyong Dai

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

The rest of presentation Background Honeystat Approach Strength & Weakness & Possible Extension

Outline Background

Worm detection Honeypots Worm infection cycle

Honeystat Approach Strength & Weakness & Possible Extension

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

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

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

Worm Infection Cycle Blaster worm illustration

Attacker VictimPort 135 exploit

ACK

Shell command

sftp getTransfer egg

Additional attack

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

Blaster Worm RevisitAttacker Victim

Port 135 exploitACK

Shell command

sftp getTransfer egg

Additional attack

Memory Event

Network Event

Disk Event

Network Event

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

Outline Background Honeystat Approach

Idea Event Correlation Modeling

Strength & Weakness & Possible Extension

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

General Idea

Event

PaPbPc

Who trigger the event?

Honeypot a

Event

PfPbPe

Honeypot bCheck other honeypots to find more evidence

General Idea Use logistic regression to find out who

make the trouble Can specify a confidence level

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 = 211 IP address

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)

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

Logistic Regression Assumption

Only one worm attack The closer packet, the better

Empirically, 5 events are needed to confidently(95%) identify the cause

PaPbPc

Do we need another?

PaPbPc

Do we need another?

PbPd

Do we need another?

yes PaPbPf

Do we need another?

yes Pe

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

Modeling How quick can we detect worm

IP coverage Number of victims needed

Internet Honeystat

Worm

Outline Background Honeystat Approach Strength & Weakness & Possible Extension

Strength Comparing to signature based

approach Do not need signature Can detect unknown worm

Strength Compare to low interactive honeypots (honeyd)

Can get more worm behavior Can detect worm confidently

Strength Comparing to scan based detection

Works in small network which is statistically unstable

Can also identify the causing packet

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

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

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

EventPaPbPc

tr

Possible Extension 1 Collaborate or global

approach A large IP space

coverage

Local network

Honeypots

Local network

Honeypots

Analysis node

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

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

PaPbPc

Abnormal?

Possible Extension 4 Packet replay

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

Event

PaPbPc

Send Pa

Send Pb

Crash

replay

Question