Description & Analysis of Conficker Botnet

Jonas Vautherin

Abstract— This document tries to depict and describe Con-ficker Botnet, discovered in November 2008. The documentcontains information regarding the behavior of the wormand its architecture. For a matter of conciseness, focus is onmechanisms used by the malware and no details will be givenabout their actual implementation.

I. INTRODUCTION

Many viruses, trojans and worms have reached globalimpact on the whole Internet over the years. Melissa worm(2001), Code Red virus (2001), Slammer worm (2003)and Storm botnet (2006) are some of the multiple famousexamples encountered since 2000. This paper focuses onConficker botnet (2008), which garnered a lot of attentionfor its complexity and efficiency. It should be noted thatConficker was sometimes called Downup, Downadup or Kidoby different organizations.

Different aspects of Conficker will be addressed in thenext few sections. Even though the conception allowing theworm to be updated resulted in 5 distinct versions of theworm, focus won’t be on this but on the mechanisms ina more general fashion. Nonetheless, some specificities ofversions are mentioned punctually. The vulnerability that wasexploited by the worm is described in Section 2. Section 3will give more details about how the attack was proceedingand the different mechanisms used by the malware to berobust, secure and efficient. Section 4 will briefly summarizethe threats induced by this worm and Section 5 focuses ondefenses that took place (with more or less success) andcounter-attacks which came from the owners of the botnet.Finally, Section 6 concludes the paper and gives an outlookof what was learnt thanks to Conficker.

II. EXPLOITED VULNERABILITY

Conficker took advantage of CWE-119 weakness (Im-proper Restriction of Operations within the Bounds of aMemory Buffer). The so-called MS08-067 buffer overflowvulnerability was present on several unpatched versions ofMicrosoft Windows (Windows 2000, Windows XP, WindowsVista, Windows 7). It basically allowed remote execution ofcode (more technical details about the actual exploit canbe found in [5]). Once injected, the code had sufficientprivileges to download a malware and make it executeautomatically at startup. The malware had then access tothe file systems, network and even Windows API, whicheventually let Conficker set up a botnet using advancedtechniques.

Jonas Vautherin is in Federal Institute of Technology (EPFL), Lausanne

III. ATTACK PROCEDURE

Before digging into more details, let’s have a quickoverview of the way the attack was proceeding. Once themalicious code (a subset of the actual worm) had beeninjected using the buffer overflow, it was executed. It thenincorporated a web server on random ports (which made itmore difficult to detect) and called the attacking computer.This way the complete code of Conficker could be down-loaded and ”installed” on the computer. Once correctly setup, Conficker was able to make the infected machine attackother computers at its turn by replicating itself on USB andshared network drives. It would later be executed on theother computers mounting those drives thanks to the autorunsystem of Microsoft Windows (AUTORUN.INF). The setupalso implied to make sure the malware would be run againat Windows startup and to create a backdoor - which wouldlater be used to update the malware. Interestingly, Confickerwas fixing the buffer overflow weakness of the system (stillcreating itself a backdoor) to ensure that no other codecould use the same way and potentially harm/deactivateit. Conficker was an advanced malware which used a lotof known techniques but in a new way. Among severalcapacities, it had mechanisms to be updated by its controllers,different communication systems and a really efficient localpropagation, that will be explained in more details in thefollowing subsections.

A. Proliferation

In order to reach as many computers as possible, the wormwas replicating and propagating onto USB drives and overthe network. It was even brute-forcing the shared file systemsto get access to others computers of the same local network,especially by using the same user login and password as thealready infected machines, assuming that machines on thesame local network are susceptible to be configured with thevery same parameters.

B. Updates

One interesting feature of the worm was its capability to beupdated by its controllers in a very elegant manner. It indeedendued HTTP client/server and Peer-to-Peer architectures(P2P was actually not present in the very first versions).

But in order for the client/server communications totake place, the malware had to know how to contact thecontrollers and receive its new orders. A hard-coded IPaddress would trivially have made the program vulnerableto neutralization. Creators of the worm therefore imagineda system of rendezvous. They used a so-called domaingeneration algorithm which was capable to deterministically

Fig. 1. Vulnerable hosts [10]

generate pseudo-random domain addresses to which thezombies (infected hosts) would connect periodically. Thecontroller had to take control of those rendezvous domainsat the good time (i.e. when the zombies where contactingthem) to have access to their botnet and send them updates.

Moreover, an entirely decentralized P2P architecture (i.e.there were no tracker or list of peers) was used for infectedhosts to transmit information between them. This way thesystem was even more decentralized and hence more difficultto contain.

C. Self-defense mechanisms

If not convinced by the replication mechanisms, oneshould get the certitude that the worm was created byexperts by discovering how they cared about the defensesand robustness of their code.

1) Authentication: The authors protected their botnetagainst potential attacks from the outside. As already men-tioned, Conficker was literally closing the door behind itself

by fixing the overflow buffer flaw and was creating abackdoor for its own use.

Additionally, as if it was not enough, the botnet was usingpublic-key cryptography and digital signatures to secure itscommunications. That way nobody was able to maliciouslytake control of the botnet or attack it by sending forgedpackets. As a funny fact, one could mention that Confickerwas using SHA-1 in its first version and quickly changed toMD-61 which had - at this time - recently been published. Asa matter of fact, Rivest found a flaw in its system one monthlater, published it, and it was then reported that Confickerhad been patched within a few weeks.

