Botnets, detection and mitigation: DNS-based techniques

1. Botnets, detection and mitigation:DNS-based techniques • John Kristoff • jtk@northwestern.edu • http://aharp.ittns.northwestern.edu • +1 847 467-5878 • Northwestern University • Evanston, IL 60208

2. What is a botnet? • An army of compromised hosts (bots) • Under a common command and control (c&c): • commonly IRC-based • The purpose: • DoS, id theft, spam • for fun and profit

3. Typical command and control • c&c functions mostly centralized • one or more IRC servers • DNS name(s) used for rendezvous • vanity web pages for malware updates • Nothing really new • CERT's October 2001 Trends in DoS paper

4. What's wrong with this picture? Welcome to irc.whitehouse.gov Your host is h4x0r.0wnz.j00 There are 9556 users and 9542invisible on 1 server 5 :channels formed 1 :operators online Channel Users Topic #help 1 #oldb0ts 5 .download http://w4r3z.example.org/r00t.exe End of /LIST

5. Botnet info is everywhere • http://www.honeynet.org/papers/bots/ • http://cert.uni-stuttgart.de/files/tf/botnets.pdf • http://www.educause.edu/ir/library/pdf/SPC0568.pdf • http://www.internet2.edu/presentations/jtsaltlake/ 20050214-Botnets-Moody.pdf • http://www.nanog.org/mtg-0410/kristoff.html

6. Some typical detection strategies • Up-to-date anti-virus software • IDS signatures for IRC/botnet traffic • Traffic flow monitoring (for known C&Cs?) • email alerts • To: security@example.org • Subject: Bot detected on your network

7. Some typical mitigation strategies • TCP port 6667 filtering • C&C IP address (&& port?) filtering • Intrusion prevention systems (IDS++) • Secure systems and applications • Careful and smart users

8. What about DNS traffic? • Repetitive A queries may indicate bot/controller • MX queries may indicate spam bot • in-addr.arpa queries may indicate a server • Usually 3 level hostname.subdomain.TLD • [^(www|mx\d+|ns\d+)]\w+\.\w+\.\w+ • Names and subdomains that just look rogue • Something .edu's can't be blamed for! :-)

9. Note: synchronization problem • If name doesn't resolve, but controller is up • connected bots instructed to update DNS • If controller(s) is(are) gone, but name resolves • DNS changed to point to new controller(s) • Synchronizing the closure of both is difficult

10. Name-based sink holes with BIND zone "rogue.example.net" { type master; file "/etc/db.badname"; }; ----------------------------------- $TTL 30D @ IN SOA ns1.example.net. root ( 2004101700 3H 15M 1W 1D ) IN NS ns1.example.net. IN A 192.0.2.1

11. Finding DNS • Someone you trust tells you • Packet capture during C&C connection • Bot malware analysis • DNS RR and C&C address correlation • Algorithmic techniques

12. NU DNS bot detection overview • Maintain blacklist of botnet c&c host names • Watch DNS query logs in real-time • Use sampling function to reduce false positives • Note: will miss stable, active botnets • Import suspect querier into NUSA

13. Enabling DNS query logs • BIND: logging { category queries { logfile; }; }; • Space and privacy considerations • We log about ~10-20 million queries/day • ~1-2 GB uncompressed/day • Could setup logfile as a FIFO named pipe

14. querywatch • Get a list of known bad names • no decent public list available that I know of • normalize name list for querywatch config • tail -f DNS log files and pipe to querywatch • pipe querywatch output to an action script • http://aharp.ittns.northwestern.edu/software/

15. simplified process view tail -f $LOG|qw -c $DNSRRs| query2db # qw = querywatch init_list(); # read in DNS RRs while (defined (my $line = <>)) next if ($loop++ % sample); # get lc(RR) and assign to $query print $line if ($list{$query}); }

16. query2db design considerations • Use logfile timestamp and a DB insert_time • Create whitelist (e.g. DNS/NetPass servers) • If log=Dec && systime=Jan, rollback year • sanity check everything • make every regex very explicit (e.g. avoid .*) • note: this script is not publicly available

17. NU DNS bot detection in review • I'm not aware of any false positives to date • Dozens of NUSA entries at any one time • many duplicates due to transient addresses • Mostly neutered bots, not imminent an threat • Can we not sample and avoid false positives?

18. DNS-based detection thoughts • What names are used for rendezvous? • How do bots query for the DNS RR? • Is a local recursive/caching server used? • What happens if the query/connection fails? • When do they query for the DNS RR? • Do all the bots query at once? • What does the authoritative server see?

19. DNS thoughts... [continued] • What does the query answer look like? • What is the TTL? • If an A RR, what address(es) is given? • How has this answer changed over time? • Related... what about whois information? • Is it valid, does it change? • What other RRs does the contact have?

20. Current DNS-related tools/research • Kristoff's anomalous name watcher • correlate with known baddies, put into NUSA • Moody's anomalous name watcher • correlate with known baddies, put into DB • Musashia's mass mailing worm detection • find unusual MX/PTR query spikes

21. DNS tools/research [cont.] • Whyte's DNS-based detection of worms/scans • correlate DNS query and traffic flows • Dagon's authoritative anomaly algorithms • capture c&c by redirecting anomalous DNS • RUS-CERT's passive DNS replication • Keep database of all DNS responses

22. DNS-related references • DNS syslog studies • http://www.cc.kumamoto-u.ac.jp/~musashi/ • DNS-OARC (operations, analysis, research) • http://oarc.isc.org • Measurement Factory, tools and papers • http://dns.measurement-factory.com/

23. The end Why are you still here?