The Legacy of the Morris Worm: Understanding and Combating Modern Botnets

Since the world’s first worm virus, the Morris Worm, drew attention for its destructive system impact and rapid spread, it has signified that in the battleground against malicious code, the speed of dissemination would inevitably become a new evolutionary form. With the rapid development of the Internet since the early 1990s, this only further provided new mediums and channels for such malicious code to spread quickly. No one anticipated that another new information security threat combining virus, Trojan, and worm techniques—botnets—would become a headache for many information security experts around the world. Even today, in efforts against botnets, the white hats on the side of justice still struggle to confidently prevail.

The software that creates and manages botnets makes them far more harmful than previous generations of malicious scripts. Not only is it a virus, but it’s a virus’s virus. Its harmfulness integrates the traditional virus, Trojan, and worm, enabling it to perform conventional system residency, information theft, remote control, and it also bears the network spreading characteristics of worms. If viruses, Trojans, spyware, backdoors, worms, and the like are likened to the various equipment in Plants vs Zombies, then describing botnets as “a large wave of zombies” couldn’t be more appropriate.

I. Characteristics of Botnets: The Morris Worm

The characteristics of botnets lie in executing predefined operations on zombie clients without the need for the bot herder (the hidden controller or botnet owner) to directly log into the client; the zombie clients can collaborate and take action on the same task or target with little to no interference from the bot herder. In fact, the only difference between a botnet and a worm virus is that a botnet has a unified, highly controllable system.

Type	Spreadability	Controllability	Secrecy	Level of Harm
Botnet	Yes	Highly controllable	Yes	High
Trojan	No	Controllable	Yes	High
Worm	Active spreading	Generally none	Generally none	High
Virus	User intervention	Generally none	Generally none	Medium

A typical botnet consists of a zombie server (usually an IRC server) and one or more zombie clients. Even a botnet composed of hundreds or thousands of zombie clients can only be called a small botnet. Since zombie clients are not limited to any specific country or region, tracking and locating the bot herder behind the scenes becomes extremely difficult. This may involve international collaboration and cooperation during the investigation, often causing investigations to be terminated due to their complexity compared with the losses suffered by companies/institutions or individuals.

II. Composition of Botnets: The Morris Worm

The composition of a botnet is modular, roughly divided into three modules: scanning module, resident module, and functional module. The scanning module scans and spreads the botnet malware, the resident module aims to stealthily reside within the target system, and the functional module executes the instructions set by the bot herder after the resident module is in place. From a modular composition perspective, it is a combination of the modules of a virus and a Trojan.

The above image is a typical lifecycle of a botnet client (different botnets may vary in process), which begins with discovering and exploiting vulnerabilities: through social engineering, system vulnerabilities, leftover Trojan backdoors, or password guessing/cracking. When communicating with the C&C (command and control) to inform that a new client is online, current botnets have adopted various encrypted communication channels to avoid detection by IDS, firewalls, or other network surveillance methods. Communicating with C&C aims to update potentially existing client modules, the client name list at the C&C end, IP addresses, or channel names, much like how servers notify clients during Trojan attacks. C&C is the intermediary for communication between zombie clients and the bot herder: the bot herder sends commands to the C&C, which then sends commands to the zombie clients.

Modular botnets enable the functional module to be changed or customized as needed by the bot herder, such as adding Bitcoin mining functionality. This makes it possible that the modules or components of a botnet may not be fully detectable by antivirus software, and if components remain after detection, there is a significant chance of re-infection. Therefore, in an enterprise environment, encountering a botnet infection typically results in restoring systems using clean system images after disconnecting from the network.

III. Harm of Botnets

What makes botnets so formidable and persistent? Depending on the functional modules, the harm of botnets includes but is not limited to:

1. Infecting other systems to become new zombie clients;

2. Launching DDoS attacks, using numerous zombie clients to attack the same system/device;

3. Conducting ad-click fraud, like deceiving clicks on Google AdSense ads to earn revenue;

4. Sending spam and phishing emails;

5. Storing and distributing illegal (pirated) intellectual property materials;

6. Using DDoS attacks for extortion;

7. Data mining from infected zombie clients (or including keylogging functionality) to obtain valuable information from the client system;

8. Using zombie clients for Bitcoin mining.

The diagram below shows the global C&C distribution map in the 24 hours before the author wrote this article (from the Shadowserver Foundation).

IV. Selection of Botnet C&C

The world’s first botnet used an IRC server as C&C, and even today many botnets still use IRC servers for this purpose. This is due to the simplicity, stability, and ease of management of IRC channels, but its drawbacks are also apparent: once the IRC server or channel is discovered, it spells the end of the botnet—meaning the bot herder can no longer communicate with zombie clients. Additionally, data in the IRC channels is easily intercepted (although the bot herder can use TOR as an additional security measure or encrypt the IRC channel commands). However, today’s C&C methods extend well beyond IRC servers and include the following approaches:

1. Using domain name resolution to set the domain as the C&C address;

2. Using web-based server systems as the C&C address and for command interaction;

3. Employing P2P networks for a distributed management of zombie clients and C&C;

4. Botnets based on instant messaging tools;

5. FTP-based botnet C&C.

Among these methods, web-based C&C is another typical substitute mechanism. Because HTTP is a stateless protocol, the bot herder cannot send commands to zombie clients via HTTP, but zombie clients can periodically access an HTTP address to check for new instructions. The advantage of this method is that its communication will not be blocked by firewalls, and sniffers cannot detect any botnet-related information during traffic monitoring.

Moreover, modern botnets no longer have a single C&C controlling thousands of zombie clients. Instead, like enterprise management, they manage on a small scale—for instance, one botnet might have 20 C&Cs, each controlling hundreds of zombie clients.

V. Detection of Botnets

For enterprises or institutions, detecting whether a botnet has infected internal systems can be done on both network and system levels. The network level includes traffic detection, firewall/NIDS, and log analysis, while the system level involves setting up honeypots and log analysis.

Typically, when zombie network clients interact with C&C for command exchanges or perform functions, there is a sudden surge in network traffic. Therefore, using sniffers like tcpdump or Wireshark for targeted traffic monitoring usually reveals unreasonable traffic. In cases where excessive network traffic causes the router CPU to be overwhelmed, sampling traffic for further analysis can help. And, if potential suspicious hosts can be identified initially from network traffic, targeted traffic content analysis can further detect the suspicious hosts.

Using an IRC server as C&C as an example, the commonly used IRC protocol messages include:

1. JOINS: Messages used by IRC clients to log into the IRC server channel;

2. PINGS: Information sent by the IRC server to the IRC client to check if the client is responsive;

3. PONGS: Messages returned by the IRC client to the server to indicate that the client is still online or has not logged out;

4. PRIVMSG: Messages containing channel names and channel data.

In network traffic monitoring, if data packets using the IRC protocol are present, and among the four message types, PRIVMSG data is much less compared to JOINS messages, it indicates that the monitored traffic and its associated host are suspicious, and it is likely a botnet.

For botnets using IRC servers as C&C, the default IRC server port 6667 becomes a key focus of firewall/NIDS, in addition to common vulnerability port scanning, DDoS traffic, etc. However, the shortcomings of NIDS (such as Snort) also lead to incomplete and comprehensive detection, as it can only detect known types of attacks.

For the system itself, antivirus software products are essential, even if they are not particularly effective against some botnet attacks! Comparatively, the role of honeypots is to study attackers’ tactics and behaviors, combined with firewall, IDS, and antivirus product logs, to further understand the behavioral characteristics and attack traces of botnets, facilitating subsequent technical evidence collection.

VI. Detection and Prevention of ZeroAccess

ZeroAccess is a Trojan program from a botnet where infected hosts perform Bitcoin mining operations and click fraud. As of the beginning of this month (December), the number of hosts infected by this Trojan is approximately between one and nine million (zombie clients in botnets are rather difficult to count), and the “earnings” this Trojan generates daily for the bot herder is roughly $100,000. With the joint efforts of Microsoft, the EU Cybercrime Center, and the FBI, it was barely possible to take down the botnet completely (traditionally, botnet operations are called “decapitation operations,” which involve detecting, discovering, and cutting off C&C. In recent years, botnets have adopted multi-C&C collaboration, P2P networking, and DNS-based C&C, making “decapitation operations” less effective). When Microsoft claimed that the joint operation was (partially) successful, it was actually a complete failure.

The ZeroAccess botnet uses a P2P network-based C&C. Unfortunately, Microsoft only detected and managed about 40% of the C&C. Based on this operation’s results, the following are ways to detect ZeroAccess:

1. The key to a botnet is that the zombie client must be connected to the internet. Disconnected zombie clients pose no threat (even if they have root access, so what?). Locate the network cable and switch interface that connects the internal network to the outside and ensure the external traffic is not interfered with.

2. Create a mirror port on the switch to dump the external network traffic to a clean system for traffic analysis. ZeroAccess uses ports 16464, 16465, 16470, and possibly 16471. These ports depend on whether ZeroAccess is 32-bit or 64-bit. Since the bot herder can update modules and change external connection ports at any time, the above ports are only temporarily “effective.” Mirror the traffic of the above ports and import it to a fixed port.

3. Use a laptop installed with Wireshark to analyze the traffic imported from the fixed port in the previous step. Normally, you can see unfiltered traffic information through Wireshark. Filter traffic for ZeroAccess’s connection ports or use Wireshark’s command “dst portrange 16464-16471.” The filtered traffic may yield false positive results due to excessive port traffic.

4. If there is an infected host within the network, patiently waiting can yield “significant” traffic results: an internal host connects with different and non-repetitive (or rarely repetitive) IP addresses externally, which is a characteristic of the ZeroAccess botnet. According to Symantec, these external IP addresses include:

    69.176.14.76
    76.28.112.31
    24.127.157.117
    117.205.13.113
    200.59.7.216
    113.193.49.54

Note that the ZeroAccess botnet’s IP addresses frequently change. While this IP list can confirm that the internal network has been infected, the absence of one IP does not prove it hasn’t been attacked.

5. Based on the above traffic monitoring results, isolate the infected devices within the internal network and use high-quality antivirus products to scan for viruses.

For preventing or stopping ZeroAccess infection, the recommendations are as follows:

- Adhere to standard security best practices to avoid ZeroAccess infection;
- Promptly update system and security product patches;
- Install a proxy server and allow only specific ports to access the internet;
- Install IDS/IPS;
- Restrict open outgoing ports, keeping only necessary service ports open;
- Retain all firewall logs.

 

Conclusion

Unless the botnet’s scale is exceptionally large, in today’s Internet world, it is difficult to reach the threat level described above. However, the nature of botnets is destined for continuous expansion and growth, which is the fundamental goal of the bot herder. A botnet with 60,000 to 80,000 zombie clients can possess capabilities and threats that are astonishing. Therefore, the best way to deal with botnets is to prevent their scale from expanding—that is, to stop the spread and intrusion of malicious software into a significant number of systems.

Security VulnerabilitiesSecurityCybersecurity