Darknet - The Darkside

Don`t Learn to HACK - Hack to LEARN. That`s our motto and we stick to it, we are all about Ethical Hacking, Penetration Testing & Computer Security. We share and comment on interesting infosec related news, tools and more. Follow us on Twitter, Facebook or RSS for the latest updates.

14 December 2006 | 6,107 views

the Art of Virology 02h

Cybertroopers storming your ship?

This is the one and only (and first article) which will present you the source code of a virus on Darknet, and a lame one too :)

Theory again…

First should mention a couple of things which haven’t been specified till now. This virus is going to be an appending virus:

An appending virus is a virus that writes all of his code to the end of the file, after which it writes a simple jump to the code at the start of the file

I will use this method, for first in the virus i’ll present here, maybe later I will adopt another technique as EPO:

Entry Point Obscuring is a method which inserts the entry point of the virus somewhere in the host file, where it can do an interception of the code for later replication, but not at the start.

…but definitely not overwriting viruses:

An overwriting virus has a simple routine to overwrite the host file, thus being easily detected because of the fact that infected files in 99% of cases won’t run anymore

Back to reality

So my first virus is called infant-a, because it only does a single thing (like an infant); also it is a DOS COM infecter, so you won’t have much trouble with it. What to say more, the source if fully commented, and if you have read the book I have suggested you in the 00h article than you won’t have any problems in understanding it.It is not detected by Avira anti virus, check it with other anti viruses and tell me if it found and under which name, oh yeah Kaspersky doesn’t find it either.

BTW: don’t compile and infect other files (computers) with it because I will look lame not you

The brilliant (and simple code) follows: infant-a

How to play with it?

Everything goes in 3 steps, or 2 depends on you…

1st step – dummy com files

Enter in DOS mode (run cmd from Windows run) and write the following lines:

2nd step – compile the virus

For this one you need TASM & TLINK, google to get them; if you have them enter the following lines supposing infant-a.asm is the virus:

3rd step – optional

Download DOSBox, install it and use the following commands (after starting DOSBox):

Let’s play

And now you can start the virus and see how it infects one file per run, the dummy COM files should have 6 bytes length, and after infection 161, you can’t miss them…

Are we done already?

Well 02h is over, but 03h is there waiting to be written; whats next? infant-b of course which will have:

  • An encryption method (XOR)
  • A traversal infection (dotdot [..] method)
  • More infections per run
  • Stealth?

Till then have fun with infant-a, and see you as soon as possible (if anybody reads this series).


14 December 2006 | 16,902 views

Hackers Break Into Water Processing Plant Network

When things like this happen it’s kinda of scary, like a while back when someone managed to get into a highly secure power station network through a stupid contractors laptop that was connected to the net via dialup and to the uber ‘secure’ power station LAN.

An infected laptop PC gave hackers access to computer systems at a Harrisburg, Pa., water treatment plant earlier this month.

The plant’s systems were accessed in early October after an employee’s laptop computer was compromised via the Internet and then used as an entry point to install a computer virus and spyware on the plant’s computer system, according to a report by ABC News.

Similar to the power station incident eh?

Can’t people just take a little care and lock down all the machines on the network, install Firefox, install Anti-virus, enable Windows updates etc.

The incident is under investigation by the FBI, but no arrests have been made in the matter, said Special Agent Jerri Williams of the FBI’s Philadelphia office. The attackers are believed to have been operating outside of the U.S.

Williams said that the hackers do not appear to have targeted the plant. “We did not believe that they were doing it to compromise the actual water system, but just to use the computer as a resource for distributing e-mails or whatever electronic information they had planned,” she said.

It could have had some serious consequences on the water processing system.

Still, the FBI is concerned that even without targeting the system itself, this malicious software could have interfered with the plant’s operations, Williams said.

Had the breach targeted the water plant, it could have had grave consequences, according to Mike Snyder, security coordinator for the Pennsylvania section of the American Water Works Association. “It’s a serious situation because they could possibly raise the level of chlorine being injected into the water… which

Seems like security is still not as important as it should be.

Source: ComputerWorld

13 December 2006 | 8,432 views

Backframe (Formerly Backweb) JavaScript Attack Console

There has been a recent release of Backframe (Formerly Backweb) Attack Console.

Backframe Attack Console was started as an experiment to create a full featured attack console for exploiting web browsers, web users and remote applications. Those who are familiar with XSS Proxy or even BEEF might already be familiar with the core principles of the project.

The console is based on simple client-server interaction. Both parts are required for successful operation. The server, also known as the attack channel, provides functionalities for establishing bi-directional communication with remote clients. On the other hand, the console is responsible for interacting with the channel providing the necessary toolkit for launching attacks against these clients.

The result of these core principles is an easy to use and understand web-client-oriented attack framework that keep the data, the presentation layer, and the underlying logic apart. This design is known as “the separation of concerns model”. This is highly effective practice which allows to easily extend upon the core elements.

Right now it is quite stable and it should work well with attack channels similar to the one described here:

Persistent Bi-directional Communication Channels

Check the AttackAPI project for the attack channel complete source code.

More information here:


You can try out Backframe here:

Backframe Application

11 December 2006 | 5,557 views

Massive Data Theft Operation Uncovered

UK Police have uncovered a fairly massive data theft operation with a total close to 8,500 victims.

It’s quite worrying when things like this are uncovered as if 1 is uncovered or discovered…imagine how many aren’t found out about, just like exploits.

British electronic-crime detectives are investigating a massive data theft operation that stole sensitive information from 8,500 people in the U.K. and others in some 60 countries, officials said Tuesday.

In total, cybercriminals targeted 600 financial companies and banks, according to U.K. authorities, who have worked over the past week to identify and notify victims.

Through intelligence sources, U.K. police were given several gigabytes of data — around 130,00 files — that came from a server in the U.S., said Charlie McMurdie, detective chief inspector for the Specialist Crime Directorate e-Crime Unit of the London Metropolitan Police. Most of the data related to financial information, she said.

Several GIG of data, that’s a hell of a lot of text.

They were using a pretty basic program though, haxdoor.

The data was collected by a malicious software program nicknamed Haxdoor that infected victims’ computers. Some 2,300 machines were located in the U.K. McMurdie said.

Haxdoor is a powerful program that can collect passwords and send them to another e-mail address plus disable a computer’s firewall, among other functions, according to a description posted on security vendor F-Secure Corp.’s Web site. Symantec Corp., another security company, wrote it first detected Haxdoor in November 2003.

Computers can get infected with Haxdoor if they don’t have security patches or up-to-date antivirus software. London police said it’s believed many victims were infected through instant message programs.

Nice to see the good guys also using technology to parse the data and locate victims.

Metropolitan police experts built a special program to search through the data and identify victims, she said. The data contained information such as logins and passwords for major Web sites such as eBay Inc., Amazon.com, BT Group PLC and Pipex Internet Ltd., a U.K. Internet service provider.

In some instances, Haxdoor employed a screen-capture function to obtain information, McMurdie said.

Source: Infoworld

08 December 2006 | 7,151 views

NMAP 4.20 released

This is just a simple warning to all NMAP users out there. If you’re registered on the announcement mailing list you already now this, otherwise, heads up.

NMAP 4.20 has been released with something that looks promising. 2nd generation OS detection. The changelog is available here.


08 December 2006 | 9,614 views

Linux Reverse Engineering Hacker Challenge

The first round results of the Linux Reverse Engineering Hacker Challenge are out!


It was expected that an intermediate hacker with Linux experience should be able to defeat the protection(s) in less than 10 hours. Participants may earn up to $4100 USD.

A total of 93 individuals registered to participate in the first Hacker Challenge. Individuals were compensated for defeating the protection and submitting a report that summarized how the defeat was executed. All individuals who defeated the protection and submitted a sufficient report were compensated with $500, while a partial defeat which was accompanied by a complete report was compensated with $200 (all payments in US dollars, with payments made anonymously via PayPal). Special payments were made for the first three successful defeats, as well as the top-three highest-quality reports

The competition is apparently run by a US based company anonymously and all payouts are made via PayPal.

We are a US company performing security testing and security metric research. This activity is being funded by a component of the US government.

The purpose of this project is to evaluate the effectiveness of software anti-piracy protections. The results of this effort will be used to improve our protection measures.

Perhaps something to do with the RIAA or DMCA as they are evaluating anti-piracy measures.

This is a security testing activity. All software and software anti-piracy measures were developed exclusively for use in this effort. No commercial protections were used in the development of this test.

Do watch out for the next competition from Hacker Challenge!

07 December 2006 | 5,016 views

(IN)SECURE Magazine ISSUE 1.9 – December 2006

(IN)SECURE Magazine is a freely available digital security magazine discussing some of the hottest information security topics. It can be distributed only in the form of the original non-modified PDF document.

The 9th issue of (IN)SECURE magazine was recently released, in this issue you can find the following:

  • Effectiveness of security by admonition: a case study of security warnings in a web browser setting
  • Interview with Kurt Sauer, CSO at Skype
  • Web 2.0 defense with AJAX fingerprinting and filtering
  • Hack In The Box Security Conference 2006
  • Where iSCSI fits in enterprise storage networking
  • Recovering user passwords from cached domain records
  • Do portable storage solutions compromise business security?
  • Enterprise data security – a case study
  • Creating business through virtual trust: how to gain and sustain a competitive advantage using information security

You can get it at www.insecuremag.com or directly here:

ISSUE 1.9 (December 2006) – DOWNLOAD

You can find the complete archive online HERE, it’s well worth a look.

05 December 2006 | 8,084 views

Metasploit 3.0 Beta 3 Released

The Metasploit Framework is an advanced open-source exploit development platform. The 3.0 tree represents a complete rewrite of the 2.0 codebase and provides a scalable and extensible framework for security tool development. The 3.0 Beta 3 release includes support for exploit automation, 802.11 wireless packet injection, and kernel-mode payloads.

Windows users are now presented with a RXVT console and an updated Cygwin environment, which greatly improves the usability of the 3.0 interface on the Windows platform.

The Metasploit Web Interface is still in development, but this release includes a preview of what the end functionality will look like. The web interface provides a “webtop” interface for interacting with the framework and uses aynschronous javascript to provide live searching. A early version of Metasploit IDE is also included with the web interface.

Downloads for all platforms can be found here:

The latest version can be pulled directly from Subversion:

Unix users may need to install the openssl zlib and dl ruby modules for the Framework to load. If you are using Ubuntu you will need to run the following commands:

Unix users who wish to try the new web interface will need to install the ‘rubygems’ package and the ‘rails’ gem. Please see www.rubyonrails.com for more information and platform-specific installation instructions.

Users of other distributions or Unix flavors may want to grab the latest version of ruby from www.ruby-lang.org and build it from source. We highly recommend using Ruby version 1.8.4 or newer.Windows users will need to exit out of any running Cygwin-based applications before running the installer or using the Framework. The old 3.0 installation should be uninstalled prior to installing and using this version.

The release packages include Subversion repository information allowing you to synchronize your Beta 3 installation with the live development tree. The Windows installer includes a “MSFUpdate” menu item that uses Subversion to download the latest updates.Unix users will need to install the Subversion client change into the framework directory and execute ‘svn update’.

On Unix systems, Subversion will complain about the self-signed certificate in use at metasploit.com. Please verify that the fingerprint matches the one below before accepting it:

– Hostname: metasploit.com
– Valid: from Jun 3 06:56:22 2005 GMT until Mar 31 06:56:22 2007 GMT
– Issuer: Development The Metasploit Project San Antonio Texas US
– Fingerprint: 1f:a2:8e:ad:14:57:53:75:b7:ab:de:67:e8:fa:17:49:76:f2:ee:ad

04 December 2006 | 6,986 views

Internet Explorer 7 (IE7) Vulnerability Hits the Streets

This was a while back, but with Microsoft’s security record it’s pretty much inevitable..

Even before release (as with Vista) flaws were found.


A vulnerability has been discovered in Internet Explorer, which can be exploited by malicious people to disclose potentially sensitive information.

Please use the test below, to see an example of how this vulnerability can be exploited, and also to determine whether or not your browser is vulnerable.

Test Case / Demonstration

The test will try to read content from http://news.google.com/ in the context of your browser.

Follow the source link below for the test.

So much for the “You wanted it easier and more secure” slogan found on Microsoft’s IE Website.

Source: Secunia

02 December 2006 | 19,298 views

Writing Worms for Fun or Profit

0x00: Preface

Media, kindly supported by AV “experts”, drawn apocalyptical vison of desctruction caused by stupid M$ Outlook / VisualBasic worm, called “ILOVEYOU”. Absurdal estimations – $10M lost for “defending the disease”, especially when you take a look at increasing with the speed of light value of AV companies market shares, made many people sick. Lame VBS application that isn’t even able to spread without luser click-me interaction, and is limited to one, desk-end operating system… Worm that sends itself to people in your addressbook, and, in it’s original version, kills mp3 files on your disk [1].

And you call it dangerous? Stop kidding.

Over year ago, with couple of friends, we started writing a project, called ‘Samhain’ (days ago, on packetstorm, I noticed cute program with same name – in fact it’s not the same app, just a coincidence ;). We wanted to see if it’s difficult to write deadly harmful Internet worm, probably much more dangerous than Morris’s worm. Our goals:

  • 1: Portability – 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).
  • 2: Invisibility – worm must implement stealth/masquerading techniques to hide itself in live system and stay undetected as long as it’s possible.
  • 3: Independence – worm must be able to spread autonomically, with no user interaction, using built-in exploit database.
  • 4: Learning – worm should be able to learn new exploits and techniques instantly; by launching one instance of updated worm, all other worms, using special communication channels (wormnet), should download updated version.
  • 5: Integrity – single worms and wormnet structure should be really difficult to trace and modify/intrude/kill (encryption, signing).
  • 6: Polymorphism – worm should be fully polymorphic, with no constant portion of (specific) code, to avoid detection.
  • 7: Usability – worm should be able to realize choosen mission objectives – eg. infect choosen system, then download instructions, and, when mission is completed, simply disappear from all systems.

With these seven simple principles, we started our work. This text describes our ideas, concepts and implementation issues. It is NOT the terrorist’s handbook, and has not been written to help people to write such piece of code on their own. It’s written to show that very serious potential risk, which we virtually can’t avoid or stop, isn’t only hypotetical. Code provided here is partial, often comes from first, instead of most recent, Samhain release and so on. But remember – working model has been written. And this model is deadly dangerous engine, which can be used to very, very bad things. Probably we aren’t the first people who thought about it and tried to write it, that’s what make us scared…

Winter 1998, three bored people somewhere in the middle of Europe.

Sit and relax.

0x01: Portability

This is probably the most important thing – we don’t want code that can run only on Windows, Linux or Solaris, or – worse – can run only on x86. The task is quite easy to complete if you decide to spread your code in platform-independent form. How could it be achieved? Well, most of systems have C compiler :) So we might spread worm in source code, with simple decryptor (let’s say it will be shell script).

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. Wormnet details have been described in section 0x04. Anyway, binary will contain appended source code, to make futher infections possible within standard procedure. Infection scheme is described in section 0x03.

First version of our decryptor looked like this:

It used very simple (per-byte increments) “encryption” for source code with custom increment value (decryptor has been modified accordingly to choosen value – \x01, \x02, \x03 and \x04 are changed by encryptor routine). Also, this constant decryptor has been every time re-written using simple polymorphic engine (see section 0x06) to avoid constant strings. Later, we modified encryption routine to something little bit stronger (based on logistic equation number generator in chaotical window) – in fact, it only makes it more difficult to detect in inactive form.

As you can see, this decryptor (or it’s early version shown above) isn’t highly-portable – what if we don’t have bash, compiler, gzip or such utilities? Well, that’s one of reasons we’ve decided to join worms in wormnet – if sent code won’t connect back to parent and report itself, host is not marked as infected, and wormnet is asked for pre-compiled binary for given architecture (assuming we already infected this architecture somewhere in the world, and we had needed utilities, or we’re running the same architecture as infected host).

NOTE: For writing extremely ugly code that can run in DOS, [ba]sh, csh, perl etc and can be compiled with C in the same time, please refer IOCCC archives [2].

Sebastian wrote virus code that can spread both on Windows/DOS platform with C compiler and Unix systems with no modifications nor any interaction. It does cross-partition infections and installs itself as compiler trojan (modifying include files to put evil instructions in every compiled source). It is called Califax and has been developed while writting Samhain, as an excercise to prove that such cross-system jumps are possible. I don’t want to include Sebastian’s sources with no permission, all I want to say
is he did it within 415 lines of c code :) Califax hasn ‘t been incorporated within Samhain project, as we don’t want to infect Winbloze for ideological reasons :P

0x02: Invisibility

After breaking into remote system, worm not always have root privledges, so first of all, we wanted to implement some techniques to hide it, make it look-like any other process in system, and make it hard to kill until there’s a chance to gain higher privledges (for details on system intrusion, please refer section 0x03). Also, we made sure it’s really hard to debug/trace running or even inactive worm – please refer section 0x05 for anti-debug code details.

Our non-privledged process masquerading code consists of following parts:

  • masquerading: walk through /proc, choose set of common process names and
    change your name to look just like one of them,
  • cyclic changes: 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

Our goal is to make almost impossible (with common tools) to ‘catch’ process, as all /proc parameters (pid, exe name, argv[0]) are changing, and even if one of them is catched, we have ‘mirror’ project. Of course, at first we should avoid such attempts by camouflage. This comment comes from libworm README for Unices:

— snip from README —

a) Anti-scanning routines

Following routines are provided to detect anti-worm stuff, like ‘kill2’
or anything smarter. You should use them before fork()ing:

int bscan(int lifetime);

bscan performs ‘brief scanning’ using only 2 childs. Lifetime should
be set to something about 1000 microseconds. Return values:
0 – no anti-worm stuff detected, please use ascan or wscan.
1 – dumb anti-worm stuff detected (like ‘kill2’); use kill2fork()
2 – smart (or brute) stuff detected, wait patiently

int ascan(int childs,int lifetime);

ascan performs ‘advanced scanning’ using given number of childs
(values between 2 and 5 are suggested). It tests environment
using ‘fake forkbomb’ scenario. Results are more accurate:
0 – no anti-worm stuff detected (you might use wscan())
1 – anti-worm stuff in operation

int wscan(int childs,int lifetime);

wscan acts like ascan, but uses ‘walking process’ scenario. It
seems to be buggy, accidentally returning ‘1’ with no reason,
but it’s also the best detection method. Return values:
0 – no anti-worm stuff detected
1 – anti-worm stuff in operation

int kill2fork();

This is aletrnative version of fork(), designed to fool
dumb anti-worm software (use it when bscan returns 1).
Return value: similar as for fork().

b) Masquerading routines

These routines are designed to masquerade and hide current

int collect_names(int how_many);

collect_names builds process names table with up to
‘how_many’ records. This table (accessible via
‘cmdlines[]’ array) contains names of processes in
system; Return value: number of collected items.

void free_names();

this function frees space allocated by collect_names
when you don’t need cmdlines[] anymore.

int get_real_name(char* buf, int cap);

this function gets real name of executable for current
process to buf (where cap means ‘maximal length’).

int set_name_and_loop_to_main(char* newname,char* newexec);

this function changes ‘visible name’ of process to newname
(you may select something from cmdlines[]), then changes
real executable name to ‘newexec’, and loops to the
beginning of main() function. PID will be NOT changed.
Set ‘newexec’ to NULL if you don’t want to change real exec
name. Return value: non-zero on error.

Note: variables, stack and anything else will be reset. Please
use other way (pipes, files, filenames, process name) to
transfer data from old to new executable

int zero_loop(char* a0);

this function returns ‘1’ if this main() code is reached for
the first time, or ‘0’ if set_name_and_loop_to_main() was
used. Pass argv[0] as parameter. It simply checks if
real_exec_name is present in argv[0].

For more details and source code on architecture-independent non-root process hiding techniques, please refer libworm sources [3] (incomplete for now, but always something).

This routines are weak and might be used only for short-term process hiding. We should as fast as possible gain root access (again, this aspect will be discussed later). Then, we have probably the most complex aspect of whole worm. Advanced process hiding is highly system-dependent, usually done by intercepting system calls. We have developed source for universal hiding modules on some systems, but it not working on every platform Samhain might attack. Techniques used there are based on well-known kernel file and process hiding modules.

Our Linux 2.0/2.1 (2.2 and 2.3 kernels weren’t known at the time ;) our module used technique later described in “abtrom” article on BUGTRAQ by (Sat, 28 Aug 1999 14:40:31) to intercept syscalls [4]. Sebastian wrote stealth file techniques (to return original contents of eventually infected files), while I developed process hiding and worm interface. Module intercepted open, lseek, llseek, mmap, fstat, stat, lstat, kill, ptrace, close, read, unlink, write and execve calls.

For example, new llseek call look this way:

In this case, we wanted to skip samhain code loader at the beginning of file. is_happy() function has been used to identify infected files. Unfortunately, it also has to check length of this loader – remember, it’s dynamically generated. This is code from is_happy() used to determine this size from our decryptor routine:

Worm isn’t spreading across the filesystem widely, so the problem doesn’t affect many files – only some executables called in boot process – to make sure we’re always resident. Process hiding is quite generic:

Also, we have to hide active network connections for wormnet and sent/received wormnet packets to avoid detection via tcpdump, sniffit etc.

That’s it, nothing uncommon. Similar code has been written for some other platforms. See my AFHaRM or Sebastian’s Adore modules for implementation of stealth techniques [5].

0x03: Independence + 0x04: Learning

Wormnet. The magic word. Wormnet is used to distribute upgraded Samhain modules (eg. new exploit plugins), and to query other worms for compiled binaries. Communication scheme isn’t really difficult, using TCP streams and broadcast messages within TCP streams. Connections are persistent. We have four types of requests:

  • infection confirmation: done simply by connecting to parent worm
    if infection succeded (no connection == failure),
  • update request: done by re-infecting system (in this case, already installed
    worm verifies signature on new worm when receiving request, then swaps
    process image by doing execve() if requesting binary has newer timestamp),
    then inheriting wormnet connections table and sending short request to
    connected clients, containing code timestamp.
  • update confirmation: if timestamp sent on update request is newer than
    timestamp of currently running worm, it should respond with ‘confirmation’,
    then download new code via the same tcp stream; then, it should verify
    code signature, and eventually swap it’s process image with new exec, then
    send update request to connected worms.
  • platform request: by sending request to every connected worm (TTL
    mechanism is in use) describing machine type, system type and system
    release, as well as IP and port specification; this request is sent
    (with decreased TTL) to other connected wormnet objects, causing
    wormnet broadcast; first worm that can provide specific binary, should
    respond connecting to given IP and port, and worm that sent platform
    request should accept it (once). Any futher connects() (might happen
    till TTL expiration) should be refused. After connecting, suitable
    binary should be sent, then passed to infection routines. Worm should
    try first with TTL approx 5, then, on failure, might increase it by 5
    and retry 3-5 times, we haven’t idea about optimal values.

Packets are “crypted” (again, nothing really strong, security by obscurity) with key assigned to specific connection (derived from parent IP address passed on infection). Type is described by one-byte field, then followed by size field and RAW data or null-terminated strings, eventually with TTL/timestamp fields (depending on type of message).

Wormnet connections structure looks arbitrary and is limited only by max per-worm connections limit. Connections are initiated from child to parent worm, usually bypassing firewall and masquerading software.

On infection, short ‘wormnet history’ list is passed to child. If parent has too many wormnet connections at time, and refuses new connection, child should connect to worm from the history list.

What about exploits? Exploits are modular (plugged into worm body), and divided in two sections – local and remote. We wanted to be platform independent, so we focused on filesystem races, bugs like -xkbdir hole in Xwindows, and inserted just a few buffer overflows, mainly for remote intrusion (but we decided to incorporate some bugs like remote pine mailcap exploit and so on… Code was kind of shell-quoting masterpiece ;)

Pine mailcap exploit (it has been already fixed after my BUGTRAQ post, but in late 1998 it was something new and nice):

Message body contained code to be executed (shell-script to connect, download and run worm, then kill any evidence). Yes, this exploit sucks – as it required some kind of user interaction (reading e-mail), but is just an example.

Both remote and local exploits are sorted by effectiveness. Exploits that succed most of the time are tried first. Less effective ones are moved at the end. This list is inherited by child worms.

Oh, spreading. Victims are choosen by monitoring active network connections. With random probability, servers are picked from this list and attacked. In case of success, server is added to ‘visited’ list – these are not attacked anymore. In case of failure, server is not attacked until new version of worm is uploaded. Of course, internal servers list is finite and sometimes server might be attacked again (if it’s not our child and it isn’t currently connected), but who cares, attempt will be ignored or upgrade procedure will happen, depending on timestamps.

This code is used to qualify host (obtained from network stats):

0x05: Integrity

The most important thing in worm’s life is not to get caught. We have to be sure it’s not easy to trace/debug us – we want to make reverse-engineering even harder. We don’t want to expose our internal wormnet protocols, communication with kernel module and detection techniques used by worms to check for themselves, etc. Four things:

  • – hide everything: see section 0x02.
  • – hash, crypt, scramble: see sections 0x01, 0x04.
  • – don’t let them caught you: see section 0x02.
  • – avoid debugging even if we cannot hide!

We used several anti-debugger techniques, including application-dependent (bugs in strace on displaying some invalid parameters to syscalls, bugs in gdb while parsing elf headers, ommiting frame pointer, self-modyfing code and so on), as well as some universal debugger-killer routines called quite often (they aren’t really time-expensive). This is one of them:

As I told before, worm modules were signed. First, using simple signatures, then using simple private key signing (not really difficult to crack, as key was relatively short, but for sure too difficult for amateurs). This made us sure we’re going to replace our worm image with REAL worm, not dummy anti-worm flare.

0x06: Polymorphism

Polymorphic engine was quite simple – designed to make sure our decryptor will be different every time. As it has been written in shell language, it was pretty easy to add bogus commands, insert empty shell variables, add \ and break contents, or even replace some parts with $SHELL_VARIABLES declared before. Getting original content is not quite easy, but of course, all you have to do is to imitate shell parsing of this decryptor to get original contents, then you’ll be able to identify at least some common code.

Code adding \ to decryptor looks like:

0x07: Usability

It’s stupid to launch worm designed eg. to steal secret information from specific host, because we have no idea if it will work fine, and won’t be caught. If so, it might be debugged (it’s made to be hard to debug, but, as every program, it’s not impossible to do it, especially if you’re able to separate worm code). Instead, we should be able to release ‘harmless’ worm, then, when we’re sure it accessed interesting host and haven’t been caught, we might send an update, which will try to reach destination worm, replace it with our evil code, then shut down every worm it can access via wormnet (by sending signed update, that will send itself to other worms, then shut down).

Maybe it isn’t the perfect solution, but in fact it’s probably much safer than inserting even generic backdoor code by default.

0x08: What happened then?

That’s it, the Samhain project, fit into approx. 40 kB of code. What happened to it? Nothing. It hasn’t been ever released, and I never removed restrictions from lookup_victim() and infect_host() routines. It’s still lying on my hard drive, getting covered with dust and oblivion, and that’s extacly what we wanted.

I stopped developing new code and testing it in January, 1999, with Samhain 2.2 and approx. 10000 lines of code. Wojtek Bojdol has been developing his much more advanced wormnet and system infection/monitoring code till February or March, but I haven’t found enough time to incorporate his sources within mainstream source tree. Then, we removed our repository from networked server we used to exchange ideas. I gradually published some bugs used in exploit database to BUGTRAQ, some of them (especially those not discovered by me) we kept for ourselves.

The story ends. Till another rainy day, till another three bored hackers.

You may be sure it will happen. The only thing you can’t be sure is the end of next story.

0x09: References

[1] ILOVEYOU worm:
Dramatical headlines:
+ http://www.cnn.com/2000/TECH/computing/05/04/iloveyou.03/
Technical analysis:
+ http://www.securityfocus.com/templates/article.html?id=30
Source of “ILOVEYOU” worm:
+ http://packetstorm.securify.com/viral-db/love-letter-source.txt

[2] International Obfuscated C Code Contest archives:
+ http://www.ioccc.org

[3] Libworm – unprivledged process hiding techniques:
+ http://lcamtuf.na.export.pl/pliki/libworm.tgz

[4] “yet another article about stealth modules in linux”
+ http://www.securityfocus.com

[5] Advanced File Hide and Redirect Module (in fact, old and lame ;)
+ http://lcamtuf.na.export.pl/pliki/afharm.zip
+ ???

Again this is an old article but it’s a good one, written by Michal Zalewski and edited by Darknet