|
|
10.1 Blast-o-Mat: Using Nepenthes to Detect Infected Clients
10.2 Search Worms
10.3 Red Hat 8.0 Compromise
10.4 Windows 2000 Compromise
10.5 SUSE 9.1 Compromise
10.6 Summary
Up to this point, we have primarily taken a look at the technique behind honeypots. We have introduced several tools and showed how to set up and configure them. Now we alter our point of view a bit and present some case studies and examples of the lessons learned with honeypots. At first, we introduce an operational example of how to detect infected machines on a network with the help of nepenthes. We present Blast-o-Mat, a custom network intrusion detection system (NIDS), developed and deployed at RWTH Aachen University, Germany. We introduce the main building blocks of the system and take a closer look at some techniques behind them, especially how the honeypot tool nepenthes is used. In addition, we present the lessons learned with Blast-o-Mat and take a closer look at one specific incident that shows the motives behind today's attacks. As a second example, we quickly introduce two lightweight intrusion detection systems based on nepenthes. These systems are used to get an overview of network attacks, and they also help you to detect infected clients on a given network.
As another case study, we show how honeypots can be used to learn more about specific attacks. We take a look at search worms — that is, worms that search their targets by querying popular search engines and then only attacking the vulnerable hosts. Honeypots can be used to study this kind of malware.
In the main part of this chapter we examine some compromises we observed when deploying several virtual high-interaction honeypots. In total, we present three examples of attacks against these honeypots. We give an attack summary and then show the actual attack with an annotated timeline of events. Moreover, we describe the captured tools. This part of the book gives you an overview of the information you can collect with honeypots. Based on this data, you can judge how honeypots can help you in your situation and how you can add a virtual honeypot (either a low-interaction or a high-interaction one) to your infrastructure.
This chapter would not have been possible without the help of several contributors. We would like to thank Jan Goebel and Jens Hektor from the Center for Computing and Communication at RWTH Aachen University for developing Blast-o-Mat and the support when running several honeypots. In addition, Torsten Stern gave us valuable information regarding the compromise of the Windows 2000 honeypot.
At RWTH Aachen University,[1] with about 40,000 computer users to support, we have built, together with the responsible people at the Center for Communication, a system to detect infected machines based on honeypots. One important building block of Blast-o-Mat is nepenthes, which we use both to detect malware-infected systems and to collect malware. Nepenthes is a low-interaction honeypot that appears as vulnerable software but instead decodes attack code and downloads malware. We introduced nepenthes in detail in Chapter 6, where you can find more background on the technique behind this tool. We have been successful at uncovering and quarantining infected systems with sensors listening at 0.1 percent of our address space, which consists of three Class B networks (about 200,000 IP addresses). Investigation of collected malware has led to discovery of many infected systems and even a huge cache of stolen identity information.
One important aspect of network attacks is malicious software (malware) that spreads autonomously over the network by exploiting known or unknown vulnerabilities. In the form of network worms or bots/botnets, malware poses a severe threat to today's Internet. For example, botnets cause damage from Distributed Denial of Service (DDoS) attacks, sending of spam, identity theft, or similar malicious activities. We take a closer look at botnets and related malware in Chapter 11. There you can find detailed information about this threat.
University networks are traditionally networks with a rather open security policy: Students and faculty staff often have unlimited access to the Internet and firewalls are sometimes only used in the sensitive parts of the network, whereas most of the network is free. In such an environment — and also in a lot of networks with higher security standards — mobile users pose a severe threat. These users have their own laptop and connect to the network via some kind of authentication — for example, with a central VPN server. The problem is that the laptops are often not secured at all — for example, important security patches are missing or the antivirus software is outdated. Such systems are often infected with some kind of autonomous spreading malware in the form of worms or bots. When the user now connects to the network, the malware tries to propagate further within the closed network and poses a threat to other users. "How can we defeat this kind of attack?" is the main question we want to answer. In the following, we show how we can achieve this goal with the help of honeypots.
Within the university network, we want to detect infected hosts as fast as possible. Only if we detect a compromised machine can we contain it and stop the spreading mechanism. This cessation protects other vulnerable hosts within the university network and also in external networks. Instead of using a classical intrusion detection system (IDS), we have built our own solution called Blast-o-Mat. The main reason for building something new was to find out whether it is viable to use honeypots as a system to detect infected machines within a given network.[2] Blast-o-Mat aims at automatic notification and handling of malware-infected hosts. The main task of Blast-o-Mat is to determine the person responsible for a system for which it receives an alert, to send out a warning to the owner, and, in case an infected host is still active after a certain period of time, to block network access to and from this host. It is automatically transferred to a quarantine network (i.e., all access to the Internet is rerouted to a certain server). Basically the infected machine can then only access certain sites to download patches and antivirus software. Within the quarantine network, we can also monitor what happens to the machine from a network point of view. As a result, we have a tool that automatically performs the time-consuming tasks that normally the network administrator has to carry out.
[2] The first version of Blast-o-Mat was built by Jens Hektor to detect systems infected with Blaster, a prominent network worm.
The system consists of several modules that try to detect an infected system:
Blast-Sniffer continuously reads traffic data from a SPAN or mirror port of a central router of the network and writes it to a MySQL database. This database serves as the input for the next two intrusion detection sensors.
Blast-PortScan detects hosts that are scanning a large number of IP addresses for certain ports, which could indicate a malware-contaminated machine. To accomplish this task, the module counts the number of TCP SYN packets sent by each host during a preconfigured period of time. Within our environment, a threshold of 50 SYN packets within four minutes has proven to be a reasonable indicator that tends not to generate false positives and is capable of detecting infected hosts efficiently.
Blast-SpamDet aims at detecting machines that send spam messages. Similar to the portscan detector, it counts the number of initiated connections from a suspicious host, but this time only connections to mailservers are considered. When a certain number of connections is reached, the server entity starts to gather e-mail header information of the suspected host with the help of packet-capture tools. All used sender addresses are filtered and counted. If the number of unique sender addresses exceeds a certain threshold, further actions are initiated.
Nepenthes is a low-interaction honeypot solution that is capable of automatically downloading malware. We have described its inner workings in a previous chapter. We use this module to get in-depth information about ongoing network attacks and the analysis of the downloaded binary can help us to further examine the incident. A nice property of nepenthes is that it does not generate any false positives. This sensor is only triggered by a successful exploit, a clearly malicious activity.
These different kinds of modules interact with each other; especially the Blast-Sniffer module is important, since it captures the network information that is then processed by the two other modules. Figure 10.1 gives a schematic overview of the system.
As you can see, the Blast-Sniffer module collects a traffic dump at the central gateway. Since the network traffic of RWTH Aachen already exceeds one Gigabit per second, we need dedicated hardware for this task. The two other Blast-modules process the information gathered by the sniffing module and try to detect network anomalies and signs of infected hosts. The nepenthes module is placed "within" the university network. Currently, we use 180 IP addresses spread evenly across the whole network range. This is achieved by routing small, dedicated network blocks to the nepenthes sensor and then adding several IP addresses to the network interface of that machine. We use the tool ip from the iproute2 utilities suite, as introduced in Section 6.2.6.
We have already introduced nepenthes in greater detail in Chapter 6, so we are going to briefly summarize its functionality here to recapitulate the core functionality. This low-interaction honeypot aims at capturing malicious software such as networks worms or bots that spread in an automated manner. The main focus of this application is to obtain the malware itself (i.e., to download and store the malware binary for further in-depth analysis). Unlike other low-interaction honeypots, nepenthes does not emulate full services for an attacker to interact with. The key idea is to offer only as much interaction as is needed to exploit a vulnerability. For this reason, nepenthes is not designed for any human interaction, as the trap would be easily detected. On the contrary, for the automated attack, just a few general conditions have to be fulfilled, thus maximizing the effectiveness of this approach. These conditions usually include displaying the correct banner information of an emulated service and sending back specific information at certain offsets during the exploitation attempts. Therefore, the resulting service is only partially implemented. This allows deployment of several thousands of virtual honeypots with only moderate requirements in hardware and maintenance. We have presented some measurements on the scalability of nepenthes in Section 6.2.10 and a complete overview of nepenthes is available in Section 6.2.
Within the Blast-o-Mat architecture, nepenthes serves as a sensor to detect infected machines. These machines typically try to propagate further by scanning for vulnerable machines. Thus, we have placed nepenthes sensors all over the network, and on each of these IP addresses they emulate common vulnerabilities as already explained. We use about 180 IP addresses to cover three /16 networks, thus covering about 0.1 percent of all addresses.
Since most autonomous spreading malware is scanning aggressively for other targets (most of the time with 200–300 threads in parallel), this splitting of the sensor IPs across the whole network range has proven to be efficient to detect infected hosts. One important finding is that nepenthes has not generated any false positives. Whenever nepenthes signals a successful exploitation attempt, it is not a portscan or misconfigured system but a real intrusion attempt. This is mainly due to the fact that the honeypot tool only triggers if a successful exploit happened. Nepenthes only sends back data to an attacking host if it matches a specific exploit signature. Thus, we are not prone to false positives, a common problem that intrusion detection systems face. To this point, the Blast-o-Mat system has already detected hundreds of infected machines and the automatic containment works without problems.
As soon as an infected system has been detected by one of the Blast-modules or nepenthes, the first question entails how to deal with it. Presumably the best way is to immediately take the system offline, giving it as little chance as possible to infect other systems in the network. The inhibition can take place on any of the Internet protocol layers, depending on the given infrastructure. If direct access to the switch port of the conspicuous machine is given, one can disable this port. In this case the host is locked at the physical layer. An inhibition on layer 2, the data link layer, is equal to blocking the MAC address of the hostile host. This approach would also prevent the system from being taken online again on a different switch port. The disadvantage of these two methods is the effort it takes to determine the correct network device to which the contaminated machine is connected. Less costly is the locking of the IP address with the help of access lists (network layer). In this case, we need to determine the router, which routes the appropriate network. Although the host is properly blocked, it can still infect systems within the same local area network (LAN). On higher layers of the Internet protocol model, it is possible to lock certain TCP or UDP ports or operate different protocol-specific filters to isolate an infected host. However, all modifications to network components have to be reverted, as soon as the problem is solved and the user wants to get back online.
A different approach of taking a contaminated host offline is to place it into a quarantine network, isolating it from other systems. This approach is also called Walled Garden, and many commercial variations are available to implement a similar approach. Quarantine VLANs with commercial NAC/NAP/TNC solutions from Microsoft, Cisco, Juniper, or other vendors implement something similar.
Although a quarantine network requires a certain infrastructure, this is the most effective solution, since additional information can be collected from the quarantined host. We could, for example, use honeypots within the quarantine network to simulate a network with which the infected machine could interact to collect more information about the incident. Currently, we have implemented a simple form of such a quarantine network: The Blast-o-Mat is capable of redirecting HTTP traffic of infected machines to a special web server. Before taking a look at the practical implementation of this approach, we introduce two ways to actually block the infected host.
When blocking, we differentiate between two different groups of users: static IPs (normally staff people or PC pools) and dynamic IPs (typically WLAN users).
To identify the responsible person(s) for hosts with static IP addresses, we maintain an XML-based database with all relevant information: For each subnet the database contains the registered administrators, their phone number and e-mail address, the netmask, the acronym of the institute, and, if available, the assigned Virtual Local Area Network (VLAN) number. Additionally, for each entry there exists information about the manageable network router, through which the associated subnet is routed. To lock a host with a static IP address, use is made of a Perl script capable of automatically creating antispoofing access lists. These access lists can be extended with firewall rules or, in our case, with lists of locked machines, thus efficiently blocking contaminated hosts from accessing the network.
To identify the responsible person for a dynamically assigned IP address, we have to ascertain the account name from the authentication or accounting server. Therefore, we have to compare the IP address and the time of the incident with the information stored in a Radius server. Remote Authentication Dial In User Service (RADIUS) is a protocol for authentication, authorization, and accounting. It is mainly used by Internet service providers to check the credentials when logging in to a network or computing accounting information. We run a slightly modified version of the FreeRadius software,[3] which writes its accounting data to a MySQL database, on a daily basis. Thus, we have a database table for each day, which greatly accelerates the process of searching for specific accounting data. The account locking of an infected host is accomplished by setting a special flag in the LDAP database, which is used for user authentication. Once the flag is set, a user with an infected machine can no longer connect to the campus network and has to contact the helpdesk to be unlocked again.
One of the more complicated tasks in automatic locking of infected systems is to notify the user of the suspected host. Our main method is to notify any responsible person via e-mail. Since every student at RWTH Aachen gets his or her own e-mail address upon enrollment, we have a fairly good possibility of reaching any student. The obvious limitation is that we cannot assure that the students read their university e-mail frequently or even at all. Therefore the Blast-o-Mat is capable of redirecting certain traffic to a specially designed web server as just mentioned. Because of the network structure at RWTH Aachen, the redirection currently works only for the wireless network, but we hope to extend this in the future. All traffic of wireless hosts has to pass one central gateway. Thus, we are able to efficiently redirect any traffic of hostile hosts at this point via the use of certain iptables rules. The main advantage of this approach is that the responsible person of a redirected host is efficiently informed, even if the warning mails of the Blast-o-Mat are not read. Every attempt to open a website on a redirected host displays the information site of the quarantine web server, showing all gathered data about the incident so far. An example of such a warning is shown in Figure 10.2. Furthermore, e-mail delivery is still possible, allowing the user to get additional information provided with the Blast-o-Mat warning messages.
To achieve the redirection of a contaminated host, the Blast-o-Mat remotely executes a Python script on the gateway server and transmits the account name, the IP address, and the time the system was online as parameters. The easiest way would be to do the redirection based on the IP address of the infected host. But since we have to deal with dynamically assigned addresses, this would not prevent the user from logging in again with a different IP address, thus circumventing the redirection measures. Therefore, we have to determine the MAC address of the offending machine. This is accomplished with the help of an additional script, which queries the DHCP server with the time the host was online and its IP address as parameters. Every DHCP server maintains a lease file, containing all MAC addresses of hosts to which it assigned an IP address, together with the time interval the given IP address is valid. With the help of this file, we are able to determine the MAC address of the system that was online with a certain IP during a given time. As a result, the script generates an iptables rule that redirects any further HTTP traffic of the specified MAC address to the quarantine web server.
A more advanced solution to build a quarantine network would involve VLANs. As soon as a host is detected by the Blast-o-Mat, the VLAN tag for this machine is changed to the tag of the quarantine network (which could be a honeynet). As a result, all traffic is redirected. The major drawback of this concept is that it requires the network infrastructure to allow access to the switch port of each host, and additionally the switch must support VLAN tagging of certain ports.
One additional option to enhance the quarantine network is to add several honeypots to this network. Imagine that the quarantine network has 255 IP addresses, of which we use 200 for (virtual) high- or low-interaction honeypots. These honeypots only act as some kind of burglar alarm within the quarantine network. Normally, these machines should not receive any network traffic, but if the malware on the offending machines tries to propagate further, it will quickly hit one of our sensors. This is a general methodology for how you can use honeypots in the area of intrusion detection: Add several honeypots near (in regards to the IP address) important servers or other sensitive infrastructure. These sensors then act as an additional alarm, since it is always suspicious if the honeypots are receiving traffic. With an automated alarm mechanism, this can help to detect attacks early in the reconnaissance phase.
In the next section, we take a closer look at one particular alert generated by nepenthes. While not strictly related to the topic of honeypots, it gives you an overview of the current level of sophistication of network attacks and what kind of attacks you can expect to see in your honeynet.
During one security incident detected by nepenthes in April 2006, we noticed a strange behavior of the infected machine: It constantly tried to post data to a certain PHP file located at a server in the United States. Since the machine had already been moved into the quarantine network, we could further observe it. We noticed that sensitive data — in this case, passwords — were sent to the remote server. A closer examination revealed the URL from the HTTP requests and we quickly noticed that these requests were caused by a variant of Haxdoor, one of the most advanced Trojans in the wild nowadays.
In addition to the normal Trojan capabilities, such as copying itself to the Windows Installation Directory or start on reboot, Haxdoor also implements rootkit capabilities and advanced identity theft mechanisms. It can, for example, hide its presence on the compromised machine via SSDT (System Service Dispatch Table) hooking, as well as steal all information entered into Internet Explorer. All of this captured information can be sent to a central server (the so-called drop site or drop zone), which is precisely the activity we observed within the quarantine network.
During further investigation of the drop site, we found several log files that contained all information stolen from all infected machines. In total, these log files contained more than 6.6 million entries, amounting to 285 MB of data. This data was stolen from the compromised machines between April 19 and April 27, 2006, within only nine days. In total, we found evidence of more than 39,000 different IP addresses that were victim of this particular Haxdoor infection. These numbers show the effectiveness of this kind of attack. The log files contained full detailed information about more than 280 bank accounts and several credit card numbers. All major German banks were victims of this incident, and several other large brands from the e-commerce sector were also targeted. In addition, the attacker also collected sensitive information, such as username and password combinations or other data entered into HTML forms from the victim's computers.
We handed this information over to DFN-CERT, the Computer Emergency Response Team responsible for German research and education networks. The affected users were warned in cooperation with universities, ISPs, and other affected sites.
Let us take a closer look at the dimension of data stolen this way and a brief overview of the victims and the estimated damage caused by this particular variant of Haxdoor. This overview highlights only some of the most important information stolen and is not complete. Nevertheless, this section should give you an overview of the possibilities the attacker has.
The vast majority of victims were located in Germany, most of them within IP ranges of dial-up users. This user group is an easy, yet very attractive, target for attackers: people who use the Internet at home for entertaining purposes are often not very security aware. Furthermore, patch management or additional security software like antivirus engines or host-based firewalls are often unfamiliar to them. Thus, an attacker can compromise these unpatched machines with the help of autonomous spreading software in the form of bots. Once he has complete control over the victim's machine, he can use it to install additional tools — for example, keylogger and backdoors or even more advanced tools like Haxdoor.
Presumably the most severe form of identity theft caused by Haxdoor is information related to financial transactions. This Trojan monitors the use of Internet Explorer and sends captured data (e.g., URLs and content of HTML-forms) to the central server operated by the attacker, and thus this very sensitive information can be captured by the attacker very easily. In the log files of the drop site, we found traces of at least 15 different banks whose customers were affected. Moreover, the log files contain at least complete information about 280 bank accounts and 28 credit card numbers with complete details. The rather low number of credit card details can be explained with the help of the nationality of the victims. In Germany, credit cards are not used as commonly as in the United States.
Table 10.1 provides an overview of some of the affected companies. This highlights some of the most prominent victims; in total, information about several hundred websites was sent to the central logging server. As you can see, all major e-commerce sites are affected and sensitive information was stolen this way.
In addition, Haxdoor is capable of retrieving the information in the Protected Storage (PStore) Service of infected machines. PStore is a mechanism provided by the Windows API to enable applications to store user data that should be kept secure or free from modification. It is mainly used by Internet Explorer and also other programs like Outlook or third-party applications. This service is responsible for encrypting data on the local system and should make sure that only the user who owns the data can access it — that is, normally only the local users. It stores sensitive information like username and password entered within Internet Explorer or used by Outlook. Again, this kind of information can be mainly used by the attacker for identity theft. In addition, he can abuse credentials for online shopping or auction sites. The following listing provides you with a (sanitized) overview of how the output of the PStore retrieval might look:
-==; Protected Storage: Outlook: pop.gmx.net | PASS http//12090.forum.onetwomax.de/:StringData | USER PASS http://ksv-hessen.de/:StringData | USER PASS http://pixum.de/:StringData | e-Mail PASS http//www.fussballstammtisch.de:StringData | USER PASS http//www.willstequatschen.com/index.php:StringData | USER PASS -==; Account POP3 Server | pop.gmx.net POP3 User Name | e-Mail |
As you can see, it contains mostly sensitive information like username and password for certain website or e-mail accounts. This kind of data can then be used by the attacker for malicious purposes.
As a side note, we want to take a quick look at the binary version of Haxdoor. Sandboxing is a well-established approach that involves executing the malware in an emulated environment and monitoring its behavior. This runtime-based analysis has proved to be a valuable approach to analyzing malware binaries. We use a sandbox named CWSandbox, whose web frontend can be accessed at http://www.cwsandbox.org. In Chapter 12 we take a closer look at CWSandbox and explain its inner workings in more detail. Preliminary results show that such a tool is able to efficiently and accurately analyze a given malware binary. CWSandbox can extract all important information from a given binary in an automated way within a short amount of time (usually a couple of minutes). The extracted information includes information about changes to the filesystem or the Windows registry, process access, Dynamic Linked Libraries (DLL) handling, and network communication.
The information in the following paragraphs is based on the reports generated by CWSandbox, enriched with information retrieved via manual binary analysis. In total, we analyzed eight different variants of Haxdoor. All of them share many characteristics, and the following description is a generalization of the different Haxdoor variants.
Typically, this specimen of malware creates several different files in the Windows installation folder. By default, this is either C:\Windows (Windows 2000 and XP) or C:\Winnt (Windows NT). The created files include normally two DLLs, three to four drivers (SYS), and several additional configuration files. For example, the variant Haxdoor.IN (according to Bitdefender) creates the following files: sndu32.dll and qm.dll (same as sndu32.dll), sndu64.sys and qm.sys, and stt82.ini, klgcptini.dat, and stt82.ini.
Upon executing, the binary loads several DLLs. These include the typical Windows DLLs such as kernel32.dll or ntdll.dll, but also network-related DLLs such as wsock32.dll and the code within the newly created files.
Haxdoor also interacts with the Windows registry to enable a mechanism to be started upon reboot. In contrast to other malware, which commonly adds a registry key under Run or RunService, Haxdoor is more advanced. It uses a mechanism to auto-load via Winlogon or even during SafeBoot. The corresponding registry keys are HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify and HKLM\SYSTEM\CurrentControlSet\Control with keys \SafeBootMinimal and \SafeBootNetwork, respectively.
Via the Windows Service Control Manager (SCM), Haxdoor also adds a service to the infected system that is automatically started upon system startup. The name of the service varies; it can, for example be "SoundDriver SDB64" or "UDP32 netbios mapping," depending on the variant. In addition, it creates a remote thread within the memory space of Explorer.exe, to add some further services. Moreover, Haxdoor has some advanced tricks to hide its presence on the infected system, and it can be hard to get rid of. This topic is, however, beyond the scope of this side note, and more information can be found on the websites of different antivirus vendors.
The Blast-o-Mat IDS has been in operation for several months, efficiently handling malware-infected hosts within the campus network of RWTH Aachen. The following data was collected in a period of more than seven month. With the help of the honeypot nepenthes and the additional intrusion sensors, more than 400 incidents were detected. A little more than one-third were reported by nepenthes, with the rest split up between the Blast-PortScan and Blast-SpamDet sensors. The PortScan sensor reported the most incidents, owing to its much larger number of monitored ports than vulnerability modules. However, each portscan that was detected on a port for which a vulnerability module exists was detected by nepenthes as well. Figure 10.3 is an example of the incident graph generated by Blast-o-Mat. It shows the number of infected machines detected by the tool, split up for the three different sensor modules. As you can see, the three different modules have different success results, nepenthes and Blast-SpamDet being the most effective ones in this example, with seven detected infected machines within one week.
Although nepenthes's missing vulnerability modules mean that nepenthes does not recognize exploit attempts on all ports, it has proven to be a great intrusion detection mechanism. The biggest advantage is its accuracy, since no false positives are reported, as well as the high detection ratio, with only a few IP addresses assigned. Currently, we are monitoring with nepenthes less than 0.1 percent of the complete IP space and already achieve almost the same results as the Blast-PortScan sensor, which receives its data from a SPAN port of a centralized router. We use both sensor components because nepenthes may miss certain types of attacks, since it only emulates well-known vulnerabilities.
Because the bandwidth of current large-scale networks such as the one of RWTH Aachen already exceeds 1 Gigabit of traffic and can approach 10 Gigabits in the near future, common SPAN port monitoring will no longer work without the use of specialized and expensive hardware. However, nepenthes will still deliver the same quantitative results with just 180 IP addresses. Therefore, it serves as a future-proof intrusion detection sensor, capable of running on a normal off-the-shelf computer.
In addition to the detection of contaminated hosts, nepenthes also captures the malware that is trying to exploit the emulated vulnerabilities. Thus, we are able to submit the collected binaries for further analysis to different applications, such as virus scanners, to determine the kind of malware, or to the CWSandbox, to find out more about the behavior of malicious software. As a result, we are able to supply a qualitative high-class report for the detected incidents, both to help clean infected machines and to raise the user's security awareness.
In a case study we also implemented a more lightweight IDS just based on nepenthes. In the following paragraphs, we will briefly introduce the network setup and describe the results we have obtained during a period of five weeks. For this use case, the computer center of the University in Karlsruhe, Germany, has provided us with a test system and an IP range. We would like to thank all responsible persons at the University of Karlsruhe, especially Jörg Krämer.
The network setup is rather simple: There is one machine with nepenthes on a commercial off-the-shelf (COTS) system. The computer is running Linux as operating system and offers no other services besides the one simulated by nepenthes and SSH for remote management. The network connectivity of the system is restricted:
No outbound connections from the system to other machines outside of the university network are allowed, besides connections from a specified network for management purposes.
Connections to other system within the university network are allowed in both directions, since we want to learn about malware that is spreading within this network.
Several smaller network ranges within the university network that are not used are routed to this machine. So it is some kind of sinkhole that takes care of all traffic that has no real target. This helps us for the early-warning system: If a machine within the network is infected with a new worm or bot, this piece of malware normally tries to spread further. And since the propagation algorithm normally prefers IP addresses that are in the nearby IP range (e.g., within the same local network or the same class B network), the chances are good that we get infected in the early phase of an attack. This is the same methodology as used in the Blast-o-Mat system. So once a computer within the university network is infected, the chances are good that we will receive traffic coming from this infected machines, presumably within a short time frame.
After having described the network setup, we can now continue with preliminary quantitative results. In a period of five weeks, we could detect 95 infected machines within the network of the university. All of these machines successfully exploited a simulated vulnerability on our low-interaction honeypot and tried to infect our sensor. This is clear proof that this was an actual malicious behavior and not just a port scan or similar action. Therefore, an automated blocking of the machine that attacked our honeypot seems to be justifiable. In this case study, we did not implement the automated blocking, but all methods introduced in Section 10.1.3 can be applied here.
The 95 infections were caused by seven different binaries that tried to propagate further within the network. Table 10.2 gives an overview of these binaries and how often they tried to spread. Please note that some of these binaries were downloaded multiple times, and thus the total number is greater than the number of infected machines. This is mainly caused by machines that tried to infect our honeypot more than once.
| Program Name | Number of Attempted Downloads |
|---|---|
| mwinads.exe | 59 |
| guardedit.exe | 52 |
| appconf.exe | 21 |
| wvsvc.exe | 20 |
| msupdate.exe | 4 |
| svhost.exe | 3 |
| MSASP32.exe | 2 |
These binaries can be used to learn more about the actual attacks. As outlined in the previous section, an analysis of the files leads to valuable information that can be used to further proactively protect the network.
Again, CWSandbox helps us to learn more about these binaries. We present a brief analysis of MSASP32.exe. This binary is a variant of Rbot. The whole family of SDbot, Rbot, and all other variants are described in more detail in Section 11.1.1. This specific binary is called Rbot-AER, one of the countless variants that exist of this bot. It creates one new file on the victim's hard disk at the location C:\WINDOWS\SYSTEM\msasp32.exe. In addition, it creates three registry keys so it will be started again if the victim reboots the system. These keys reside at the usual location HKLM\Software\Microsoft\Windows\CurrentVersion with the keys Run and RunServices.
These two pieces of information could be used by an automated protection system to scan for further computers that are infected within the network. In addition, this information helps to develop patterns for antivirus software so that also other parties benefit from our work.
Moreover, this bot tries to connect to an IRC server that is used for Command and Control (C&C). The information about the location of the C&C server is also valuable for us. It can on the one hand be used to prevent computers from within the campus network to access this particular server, since it is obviously suspicious. This is a short-term solution that prevents further damage from this C&C server for the local network. On the other hand, we can use the collected information also for a long-term solution. We can contact the responsible administrator for the network range of the C&C server and help them to shut down this server, if it is indeed used for malicious purposes.
The other six files provided us with similar information that could be used to proactively secure the network and defend it against new trends. So this approach seems to be viable, and we hope to further explore its possibilities in the future.
A short side note on a pattern we found: In the five-week period we could observe 580 infection connections in total against the collection server. Since the server does not offer any real service, it should not receive any traffic at all, and thus all connections are suspicious. Presumably, these connections were the result of bots that try to spread further. An indication for this presumption is that we could actually collect malware. From an analysis point of view it is interesting to take a look at the number of infection attempts received per time of day, which is shown in Figure 10.4. We see that there are periods with fewer and periods with more connection attempts. Since the collection server is only reachable from machines within the network, only those machines can cause infection attempts. This is important, since all infection attempts are caused by computers in the same timezone so we do not have to take time shifts into account.
What we see is that the progression follows the sleep-wake rhythm of humans. At nighttime (especially between 3 and 5:30 AM), we receive almost no infection attempts. In the morning (7 to 9 AM), people turn on their computers, and malware begins to spread. We see a spike during the working hours between 2 and 6 PM — presumably corresponding to people who use their infected computers. Between 6 and 9 PM, we again see a period with rather low activity, in which only several people apparently use the computer. And before bedtime (around 10 PM), seemingly many people turn on there computer and connect to the Internet. The malware benefits from this situation and tries to spread further. So, interestingly, the propagation of malware follows the sleep-wake rhythm of humans. A study by Dagon et al. [17] takes a closer look at these patterns.
SURFnet, a national research and education network provider from the Netherlands, has explored feasible ways to use honeypots as a new kind of IDS. Based on nepenthes, they have built a network intrusion detection called SURFnet IDS. The goals of this project are manifold: On the one hand, the system should enable us to understand the types and amount of malicious traffic within a LAN. In addition, it should stop spreading worms and other kinds of malware. On the other hand, the solution must be scalable and easy to manage and maintain. Zero-maintenance of the individual sensors is desirable and a missing feature of many existing solutions. Our current experience shows that nepenthes scales well to a couple of thousand honeypots with just one physical machine. In addition, a hierarchical setup can be used to distribute load if an even larger setup is needed. The nepenthes platform can also scale to high-speed networks due to its limited amount of memory resource and only moderate amount of processing resources needed. Furthermore, the proposed NIDS should have close to no false positives. Up to now, we did not have any false positives with our nepenthes setup, so this goal seems to be reachable. This is mainly due to the assumption of honeypots. All network traffic is suspicious. False negatives of our platform generate a log-entry, and all captured information about network traffic that could not be handled are saved. This way, all possible information to help in avoiding false negatives is already available for analysis by a human.
The whole project is based on the five following rules:
With the help of nepenthes, this IDS has up to now collected information about many infected machines within the SURFnet network. Based on the data, the infected machines could be taken offline and cleaned up — thus helping the victims of the attacks.
Since we have already introduced several similar projects, we do not want to address this project in detail. As some eye candy, we just want to present a short example of the kind of data you can observe with SURFnet IDS: Figure 10.5 depicts a geographical mapping of the attack source observed by sensors deployed for this IDS. Using Google Maps and information about the geographical location of an IP address, it is possible to estimate where the attacking machine is located. This way you can receive some kind of overview of the current threat level on the Internet.
You can find more information about the project, including an extensive documentation about how to set up your own SURFnet IDS, at the website of the project: http://ids.surfnet.nl/.
|
|