TUCoPS :: Malware :: in200109.htm

Code Red II exploits buffer overflow
CERT Incident Note IN-2001-09: "Code Red II:" Another Worm Exploiting Buffer Overflow In IIS Indexing Service DLL

"Code Red II:" Another Worm Exploiting Buffer Overflow In IIS Indexing Service DLL

Release Date: August 6, 2001

Systems Affected

I. Overview

The CERT/CC has received reports of new self-propagating malicious code exploiting the vulnerability described in CA-2001-13 Buffer Overflow In IIS Indexing Service DLL. These reports indicate that the worm has already affected thousands of systems. This new worm is being called "Code Red II," however, except for using the same buffer overflow mechanism, it is different from the original "Code Red" worm described in CA-2001-19 "Code Red" Worm Exploiting Buffer Overflow In IIS Indexing Service DLL.

The "Code Red II" worm causes system level compromise and leaves a backdoor on certain machines running Windows 2000. Vulnerable Windows NT 4.0 systems could experience a disruption of the IIS service.

II. Description

The "Code Red II" worm is self-propagating malicious code that exploits a known vulnerability in Microsoft IIS servers (CA-2001-13).

Attack Cycle

The "Code Red II" worm attacks as follows:

  1. The "Code Red II" worm attempts to connect to TCP port 80 on a randomly chosen host assuming that a web server will be found. Upon a successful connection to port 80, the attacking host sends a crafted HTTP GET request to the victim, attempting to exploit the buffer overflow in the Indexing Service described in CA-2001-13
  2. The same exploit is sent to each of the randomly chosen hosts due to the self-propagating nature of the worm. However, there are varied consequences depending on the configuration of the host which receives this request.

    • Unpatched Windows 2000 servers running IIS 4.0 or 5.0 with Indexing Service installed are likely to be compromised by the "Code Red II" worm.
    • Unpatched Windows NT servers running IIS 4.0 or 5.0 with Indexing Server 2.0 installed could experience crashes of the IIS server.
    • Unpatched Cisco 600-series DSL routers will process the HTTP request thereby exploiting an unrelated vulnerability which causes the router to stop forwarding packets. [http://www.cisco.com/warp/public/707/cisco-code-red-worm-pub.shtml]
    • Patched systems, or systems not running IIS with an HTTP server listening on TCP port 80 will probably accept the HTTP request, return with an "HTTP 4xx" error message, and potentially log this request in an access log.

  3. If the exploit is successful, the worm begins executing on the victim host.


Upon successful compromise of a system, the worm

  1. Checks to see if it has already infected this system by verifying the existence of the CodeRedII atom. If the worm finds this atom it sleeps forever. Otherwise it creates this atom and continues the infection process. Reference information regarding atoms may be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/hh/winbase/atoms_0p83.asp
  2. Checks the default system language, and spawns threads for propagation. If the default system language is "Chinese (Taiwanese)" or "Chinese (PRC)", 600 threads will be spawned to scan for 48 hours. Otherwise, 300 threads will be created which will scan for 24 hours.
  3. Copies %SYSTEM%\CMD.EXE to root.exe in the IIS scripts and MSADC folders. Placing CMD.EXE in a publicly accessible directory may allow an intruder to execute arbitrary commands on the compromised machine with the privileges of the IIS server process.

  4. Creates a Trojan horse copy of explorer.exe and copies it to C:\ and D:\. The Trojan horse explorer.exe calls the real explorer.exe to mask its existence, and creates a virtual mapping which exposes the C: and D: drives.

    On systems not patched against the "Relative Shell Path" vulnerability (http://www.microsoft.com/technet/security/bulletin/MS00-052.asp), this Trojan horse copy of explorer.exe will run every time a user logs in. In this fashion, certain pieces of the worm's payload have persistence even after a reboot of the compromised machine.

System Footprint

The "Code Red II" worm can be identified on victim machines by the presence of the following string in IIS log files:


The presence of this string in a log file does not neccessarily indicate compromise, it only implies that a "Code Red II" worm attempted to infect the machine.

The worm will create several files on the compromised machines. These files include c:\explorer.exe or d:\explorer.exe, as well as root.exe in the IIS scripts or MSADC folder. While the existence of the file root.exe could indicate compromise, it does not necessarily imply the presence of the "Code Red II" worm. This file name has been used for artifacts of other exploits, including the sadmind/IIS worm (see CA-2001-11).

Network Footprint

A host running an active instance of the "Code Red II" worm will scan random IP addresses on port 80/TCP looking for other hosts to infect. The IP addresses scanned by the "Code Red II" worm are determined in a probabilistic manner:

Additional detailed analysis of this worm has been published by eEye Digital Security at http://www.eeye.com.

III. Impact

Intruders can execute arbitrary commands within the LocalSystem security context on Windows 2000 systems infected with the "Code Red II" worm. Compromised systems may be subject to files being altered or destroyed. Denial-of-service conditions may be created for services relying on altered or destroyed files. Hosts that have been compromised are also at high risk for being party to attacks on other Internet sites.

The widespread, automated attack and propagation characteristics of the "Code Red II" may cause bandwidth denial-of-service conditions in isolated portions of the network, particularly near groups of compromised hosts where "Code Red II" is running.

Windows NT 4.0 systems and Cisco 600-series DSL routers may experience denial-of-service as a result of the scanning activity of the worm.

IV. Solutions

Infection by the "Code Red II" worm constitutes a system level compromise. If you believe a host under your control has been compromised, please refer to

Steps for Recovering from a UNIX or NT System Compromise

Consistent with the security best-practice of denying all network traffic and only selectively allowing that which is required, ingress and egress filtering should be implemented at the network edge. Likewise, controls must be in place to ensure that all software used on a network is properly maintained. See CA-2001-23 Continued Threat of the "Code Red" Worm for more information on these topics.

V. Reporting

The CERT/CC is interested in receiving reports of this activity. If machines under your administrative control are compromised, please send mail to cert@cert.org.

Author(s): Roman Danyliw, Allen Householder, and Marty Lindner

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH