Worst Nightmares Come Alive
This document has been written with great
care. I urge you to read the complete document before commenting on
it. Furthermore, I urge you to think about it for a while before
commenting on it. If you have constructive comments please send it
You may replicate this document at will - but please do not
butcher it - copy the *whole* document, and give me credit. I would
also appreciate it if you let me know where you publish it - just to
keep track of it.
Part I: Background
Part III: Detail design
Part IV: QWRNA (Questions
We Rather Not Ask)
Part I: Introduction to your worst
guess it was bound to happen someday - please spread the word". This
message was posted to a computer mailing list by Gene Spafford on 03
November 1988 - back in the days when the Internet, still in its
infancy, was a tool for academics and a toy for geeks. Spafford is
referring to an Internet-born computer worm (a type of
self-sustained virus) that eventually managed to effect more then
10% of the 60,000 hosts then connected to the Internet. Despite the
fact most of the world hadn't heard of the Internet or email before,
and the fact that the Dukakis-Bush election was just days way, the
incident made it to the front page of most major newspapers. This
was not because the worm was particularly viscous - it was actually
quite benign - but because people recognized the potential for
large-scale damage the worm represented. Were it not for a small
programming error in the worm's code it may never even have been
discovered. Ten years ago the "Morris Worm" shocked the world into
realizing the fragility of Internet. Today, very little has changed.
Despite ten years of new knowledge and experience the Internet today
is as least as vulnerable to Morris-type attacks as it was ten years
ago. In fact, even more so. Consider the following:
Ten years ago the Morris worm used weaknesses common to a number of
different UNIX systems to take control of the computers and
propagate itself. Today the same operating system is installed on
90% of all desktop computers. A single program could attack all
Ten years ago the Internet belonged to an elite group of specialists
and professionals. They understood their computers intimately and
managed them closely. Today every home has a computer and a
connection to the Internet. The average computer user can't tell
"email" from "mpeg".
Ten years ago the Internet was used primarily by scientists,
researchers and academics. Today it is a major business conduit.
Billions of dollars are moved over the Internet daily in various
forms and most companies would simply not be able to ANY business
without their IT computer systems.
The widespread use of firewalls on computer systems does
little to alleviate the risk. The threat here is not an attack from
some hacker on the Internet, but a program run unwittingly on a
computer already inside the protected network. The sections that
follow show exactly just how feasible such a program is. While
reading you will note the following frightening truths:
Just how relatively easy such a program is to write. Similar
programs already exist and are widely known.
Just how easy such a program is to spread. The Internet is the
perfect mass distribution system and its strength is also its
Just how easy such a program is to hide. The average user doesn't
understand half the processes running on the system legitimately,
let alone a program doing its utmost to conceal itself.
Just how hard such a program is to stop. The program can spread at
the speed of light, take any form, hide itself and mutate with every
new installation. Immeasurable damage could be done before it is
Just how ugly such a program could be. This kind of software could
bring entire sectors of industry to their knees. A well-planned
infection with malicious intent would make the Morris Virus of '88
look like a mild case of the flu.
what can be done to prevent this from happening? Not too much I'm
afraid. Like the citizens of a volcanic island we need to be aware,
stay alert and hope we spot the eruption early enough to prevent a
disaster. Here are some precautions a company can take:
Policy. The use of any unauthorized software should be prohibited.
User education, user education, user education. Make your users
aware of the dangers of running software from untrusted sources.
Audits. Perform regular checks to see what's installed and running
on your PCs.
Operating systems. A strong operating system with proper multi-user
support can minimize the damage done by a worm. Install Microsoft NT
rather then Windows 95 or 98. Consider using other operating
systems, like Line or BSD.
Diversity. By mixing a number of operating systems one can minimize
the amount of damage a virus or worm could do. This, however,
introduces added complexity in the management of the all the
different systems. Your call...
Network security. Firewalls, file encryption, operating system
security, etc. all make it more difficult for the would be worm. In
particular virus scanners and HTML, FTP and SMTP content scanners
help us weed out these kinds of threats. Consider stripping
executable attachments and other active content completely.
Host-based IDS. Intrusion detection systems may detect attacks
either on the network or the computers themselves.
Assume the worst. Plan for disasters with disaster recovery sites,
backups, and business continuity plans. Test and practice with these
you read the description that follows, imagine the consequences of
the release of such an animal and ask yourself how long it will be
before we are again saying to ourselves "I guess it was bound to
Part II: The bare bone
This is the part of the
document that will try to give a very basic understanding of the
Trojan/virus. It is *suppose* to raise questions - these questions
will be dealt with in the third section. It will only give the
reader an idea of the dynamics of the virus. It the "press release"
part of it.
The package is a
single executable. The executable contains two parts, a normal
functional program, and the Active Ingredient (AI). The normal
program can be anything, but should be of interest for the Internet
community. Examples could include: screensavers. auto playing
AVI,MPEGs, flash movies, anti virus software, a new hacking tool or
even an anti virus solution.
The type of package could be customized to suit the
way of transportation.
will be distributed on the Internet. This is done by "robots". These
"robots" will upload the infected package to FTP servers, mass mail
the package to users, repackage existing software to contain the AI,
and DCC the package at random to users connected to IRC servers. The
'net should be flooded by infected programs, all different in size
and apparent functionality.
Conventional virus spreading methods can also be
used. Initial infection could last in the order of 2 months.
Upon first execution on client machine
A user will obtain the package,
and execute it.
- Settle in.
AI will rename itself to a
non-suspect filename. The AI will take the necessary precautions to
ensure that it will be executed every time the host is restarted.
- Registration on server
AI should wait until it
detects the possibility to connect to a server on the Internet. When
this happens, the AI should contact a predefined web server(s),
uploading information to this site. It will save a file on this site
containing detailed information of the host. Each AI will save the
file with a unique name / serial number.
Day to day activity of
The AI will monitor activity, and if
it detects traffic to the WWW, it will periodically check for
instructions, posted on the predefined web server. These commands
will be downloaded from the WWW, and executed on the host. The
commands are to be found in a file that match the serial number that
the AI registered in the initial contact. The AI will execute all
commands found in the command file. If the AI cannot find the
command file, it will fall back to a general command file. If it
cannot find this file it will proceed with preprogrammed
that is infected "reports" to one of the predefined servers. It will
update a counter file. Every host that is infected with the initial
spread will increment a number stored in the "infection count" file.
When this file reach a critical mass, all AIs will begin secondary
The AI will extract all email addresses contained
within the address book of popular mailers (Outlook, Netscape,
Eudora). The AI will start sending email with attachments to
addresses harvested from the mailers. The attachment will be the
package. The rate at which the AI will send mail can be controlled
via command files.
Part III: Inner
This section will try to
explain consideration that should be taken, technical specifications
etc. It is aimed at people who understand the underlying technology.
It is mainly aimed at programmers that know their stuff.
Robots that will download executables from
frequently visited sites (Tucows etc.), and repackage it to contain
the package. These bots could be instructed to visit certain sites
more frequent than others and to target certain files. These bots
should have the ability the decompress distributions, repackage, and
compress it as well.
- DCCsend bot
Robots on multiple IRC channels
that will at random DCC the package to clients that are detected
running the de facto standard Windows client (Mirc). Robots could be
written with intelligence to con users to accept the DCC. Bots could
be situated in "Warez" channels, spreading the repackaged commercial
- FTP put bot
Robots that will search the
Internet for FTP servers with writable /pub and /incoming
directories, and drop the package in those directories.
- Mail bot
These bots will be not unlike the
mass mailer programs, mailing the package to many individuals,
posing as representatives from various organizations such as
Hotmail, Geocities etc, with package as free "gift". This "gift" can
be something like a new screensaver or HTML writer.
Note that all transport mechanism implies that the
receiver is connected to the Internet on some way or another.
The AI itself can be coded in different forms, so
that there will be hundreds of different code signatures - this will
make it difficult for anti virus vendors to develop a program that
will search for code signatures.
When the user
downloaded the package, he/she will execute it. The package will run
the normal program, and the AI will also execute. The AI will
install itself within the system, in such a way that it will always
execute at startup. It will also disguise itself, by renaming itself
to a non-suspect filename. This name will contain random letters,
and should not be longer than 6 letters. At every restart, it will
rename itself again (and modify the startup correctly). It could
also modify the startup method -e.g. modifying the registry, or the
The AI must be able to detect itself. This will
ensure that the AI will not be installed every time the package is
executed. This can be done by "marking" the host - it will not
reveal where the AI is located, just that it has been infected. This
"marking" will furthermore hamper the detection process later on, as
this mark has to be removed before the host can be re-infected for
The AI will proceed to determine if it is situated
in an online environment (it can open a session to a machine on the
Internet). If direct connection is not possible, it will determine
if a proxy is present (registry), and use the proxy to connect to
the Internet. Ideally, the AI will monitor network traffic with
destination port 80, and determine the best path out - be that
direct, or via a proxy. As this could involve installing a custom
packet driver, the AI could monitor CPU load across different
applications, and register an online situation when a browser (IE or
Netscape) uses CPU load.
The AI will only try to make a connection if it can
safely determine that there is an already open connection to the
The AI will contain a list of web servers that will
be ready to accept the registration. For every AI, this list will
contain random preferences. The AI will try to contact the web
server with higher preference and send a report to the web server.
The AI will send the report in the same way that browsers upload
files to web servers. This list could typical contain up to 75
The initial report that the AI will send to the web
server should contain:
-Self generated serial number
information (type, speed etc)
-Platform (e.g. CPU,
-Browser support (Netscape / IE)
(Outlook, Eudora etc)
Most of this information can be extracted from
the registry. The AI will save this report in a file with the same
name as the self generated serial number.
The AI will try to download a file called
"counter". This file will contain a number. It will increment this
number, and upload the file, with the same filename. This file is
thus a counter of the number of infected hosts that could reach the
server(s). A "counter.lock" file can be used to ensure that two
hosts do not access the file at the same time. A host that
encounters a lock file will wait for a predefined period of time,
It is *very* important that the virus is not
discovered during the initial infection stage. Care should be take
that the AI should under no circumstances reveal itself. It should
rather end its life than reveal itself.
Using different spreading mechanism, and different
"host programs" should ensure that the AI could still reproduce. The
packages will still contain the AI, and infection can spread along
The web servers
These are the
web servers where the AIs will register, and receive commands from.
The web servers should all be public accessible web servers, where
free webspace can be obtained - e.g. Geocities, Iname, Yahoo, to
name a few. Multiple accounts should be registered on every server.
Commands "dropped" for the AIs should be replicated
between the servers. This means that all commands should be present
on all servers, so that a certain AI can pick up commands from
different servers (in the case that one server might be down,
blocked, or administratively taken down).
Replicating the data can be easily automated if the
web server accepts FTP connections. If the sever does not, a PERL
script can be build to interrogate web interfaces. As it is
envisaged that this virus will be controlled by a group of people, a
CRC checksum of all command files could be stored on the web server.
Replication will only happen when CRC checksums between web servers
does not match.
To hamper detection, fake web servers can be
included in the list. The AI will know that these sites does not
contain a "drop zone", and will not attempt to retrieve commands or
drop reports to it. The only purpose of these fake sites will be to
cause confusion to anti virus vendors once the AI is detected.
More information on the format and distribution of
"dropped" commands will follow.
Day to day activity of the
When the AI detects that it
can open a pipe to its web server of choice (as explained in the
"First Contact" section), it will try to download a file called
".cmd.". Failing this, it will try to download a file named
"general.cmd.". The first file is a file containing specific
commands for the AI. The AI will internally keep count of command
files that was received and executed and will only act on command
files with counters larger than its saved counter. The second file
is a file that is used for sending commands to be executed by all
AIs. It is envisaged that this will be the default action, unless
the controller have something specific in mind for a particular
Both these files contain commands for the AI(s).
After downloading the command file, the AI will execute the
commands. If the AI acts on general commands it will increment a
counter within a file called "". By doing this, the controller can
see how many AIs have already executed the general command. Access
to the command counter file can also be regulated by a lock file.
An instruction set could contain the following
Remove the AI from memory, hard drives
and IP stack.
Erase all data, and reboot.
- sync (time)
Will command AI to periodical
fetch new command file every "time" minute. The AI will still only
contact the server when it can do so safely.
- batch begin, batch end
All commands between
batch begin and batch end will be executed as a batch job. Commands
between "begin" and "end" should be chosen to redirect its output to
files - see the example.
-download (filename, local name)
web server, and save it as on the host's hard drive.
- upload (local file,remote file)
Uploads to web
server, saving it as on the server.
-update (local file)
The AI will download and
update itself. This could be useful when anti virus vendors start to
realize the threat.
-spread (count, rate)
See section on secondary
-default begin (count), default end.
between default begin and default end will be executed if the AI
cannot connect to servers in succession. (it will still only try to
reach these servers when it detects that it is in an online
The command set can obviously be expanded to
include typical BO commands. An example of an AI command file could
default begin 4
dir c:\*.doc /s >
upload c:\dirall.docs 16643dhas13.all_docs
In this example the AI will erase all data on
all drives when contact are lost with its top 4 servers. It will try
to download command files every 15 minutes. It will upload a file
called 16643dhas13.all_docs containing a listing of all .DOC files
on the C: drive. It will download and install Back Orifice. The
"spread" command will be discussed in the next section.
Note the "END" at the end of the command file. If
the AI cannot find "END" at the end of the command file, it must
regards the command file as incomplete, and not execute any
With minimal effort, command file and reports can
be encrypted. Encrypting the data should make it much more difficult
to determine the mechanics of this virus. It will also help to
ensure that anti virus vendors cannot send commands to the web
servers to automatically erase the AI - such as "remove()".
Combining encryption with the "default begin
default end" command makes for a powerful concept. If the host is
left on the 'net, it can be remotely controlled. If the sites that
the AI is visiting is taken down, the host goes down with the AI.
Anti virus vendors, security exports cannot talk to the AI, because
communication is encrypted. The only way to be totaly safe is to
disconnect the host permanently from the Internet.
AI that registers will increment the "counter" file. The "spread"
command act on the number contained in the "counter" file. If the
counter exceeds , secondary infection procedures are executed at
The AI will "farm" email addresses from known mail
clients - e.g. Outlook, Eudora and Netscape mail. It will extract
mailer information (SMTP gateway, local email address owner etc.)
from the registry, or directly from the mail client. The AI will
disregard email addresses that is within the same domain as the host
(that is - it will never send email to firstname.lastname@example.org, if the local
domain is bobby.com). This is to minimize the chance that the virus
will be discovered by inter-human contact.
The AI will start sending out packages (see Part
II) to number of persons per day. Each message sent out will contain
different subject lines - e.g. "check this out", "have a look", "for
your information" etc. If the host contains less than email
addresses, it will send it to the maximum number of recipients,
given that they are not within the same domain. Note that via the
command file, the rate of infection can be controlled.
Let's assume that we have an initial install base
of 10000 (which is pretty conservative). If we send a spread index
of 7 the virus/Trojan will spread like this (assuming that the
receiver is not yet infected):
1st iteration: 70,000
3rd iteration: 3,430,000
4th iteration: 24,010,000
If we assume that only 75% of receivers will
have an OS that is susceptible for this virus/Trojan, and that only
50% of those will execute the attachment we are still looking at:
1st iteration: 26,250
3rd iteration: 180,878
4th iteration: 475,807
at which time it will become difficult for the
web servers to keep up. Keep in mind that the 4th iteration can be
reached within hours, where after a mass_destruct() signal could
possibly be issued.
Part IV: Now think about
Ask yourselves these
-Can this really be done? The answer is yes.
Yes yes yes. It has been done to a much smaller extent. Think of
Melissa, think of the '88 worm. All of them were minor threats in
comparison with this.
-Why is this then different from what we have seen
The major difference here is that this Trojan/virus will
initiate communication. This means it can bypass firewalls, as
firewalls are generally build to block incoming traffic, while
allowing (some) outgoing traffic. This Trojan/virus will also have
the ability to communicate with its controller (and even inter-virus
communication is possible). The virus/Trojan is basically a
streamlined, neatly packaged combination of all the bad things that
are floating around the 'net today.
-how much "smarter" can this thing be made?
smarter. I am not the brightest person on earth, and I can come up
with something like this. There are many of us out there, smarter,
and brighter...and with the resources to create this monster.
-what would be the implications of this?
could mean that the Internet would change, to such an extent that it
will no longer be possible for companies to use it as a commercial
tool. Back to the old days of vast open, purely academic networks.
-Is the IT security world ready to handle such an
Not really. When this Trojan/virus reaches secondary
infection phase, it can spread to millions of hosts within hours,
and disconnection of hosts could lead to disaster. Remember that the
rate at which the anti virus could spread is just as fast, or slower
than that of the virus.
-what would happen if this were wired into an
existing stable reputable product?
I rather not think of it...
-How do we know that there is not something like
this out there?
We don't. Isn't it strange that our friends at
cDc and L0pht haven't released something like this? Or have they?
-why have you written this?
I think that a
monster the likes of this is about to be released. It will be only a
question of time before a thing like this will happen. The only
thing keeping it from happening is that the people with skills to
write such an application is not willing to do so, since they, as
experts, know the implications.
Taking it one step further (the really nasty
see...what would happen if the AI was to encrypt *.DOC *.CPP, *.C
files and store the keys on the web servers (encrypted under a
masterkey)? I can see it now - "buy your code & documents back
at our special discount price"...
Last words &
And you thought all we do in South
Africa is dodge the elephants... My sincere thanks goes out to Charl
for his ideas and for writing part I.