If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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

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.

Hmm..

I have recently looked on www.attrition.org 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 www.attrition.org and www.netflood.net 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.

Ok, this is NOT a new variant of Code Red, my mistake. It looked like is was. Instead its this. (from Security Focus)

CodeRedII
DRAFT

Analysts:
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.

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.

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.

Recommendations

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:

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
threads.

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

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 192.168.1.1, the new one to try might be
192.168.45.67 (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 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:

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:

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.

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
infected.