Windows Server Under Threat: Blaster Worm & Variants - Immediate Action Required
This article provides critical information regarding the Blaster worm and its dangerous variants, offering guidance on preventing infection and recovering compromised systems. As a rapidly spreading network worm, Blaster posed a significant threat to vulnerable Windows operating systems, leveraging known security flaws to propagate autonomously across the internet. Immediate and decisive action was necessary to mitigate its impact and restore system integrity.
Summary: The Blaster Worm Threat¶
On August 11, 2003, Microsoft initiated an urgent investigation into a newly identified computer worm. This malicious software, quickly dubbed “Blaster,” gained notoriety for its aggressive self-propagation. Unlike some viruses that require user interaction, worms like Blaster spread automatically across networks. This particular worm exploited a critical vulnerability within the Remote Procedure Call (RPC) service, a fundamental component of Windows. The vulnerability, detailed in Microsoft Security Bulletin MS03-026, allowed the worm to execute arbitrary code remotely on affected systems simply by connecting to open RPC ports. This mechanism enabled Blaster to infect large numbers of computers running various Windows products, including Windows XP, Windows Server 2003, Windows 2000, and Windows NT 4.0.
The Blaster worm was identified under several names by various antivirus vendors, reflecting its widespread impact and the variations that emerged. These included W32.Blaster.Worm, W32.Blaster.C.Worm, W32.Blaster.B.Worm, W32.Randex.E (Symantec), W32/Lovsan.worm (McAfee), WORM_MSBLAST.A (Trendmicro), and Win32.Posa.Worm (Computer Associates). Understanding these different designations was crucial for network administrators and IT professionals trying to identify and combat the threat effectively. Antivirus software vendors played a vital role in providing the necessary detection signatures and removal tools.
While technical users and administrators needed detailed recovery steps, home users were also significantly affected. Microsoft provided resources specifically tailored for home users to help them protect their personal computers and recover from potential infections. The widespread nature of the RPC vulnerability meant that any internet-connected Windows machine that hadn’t been patched was at high risk. The worm’s payload varied slightly between variants, but the core method of exploitation remained consistent, making the RPC vulnerability a critical focus for remediation efforts across all affected Windows platforms.
Symptoms of Infection¶
Identifying an infection by the Blaster worm or its variants could sometimes be challenging, as symptoms varied depending on the specific variant and the system’s configuration. In some cases, a compromised system might not exhibit any overt signs immediately. However, several common and distinctive symptoms indicated a likely infection. Recognizing these signs promptly was essential for initiating recovery procedures and preventing further spread.
One of the most prominent symptoms was the appearance of specific error messages. Users might encounter dialog boxes stating:
The Remote Procedure Call (RPC) service terminated unexpectedly.
The system is shutting down. Save all work in progress and log off.
Any unsaved changes will be lost.
This shutdown was initiated by NT AUTHORITY\SYSTEM.
This message directly related to the worm’s interference with the critical RPC service, which was a key part of its operation and exploitation. Unexpected system shutdowns or repeated restarts at random intervals were also hallmark symptoms. These reboots were often triggered by the instability caused by the worm’s attack on the RPC service, making affected systems difficult to use or manage.
On systems running Windows XP or Windows Server 2003, an infection might trigger the error reporting mechanism, leading to a dialog box offering the option to report the problem to Microsoft. While this didn’t directly indicate the worm, it signaled a critical system failure often linked to the RPC service crash caused by Blaster. Older operating systems, specifically Windows 2000 and Windows NT 4.0, might experience a Stop error message, commonly known as a “Blue Screen of Death,” due to the instability induced by the worm.
Beyond system behavior, the presence of specific files on the system was a definitive indicator of infection. The Blaster worm and its variants were known to drop executable files with distinct names in the Windows system directory (%systemroot%\System32). Searching for files such as Msblast.exe, Nstask32.exe, Penis32.exe, Teekids.exe, Winlogin.exe, Win32sockdrv.dll, or Yuetyutr.dll was a key diagnostic step. Additionally, the worm often utilized the Trivial File Transfer Protocol (TFTP) service to download copies of itself onto vulnerable machines, potentially leaving unusual TFTP* files present on the computer. The presence of any of these files strongly suggested a compromised system.
Technical Details: Detection¶
Detecting the Blaster worm required a combination of vigilance and technical checks. While updated antivirus software was the primary tool for automated detection, manual checks were also possible, especially if the system was too unstable to run traditional scans. Understanding the worm’s modus operandi and the files it deposited was key. As mentioned, the worm placed specific executable files into the system directory.
To manually check for the presence of these malicious files, command-line tools could be utilized. This method allowed administrators to search for known worm files even if the system was experiencing instability or if antivirus definitions were outdated. The process involved accessing the command prompt and executing targeted searches.
Here are the steps to manually search for the worm files:
- Click Start, then click Run.
- In the Open box, type
cmdand press OK to open the command prompt. - At the command prompt, type the following command to search for a specific file:
dir %systemroot%\system32\filename.ext /a /s
Replace filename.ext with the name of the suspicious file you are looking for (e.g.,Msblast.exe).
Then, press ENTER.
This command searches the specified directory and all subdirectories (/s) for the file, including hidden and system files (/a). You must repeat this command for each known worm filename: Msblast.exe, Nstask32.exe, Penis32.exe, Teekids.exe, Winlogin.exe, Win32sockdrv.dll, and Yuetyutr.dll.
If any of these files are found, it is highly probable that the computer is infected with the Blaster worm or a variant. If a file is located, the next step is to remove it. At the command prompt, the file can be deleted using the command:
del %systemroot%\system32\filename.ext /a
Again, replace filename.ext with the specific file name found. Press ENTER to execute the deletion.
Important: While manually deleting these files is a necessary step, it is not sufficient for complete recovery. A worm infection often involves changes to the system’s configuration, including registry keys and startup entries, which manual deletion alone does not address. Therefore, following the full recovery steps, including running updated antivirus software and applying security patches, is mandatory after identifying and manually removing the core worm file. Antivirus software vendors provide specific technical details on the registry changes and other modifications made by the worm; consulting their resources is recommended for a deeper understanding.
Prevention¶
Preventing an infection by the Blaster worm and its variants primarily relied on two critical security measures: employing a firewall to block the ports used by the worm for propagation and applying the relevant security patches released by Microsoft. Because the worm exploited a known vulnerability, patching the system was the most effective long-term prevention strategy.
Implementing a firewall was the first line of defense against network-based attacks like Blaster. The worm spread by scanning for and connecting to vulnerable systems through specific TCP and UDP ports associated with the RPC service and TFTP. Blocking these ports at the network edge or on individual hosts could significantly reduce the risk of initial infection.
Affected ports included:
* TCP ports: 135 (RPC endpoint mapper), 139 (NetBIOS session service), 445 (Microsoft-DS SMB file sharing), 593 (RPC over HTTP), and 4444 (for remote command shell).
* UDP ports: 69 (TFTP), 135 (RPC endpoint mapper), 137 (NetBIOS name service), and 138 (NetBIOS datagram service).
On modern Windows operating systems like Windows XP and Windows Server 2003, the built-in Internet Connection Firewall (ICF) feature could be used to block these incoming connections. For networks, dedicated firewalls like Microsoft Internet Security and Acceleration (ISA) Server 2000 or third-party firewall appliances and software were essential.
Steps to enable ICF on Windows XP or Windows Server 2003:
- Go to Start, then Control Panel.
- In Control Panel, double-click Networking and Internet Connections, then click Network Connections.
- Right-click the network connection you use to access the internet and select Properties.
- Click the Advanced tab.
- Check the box labeled Protect my computer or network by limiting or preventing access to this computer from the Internet.
For dial-up connections, which might not appear directly in Network Connections, the firewall could often be configured via Internet Options in Internet Explorer:
- Start Internet Explorer.
- On the Tools menu, click Internet Options.
- Click the Connections tab, select your dial-up connection, and click Settings.
- In the Dial-up settings area, click Properties.
- Click the Advanced tab, and check the box labeled Protect my computer or network by limiting or preventing access to this computer from the Internet.
While ICF provided basic protection for individual computers connected directly to the internet, it was not available on Windows 2000 or Windows NT 4.0. For these systems, relying on network-level firewalls or host-based third-party firewall software was necessary. Basic Firewall, a component of Routing and Remote Access on Windows Server 2003, offered similar capabilities for server roles.
Beyond firewalls, the most critical step in prevention was applying the security patch that addressed the underlying RPC vulnerability. Microsoft Security Bulletin MS03-026 detailed this vulnerability and provided the initial patch (823980). However, this patch was later superseded by the 824146 security patch, which included fixes for issues addressed in MS03-026 as well as other security updates (MS03-039). Ensuring that the latest relevant patch (824146) was installed on all vulnerable systems was paramount to preventing the worm from exploiting the system in the first place. Regularly updating operating systems with the latest security patches is a fundamental practice that mitigates the risk from known vulnerabilities exploited by worms like Blaster.
Finally, maintaining up-to-date antivirus software with the latest signature definitions was essential. While patching closed the exploit vector, antivirus could detect and block the worm executable itself, providing an additional layer of defense. Regularly scheduled scans and real-time protection helped catch the worm if it somehow bypassed other defenses or arrived via alternative infection vectors (though Blaster’s primary method was the RPC exploit).
In summary, a layered approach combining firewall protection and prompt application of security patches, supported by current antivirus software, offered the best defense against the Blaster worm and similar threats exploiting known vulnerabilities.
| Port Type | Port Number | Protocol | Service | Role in Blaster Infection |
|---|---|---|---|---|
| TCP | 135 | TCP/UDP | RPC Endpoint Mapper | Exploitation, scanning |
| TCP | 139 | TCP | NetBIOS Session Service | Related services, scanning |
| TCP | 445 | TCP | Microsoft-DS (SMB over TCP) | Related services, scanning |
| TCP | 593 | TCP | RPC over HTTP | Potential exploitation |
| TCP | 4444 | TCP | Remote Command Shell (used by worm) | Post-exploitation/control |
| UDP | 69 | UDP | TFTP (Trivial File Transfer Protocol) | Worm file transfer |
| UDP | 137 | UDP | NetBIOS Name Service | Related services, scanning |
| UDP | 138 | UDP | NetBIOS Datagram Service | Related services, scanning |
Table: Ports Involved in Blaster Worm Activity
Recovery¶
Recovering from a Blaster worm infection required careful steps to ensure complete eradication of the malware and restoration of system integrity. Security best practices advocate for a complete reinstallation of the operating system on any system that has been compromised by malware exploiting a fundamental service vulnerability. This approach, often referred to as a “clean install,” guarantees that no remnants of the malware, including potentially undetected backdoors or configuration changes, remain on the system, which could lead to future compromises. Resources like CERT advisories often recommend this stringent approach for systems suspected of deep compromise.
However, recognizing that a full reinstallation might not always be immediately feasible or practical for every system, particularly in large network environments, antivirus companies developed specific tools designed to remove the Blaster worm and its known variants. Utilizing these tools in conjunction with other protective measures could offer a pathway to recovery without a complete system rebuild, provided the infection was limited and the tools were effective against the specific variant encountered.
The recovery process varied slightly depending on the version of the Windows operating system. Regardless of the OS, a critical initial step, especially if the system was experiencing the repeated shutdown symptom, was to disconnect the infected computer from the network or the internet. This prevented the worm from continuing to spread and also provided a stable environment to perform the cleanup steps without interruption from unexpected reboots. For broadband connections, physically unplugging the Ethernet cable or modem cable was necessary. For dial-up connections, unplugging the phone line from the modem or wall jack achieved this isolation.
If a system was repeatedly shutting down due to the RPC service crash caused by the worm, making recovery difficult, a temporary command could be used to prevent the RPCSS service from triggering reboots upon failure. Opening a command prompt and typing sc failure rpcss reset= 0 actions= restart would configure the service’s recovery options to simply restart the service upon failure rather than rebooting the system. This command provided a window of stability to perform the cleanup steps. After recovery, the setting should be reverted to default using sc failure rpcss reset= 0 actions= reboot/60000.
Recovery for Windows XP, Windows Server 2003 Standard Edition, and Windows Server 2003 Enterprise Edition¶
For these operating systems, the recovery steps leverage the built-in ICF or other firewall solutions:
- Enable Firewall: If the system is connected to the internet, ensure the Internet Connection Firewall (ICF) is enabled on the connection used, or that an external/software firewall is actively blocking the relevant ports (TCP 135, 139, 445, 593, 4444; UDP 69, 135, 137, 138). The steps for enabling ICF are the same as detailed in the Prevention section.
- Note: If the system is part of a network sharing a single internet connection, the firewall should ideally be on the system directly connected to the internet (e.g., the gateway or NAT device), not on internal machines sharing the connection unless specifically configured.
- Apply Security Patch: Download and install the latest security patch (824146) that addresses the RPC vulnerability (MS03-026 and MS03-039). This patch closes the security hole the worm exploited. Ensure the patch installation is successful.
- Update and Run Antivirus: Install reputable antivirus software or ensure your existing solution is updated with the very latest virus signature definitions. Perform a complete system scan to detect and remove the Blaster worm and any associated files.
- Run Worm-Removal Tool: Many antivirus vendors provided specific tools designed to specifically remove the Blaster worm, addressing its specific behaviors and registry changes. Downloading and running the official removal tool from your antivirus vendor is highly recommended for thorough cleaning.
Recovery for Windows 2000 and Windows NT 4.0¶
Windows 2000 and Windows NT 4.0 do not have the built-in ICF feature. Recovery on these platforms relies on network-level firewalls, third-party host-based firewalls, or configuring the built-in TCP/IP Filtering feature for LAN connections if no other firewall is available. TCP/IP Filtering is not an option for dial-up connections; therefore, an external firewall is necessary if using dial-up on these older OS versions.
-
Configure TCP/IP Security (LAN Connections): If a dedicated firewall is not in place, configure TCP/IP Filtering to block the affected ports.
- Windows 2000:
- In Control Panel, double-click Network and Dial-up Connections.
- Right-click the LAN connection accessing the network/internet, and click Properties.
- Select Internet Protocol (TCP/IP) in the components box and click Properties.
- Click Advanced.
- Click the Options tab.
- Select TCP/IP filtering, and then click Properties.
- Check Enable TCP/IP Filtering (All adapters).
- In the TCP Ports, UDP Ports, and IP Protocols columns, select the Permit Only option. Note: Choosing Permit Only means you must explicitly add any ports/protocols you *do need to allow for network services to function.*
- Click OK to apply changes and close dialogs.
* Note: Configuring “Permit Only” without specifying allowed ports will block almost all network traffic. This is a highly restrictive measure suitable only as a temporary emergency step. You would need to identify and add exceptions for necessary services (like HTTP/80, HTTPS/443 for web browsing, SMTP/25, POP3/110, IMAP/143 for email).
- Windows NT 4.0:
- In Control Panel, double-click Network.
- Go to the Protocol tab, select TCP/IP Protocol, and click Properties.
- Click the IP Address tab, then click Advanced.
- Check Enable Security, and click Configure.
- In the TCP Ports, UDP Ports, and IP Protocols columns, select the Permit only setting. Again, this is highly restrictive.
- Click OK and close the Network tool.
- Windows 2000:
-
Apply Security Patch: As with newer systems, download and install the security patch 824146, which fixes the RPC vulnerability on Windows 2000 and Windows NT 4.0 as well. This is a critical step to prevent re-infection.
- Update and Run Antivirus: Install or update antivirus software with the latest signatures and perform a complete system scan to remove the worm files and associated malware components.
- Run Worm-Removal Tool: Use the specific Blaster worm removal tool provided by your antivirus vendor for thorough cleaning.
After completing the recovery steps, it is crucial to reconnect the system to the network/internet cautiously and monitor its behavior. Verify that system stability is restored and that the worm files are no longer present. If TCP/IP Filtering was used as a temporary measure, assess if it’s still needed or if a less restrictive firewall configuration can be implemented based on network requirements and risks. Regularly scheduled security audits and continuous patch management remain essential to maintain a secure environment.
Many antivirus vendors participating in the Microsoft Virus Information Alliance (VIA) provided detailed technical analyses and specific recovery tools for the Blaster worm. Consulting their resources offered further technical insights and access to the necessary cleanup utilities.
For more information on general steps for recovering from a system compromise, resources like the CERT Advisory website provide valuable guidance, often emphasizing the benefits of a clean system installation to ensure full recovery.
We hope this detailed information assists you in understanding the Blaster worm threat and taking appropriate steps for prevention and recovery. Have you encountered the Blaster worm or similar threats in the past? What were your experiences and the most effective methods you used for recovery? Share your thoughts and questions in the comments below.
Post a Comment