During my discussions with MrCorp, he indicated that I should clearly indicate
the definitions of "worm" and "virus. I have used these terms
interchangeably in the essay. The purists will be more happy by this distinction
- worms spread but don"t multiply within the host while viruses may or may not
multiply (i.e. infect more files). You maybe more comfortable classifying them
as "malware". Malware can be defined as programs written with harmful
and deliberate intent.
Text from original documentation is italicized.
** WARNING **
This document is strictly meant to be a snapshot indicating the various developments
in the area of virus research.
I strongly advice the readers to explore this topic strictly from a research
point of view and refrain from releasing harmful code. This warning is not to
be taken lightly as I speak from personal experience and interaction with many
people. History teaches us that both in h/v scenes, things turn nasty for the
creators once it"s out of control.
This text is dedicated to all @ SWG.
" I"ll take you
Right into the Danger Zone "
-- Kenny Loggins
The troubling aspect about the current wave of malware is the return of one
element - intelligence. The last such effort was in 1988 in the form of the
Morris worm. It was a piece of beauty with structural foundations that reflected
a brilliant mind. The deployment was shoddy and accidental leading to the worm
and it"s originator"s quick arrest.
Now after more than 10 years, a group of people have done some impressive work
in this gray area. They also demonstrated responsibility by not releasing working
versions of their efforts.
In a rather lighthearted article, Michal Zalewski along with his team outlines
a working prototype of a next generation virus structure. The project was called
"Samhain". The group wanted to check out how tough it would be to
write a truly dangerous I-worm (something like Morris ver 2.0).
Before we make an effort at understanding Samhain, a basic concept introduced
by them needs to be evaluated. It"s called Wormnet and refers to a network
established by the instances of the worm. This helps in varied issues like communication,
updating and learning (intelligence, adaptability.. call it what you want to)
Now let"s take a look at the project goals:
" worm must be architecture-independent, and should work
on different operating systems (in fact, we focused on Unix/Unix-alikes, but
developed even DOS/Win code). "
An old mission statement. The difference this time is the choice of platforms.
The combo of Unix and Windows make a target playing field of almost whole of
the networked world. For those of you who think Linux (Unix) is having some
kind of immunity to viruses, please take a look at viruses like VIT (an experimental
prototype by the author Silvio Cesare given along with his 1998 article - Unix
elf virus and Parasites). Several underground zines now have detailed tutorials
on malware construction for "nix environments.
There have been earlier efforts to construct multi-processor and true multiplatform
viruses, one of the most technically interesting was that of Esperanto written
by Mister Sandman.
This virus is interesting for the following reasons:
i) It is written entirely in assembly and C. It"s not a pseudo effort like
macro viruses (which take the benefit of the scripting environments provided
ii) The sheer complexity of the project is impressive for a single individual
to handle. This shows the kind of people involved in virus writing.
iii) It is highly modularized with the final target being a single cohesive
Fortunately, this remained a zoo virus effort. No further practical efforts
(read enhancements that would have made it work) have been made in this direction.
The virus writer Jacky with his virus Win32.Cabanas demonstrated a more practical
and very effective demonstration of multi OS infection in 1997. This virus is
compatible with Win2K, NT, Win9x, and Win32s (Extension to Windows 3.x to run
32-bit applications. It is still used by many people with old systems).
Another factor that helps in virus writing for Win 9x/2k/NT environments is
the PE (Portable Executable) format, which is used by all system and third party
Now, getting back to Samhain. The team basically decided on distributing in
the source form with the decryptor (detonator) written in shell script. The
problem that the required compiler for the platform may not be available at
the host is solved by the wormnet structure.
The structure helps solving the problem in the following manner:
" But wait, some (not much) systems don"t have C compiler.
What can we do? Using wormnet, worm during infection might ask other wormnet
members for compiled binary for given platform… Anyway, binary will contain
appended source code, to make further infections possible within standard procedure.
The first version of the team on writing a decryptor used a simple ("per-byte
increments") encryption scheme for masking the worm source. This module
itself changed in each new instance of the worm using a polymorphic engine to
avoid the possibility of constant strings. This aids in evading signature based
detection (which is still is being applied in case of the various new script
viruses, even by the so called intelligent virus scanners).
The dependency on various utilities and commands in the shell script or the
whole binary module sent to the host was solved again via the wormnet structure.
Incase the child sent won"t connect back to the parent and report itself, the
wormnet is queried for a pre-compiled binary for the given architecture (this
principle works under the assumption that the virus has infected a similar machine
Is equal to invincibility. The art of remaining unseen remains the most elusive
and difficult to learn or implement. Sometimes, the very modules or code written
to provide this reveals the presence of the rogue program.
Most stealth systems are also highly platform dependent. In the case of Samhain,
the team knew that even after the worm attaches to the host successfully, it
may not have high enough privileges (read root) to go into godmode.
Techniques that can hide, feint and generally aid in making the worm hard to
kill were needed. The assumption of encountering an environment that operates
on access restrictions may look silly to the Win 9x based folks but most future
operating systems even for standalone workstations would be stripped down versions
of network operating systems (for example Win 2k). They will also have lot of
features based on principles of file integrity checking (Eg. SFC of Windows,
Tripwire for "nix), unauthorized network activity detection etc. to detect the
presence of rogue programs.
Hence the most important thing for a virus is to remain hidden till it can
be in a position to override all these. Samhain details a "non-privledged
process masquerading" unit which consists of the following parts:
The process name of the worm would be such that it is similar to a chosen
set of common process names.
" change your name (and executable name) as
well as pid frequently; while doing it, always keep "mirror" process, in case
parent or child get killed by walking skill-alike programs."
The documentation also points us to an excellent source of information on architecture
neutral, non-root process hiding techniques. It is in the archive http://lcamtuf.na.export.pl/pliki/libworm.tgz
Though effective, these routines are useful only for a short period of time
and the worm should aim to gain root ASAP. After doing that, advanced process
hiding can be deployed. The Samhain team developed source for some test platforms
based on well-known kernel file and process hiding modules.
Invisibility was also an issue with old DOS viruses like preservation of file
date and time, no change in file sizes when stealth module was in memory, bypassing
online virus scanners, maintaining compatibility with the loaded modules of
the system etc.
In Win 9x/2k/NT environments, the issue becomes more complex due to the more
sophisticated and larger executable formats. We saw a return to old techniques
like cavity infection (this is a technique by which the virus takes up empty
portions in the host file) and the building of new ones like installation archives/ZIP
file infection, E-mail attachments, using new mediums like IRC, ICQ etc. for
spreading. Further obstacles for the virus writer are the checks performed by
the OS for possible file corruption by comparing the image size in the PE header.
Another dimension of invisibility is to destroy those who try to see you. This
is demonstrated by new techniques that deactivate or nullify the virus scanner"s
attempt to catch the bug at say the e-mail gateway. A few interesting ideas
include distribution in ZIP files (encrypted), using some properties to DoS
(launch a Denial of Service attack) well-known virus scanners. A simple example
would be the one suggested by the British virus writer Rajaat. It involves construction
of a malformed ZIP archive, which would disable most anti virus solutions at
the time of scanning. This is basically old trick of putting a reserved device
name in one of the filenames (eg. Replace blah.txt in blah.zip with CON).
Independence and learning
Most conventional computer viruses rely on some kind of user interaction to
infect the host. For eg. Running executables, opening/previewing attachments
The Samhain team formulated another postulate that worries me the most,
" worm must be able to spread automatically with no user
interaction, using built-in exploit database "
According to the team members, the wormnet structure can easily be used to
provide this functionality. The structure is used to:
- Distribute upgraded Samhain modules (i.e. new exploits/functionality) across
the members of the wormnet.
- Query other worms for compiled binaries incase the one sent is not working
The communication scheme used by the proposed wormnet structure is based on
a simple TCP stream and connections established are persistent. This is unlike
programs like BO2K which use UDP.
In the Win 32 world, one virus which show the early inklings of a communication
system is the complex Win32.Babylonia written by the virus author who goes by
the name Vecna. It demonstrated how a virus can update itself via plugins. Another
interesting feature was the fact that it was also a very efficient e-mail worm.
Let"s now evaluate how the wormnet deals with various events in the host environment:
This is done simply by the worm connecting back to the parent from which
it originated. If the infection was not successful, no connection is made.
Incase new "improved" versions of the whole worm or some features
are made, all the members of the wormnet can get updated by "re-infecting"
The Samhain team demonstrates that how security measures are needed even in
malware to ensure it"s survival. They made a scheme by which the replacement/updation
takes place only after the already installed worm verifies the new one by a
signature. This scheme can be replaced by any asymmetric cryptographic technique
in future worms.
Now two cases can occur:
I) The already installed worm has an older timestamp. In this case, the approach
would be to send back a "confirmation" and download the new code via the same
tcp stream. Proper error checking and verification should be done throughout
the process. After the new module has been downloaded, its code signature has
to be verified and finally "install".
II) We find that the already installed worm has a newer timestamp. In that
case, the wormnet segment from which the worm placed a request for updation
will itself get updated with the new version.
This scheme ensures that the whole wormnet gets updated with a new version
Requesting for new platform
Before understanding how this is implemented, I should explain the term TTL. It
expands as "Time to Live" and stands for an 8 bit field in the IP header
of a datagram. TTL limits the life of a datagram by setting an upper limit to
the number of points (routers) through which it passes.
Suppose a worm instance is about to infect a new platform and it finds that
the concerned platform is not compatible to itself. Incase this happens, it
places a request to every connected worm describing system specifications, as
well as IP and port specification. This is relayed with a decreased TTL to other
connected objects causing a "broadcast". The first worm that can provide the
binary will respond connecting to the IP (and port) immediately. Any further
connects which occur within till TTL expiry should be refused (I had a small
addendum to this idea.. incase the new connect responds with a newer timestamp,
request for updation should be the next logical step).
The documentation again leaves the selection of the TTL and number of retries
to us. Packets transmitted via the wormnet structure are to be encrypted. The
connection structure is arbitrary and is only limited by limits defined in the
specifications. Connections are initiated from child to parent bypassing firewall
and other monitoring software. Each child is equipped with a short "wormnet
history" list that allows it to connect to alternative parents. This is
necessary, as the original parent may have reached a saturation limit with respect
to the number of connections.
An example wormnet:
P1 ..................... C1 --- P2
| \ |
| \ |
| \ |
| \ |
C2 C3 C4
C2,C3 and C1 are all originally P1"s children. Assuming max connect limit to be
2, C1 is not able to connect back to P1. It looks up in the history list and finds
The worm has a database of exploits organised according to:
1) The success rate - The exploits that succeed most frequently are applied
2) Local and Remote - Helps to form both a pre and post infection strategy
for the worm.
Actual victims chosen for attack are decided by monitoring active network connections.
The server to be targeted are picked from this list randomly and incase it is
successfully infected, the server is marked as infected.
The wormnet"s integrity is critical to its survival. If someone wants to neutralize
the structure, he could hypothetically introduce false code into the structure.
To prevent from people other than the originator from doing this, a proper cryptographic
signing mechanism is built into every aspect of the worm.
Other features have to be built to prevent reverse engineering of the worm
body, the protocols used for communication and detection techniques used by
the worms to check for themselves.
Virus writers have used the technology of polymorphism for quite a while now.
It essentially defeats conventional scanning based on identifying repetetive
code structures. The poly engine used in Samhain was simple and it"s objective
was to make sure that the decryptor (detonator) would be different in each case.
Surprisingly with respect to the above, things are more exciting in the Win
Welcome to Metamorphism
This is the latest development in the Win 32 world. Incase of poly engines,
only the decryptor (or a part of the code) changed. A meta engine would work
in this fashion:
Input code -> Engine -> output code completely mutated but similar in
This technology has now been implemented in actual working viruses (Eg. Win32.Evol)
Bugs having this kind of capability would have to have a complete disassembler
built into them. They would be extremely resistant to analysis and would cause
great problems to remove. This technology is now in the infancy stage. Many
virus writers are working on it.
This part of the Samhain blueprint is only limited by one"s own imagination.
The wormnet can be used to setup a distributed computer working to crack passwords,
install backdoors etc.
An interesting idea given by the team is to first test target system with a
blank. It means that instead of sending the actual worm with say a payload or
something, we should first test if the environment is safe for the actual worm.
This again ensures that incase of a "mishap" (say the sysadmin comes
to know of our efforts), the wormnet can recover.
A few months back, a virus called I-Worm.Hybris was released
by Vecna. Eugene Kaspersky (the author of AVP antivirus) has said that Hybris
is the most complex windows virus written ever. The virus again features a plugin-based
upgradation of its abilities and is extremely resistant to reverse engineering.
The plugins for I-worm.hybris can be created and introduced into the worm"s
network after getting electronically "signed" by the controller (Vecna).
A strong RSA based algorithm is used for the encryption wrapper. The virus
writer has given out a full development kit (he calls it the Muazzin SDK ;-)
for people to develop plugins.
Hybris is totally different from the current wave of worms like the Code.Blue/Red
etc and Nimda.. which are fast burning and
usually don"t last much.
Read more about it at
Well that"s it for this time. I wish to thank a friend who provided valuable
inputs to this document. He wishes to remain anonymous.
Some interesting links
(Link to the Samhain document)
(Homepage of Silvio Cesare, lot of information on Linux viruses)
Mentioned in the documentation of Samhain, it is one of the best resources
for "extremely ugly code that can run in DOS, [ba]sh, csh, perl etc and
can be compiled with C in the same time "
(An excellent article on Win 32 viruses by Eugene Kaspersky et.al)
(Check out the zines. 29A needs no introduction ;-)
(A master repository of vx related links)
(My article about the technique of tunneling which could be used both by viruses
and anti-viruses. Though not relevant to the Win32 world, It"s interesting reading
for those trying to understand the old school.)
(Written by my good friend, Ayan Chakrabarti, Guptachar is a full remote adminstration
tool. The package comes w/ source code for your study and analysis. It"s much
easier to follow than stuff like BO2k, offers client side independence. This
means that you can access the server from any platform that has a webbrowser)