Results 1 to 5 of 5

Thread: New Code Red Variant ?

  1. #1
    Junior Member
    Join Date
    Jul 2001

    Thumbs down New Code Red Variant ?

    I'm no security whiz but my Apache logs saw a few CRv1 and CRv2 hits they looked something like this (entry modified very slighty so it won't work) - - [19/Jul/2001:15:54:40 -0400] "GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53f%u0078%u0000%u00=a HTTP/1.0" 400 323

    Now I only saw about 50 entries in my logs that looked like this, now I have had over 400 entries which replace the NNNNN's with XXXXX's. Also the other thing I noticed about this is if you check the IP addresses they are all gonna be comming from your /8 subnet. Example

    Using this mini script

    for h in `cat access_log | grep .ida?XXX | awk '{print $1}'`; do
    echo "IP: " $h " HOST: " `host $h | awk '{print $5}'`
    done | sort | uniq -c

    it produced a list of all the IP addresses and their host names to match like so

    4 IP: 66.xx.xx.xx HOST:
    8 IP: 66.xx.xx.xx HOST:

    This is where I noticed ALL ips start 66.xx.xx.xx. w my IP starts 66.xx.xx.xx so looks like there is a new variant out which scans its own /8 subnet only (Well a lot more often than CRv1 or CRv2 did). Hence the more frequent attempts.

    Also in my error_log instead of seeing

    [Sun Aug 5 00:13:09 2001] [error] [client] Client sent malformed Host header

    I now get this

    [Sat Aug 4 17:28:24 2001] [error] [client 66.xx.xx.xx] File does not exist: /www/html/default.ida

    Anyway, Comment away !


  2. #2


    I have recently looked on and noticed a fairly large archive of logs and other things of the sort that refer back to JP and AntiOnline participating in questionable and fraudulant acts. Due to my support for and I am currently pulling all my posts from this site and ask for my account termination. If you, JP, find that at any point you feel you can be at least half ass honorable then I will consider posting here again.

  3. #3
    Junior Member
    Join Date
    Jul 2001
    Ok, this is NOT a new variant of Code Red, my mistake. It looked like is was. Instead its this. (from Security Focus)


    Ryan Russell
    Guest Analysts:
    Marc Maiffret and Ryan Permeh

    Incident Analysis Report
    August 4, 2001

    Executive Summary

    A new worm affecting unpatched Microsoft IIS web servers has been
    discovered. 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.

    The fix is to apply the Microsoft patches. Most companies will have these
    in place by now due to Code Red.

    Associated Vulnerability: MS Index Server and Indexing Service ISAPI Extension
    Buffer Overflow Vulnerability
    Associated Bugtraq ID: 2880
    Urgency: High
    Ease of Exploit: Automatic
    Associated Operating Systems: Windows NT 4.0, Windows 2000


    A new worm, which has been named CodeRed II, has been discovered in the
    wild. 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.


    * Windows NT 4.0:

    * Windows 2000:

    Attack Signatures

    The original Code Red worm sends the following request during the attack:


    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.

    IDS Updates

    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.


    SecurityFocus recommends that you apply the patch immediately. In
    addition, SecurityFocus analysts recommend that you implement as much of
    the following hardening/checklist document as possible:

    * IIS4:

    * IIS5:

    There is also an IIS5 Hotfix Checking Tool to check for patches that
    haven't been installed. You can get it from Microsoft Technet at:

    Attack Data

    Figure 1 - ISAPI Overflows and cmd.exe requests August 3 - 5

    Figure 2 - Top attacking countries for ISAPI Overflows and cmd.exe
    requests August 3 - 5

    The trailing off of the graphs is a result of that being the most recent
    data at the time, and is not indicative of the worm slowing down.

    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

    Technical Description

    This 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 PRC)
    * 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 advantage.
    * 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

    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

    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 steps:

    * 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 c:\progra~1\common~1\system\MSADC\root.exe
    * Creates c:\explorer.exe
    * Goes back and repeats the steps for drive d: instead of c:

    The trojan explorer.exe doesn't get executed until the next time the host
    is rebooted and someone logs in. When it is run, it executes the real
    explorer, and then does the following in an infinite loop:

    * Sets SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SFCDisable to 0FFFFFF9Dh (disables system file protection)
    * Sets SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\Scripts to ,,217
    * Sets SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\msadc to ,,217
    * Sets SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\c to c:\,,217
    * Sets SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Virtual Roots\d to d:\,,217
    * Sleeps for 10 minutes

    The Virtual Roots ensure that the scripts and msadc directories stay
    mapped, and maps a c and d virtual root which don't normally exist.
    These are mapped to the drive roots, which will allow an attacker yet
    another way into the victim web server remotely. Even if the root.exe
    files are removed and the overflow patched, if explorer.exe is running, an
    attacker can execute the original cmd.exe, or any other executable, with a
    command similar to the following:


    File Names

    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.


    Securing IIS:

    Free Code Red scanner from eEye:

    Community Credits

    SecurityFocus wishes to thank the many Internet users who have provided us
    with logs during the Code Red process, as well as now CodeRed II. This
    has enabled us to notify many Code Red victims, who were then able to
    clean up their affected hosts. We also wish to thank the many ISPs and
    other providers who had to search through their logs to track down who had
    the dynamic IP address at that time, and notify them that they were


  4. #4
    Junior Member
    Join Date
    Aug 2001


    Well, Knightmb, it looks like his goal is to post it in every single stinking forum on

    Beyond that, thank you Asmod for that very detailed article.

    God bless you all
    Usually, no one cares what I think... If I\'m lucky, maybe YOU will :-)

    --Alexander Paul Baston

  5. #5
    Senior Member
    Join Date
    Jul 2001
    Originally posted by AlexPBaston
    Well, Knightmb, it looks like his goal is to post it in every single stinking forum on

    Beyond that, thank you Asmod for that very detailed article.

    God bless you all
    I have (2) posts in all on this board. It's going to take a lot more than that to get a post in every forum here

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts