Vous êtes sur la page 1sur 4

Description & Analysis of Concker Botnet

Jonas Vautherin
III. ATTACK PROCEDURE Before digging into more details, lets have a quick overview of the way the attack was proceeding. Once the malicious code (a subset of the actual worm) had been injected using the buffer overow, it was executed. It then incorporated a web server on random ports (which made it more difcult to detect) and called the attacking computer. This way the complete code of Concker could be downloaded and installed on the computer. Once correctly set up, Concker was able to make the infected machine attack other computers at its turn by replicating itself on USB and shared network drives. It would later be executed on the other computers mounting those drives thanks to the autorun system of Microsoft Windows (AUTORUN.INF). The setup also implied to make sure the malware would be run again at Windows startup and to create a backdoor - which would later be used to update the malware. Interestingly, Concker was xing the buffer overow weakness of the system (still creating itself a backdoor) to ensure that no other code could use the same way and potentially harm/deactivate it. Concker was an advanced malware which used a lot of known techniques but in a new way. Among several capacities, it had mechanisms to be updated by its controllers, different communication systems and a really efcient local propagation, that will be explained in more details in the following subsections. A. Proliferation In order to reach as many computers as possible, the worm was replicating and propagating onto USB drives and over the network. It was even brute-forcing the shared le systems to get access to others computers of the same local network, especially by using the same user login and password as the already infected machines, assuming that machines on the same local network are susceptible to be congured with the very same parameters. B. Updates One interesting feature of the worm was its capability to be updated by its controllers in a very elegant manner. It indeed endued HTTP client/server and Peer-to-Peer architectures (P2P was actually not present in the very rst versions). But in order for the client/server communications to take place, the malware had to know how to contact the controllers and receive its new orders. A hard-coded IP address would trivially have made the program vulnerable to neutralization. Creators of the worm therefore imagined a system of rendezvous. They used a so-called domain generation algorithm which was capable to deterministically

Abstract This document tries to depict and describe Concker Botnet, discovered in November 2008. The document contains information regarding the behavior of the worm and its architecture. For a matter of conciseness, focus is on mechanisms used by the malware and no details will be given about their actual implementation.

I. INTRODUCTION Many viruses, trojans and worms have reached global impact 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 famous examples encountered since 2000. This paper focuses on Concker botnet (2008), which garnered a lot of attention for its complexity and efciency. It should be noted that Concker was sometimes called Downup, Downadup or Kido by different organizations. Different aspects of Concker will be addressed in the next few sections. Even though the conception allowing the worm to be updated resulted in 5 distinct versions of the worm, focus wont be on this but on the mechanisms in a more general fashion. Nonetheless, some specicities of versions are mentioned punctually. The vulnerability that was exploited by the worm is described in Section 2. Section 3 will give more details about how the attack was proceeding and the different mechanisms used by the malware to be robust, secure and efcient. Section 4 will briey summarize the threats induced by this worm and Section 5 focuses on defenses that took place (with more or less success) and counter-attacks which came from the owners of the botnet. Finally, Section 6 concludes the paper and gives an outlook of what was learnt thanks to Concker. II. EXPLOITED VULNERABILITY Concker took advantage of CWE-119 weakness (Improper Restriction of Operations within the Bounds of a Memory Buffer). The so-called MS08-067 buffer overow vulnerability was present on several unpatched versions of Microsoft Windows (Windows 2000, Windows XP, Windows Vista, Windows 7). It basically allowed remote execution of code (more technical details about the actual exploit can be found in [5]). Once injected, the code had sufcient privileges to download a malware and make it execute automatically at startup. The malware had then access to the le systems, network and even Windows API, which eventually let Concker set up a botnet using advanced techniques.
Jonas Vautherin is in Federal Institute of Technology (EPFL), Lausanne

Fig. 1.

Vulnerable hosts [10]

generate pseudo-random domain addresses to which the zombies (infected hosts) would connect periodically. The controller had to take control of those rendezvous domains at the good time (i.e. when the zombies where contacting them) 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 infected hosts to transmit information between them. This way the system was even more decentralized and hence more difcult to contain. C. Self-defense mechanisms If not convinced by the replication mechanisms, one should get the certitude that the worm was created by experts by discovering how they cared about the defenses and robustness of their code. 1) Authentication: The authors protected their botnet against potential attacks from the outside. As already mentioned, Concker was literally closing the door behind itself

by xing the overow buffer aw and was creating a backdoor for its own use. Additionally, as if it was not enough, the botnet was using public-key cryptography and digital signatures to secure its communications. That way nobody was able to maliciously take control of the botnet or attack it by sending forged packets. As a funny fact, one could mention that Concker was using SHA-1 in its rst version and quickly changed to MD-61 which had - at this time - recently been published. As a matter of fact, Rivest found a aw in its system one month later, published it, and it was then reported that Concker had been patched within a few weeks. 2) Local protection: The worm was also protecting itself against threats coming from inside; it was blocking access to security companies websites, changing Windows rewall settings, disabling Windows Safe-mode, reseting system restore points to dates only after the infection and disabling
1 developed

by Ron Rivest

Fig. 2.

Rendezvous mechanism [3]

security software that were able to harm it (such as Windows defender, Windows Automatic Updates and Windows Security Center). If ran under a debugger, the program was detecting it and killing itself to make analysis and reverse engineering even more tricky. 3) Obfuscation: Stealthiness is an important point for a virus. One doesnt want it to be easily detected, and Concker was - not surprisingly - using state-of-the-art obfuscation methods. First of all, it was patching the Windows API in order to create invisible threads. It was embedded into Windows services (e.g. explorer) and not using its own service which would have made it way easier to detect. Still in the topic of hiding its activity, P2P protocols where hindered and purposely made difcult to analyze. Last but

not the least, the worm was periodically contacting randomly generated rendezvous domains. After a successful update, it was also waiting a few days (or a few hours - depending on the version) before checking again for updates. When it came to hiding what it was, the program actually was copied into a randomly named DLL located in carefully chosen places (such as System32) and this DLLs date was set to the same as kernel32.dll. Finally, it was also creating fake keys in the registry. IV. THREATS The botnet was able to install and run any program the controllers could send to it using the network. One could imagine innitely many scenarios, such as using the botnet for spam, selling fraudulent spywares, DDoS attacks, key-

logging and so on and so forth. The botnet reached such a big size that it became seriously considered as dangerous even for governments. V. DEFENSES AND COUNTER-ATTACKS Concker became so important that the so-called Concker Working Group (see [2]) was created, regrouping security experts from different major companies. They tried to analyze the worm using different techniques (reverse engineering, honeypots, network telescopes) and tried different approaches to contain the botnet. They tried to attack it with forged packets, but the authentication system successfully protected the malware against this. Microsoft and other security companies proposed removal tools, but it was difcult to make people use them. Primarily because access to security companies webpages was blocked by the worm, or because people were not always aware that they were infected. But also because of costs; some companies could simply not afford changing their security system in an adapted fashion. Nevertheless, some successfully reverse-engineered the domains generation algorithm, blocked the domains and used sinkholing to identify infected hosts. This could be done for an early version of the program which was not yet using P2P for communications. As a response, the authors of the worm counter-attacked by adding P2P architecture to their program. Moreover, they changed the number of randomly generated domains from 250 domains over 5 TLDs to 8 TLDs and then 50 000 candidate domains (of which 500 where effectively contacted each day) over 110 TLDs, so that it became impossible to block them all. VI. CONCLUSION Concker was one of the most advanced botnet of all time, combining advanced techniques from different topics in a way that had never been done before. The randomness of the system, communication vectors, obfuscation mechanisms and possibility to update the botnet to deal with defensive measures taken by the international community all contributed to make defense against the worm a pain even for security experts. But attacking the program itself was not necessarily the best option: it was lighter than an operating system by essence and therefore easier to protect. A relevant point is that the malware was exploiting one single aw in Microsoft Windows, for which updates were quickly published. The main problem probably came from the fact that a lot of Windows copies worldwide are not genuine and consequently arent updated regularly. But even though the botnet still exists, authors apparently were arrested by the FBI or stopped controlling it. Some believe that Concker

will disappear gradually with the arrival of Windows 8 which will be protected against it. Good lessons were learnt by the international community about cybercriminality, such as the need to have cohesion between different domains and to be able to react quickly to contain such an attack. R EFERENCES
[1] G. Lawton, On the Trail of the Concker Worm, in Technology News, IEEE, June 2009, pp 19-22. [2] Concker Working Group. http://confickerworkinggroup.org/wiki/ [3] SRI-International, An analysis of Concker C. http://mtc.sri.com/Conficker/ [4] DDoS and Security Report, The Concker Cabal Announced, in The Arbor Networks Security Blog, February 2009. http://ddos.arbornetworks.com/2009/02/theconficker-cabal-announced/ [5] Concker/Downadup: Memory Injection Model, in Threat Expert Blog, January 2009. http://blog.threatexpert.com/2009/01/conficker downadup-memory-injection.html [6] Centralized Information About the Concker Worm, in Microsoft Malware Protection Center. http://blogs.technet.com/b/mmpc/archive/2009/ 01/22/centralized-information-about-theconficker-worm.aspx [7] Downadup: Small Improvements Yield Big Returns, Symantec, July 2010. 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, Concker and Beyond, a Large Empirical Study, in ACSAC10, Austin, Texas, December 2010, pp 151-160. [10] Microsoft. http://www.microsoft.com