Technical Analysis

The following analysis was performed by a group of U.S. government and private sector researchers cooperating over the weekend of August 4th shortly after the second Code Red worm — CodeRedII — appeared:

Code Red II Worm Analysis Update
The new worm that was first noticed yesterday has been analyzed. Here
is a summary of the facts based on the excellent analyses referenced
at the bottom of this page.

This worm uses the same mechanism as the original Code Red worm to
infect vulnerable servers. That is, the worm looks for IIS servers
that have not patched the unchecked buffer vulnerability in idq.dll
or removed the ISAPI script mappings. See the Code Red Patch FAQ
at for information on
patching systems to remove the vulnerability.

Except for using the buffer overflow mechanism in order to get the
worm code executed on a vulnerable IIS server, this new worm is
entirely different from the original Code Red CRv1 and CRv2 variants.

Note: According to eEye, the worm code will be successfully executed
only on a Win2000 system running a vulnerable IIS server, WinNT-based
IIS servers will simply crash when attempting to execute the worm
code. Our experiments and reports received from users confirm this

The most damaging property of this new worm is that the worm creates
a back door on an infected server, leaving the system wide open to any

The worm copies %windir%\CMD.EXE to the following locations:


This provides a means for a remote attacker to execute arbitrary
commands on the compromised server.

In addition, the worm creates a trojan copy of explorer.exe as
described below. Due to the actions of the trojan explorer.exe,
IIS will make the C: and D: root directories accessible to a remote
attacker even if the root.exe command shell program is removed from
the scripts and msadc directories.

The worm carries its own copy of explorer.exe. The worm places its
own copy of explorer.exe at c:\explorer.exe and d:\explorer.exe. By
placing the trojan file in these locations, Windows will find and
run the trojan rather than the real explorer.exe because of the way
Windows seaches for executables by default. Specifically, unless the
system has been patched against the "Relative Shell Path"
vulnerability, the trojan explorer.exe will be executed when the next
user logs into the system. (See

Upon execution, the trojan first runs the real explorer.exe (thus the
user will not notice any problems) and then goes on to modify the
system registry as outlined below.

First, the trojan program adds the value SFCDisable=0xFFFFFF9D
to HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogin.
This registry setting completely disables the Windows File
Protection (WFP) mechanism. WFP prevents the replacement of
certain monitored system files. See the following for more info:

Next, the trojan sets the following "Virtual Roots" in the

SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots
\scripts to ,,217

SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots
\msadc to ,,217

These "217" settings ensure that the scripts and msadc directories
(which contain the root.exe copy of cmd.exe) have
read/write/execute permission.

Finally the trojan sets these two "Virtual Root" values as well:

SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\c
to c:\,,217

SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\d
to d:\,,217

These mappings, which do not normally exist, map the root C: and D:
drives to a place where IIS can find them, namely /c and /d. The
permissions here are also set to read/write/execute.

Quoting eEye's analysis, the purpose of these mappings are described:
Basically the above code creates a virtual web path (/c and /d) which 
maps /c to c:\ and /d to d:\. The writer of this worm has put in this
functionality to allow for a backdoor to be placed on the system so 
even if you remove the root.exe (cmd.exe prompt) from your /scripts
folder an attacker can still use the /c and /d virtual roots to
compromise your system. The attacks would basically look like:

(if root.exe was still there) or:
(Where dir could be any command an attacker would want to execute).


Note that the trojan explorer.exe need only be executed once for
these registry changes to be made. Thus, all the backdoors are
enabled, and continue to be enabled, forever after, regardless of
whether or not explorer.exe is running.

To emphasize, note that even killing the trojan explorer.exe process
will not remove the back doors. Further, even killing the explorer.exe
process and removing the copies of root.exe and deleting the registry
settings will not eliminate the backdoors. If the trojan explorer.exe
is executed again (e.g. when the next person logs in), the registry
settings will be reinstated, making the C: and D: drives again
externally accessible. Finally, note that even deleting the registry
settings, removing the copies of root.exe, and removing the trojan
explorer.exe is not sufficient to clean the system. During the
time the system was backdoored any other attacker could have
installed new backdoors that are not associated with this worm.

The trojan process sleeps most of the time, but wakes to loop through
these registry key modification steps every 10 minutes. This way, even
if an administrator notices the registry settings and deletes them,
the trojan will reinstate the settings a few minutes later.

How aggressively the worm attempts to propagate itself depends on
whether or not Chinese is the language installed on the system. If
Chinese, the worm creates 600 threads and attempts to spread for 48
hours. If non-Chinese, the worm creates 300 threads and attempts to
spread for 24 hours. After the infection-spreading interval, the
system is forcibly rebooted. The reboot flushes the memory resident
worm, and leaves the backdoors and the explorer.exe trojan in place.

The 300 or 600 worm threads all work simultaneously to propagate the
infection. Each chooses a random target IP and then uses one of the
following masks with the given probabilities.The masked parts of the
IP are replaced with the host computer's own IP information. Thus, the
worm mostly confines its targeting to IP addresses close to the host
computer's own.         (probability 12.5%) => random       (probability 50.0%) => same class A     (probability 37.5%) => same class B

Target IPs which are excluded are 127.x.x.x and 224.x.x.x, and no
octet is allowed to be 0 or 255. In addition, the host will not
attempt to re-infect itself.

Before each attempt to connect to a new target, the worm checks the
local time to see if the year is less than 2002 and if the month is
less than 10. If either of these checks return false, then the worm
ceases the propagation cycle and reboots the server. Note that this
implies that all worms will cease propagating by Oct. 1, 2001.

To aid performance, the worm uses a nonblocking socket to connect to
each target. Specifically this means that if one thread is stuck
waiting for a slow connection to a particular target, the wait will
not slow down the rest of the threads from continuing their scanning

After making a successful connection with a target (the three way
handshake has completed), the worm thread uploads all of the worm code
at once, looks for an acknowledgement, and then moves on to attempting
to infect other hosts.

When a worm first arrives on a target and begins execution, the worm
checks to see if the host has already been infected, and if so,
disables itself. Specifically, the worm checks to see a CodeRedII atom
has been placed using "GlobalFindAtomA". If the worm finds that the
atom exists then it goes to sleep forever. If the CodeRedII atom does
not exist, the worm creates the atom and continues execution.

Corecode provides a .zip file containing a IDA Pro project file and a
plaintext disassembly for both the worm and the trojan explorer.exe

To download the eEye analysis and their disassembly files:

The worm binary can be found at the Unixwiz site:

Corecode's Analysis:

NAI's Analysis:

eEye's Analysis:

SecurityFocus Analysis:

We are very grateful to Jesper Johansson for reviewing this report and
providing many helpful suggestions and technical details.

Many thanks are due to corecode, who stayed up all night and provided
the very first analysis of the worm binary to the public.

We'd also like to recognize Stephen Friedl of Unixwiz for performing
a higher level analysis last night and posting his findings to the
web before any other concrete information was available.

Also, we thank Matt Scarborough for testing the worm on WinNT to
confirm that these systems crash rather than running worm code

To return to the previous page, press your browser's BACK button.

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2016 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.
Jump to top of page

Last Edit: Oct 03, 2003 at 21:17 (5,131.34 days ago)Viewed 1 times per day