2) Local protection: The worm was also protecting itselfagainst threats coming from inside; it was blocking accessto security companies websites, changing Windows firewallsettings, disabling Windows Safe-mode, reseting system re-store points to dates only after the infection and disabling

1developed by Ron Rivest

Fig. 2. Rendezvous mechanism [3]

security software that were able to harm it (such as Win-dows defender, Windows Automatic Updates and WindowsSecurity Center).

If ran under a debugger, the program was detecting it andkilling itself to make analysis and reverse engineering evenmore tricky.

3) Obfuscation: Stealthiness is an important point fora virus. One doesn’t want it to be easily detected, andConficker was - not surprisingly - using state-of-the-art ob-fuscation methods. First of all, it was patching the WindowsAPI in order to create invisible threads. It was embeddedinto Windows services (e.g. explorer) and not using itsown service which would have made it way easier to detect.Still in the topic of hiding its activity, P2P protocols wherehindered and purposely made difficult to analyze. Last but

not the least, the worm was periodically contacting randomlygenerated rendezvous domains. After a successful update, itwas also waiting a few days (or a few hours - depending onthe version) before checking again for updates.

When it came to hiding what it was, the program actuallywas copied into a randomly named DLL located in carefullychosen places (such as System32) and this DLL’s date wasset to the same as kernel32.dll. Finally, it was alsocreating fake keys in the registry.

IV. THREATS

The botnet was able to install and run any program thecontrollers could send to it using the network. One couldimagine infinitely many scenarios, such as using the botnetfor spam, selling fraudulent spywares, DDoS attacks, key-

logging and so on and so forth. The botnet reached sucha big size that it became seriously considered as dangerouseven for governments.

V. DEFENSES AND COUNTER-ATTACKS

Conficker became so important that the so-called ConfickerWorking Group (see [2]) was created, regrouping securityexperts from different major companies. They tried to an-alyze the worm using different techniques (reverse engi-neering, honeypots, network telescopes) and tried differentapproaches to contain the botnet. They tried to attack it withforged packets, but the authentication system successfullyprotected the malware against this. Microsoft and other secu-rity companies proposed removal tools, but it was difficult tomake people use them. Primarily because access to securitycompanies webpages was blocked by the worm, or becausepeople were not always aware that they were infected. Butalso because of costs; some companies could simply notafford changing their security system in an adapted fashion.

Nevertheless, some successfully reverse-engineered thedomains generation algorithm, blocked the domains and usedsinkholing to identify infected hosts. This could be done foran early version of the program which was not yet usingP2P for communications. As a response, the authors of theworm counter-attacked by adding P2P architecture to theirprogram. Moreover, they changed the number of randomlygenerated domains from 250 domains over 5 TLDs to 8TLDs and then 50 000 candidate domains (of which 500where effectively contacted each day) over 110 TLDs, sothat it became impossible to block them all.

VI. CONCLUSION

Conficker was one of the most advanced botnet of alltime, combining advanced techniques from different topicsin a way that had never been done before. The randomnessof the system, communication vectors, obfuscation mech-anisms and possibility to update the botnet to deal withdefensive measures taken by the international communityall contributed to make defense against the worm a paineven for security experts. But attacking the program itselfwas not necessarily the best option: it was lighter than anoperating system by essence and therefore easier to protect.A relevant point is that the malware was exploiting one singleflaw in Microsoft Windows, for which updates were quicklypublished. The main problem probably came from the factthat a lot of Windows copies worldwide are not genuine andconsequently aren’t updated regularly. But even though thebotnet still exists, authors apparently were arrested by theFBI or stopped controlling it. Some believe that Conficker

will disappear gradually with the arrival of Windows 8 whichwill be protected against it.

Good lessons were learnt by the international communityabout cybercriminality, such as the need to have cohesionbetween different domains and to be able to react quickly tocontain such an attack.

REFERENCES

[1] G. Lawton, On the Trail of the Conficker Worm, in Technology News,IEEE, June 2009, pp 19-22.

[2] Conficker Working Group.http://confickerworkinggroup.org/wiki/

[3] SRI-International, An analysis of Conficker C.http://mtc.sri.com/Conficker/

[4] DDoS and Security Report, ”The Conficker Cabal Announced”, in TheArbor Networks Security Blog, February 2009.http://ddos.arbornetworks.com/2009/02/the-conficker-cabal-announced/

[5] Conficker/Downadup: Memory Injection Model, in Threat ExpertBlog, January 2009.http://blog.threatexpert.com/2009/01/confickerdownadup-memory-injection.html

[6] Centralized Information About the Conficker Worm, in MicrosoftMalware Protection Center.http://blogs.technet.com/b/mmpc/archive/2009/01/22/centralized-information-about-the-conficker-worm.aspx

[7] Downadup: Small Improvements Yield Big Returns, Symantec, July2010.http://www.symantec.com/connect/blogs/downadup-small-improvements-yield-big-returns

[8] Security TechCenter, Microsoft Security Bulletin MS08-067 - Critical.http://technet.microsoft.com/en-us/security/bulletin/ms08-067

[9] S. Shin and G. Gu, Conficker and Beyond, a Large Empirical Study,in ACSAC’10, Austin, Texas, December 2010, pp 151-160.

[10] Microsoft.http://www.microsoft.com