SEARCH

SEARCH BY CITATION

Keywords:

  • botnet spoofing;
  • C&C;
  • BotSpoofer;
  • Conficker

ABSTRACT

  1. Top of page
  2. ABSTRACT
  3. 1 INTRODUCTION
  4. 2 RELATED WORK
  5. 3 OVERVIEW OF BOTNET SPOOFING
  6. 4 BOTNET SPOOFING IMPLEMENTATION
  7. 5 A CASE STUDY OF CONFICKER
  8. 6 APPLICATION SCENARIO
  9. 7 BOTSPOOFER HONEYPOT
  10. 8 CONCLUSIONS AND FUTURE WORK
  11. ACKNOWLEDGEMENTS
  12. REFERENCES

As the arms race between botmasters and defenders becomes increasingly common, the emerging advanced botnets have evolved to be more resilient to traditional mitigation strategies. For security-conscious Internet users, the host-based security software (i.e., antivirus and firewall) could provide effective protection against the botnet attacks; however, the remaining security-unconscious users will suffer from the botnet attacks and will be compromised easily. Consequently, how to protect both security-conscious and security-unconscious users against advanced botnets (without any command and control vulnerability) has posed a great challenge to this day. In this paper, we propose the idea of botnet spoofing that aims at addressing the aforementioned challenge to some degree. Botnet spoofing exploits the essential property of a persistent bot that it MUST obtain its file path before subsequent autostart registration or self-propagation to spoof a specific bot and trick the specific bot to propagate BotSpoofer instead of propagating itself, consequently making the victim not only avoid an originally successful attack but also achieve extra protection provided by BotSpoofer. Thus, botnet spoofing is independent of the vulnerability, protocol, and structure of botnet command and control. To prove the feasibility of botnet spoofing, we create a prototype named ConSpoofer-targeting Conficker. The results show that ConSpoofer could be passively delivered to other victims, which are located by Conficker, through Conficker's three propagation methods in an automatic, simple, accurate, and scalable manner. The goal of our work is to provide a new mitigation strategy that will promote the development of more efficient countermeasures against advanced botnets. Copyright © 2013 John Wiley & Sons, Ltd.

1 INTRODUCTION

  1. Top of page
  2. ABSTRACT
  3. 1 INTRODUCTION
  4. 2 RELATED WORK
  5. 3 OVERVIEW OF BOTNET SPOOFING
  6. 4 BOTNET SPOOFING IMPLEMENTATION
  7. 5 A CASE STUDY OF CONFICKER
  8. 6 APPLICATION SCENARIO
  9. 7 BOTSPOOFER HONEYPOT
  10. 8 CONCLUSIONS AND FUTURE WORK
  11. ACKNOWLEDGEMENTS
  12. REFERENCES

A botnet consists of a network of compromised computers connected to the Internet that is controlled by a remote attacker (botmaster) via command and control (C&C) channels. Botnets are the root cause of many Internet attacks such as e-mail spam, extortion through distributed denial-of-service, seeding malware, online identity theft, and click fraud. As botnet-based attacks become popular and dangerous, security researchers have studied how to detect, track, measure, and defend against them. Besides, some researchers focus on advanced botnet designs that could be developed by attackers in the near future. Most of all, the ultimate goal is fighting back the botnet threat. For example, as a result of cooperative defense efforts, defenders have successfully shut down many famous botnets such as Rustock [1], Mariposa [2], Waledac [3], Stuxnet [4], and Coreflood [5] by exploiting their C&C design flaws, that's really exciting.

However, the emerging advanced botnets will not simply rely on a centralized C&C, botnets using domain flux [6] algorithm and customized P2P protocol have become increasingly common in the arms race between botmasters and defenders; they are more resistant to traditional mitigation strategies such as domain revocation, DNS (Domain Name System) redirection, index poisoning, and Sybil attack. For example, Conficker [6] constructs an extremely resilient C&C channel by combining domain flux and unstructured random scan-based P2P protocol, making traditional countermeasures inefficacious. Because we cannot exploit its vulnerability of C&C to disable it, the only realistic method to disrupt the botnet seems to be host-level clean. However, a large percentage of security-unconscious Internet users would never install any security software, resulting in vulnerable to Conficker attack for a long time. Once these vulnerable computers are infected, they will subsequently become fresh attack sources and then propagate continuously. Therefore, how to fight against advanced botnets without any C&C vulnerability as well as protect the extensive vulnerable users has posed a great challenge to this day.

By considering the challenges and requirements listed earlier, in this paper, we propose our research on a novel botnet mitigation approach named botnet spoofing to address the aforementioned challenges to some extent. We define botnet spoofing as a technique that could trick a malicious bot to spread BotSpoofer instead of spreading itself. BotSpoofer is defined as a computer program that implements botnet spoofing technique.

