Nimda
Nimda is a computer worm discovered on September 18, 2001, that rapidly infected over two million Microsoft Windows systems worldwide by exploiting multiple vulnerabilities in Internet Information Services (IIS) web servers and client software.[1][2] Named after "admin" spelled backwards, Nimda combined sophisticated propagation techniques, including mass email attachments disguised as "README.EXE," scanning for open network shares, infecting websites to enable drive-by downloads, and leveraging backdoors left by prior worms like Code Red II.[3][4] It targeted unpatched systems running Windows NT, 2000, and earlier versions, as well as Internet Explorer 5.0 and later, using directory traversal flaws and buffer overflows to gain administrative access.[1][5] The worm's payload modified HTML and ASP files by appending JavaScript code to automatically email itself from infected machines, created hidden administrative shares such as C$, and added a Guest account with full privileges, severely compromising system security.[5][1] This multi-vector approach—encompassing client-to-client, server-to-client, and client-to-server infections—made Nimda one of the fastest-spreading malware at the time, surpassing the Code Red worm in speed and reach within hours of its release.[4] Its emergence just one week after the September 11 attacks heightened concerns, though no evidence linked it to terrorism; instead, it clogged Internet traffic, caused denial-of-service conditions, and particularly disrupted U.S. financial networks.[3] In terms of impact, Nimda infected hundreds of thousands to millions of hosts across the U.S., Europe, and Asia, leading to widespread system slowdowns, file corruption, and cleanup costs potentially exceeding those of Code Red, estimated at $2.4 billion.[2][4] Unique for being the first worm to proactively alter uninfected websites for malware distribution, it underscored vulnerabilities in Microsoft's ecosystem and prompted urgent patches from the company.[6] Removal involved isolating systems, deleting replicated files like load.exe, restoring modified files, and applying security updates, but its persistence in registries and shares complicated eradication efforts.[1][5] Overall, Nimda highlighted the evolving threat of hybrid worms, influencing subsequent cybersecurity research on early detection and containment.[2]Background and Discovery
Release and Historical Context
The Nimda worm emerged on September 18, 2001, precisely one week after the September 11 terrorist attacks on the United States.[7] This timing coincided with widespread public and governmental focus on potential threats to critical infrastructure, amplifying concerns over digital security in the immediate aftermath of the physical assaults.[8] The year 2001 marked a high point in the prevalence of computer worms, building on earlier outbreaks such as the SirCam worm in July, which spread via email attachments containing personal files, and the Code Red worm later that month, which targeted Microsoft IIS servers and infected hundreds of thousands of systems globally.[9] These incidents highlighted escalating vulnerabilities in networked systems and paved the way for Nimda's innovative use of multiple propagation vectors to achieve rapid dissemination.[10] Initial reports on the release day described significant slowdowns in Internet traffic and email delivery as Nimda began scanning and infecting systems worldwide.[11] Antivirus companies, including Symantec, promptly identified the threat and issued alerts, enabling early mitigation efforts amid the worm's aggressive spread.[12]Naming and Initial Attribution
The name "Nimda" is derived from "admin" spelled backwards, a reference to the worm's ability to gain administrative privileges on infected Windows systems.[13][14] Security researchers first identified the worm on September 18, 2001, shortly after the 9/11 attacks, with firms such as TruSecure Corporation and Symantec assigning it the designation W32/Nimda.A@mm based on its self-replicating code and mass-mailing capabilities.[15][16] The worm's internal strings explicitly labeled it as such, aiding in its rapid classification by antivirus vendors like F-Secure, which described it as a complex mass-mailing worm.[17][18] Initial efforts to attribute the worm's authorship faced significant challenges, as no confirmed creator has ever been identified despite extensive investigations.[19] Unfounded rumors circulated linking it to terrorist groups, fueled by its release just one week after the September 11 attacks, though U.S. Attorney General John Ashcroft publicly stated there was no evidence of such a connection.[11][20] In response, the FBI established a task force to probe the worm's origins and propagation methods, collaborating with private sector security experts, but the investigation yielded no arrests or definitive leads.[14][21]Infection Mechanisms
Email-Based Propagation
The Nimda worm employed email as a primary vector for client-to-client propagation by harvesting email addresses from infected systems and sending mass-mailed messages containing its payload. Upon infection, the worm scanned the victim's Windows address book via the MAPI interface, as well as email messages stored in the system's web cache, to compile a list of target recipients. It then used the local email client, such as Microsoft Outlook or Outlook Express, to dispatch these messages without requiring manual intervention from the user. This automated process allowed rapid dissemination, with the worm programmed to repeat the emailing cycle every 10 days until removal.[12][5] The emails generated by Nimda featured randomized subject lines exceeding 80 characters in length, often appearing innocuous or nonsensical to evade immediate suspicion, while the message body utilized a MIME multipart/alternative format. This structure included an empty HTML text section followed by an "audio/x-wav" section embedding the worm as a base64-encoded executable file named README.exe, approximately 57 KB in size. The filename README.exe served as a subtle social engineering lure, mimicking a benign document that users might be inclined to open if the automatic execution failed, thereby exploiting curiosity or assumptions about safe file types in professional or personal communications. Infected systems targeted prevalent 2001-era email clients like Microsoft Outlook, leveraging their integration with Internet Explorer for broader compatibility.[12][22] Upon receipt, the attachment executed automatically on vulnerable Windows systems without user interaction, primarily due to a flaw in Internet Explorer versions 5.5 and earlier (excluding 5.01 SP2) that permitted MIME type handling vulnerabilities, as detailed in CERT vulnerability note CA-2001-06. This allowed the worm to infect the host during email preview or opening, immediately initiating further scans of the address book for propagation and combining with other vectors like network shares for amplified spread. The mechanism's reliance on both technical exploits and the trust users placed in email attachments from known contacts underscored its effectiveness in 2001 enterprise environments dominated by unpatched Microsoft software.[12][22]Network Share Exploitation
The Nimda worm exploited open network shares on Windows systems to facilitate lateral movement within local networks, primarily targeting unsecured file-sharing resources accessible via the Server Message Block (SMB) protocol. Upon infection, Nimda scanned for vulnerable hosts by probing ports 135 through 139, which are associated with NetBIOS and RPC services used for network enumeration and share discovery.[23][24] This scanning allowed the worm to identify systems with open shares lacking password protection, particularly on Windows 95, 98, and ME. On all affected systems, including Windows NT and 2000, it disabled share security by deleting subkeys in the registry key [SYSTEM\CurrentControlSet\Services\lanmanserver\Shares\Security], while on NT and 2000 it additionally created administrative shares and modified the Guest account to facilitate access.[25] Once an open share was located, Nimda copied itself to the target system, often disguising the payload as innocuous files such as load.exe in the Windows system directory or by appending its code to existing executable (.exe) files, thereby modifying them to execute the worm upon launch.[26][25] It also targeted mapped drives and SMB shares, including administrative shares like C and D, granting full write permissions to propagate further across enterprise environments without requiring user interaction or email as an entry point.[27][25] This file-based infection mechanism enabled rapid spread in internal networks, infecting documents and executables on shared resources to ensure persistence and continued scanning from newly compromised machines. To maintain remote access, Nimda created backdoor accounts by activating or adding the Guest account to the Administrators group on Windows NT and 2000 systems, assigning it a blank password for unrestricted control.[27][26] It further compromised security by creating hidden administrative shares (e.g., c through z) on all local drives with full access for the Everyone group, disabling share-level security and exposing entire file systems to lateral propagation.[26] These modifications allowed unauthorized remote administration and accelerated the worm's dissemination within organizations, often independent of its email vector.[23]Web Server Vulnerabilities
The Nimda worm targeted web servers running Microsoft Internet Information Services (IIS) version 5.0, exploiting a known buffer overflow vulnerability in the IIS Indexing Service DLL through specially crafted requests to .ida and .idq files, as detailed in Microsoft Security Bulletin MS01-020.[27] This flaw, originally targeted by the Code Red II worm earlier in 2001, allowed remote attackers to execute arbitrary commands on unpatched servers without authentication.[1] Upon successful exploitation, Nimda issued commands via the server's cmd.exe, often using TFTP to download the worm's payload (admin.dll) from the attacking host. It then creates backdoors, such as copying cmd.exe to root.exe in web-accessible directories like c:\inetpub\scripts\root.exe, to enable remote execution and further propagation.[28] Once in control, Nimda modified infected websites by appending malicious JavaScript code to all accessible .htm, .html, and .asp files in the server's directory structure.[1] The injected script, such as<SCRIPT language="jscript">window.open("readme.eml")</SCRIPT>, automatically executed in vulnerable browsers (e.g., Internet Explorer versions affected by MIME-type vulnerabilities) when users visited the altered pages, prompting the download of the worm disguised as an email attachment named readme.exe.[28] This technique transformed compromised sites into active infection vectors, redirecting unsuspecting visitors to load and execute the malware directly from the server.[17]
To locate additional targets, Nimda scanned the internet for vulnerable IIS servers by sending HTTP GET requests probing for specific default files indicative of unpatched installations, including "alltext.html" and "default.ida."[28] If these files returned a 200 OK status or other signs of IIS presence (e.g., responses from /scripts or /msadc directories), the worm attempted the .ida buffer overflow exploit against the host.[1] This method marked Nimda as the first computer worm to systematically weaponize modified web content for self-propagation, leveraging end-user browsers as unwitting scanners and distributors within both internet and intranet environments.[17]
Technical Analysis
Payload and System Modifications
Upon successful infection, the Nimda worm deploys a payload that primarily focuses on propagation and persistence rather than data destruction, ensuring no files are deleted or overwritten in a destructive manner.[12] Instead, it creates multiple copies of itself across the infected system, such as placingLOAD.EXE in the Windows system directory (%System%) and MMC.EXE (a renamed copy of the worm) in the same location, along with additional files like RICHED20.DLL and ADMIN.DLL.[26][17] These copies facilitate further self-replication to local drives, network shares, and even remote systems via exploited backdoors.[29]
To achieve persistence, Nimda modifies system configuration files and registry keys; for instance, it alters the SYSTEM.INI file by appending shell=explorer.exe load.exe –dontrunold to ensure the worm loads on startup, and it adjusts registry entries under HKCU\Software\[Microsoft](/page/Microsoft)\Windows\CurrentVersion\Explorer to hide file extensions and suppress displays of hidden or system files.[26][17] Additionally, it activates the Guest account with administrator privileges and creates hidden administrative shares for all local drives (e.g., C, D, ..., Z$) with full access permissions, compromising system security without altering core user data.[29][26]
The worm exhibits rootkit-like behavior by concealing its presence, setting hidden and system attributes on its files (e.g., RICHED20.DLL and LOAD.EXE) to evade casual detection, and infecting .EXE files—excluding WINZIP32.EXE and those exceeding approximately 8 MB—by prepending malicious code and embedding the original executable as a resource.[17][26] It also targets web documents, appending JavaScript code to .HTML, .HTM, and .ASP files that, when accessed via a browser, prompts the download of README.EXE (another worm copy).[12][17] These modifications affect a broad range of file types but prioritize executables and server-side scripts for maximum spread.
Nimda's operations lead to significant system performance degradation, as it continuously scans for vulnerable targets—such as random IP addresses for IIS servers—and attempts mass emailing, consuming bandwidth and CPU resources in a manner that mimics denial-of-service effects on both local networks and infected hosts.[12][26] This relentless activity, including the creation of temporary files like MEP*.TMP during propagation, can slow traffic and overload systems, though the worm includes no intentional destructive elements beyond these disruptive behaviors.[17]