Botnets Presentation For Malware Class (Hacking Illustrated Series
InfoSec Tutorial Videos)
Botnets Presentation For Malware Class
I have to present two papers for my malware class, so I figure
I'd share my practice video with my readers. Slides are available in
To download, right click the link below:
Text version of the slides:
Article presentation for:
The Dark Cloud: Understanding and Defending against Botnets and Stealthy Malware
Based on article by:
Jaideep Chandrashekar, Steve Orrin, Carl Livadas, Eve M. Schooler
This presentation by:
A little information to get you up to speed on botnets
So, what is a Botnet?
A collection of compromised computers that can be sent orders
Individual hosts in a Botnet are know as bots or zombies
The administrator of the Botnet is often known as a Bot Herder
A few examples of Botnets include:
Botnet life cycle
(As outlined by the article)
SE Spam, Web drive bys, Network worm functionality, etc.
Command and Control Phase
How do hosts become part of a Botnet?
Drive by malware installs via web browsers
Automated or targeted network vulnerability attacks
End users socially engineered to install them via phishing attacks, or
confusing browser messages
Botnet Source Code Families
Lots of source code is out there:
Search for BotNet.Source.Codes.rar
How are Botnets controlled?
Decentralized Command and Control Channels (C&C)
Decentralization is important to make C&C harder to shutdown
By using Command and Control Channels, bot herders can change what their
Botnet is tasked to do, and update the Botnets nodes
Illustration of C&C
Illustration of C&C: Another take
Illustration of C&C: Yet another take
Illustration of C&C: Blind drop
Economics of Bot Herding
So, why would some one want a Botnet?
Distributed Denial Of Service (DDoS)
Spam (both email and web posts)
Harvested identities (Sniffers, Key Loggers, Etc.)
They can also be rented out for tasks
BBC show Click rents a Botnet:
Problems with detecting/removing a Bot installation
Main points from the article:
Only periodic communications back to controller
Retaliation Denial of Service
Articles proposal: Canary Detector
Made with three main strategies (paraphrased):
Establish a baseline for the network.
Use end-host detection algorithm to determine botnet C&C channel, based on
destinations that are regularly contacted.
Aggregate information across nodes on the network to find commonality.
Canary Detector: Atoms
Uses the tuple:
destIP/dstService = Host being contacted
destPort = Port number
proto = UDP or TCP
(google.com, 80, tcp)
(184.108.40.206, 53, udp)
(ftp.nai.com, 21:>1024, tcp)
Canary Detector: Persistence
Look for temporal heavy hitters
Not so concerned about amount of traffic
Concerned about regularity
Starting with a small tracking window (w) time, track if an Atom was contacted
Set an observational time window (W), for example W=10w in duration
The authors also use multiple time scales 1 through 5
Canary Detector: Commonality
How common is a destination Atom amongst network nodes?
The more common the Atom, the more important it is
Canary Detector: Whitelists
Ignore safe Atoms to easy computation
Observe traffic during training period to see common, regularly contacted
Atoms (Windows update servers might be an example)
Set nodes to ignore, adjust as needed.
Whitelists are established at both the host and network level.
Canary Detector: Alarm Types
p-alarms (persistence): When a destination Atom not contained in the hosts
whitelist becomes persistent. More for local use, whitelist or flag.
c-alarms (commonality): When a destination atom is observed at a large number
of end-hosts in the same window and is identified as common. More for network
use, whitelist or flag.
Using the information
Article defines thresholds for persistence and commonality (p* and c*) for
when to take note
Suspicious alarms can be acted upon
Tested against real bots
SDBot: Controlled over IRC, but easy to spot because of connecting to
irc.undernet.org. Scans ports scans on ports 135, 139, 445, 2097 looking to
Zapchast: Five IRC service atoms (about 13 distinct IPs). Mostly NetBIOs
Storm: P2P based. The traces were two orders of magnitude larger than the
other botnets tested.
Graph of botnet Atom persistence
Storm (Blue Dots)
Note that they only
graphed 100 atoms
Links for more research
The Dark Cloud: Understanding and Defending against Botnets and Stealthy
SANs Internet Storm Center
LAN of the Dead
How difficult is it to choose good thresholds for persistence/commonality?
What if Botnets varied their call back times?
Whitelisting of services that have become blind drops?