The initial idea of botnet spoofing is inspired by cockroach killer. Cockroach killer could lead to a contagion inside the cockroach group. In other words, the infected cockroach is not expected to die immediately; on the contrary, it is misled to use its own addressing method to back infect other cockroaches. BotSpoofer works similar to cockroach killer to some extent. It tricks a malicious bot, using its own propagation mechanisms, to spread BotSpoofer instead of spreading itself to other victims. After BotSpoofer is delivered and executed on the victims, the victims will not only avoid an originally successful attack but also obtain extra protection provided by BotSpoofer. Compared with BotSpoofer, antivirus software is similar to a mousetrap, that is, clip the occasionally passing mouse (i.e., bot) and then kill it.

The ultimate objective of botnet spoofing is to clean the infected hosts as well as protect vulnerable hosts in the Internet. It mainly targets self-propagating persistent botnets. Here, a persistent bot is referred to as a bot carrying at least one file in the hard disks. In fact, most current bots are persistent (i.e., RBot, SDBot, Agobot, Conficker, and Waledac). They normally exist as DLL or EXE files in the hard disks. Note that there also exists some nonpersistent malware. For example, Slammer and CodeRed worms are nonpersistent because they only exist in memory and will disappear after the victim is powered off.

This paper makes the following main contributions.

  • This paper proposes a novel and effective botnet spoofing technique to hold back advanced botnets. Unlike existing mitigation approaches, the proposed technique is grounded on the essential properties of persistent bots rather than the C&C vulnerabilities of botnets. Thus, the technique is independent of the vulnerability, protocol, and structure of botnet C&C.
  • This paper builds a ConSpoofer prototype to fight against Conficker—one of the most widespread and sophisticated botnet till now. The results show that the proposed technique is effective and can effectively eliminate Conficker in an automatic, simple, accurate, and scalable manner.

The rest of the paper is organized as follows. Section 2 introduces related studies. In Section 3, we describe the main idea of botnet spoofing technique. In Section 4, we introduce the implementation of botnet spoofing. In Section 5, we build a ConSpoofer to defeat Conficker to prove the feasibility of botnet spoofing. In Section 6, we discuss the legal and ethical issues. In Section 7, we discuss some intuitive controversy about botnet spoofing. We conclude the paper in Section 8.

2 RELATED WORK

  1. Top of page
  2. ABSTRACT
  3. 1 INTRODUCTION
  4. 2 RELATED WORK
  5. 3 OVERVIEW OF BOTNET SPOOFING
  6. 4 BOTNET SPOOFING IMPLEMENTATION
  7. 5 A CASE STUDY OF CONFICKER
  8. 6 APPLICATION SCENARIO
  9. 7 BOTSPOOFER HONEYPOT
  10. 8 CONCLUSIONS AND FUTURE WORK
  11. ACKNOWLEDGEMENTS
  12. REFERENCES

The existing botnet mitigation approaches mainly fall into three categories. The approaches in the first category make use of the vulnerabilities of the single-point-of-failure existed in centralized C&C botnets. Common countermeasures proposed in this category include DNS redirection, DNS domain revocation, and rendezvous server shutdown. These approaches can directly result in botnet masters' loss control of their bots [1, 2, 4, 5, 13]. However, these approaches will fail to work, if the centralized botnets use dynamically generated domain names [7, 14]. The approaches in the second category focus on fighting against DHT (Distributed Hash Table)-based P2P botnets. The most common countermeasures proposed in this category are index poisoning and Sybil attack. These two approaches can lower C&C efficiency; however, they could not shut down the whole botnets [15, 16]. Some other research makes use of bootstrap attack to mitigate botnets. Although bootstrap approaches are effective in theory, they are not practical because of their high coordination cost. Besides, botnets could replace the hard-coded bootstrap nodes gradually [17]. The approaches proposed in the third category focus on offensive countermeasures such as hijacking and exploitation. The hijacking approaches make use of authentication vulnerabilities in C&C protocol to inject fake commands (i.e., uninstall and execute program) into botnets. The exploitation approaches make use of bugs in bots to perform clean actions on the infected machines [13].

However, all of the existing countermeasures could not counter advanced botnets effectively because they can only work depending on the vulnerabilities of botnets. Advanced botnets have no C&C vulnerabilities to be exploited. They are resilient to the existing mitigation approaches. Let us consider Conficker as a real example. Conficker combines domain flux and unstructured random scan-based P2P to construct its C&C channel. This kind of C&C channel is too resistant to be defeated by any existing countermeasures. Although the MD6 algorithm used by Conficker.B has been found to contain buffer overrun vulnerability, this vulnerability is not exploitable. In addition, sinkhole can be used to lower the efficiency of domain flux-based C&C; however, this approach is helpless to deal with P2P-based C&C. In fact, we have no effective countermeasures to fight against Conficker at present.

