First, rather than blindly scanning a network, why not use traceroute and/or DNS to
build your host list? Many sites still allow zone AXFRs, which means you have a greater
probability of hitting a 'live' host. In addition, some simple brains (ala nmap) to detect
when a subnet is behind a firewall would go a long way towards speeding up scanning -
albeit at the risk of missing some hosts. Why throw wet noodles at a wall all afternoon?
Also, traceroute is a brilliant way to scan upstream hosts, who can then scan their local
subnet, and then hit the border router and go from there. Combining this with a cached list
of ARIN inquiries to find other networks that might be local to it (but not in the host's
own router tables), would also speed up scanning. Lastly, has anyone considered coding a virus to sniff out remote router access from the administrator, and then grab the login/password, and slip in to grab the router table (for propagation purposes)? It's an innovative approach, but it would also bloat the virus' codesize quite a bit.

Lastly, why must a virus be of a single strain? Why not create a module-virus that
can be uploaded in chunks? Have one module that does scanning, another sniffing, another
to infect variants of the server in question (or other servers), etc. Thus, rather than
dealing with 1 virus, a virus with 5 modules could have 120 possible strains. A
virus with 10 modules could have a whopping 3,628,800 possible strains. This would severely
delay any A/V 'auto-removal' of the worm.

But, I am drifting off topic -

*Back on the beat*. As anyone knows, with geometric progressions a small difference
in the initial numbers can lead to huge differences within just a few transformations.
So we're going to say that 12,500 machines are initially infected, not 12,000. This,
as the author put it, is where "the second stage begins." 12,000 hosts can scan 100
hosts per second. That means each second 1,200,000 hosts are being scanned. As I noted
earlier, only about 1 in 4,295 hosts will result in a 'hit'[1]. So 279 hosts seems to
be what we'd get within the first second of the virus going active. Assuming this
continues in a geometric progression, after 60 seconds, we will have 46,658 hosts
infected. After only 292 seconds (just under 5 minutes), we will have reached our
1 million hosts mark, thus ending the attack. The formula, that I used:
"= ( A1 * 100 / 4295 ) + A1", and I stuffed that into an Excel spreadsheet, mostly
because I didn't have time to dig out a real scientific calculator. :^) Had we used
the author's numbers (12k), however, it would have taken 2 more seconds.

I'm going to assume a much more modest number of hosts to start
the infection - 10. At the same time that our earlier calculations had about 1 million
infected hosts, this one now has only about 10,000. How long does it take to reach
1 million hosts? 502 seconds, or about 8.5 minutes. If only 1 host starts out
infected? It takes almost 602 seconds, or about 10 minutes. In short, the initial
number of infected hosts is totally irrelevant.

Now, the math is fairly impressive, no? This is the foundation of this paper,
and sadly, I had to recreate the math he used to arrive at these conclusions as he
did not include it. But, as many have said - math is that wonderful kind of logic
that allows you to arrive at the wrong conclusion with confidence...

*There are 4 billion internet addresses*

Yes, but thanks to the way ARIN has allocated them, only a fraction of those
would have any hope of having machines on them. So this assumption is totally unrealistic.
But, we'll assume it is a simple virus and doesn't know this. Either way, there are
*4,294,967,296 possible IP addresses*,
which is a change of about 7% - enough to throw off calculations just a little.
*Assume that the worm is under 100k in size and is multithreaded, allowing it to probe and attack many machines simultaneously.*

Reasonable.

*Further assume that the targeted servers have good network connections, allowing a running copy of the worm to scan 100 machines per second, probe and infect 10 machines per second, and it takes 1 second to actually transfer over the worm to a new target. *

It could not, possibly, take an average of 1 second to transfer a worm of 100k to another
host if the infection is over a TCP/IP connection. Assuming 60ms of latency between hosts,
it would take 240ms just to setup the connection. Most (sane) operating systems use a
'black hole' method of MTU discovery - meaning the initial packets will be small. Even
assuming a *huge* RECV window of 65K, that still means that it's going to take a bit
more than 1 second to complete. Probably 2-3 seconds, if you factor in packet loss over
the aggregate connection times plus the assumption that you'll be using OS calls, not
raw sockets, to chat with remote hosts. The math required to determine the impact of this
lag, however, is beyond me. Perhaps someone better at calculus than me is reading this?
I suspect, though, it would lengthen the infection time out by at least double.

Now, the '1 million hosts' is conservative. Check out the netcraft survey.
As you can see, there were about 3.4 million IIS hosts out there.

In short, the math needs to be re-done on this paper. And the Code Red worm did move upwards in a geometric progression... by now, shouldn't we all have been packetted into oblivion though? There's a good, real world explanation for this, which unfortunately, the math does not give any hints on where it would be.