Our study compliments the existing research in that (i) botnet spoofing could mitigate most of botnets even though there is no vulnerability in the C&C design and implementation, (ii) botnet spoofing is independent of botnet C&C protocol and structure and does not requires an in-depth and comprehensive analysis over the targeted botnet, (iii) botnet spoofing need less cooperation, and (iv) BotSpoofer will not bring extra traffic to the Internet. All of the aforementioned features make botnet spoofing a desirable compliment to current research.

3 OVERVIEW OF BOTNET SPOOFING

  1. Top of page
  2. ABSTRACT
  3. 1 INTRODUCTION
  4. 2 RELATED WORK
  5. 3 OVERVIEW OF BOTNET SPOOFING
  6. 4 BOTNET SPOOFING IMPLEMENTATION
  7. 5 A CASE STUDY OF CONFICKER
  8. 6 APPLICATION SCENARIO
  9. 7 BOTSPOOFER HONEYPOT
  10. 8 CONCLUSIONS AND FUTURE WORK
  11. ACKNOWLEDGEMENTS
  12. REFERENCES

3.1 Framework of botnet spoofing

In the framework of botnet spoofing, Internet hosts can be classified into three groups; they are Infected, Vulnerable, and BotSpoofer groups, respectively. The Infected group contains hosts that have already been compromised by a bot, the Vulnerable group contains vulnerable hosts that could be located and then infected by a bot, and the BotSpoofer group contains hosts that have been equipped with BotSpoofer. There are a total of three kinds of actions to trigger a host to transfer from one group into another group, as shown in Figure 1.

image

Figure 1. Framework of botnet spoofing.

Download figure to PowerPoint

Action 1—triggers hosts to transfer from Vulnerable to Infected group. When an infected host compromises a vulnerable host, the latter will become infected.

Action 2—triggers hosts to transfer from Vulnerable to BotSpoofer group. When BotSpoofer compromises a vulnerable host, the latter will equipped with BotSpoofer.

Action 3—triggers hosts to transfer from Infected to BotSpoofer group. When BotSpoofer compromises an infected host where a specific bot is resident, BotSpoofer will clean the infected host under user's grants.

With the increase in the size of BotSpoofer group and the decrease in the size of infected and vulnerable group, the specific bots will decline continuously. At the same time, the vulnerable hosts will be protected automatically by the BotSpoofer.

3.2 The difference between botspoofer and antiworm

BotSpoofer is similar to antiworm (or good worm) [18] at first glance, whereas they are different in essential.

  • Antiworm needs to write a complete new code that could not exploit the function of the existing malicious worm. Thus, it costs more time and resources.
  • Antiworm coexists and overlaps with the malicious worm, so it will inescapably arise extra traffic, making situation worse.
  • The victim-locating method between antiworm and the malicious worm is different, so antiworm might probably infect innocent victims.

4 BOTNET SPOOFING IMPLEMENTATION

  1. Top of page
  2. ABSTRACT
  3. 1 INTRODUCTION
  4. 2 RELATED WORK
  5. 3 OVERVIEW OF BOTNET SPOOFING
  6. 4 BOTNET SPOOFING IMPLEMENTATION
  7. 5 A CASE STUDY OF CONFICKER
  8. 6 APPLICATION SCENARIO
  9. 7 BOTSPOOFER HONEYPOT
  10. 8 CONCLUSIONS AND FUTURE WORK
  11. ACKNOWLEDGEMENTS
  12. REFERENCES

4.1 Spoofing methodology

The most important part of botnet spoofing is the methodology of spoofing a bot, that is, to make a bot reside and propagate BotSpoofer instead of spreading itself. With reading source code and reverse analyzing binary file of a good deal of self-propagating worms and bots (including but not limited to MSBlaster, Welchia, SDBot family, Rbot family, Agobot family, Slapper, Mariposa, Rustock, Conficker, Waledac, Bobax/Kraren, Storm, etc.), we have a fundamental observation that a persistent bot (both EXE and DLL) MUST obtain its file path for its subsequent autostart registration and self-propagation. Therefore, the key issue of spoofing a bot lies in tricking it to retrieve a fake path. In this paper, we present two straightforward spoofing methods as follows. In fact, many other ways can be used to spoof a bot. We believe that other more creative methods are only limited by imaginations.

API hooking. Given the fact that most bots employ the application programming interface (API)—GetModuleFileName—to obtain their full file paths, we can hook this API so as to cheat the bots, as shown in Figure 2. Specially, whenever GetModuleFileName API is called in the process space of a bot, the file path of BotSpoofer will be returned instead of the real path of the bot. Note that the hook operation can only be carried out in malicious bot's process space; therefore, other processes cannott be affected by API hooking. Generally speaking, this is the most simple but commonly effective spoofing method to counter most of advanced bots.

image

Figure 2. Spoofing via API hooking.

Download figure to PowerPoint

Address substitution. Bots relying on remote vulnerability exploitation must send Shellcode to remote potential victims. The Shellcode always contains the IP address of infection source and a PORT opened by the malicious bot as a service, which will be used for subsequent reverse connection from the victim. Hence, BotSpoofer could replace this PORT with a new one listened by it, by which way the remote Shellcode on victim will connect back to BotSpoofer instead of the real bot. An example is shown in Figure 3. Note that it is also quite frequent that the bot is obtained from a third party, not from the infection source. In this situation, BotSpoofer will substitute the IP address rather than the PORT.

image

Figure 3. Spoofing via address substitution.

Download figure to PowerPoint

4.2 Creating BotSpoofer

A priori analysis. Having an a priori knowledge of a specific bot is the first step to create a corresponding BotSpoofer. In general, we need four aspects of a priori knowledge.

  • First, how the specific bot locates itself. For example, a bot usually calls GetModuleFileName API to retrieve its file path.
  • Second, how it is loaded. For example, bot existing as a DLL file usually uses rundll32.exe as its loader while bot existing as an EXE file can be activated by any parent processes.
  • Third, how the bot verify itself. For example, a bot could calculate the hash of the file, obtain the file size, or read a magic value from the file to verify its authenticity. If a bot has self-verification capability, we must first patch (similar to crack) its verification related code to prevent the bot from detecting that it has been encapsulated into a BotSpoofer binary. Note that not all verification code in the bot can be easily patched; in the presence of packed or obfuscated bot binaries, such modifications are better to be performed dynamically for simplicity. Although most of current malware do not verify their authenticity, we believe it is just a matter of time.
  • Fourth, how the bot implements its C&C. For example, a bot could use IRC (Internet Relay Chat), HTTP (Hypertext Transfer Protocol), and P2P (PeertoPeer) protocol. Luckily, the C&C and self-propagation procedure usually use different PORTs, differentiating them on the basis of PORT possible (other methods are also possible). For example, BotSpoofer could block or filter all C&C traffic to prevent the bot from receiving commands via C&C channel that could avoid a wide range of malicious and illegal activities such as sending spam and stealing information. At the same time, the bot could continue to propagate.

Generally speaking, the a priori analysis is not a hard work and do not need an in-depth and comprehensive analysis, which facilitates the creation of BotSpoofer. After the a priori analysis, locating method, loading method, self-verification patching method, and C&C blocking method will be hard coded in BotSpoofer as shown in Figure 4.

image

Figure 4. BotSpoofer PE structure.

Download figure to PowerPoint

BotSpoofer PE (Portable Executable) structure. BotSpoofer is an executable program; its file extension is determined by the targeted bot. BotSpoofer hard codes the specific bot and the corresponding locating method and loading method in its resource section, as shown in Figure 4. When BotSpoofer executes, it releases the specific bot, loads, and spoofs it on the basis of the hard-coded loading and locating policy. As a result, when the specific bot tries to locate its file path, it is tricked to return the file path of BotSpoofer. When the specific bot exploits other victims, copies itself to removable devices, sends itself as an e-mail attachment, or joins to P2P networks as shared resource; it is actually spreading BotSpoofer instead of spreading itself.

BotSpoofer for different persistent bots. The file types of most persistent bots are either DLL or EXE. Although there are also some other extension names such as SCR (Screen), their spoofing procedures are the same as that of bots with EXE extension names. Therefore, we will demonstrate how to create different BotSpoofers for these two types of persistent bots. Note that other approaches are also possible.

  • DLL bot. If a bot is a DLL file, BotSpoofer should hook GetModuleFileName first and then release and load the bot (i.e., LoadLibrary). So, BotSpoofer and the bot will run in same process space (i.e., rundll32.exe). An example of the process image is shown in Figure 5. When the bot calls GetModuleFileName, the file path of BotSpoofer will be returned.
  • EXE bot. If a bot is an EXE file, BotSpoofer should execute the bot first in suspend mode and then inject a remote thread to hook the bot's GetModuleFileName. After the hooking operation is completed, BotSpoofer resumes the bot process. When the bot calls GetModuleFileName, the file path of BotSpoofer, which has been already written into the process space of the bot, will be returned. The spoofing procedure is shown in Figure 6.
image

Figure 5. Making specific BotSpoofer for DLL bot.

Download figure to PowerPoint

image

Figure 6. Making specific BotSpoofer for EXE bot.

Download figure to PowerPoint

4.3 BotSpoofer distribution mechanism and policy

BotSpoofer is distributed to massive Internet users mainly through two channels.

  • Security-conscious users download and install BotSpoofer actively and voluntarily. Obviously, it is not necessary for security-unconscious users to install BotSpoofer actively.
  • Delivered to either vulnerable hosts or infected hosts by the spoofed bot.

In the first case, users have the authorization to decide what functions inside BotSpoofer could be activated, how long it is permitted to survive, and how it is executed. In the second case, in addition to the policies mentioned earlier, BotSpoofer must obey more rules, for example, asking users' permission for downloading the corresponding patch through which it penetrates in and downloading other BotSpoofer that targets other malicious botnets. In one words, for BotSpoofer, it only works with the users' explicit authorization; as regards users, only those who are willing to devote computing and network resources will in turn have a chance to obtain further protections provided by BotSpoofer.

5 A CASE STUDY OF CONFICKER

  1. Top of page
  2. ABSTRACT
  3. 1 INTRODUCTION
  4. 2 RELATED WORK
  5. 3 OVERVIEW OF BOTNET SPOOFING
  6. 4 BOTNET SPOOFING IMPLEMENTATION
  7. 5 A CASE STUDY OF CONFICKER
  8. 6 APPLICATION SCENARIO
  9. 7 BOTSPOOFER HONEYPOT
  10. 8 CONCLUSIONS AND FUTURE WORK
  11. ACKNOWLEDGEMENTS
  12. REFERENCES

To prove the feasibility of botnet spoofing, we create a prototype named ConSpoofer to fight against Conficker. Although botnet spoofing is independent of the vulnerability, protocol, and structure of botnet C&C, selecting an advanced botnet without any C&C vulnerability is obviously more meaningful and persuasive. For this reason, we take Conficker as an example to illuminate botnet spoofing. For discussion convenience, we name this specialized BotSpoofer targeting Conficker as ConSpoofer.

5.1 Background of Conficker

Conficker, first appeared in November 2008, is one of the most widespread and sophisticated botnet till now. It exploits three propagation vectors including MS08-067 vulnerability, removable devices, and network share. Conficker utilizes many new and advanced techniques including domain generation algorithm, customized random scan-based P2P C&C and self-defense mechanisms. As a result, it could infect about 7–15 million computers in the world in a short time [9]. Existing research on Conficker mainly falls into two categories. The approaches in the first category focus on analyzing the Conficker binary codes, to reveal its internal principles [6, 9, 10]. The approaches in the second category mainly focus on analyzing the network data [11] and DNS sinkhole data [12], to reveal the propagation characteristics of Conficker. However, there are still no efficient countermeasures that could eliminate it or hold back its propagation because of its extremely robust C&C and sophisticated propagation mechanisms.

5.2 A priori analysis

PE information. We randomly select a Conficker.B sample. Its MD5 is 3aff8601a8a6fc1dccb836ae3e971e3e, file name is atsjshck.dll, and file size is 158967 bytes.

Locating method. Conficker, like majority of botnets, also employs GetModuleFileName, as shown in Figure 7(a), to locate its file path. Thus, we could adopt API-hooking method to spoof it. Note that other methods are also feasible. For example, when propagating via MS08-067, Conficker needs to send a Shellcode containing the IP address of infection source and a HTTP server opened by Conficker. We can replace the port to make the remote victim connect back with new HTTP server opened by ConSpoofer and then download ConSpoofer.

image

Figure 7. Conficker reverse engineering.

Download figure to PowerPoint

Loading method. When arriving at a new victim, Conficker always uses rundll32.exe as loader, as shown in Figure 7(b). More specially, when Conficker tries to propagate via MS08-067, removable devices, and network share, it always relies on rundll32.exe to execute for the first time. More accurately, rundll32.exe is Conficker's initial loader.

Self-verification patching method. Similar to most of current bots, Conficker does not verify the authenticity of its executable file, which facilitates the creation of ConSpoofer because we do not need to patch it.

C&C blocking method. The domain flux-based C&C of Conficker only uses HTTP 80 PORT; however, its P2P-based C&C may use any PORT. Thus, it is impossible to block C&C PORTs directly. Considering that Conficker only uses TCP (Transmission Control Protocol) 445 and 139 PORT to propagate, so we could block all PORT except TCP 445 and 139 to disable its C&C channel.

5.3 Creating ConSpoofer

ConSpoofer is designed to be a DLL file since Conficker is. To take along with Conficker, locating method and loading method, ConSpoofer embeds them into the resource section as shown in Figure 8(a). When ConSpoofer executes, it first hooks GetModuleFileName and then releases Conficker as a DLL file to a temporary directory with a random filename and then loads it (using LoadLibrary API), as shown in Figure 8(b). When Conficker is loaded, it will begin to retrieve its file path by using GetModuleFileName and store the path to a global variable. Of course, the file path actually points to ConSpoofer thanks to the hooked GetModuleFileName, which always returns the path of ConSpoofer. Note that ConSpoofer must sleep for enough time (i.e., infinite) to ensure that Conficker could finish all its work. After that, Conficker will call ExitProcess API, resulting in the termination of rundll32.exe process. During the procedure, ConSpoofer is registered as an autostart service and spread to other victims by Conficker. The pseudo-core code of ConSpoofer is abstracted as Table 1.

image

Figure 8. ConSpoofer file and image.

Download figure to PowerPoint

Table 1. The pseudo-core code of ConSpoofer.
Hook GetModuleFileName and then Load Conficker
BOOL APIENTRY DllMain (…)
{
GetModuleFileName(hModule,szConSpooferPath, …);
HookGetModuleFileName (szConSpooferPath);
LoadLibrary (szConfickerPath);
Sleep (INFINITE);
}
DWORD WINAPI NewGetModuleFileName ( …)
{
lstrcpy (me, szConSpooferPath);
return lstrlen (me);
}

5.4 Experiments

Because Conficker employs three propagation vectors, we set up an experiment environment with four computers, where computer V has MS08-067 vulnerability, computer W has weak password vulnerability, computer U has autorun feature, and computer S is an infection source that equips with ConSpoofer.

After ConSpoofer is started on S for several minutes, S infects V and W successfully. In V, ConSpoofer is executed by the Shellcode sent from S to V. In W, ConSpoofer is added to Task Scheduler and waiting to be executed. In addition, after an USB (Universal Serial BUS) device is inserted into S, Autorun.inf and ConSpoofer files are created in the USB device immediately. When the USB (Universal Serial BUS) device is connected to U, ConSpoofer is activated. Furthermore, ConSpoofer is registered as an autostart service automatically by the released Conficker in all computers.

5.5 Effectiveness analysis of ConSpoofer

  • Automation. For vulnerable hosts, they need to do nothing but wait for the incoming ConSpoofer. Once infected by ConSpoofer, the vulnerable hosts will avoid a Conficker attack automatically.
  • Simplicity. The simplicity of applying ConSpoofer is obvious. We only need to know the locating and loading methods of Conficker before spoofing it. In addition, the autorun.inf file and the scheduled task created by Conficker in the process of propagation also help to make sure its loading.
  • Accuracy. ConSpoofer knows nothing about the addressing algorithm of attack targets. It relies on Conficker to locate possible victims; otherwise, the victims will be infected by real Conficker. Consequently, the selection of attack victims is extremely accurate.
  • Scalability. Host-based security software could not protect those security-unconscious users. On the other hand, although network-based security systems are useful, we believe it is unpractical to deploy any network-based system across Internet scale because of the limitation of the immeasurable resources consumption. In comparison, ConSpoofer is naturally scalable—the more nodes deployed, the more effective it will be. Moreover, it is almost cost free.

The effectiveness analysis is also suitable for other BotSpoofers that aim to defeat other botnets. Because most of DLL-based botnets share common loading mechanisms, the differences between their corresponding BotSpoofers are little. To a great extent, ConSpoofer is also suitable to many other DLL-based botnets without any modification.

6 APPLICATION SCENARIO

  1. Top of page
  2. ABSTRACT
  3. 1 INTRODUCTION
  4. 2 RELATED WORK
  5. 3 OVERVIEW OF BOTNET SPOOFING
  6. 4 BOTNET SPOOFING IMPLEMENTATION
  7. 5 A CASE STUDY OF CONFICKER
  8. 6 APPLICATION SCENARIO
  9. 7 BOTSPOOFER HONEYPOT
  10. 8 CONCLUSIONS AND FUTURE WORK
  11. ACKNOWLEDGEMENTS
  12. REFERENCES

The technical feasibility of the botnet spoofing technology does not justify its application in the real Internet [8]. In this section, we will discuss the legal and ethical aspects and the practical application scenario of botnet spoofing technology.

6.1 Legal and ethical issues

Considering the aspect of compromising other vulnerable computers, BotSpoofer also suffers from the enormous legal and ethical problems involved with running unsolicited code on arbitrary systems. Moreover, a malicious botnet is not only propagating itself but also sends spam, steals information, and performs a wide range of malicious and illegal activities. Therefore, letting the malware run so that BotSpoofer can propagate to other machines would also cause many other problems that could have been avoided by stopping the malware in the first place. In addition, because the BotSpoofer contains almost all codes of the malware, when people voluntarily download and install it, they basically compromise their system with the malware too. To sum up, the legal and ethical issues are a major problem that cannot be easily overcome. Consequently, BotSpoofer should never be deployed in real Internet. We must apply them in a less ethically sensitive scenario, which could ensure the capability of BotSpoofer at the same time preventing it from causing harm.

7 BOTSPOOFER HONEYPOT

  1. Top of page
  2. ABSTRACT
  3. 1 INTRODUCTION
  4. 2 RELATED WORK
  5. 3 OVERVIEW OF BOTNET SPOOFING
  6. 4 BOTNET SPOOFING IMPLEMENTATION
  7. 5 A CASE STUDY OF CONFICKER
  8. 6 APPLICATION SCENARIO
  9. 7 BOTSPOOFER HONEYPOT
  10. 8 CONCLUSIONS AND FUTURE WORK
  11. ACKNOWLEDGEMENTS
  12. REFERENCES

7.1 Deployment environment

Considering the fact that BotSpoofer may cause harm to Internet, it is better to be deployed in a local area network (LAN) and acts as a particular Honeypot we name BotSpoofer Honeypot (BH). In comparison, traditional Honeypots could only capture malware or intrusion behaviors. However, a honeypot equipped with BotSpoofer goes a further step; it could protect many security-unconscious internal computers from being compromised by the same threat that has already been detected by BH.

In the LAN, BotSpoofer is deployed in a Honeypot computer and waits for being attacked by the hard-coded known self-propagating malware originating from either Internet or LAN. To intercept the malicious activities inside the malware, in BH, all outgoing traffic destined to Internet excepting the C&C communication should be blocked. However, traffic destined to computers in the same LAN is allowed to enable the propagation ability of the given malware. Furthermore, in such an environment, BotSpoofer will adopt an extreme policy that does not hard code the original malware because the main usage of it is to identify the possible vulnerable computers in the LAN. Because a LAN has corresponding network administrators and relatively cooperative users, such a deployment policy is quit feasible. The typical deployment environment and working procedure are shown in Figure 9.

image

Figure 9. The typical deployment environment and working procedure.

Download figure to PowerPoint

7.2 Security of BotSpoofer Honeypot

Security of LAN. Generally, a malware scanning and attacking local computers only aims to propagate itself. So when the malware in BH successfully finds a exploitable vulnerability of a victim, it will transfer BotSpoofer containing no malware to the vulnerable computer. BotSpoofer could then alert the users and LAN administrators. Because only BotSpoofer is allowed to leave the Honeypot, the real malware could not cause harm to the LAN.

Security of Internet. When a malware executes in BH, it may perform some malicious activities such as distributed denial-of-service and sending spam. However, the administrators have blocked all kinds of traffic initiating from BH except C&C traffic in advance. Therefore, BH is hard to cause harm to the Internet.

Resilience of BotSpoofer. When botmasters know the existence of botnet spoofing, they would probably employ new evading techniques. If they develop new locating methods to evade both API hooking and address substitution (much in the same way that virus writers seek to evade current antivirus software), we must respond corresponding. For example, if a bot uses GetModuleFileNameEx or QueryFullProcessImageName to retrieve its full path, BotSpoofer must hook them correspondingly; if the particular bot employs self-verification mechanism, we must patch it (much in the same way that crackers seek to bypass the verification mechanism of legal copy software) before creating a specific BotSpoofer. For example, if the bot uses MD5, file size, and magic number to verify itself to guard against modification, a binary patch is needed in advance (i.e., patch the jne instruction to je instruction). For the aforementioned reasons, we must have the a priori knowledge about a particular bot before creating a corresponding BotSpoofer. Thanks to the a priori knowledge and patching mechanism, botnet spoofing promises to be resilient to the countermeasures of botmasters.

8 CONCLUSIONS AND FUTURE WORK

  1. Top of page
  2. ABSTRACT
  3. 1 INTRODUCTION
  4. 2 RELATED WORK
  5. 3 OVERVIEW OF BOTNET SPOOFING
  6. 4 BOTNET SPOOFING IMPLEMENTATION
  7. 5 A CASE STUDY OF CONFICKER
  8. 6 APPLICATION SCENARIO
  9. 7 BOTSPOOFER HONEYPOT
  10. 8 CONCLUSIONS AND FUTURE WORK
  11. ACKNOWLEDGEMENTS
  12. REFERENCES

To defend against the emerging advanced botnets and protect the extensive vulnerable Internet users, in this paper, we propose the idea of botnet spoofing and have a systematic study on it including the methodology of botnet spoofing, the principle of making a specific BotSpoofer, and the distributing policies. Botnet spoofing exploits the essential property inside a persistent bot to trick it to spread BotSpoofer instead of spreading itself. In this way, BotSpoofer could be distributed to massive vulnerable computers by the malicious bot and then begin to protect them. Compared with traditional mitigation strategies, the distinctive advantage of botnet spoofing lies in its capability to clean the bots even no vulnerability existing in the botnet C&C and protect the vulnerable hosts including both security-conscious and security-unconscious users. In addition, botnet spoofing requires less supports from ISP (Internet Service Provider) and domain registrar and could operate in an automatic, simple, accurate, and scalable way. We believe all these features make botnet spoofing a meaningful complement to current mitigation strategies. We also make a specific BotSpoofer targeting Conficker, and the experiment results prove that it is feasible. In the end, we give a feasible application scenario of botnet poisoning, which could avoid its natural legal and ethical problems when deploying on the real Internet. In the future, we will invest more research on how to eliminate the harm of the hard-coded particular bot [19] while still ensuring that it exhibits its inherent propagation behavior.

ACKNOWLEDGEMENTS

  1. Top of page
  2. ABSTRACT
  3. 1 INTRODUCTION
  4. 2 RELATED WORK
  5. 3 OVERVIEW OF BOTNET SPOOFING
  6. 4 BOTNET SPOOFING IMPLEMENTATION
  7. 5 A CASE STUDY OF CONFICKER
  8. 6 APPLICATION SCENARIO
  9. 7 BOTSPOOFER HONEYPOT
  10. 8 CONCLUSIONS AND FUTURE WORK
  11. ACKNOWLEDGEMENTS
  12. REFERENCES

This work is supported by the National Natural Science Foundation of China under grant (No. 61202409 and 61070186) and the National High Technology Research and Development Program (863 Program) of China under grant (No. 2012AA012902 and 2011AA01A103).

REFERENCES

  1. Top of page
  2. ABSTRACT
  3. 1 INTRODUCTION
  4. 2 RELATED WORK
  5. 3 OVERVIEW OF BOTNET SPOOFING
  6. 4 BOTNET SPOOFING IMPLEMENTATION
  7. 5 A CASE STUDY OF CONFICKER
  8. 6 APPLICATION SCENARIO
  9. 7 BOTSPOOFER HONEYPOT
  10. 8 CONCLUSIONS AND FUTURE WORK
  11. ACKNOWLEDGEMENTS
  12. REFERENCES
  • 1
    Williams Jeff. Operation b107 – Rustock Botnet Takedown. http://blogs.technet.com/b/mmpc/archive/2011/03/18/operation-b107-rustock-botnet-takedown.aspx. 2011.
  • 2
    Help Net Security. Massive Mariposa Botnet Shut Down. Net-security.org. http://www.net-security.org/secworld.php?id=8962. 2010.
  • 3
  • 4
  • 5
    Rashid Fahmida Y. FBI Shuts Down Coreflood Botnet, Zombies Transmitting Financial Data. http://www.eweek.com/c/a/Security/FBI-Shuts-Down-Coreflood-Botnet-Zombies-Transmitting-Financial-Data-767165. 2011.
  • 6
    Porras P, Saidi H, and Yegneswaran V. A Foray into Conficker's Logic and Rendezvous Points. In USENIX Workshop on Large-Scale Exploits and Emergent Threats (LEET'09). 2009.
  • 7
    Stone-Gross B, Cova M, Cavallaro L, Gilbert B, Szydlowski M, Kemmerer R, Kruegel C, and Vigna G. Your botnet is my botnet: analysis of a botnet takeover. In Proc of the 16th ACM Conference on Computer and Communications Security (CCS'09). 2009.
  • 8
    Panel: Ethics in Botnet Research, In USENIX Workshop on Large-Scale Exploits and 8Emergent Threats (LEET'09). 2009.
  • 9
    Shin Seungwon and Gu Guofei Conficker and beyond: a large-scale empirical study. To appear in Proceedings of 2010, Annual Computer Security Applications Conference (ACSAC'10), Austin, Texasi, December 2010.
  • 10
    Watson D. Know Your Enemy: Containing Conficker. http://www.honeynet.org/papers/conficker.
  • 11
    CAIDA. Conficker/Conflicker/Downadup as seen from the UCSD Network Telescope. http://www.caida.org/research/security/ms08-067/conficker.xml.
  • 12
    Kristoff J. Experiences with Conficker C sinkhole operation and analysis. In Proceedings of Australian Computer Emergency Response Team Conference, May 2009.
  • 13
    Leder Felix, Werner Tillmann, and Martini Peter. Proactive botnet countermeasures – an offensive approach. In Cooperative Cyber Defence Centre of Excellence Tallinn. 2009.
  • 14
    Amini P, Pierce C, Kraken Botnet Infiltration. Blog on DVLabs. http://dvlabs.tippingpoint.com. 2008.
  • 15
    Davis C.R, Fernandez J, Neville S, Robert J. M, and McHugh J. Sybil attacks as a mitigation strategy against the Storm botnet. In the 3rd International Conference on Malicious and Unwanted Software. 2008.
  • 16
    Holz T, Steiner M, Dahl F, Biersack E. W, and Freiling F. Measurements and mitigation of peer-to-peer-based botnets: A case study on storm worm. Proc of the 1st Usenix Workshop on Large-scale Exploits and Emergent Threats. 2008.
  • 17
    Ping W, Sherri S, Cliff C. Z. An advanced hybrid peer to peer botnet. In Proc. of the First Workshop on Hot Topics in Understanding Botnets (HotBots'07), 2007.
  • 18
    Castaneda F, Sezer E.C. and Xu J. WORM vs. WORM: preliminary study of an active counter-attack mechanism. In Proc. of the 2004 ACM Workshop on Rapid Malcode. 2004.
  • 19
    Kreibich C, Weaver N, Kanich C, Cui W and Paxson V. GQ: practical containment for measuring modern malware systems. In Proc. of the 2011 ACM SIGCOMM Conference on Internet Measurement Conference. 2011.