What kind of information can be derived about the person who developed this tool? For example, what is their skill level?

When was the program written?

The earliest it could have been written is May 2000. We can say this because the Jolt2 exploit (which has been cut and pasted into this program) was written then (according to the jolt2.c source code). However, as a patch to prevent the Jolt2 exploit was released by Microsoft, this tool was probably written close to the jolt2 release date to exploit the window of opportunity, between vunerability announcement and patches occuring.

It is a given that many Windows users do not apply security patches (probably many do not even know what a security patch is). However, if I was writing an exploit tool, I would choose the very latest vunerabilities to include, not ones two years old. The existance of the Jolt 2 DOS attack has helped us to date when this tool was written.

On what system was the program written?

The program was compiled on a Slackware 3.1 (libc5) system. This was established in the analysis. It is most likely that the tool was written on this system as well. But we shall test this hypothesis. From the signal(2) manpage

       The  original  Unix  signal()  would  reset the handler to
       SIG_DFL, and System V (and the Linux kernel  and  libc4,5)
       does  the same.  On the other hand, BSD does not reset the
       handler, but blocks new  instances  of  this  signal  from
       occurring  during  a  call  of  the  handler.   The glibc2
       library follows the BSD behaviour.

As the code exhibits an excess of calls to signal, it would seem that the programmer was having problems with the System V (libc5) behaviour of resetting signal handlers. This implies that the program followed the test - update code - test cycle on a libc5 system, rather than on a glibc2 system. Hence we can say that it is likely that the program was written on the system it was compiled on.

Why use a Slackware 3.1 system in 2000?

We have established that the programmer wrote the tool in 2000 (possibly early 2001), and used a Slackware 3.1 system for development. Slackware 3.1 was released in 1996. Why use a four year old distribution? Schools are places lagging behind in technology, due to being typically under funded. Many linux user groups lack the funds for later hardware, and can typically have old software running on old hardware. If you had a 486sx25 with no cdrom drive running Slackware 3.1, would you be in a hurry to install a later version one floppy at a time?

While we have no definite answers to this question, we do have possibilities. The programmer possibly lacks the funds for up to date hardware and/or software. Perhaps the programmer doesn't own their own computer, but uses one at a local linux user group. Perhaps the programmer is still in school?

Why write the program anyway?

In early 2000, distributed denial of service tools such as trinoo and the tribe flood network were being vehemently covered by the media. It appears that these were inspirations for the construction of this tool, considering the similarities (agent / handler model, handler has range of possible DOS attacks, handler has on demand backdoor). Was this tool written to be widely used, or was it written to impress peers? Given that this tool hasn't be reported before (that could be found), we can assume that it was written for prestige, or was a serious attempt that was abandoned early in its development. Although the tools has few feature and several bugs, it feels complete, due to the lack of "scaffolding" for further building. So the conclusion is that this tool was inspired by the success of tools like trinoo and TFN, written to impress peers, and then abandoned.

What is the programmer's skill level

The skill level of the programmer is that of a novice programmer. Much code has been cut and pasted from other projects. This is evidenced by the inconsistent calls to rand() and random(), and a general mismatch of coding style, an example of which is shown below:

sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW);
if (sockfd == -1) {
    return 0;
}
. . .

sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW);
if (sockfd > 0) {
   . . .
}

Further evidence of the programmers novice status is due to the unnessary use of global variables.

The programmer has a poor understanding of the concept of pointers. Consider:

   memcpy(hostname, cmd_buffer, 255);
   for (i = 0; i < 255; i++) {
       hostname[i] = hostname[i + 9];
   }

We ignore the reading past the end of the buffer (further evidence of the programmer's novice status). This could be written more effectively (without the double copying) as:

   memcpy(hostname, cmd_buffer + 9, 255 - 9);

Poor understanding of the system() call. Executing a shell command is achieved by using sprintf to construct a string to execute with the template /bin/csh -f -c "%s" , then passing the result to system(). The "/bin/csh -f -c" is superfluous, as the manpage for system() clearly status that commands are executed with "sh -c".

However, the programmer is not an idiot. The method of tunneling data in IP datagrams with a protocol field of 11, is not common in the widely available blackhat tools. The programmer either thought of this themselves, or got a suggestion for this from one of their peers. Either way, to create a working tools requires more intelligence than that of the average script kiddie.

Other oddities

The password for the remote shell is "SeNiF". Is there more to this than just spelling "fines" backwards? Note the alternating caps, which was as popular in past years as 1337 sP33k is today. Senif can be used as a surname, perhaps the name of a friend or enemy?

For the DNS attack, SOA queries for the following domains are made

com
net
edu
org
de Germany
usc.edu University of Southern California
es Spain
gr Greece
ie Ireland

Why the contrast between country codes for countries in Europe, and an US university? A theory on this is that the programmer resides in Europe, hence the familiarity with the European country codes, and has friends studying at usc.edu.

Summary

The program was written in 2000, being inspired by the media attention of the trinoo and TFN DDOS tools. The programmer is most likely young with limited personal resources. The programmer has a low skill level and resorts to the "cut and paste" style of programming. The programmer possibly resides in Europe and socialises with other blackhat style programmers. The programmer is male, overweight and has no social life other than his computer. He wears glasses and was bullied throughout school. He uses computers as a way of getting back at the world which has maligned him. You decide where reality steps aside and Hollywood takes over.

What advancements in tools with similar purposes can we expect in the future?

As distributed denial of service tools advance, we are likely to see an increased effort to hide the network communication between agent and handlers. We currently have communication tunneled through ICMP and DNS packets (see the phrack paper on Loki). Increases in steganography as applied to network communication are likely.

Currently the distributed networks are used to wage DOS attacks. As new vunerabilities are found, tools have to be updated and redeployed. Stacheldraht has the ability to update clients on command. This is likely to be standard in the future. An added possibility is that clients could be sent the latest vulnerability, and they could automatically add that to themselves (dynamically loaded library, modifying running instance in memory).

At the moment hosts are compromised and the client installed manually (or with a script). A future advancement could be that the distributed network itself searches for more hosts to increase its size.

Once a distributed network is in place, it can be used for more than just DOS attacks. Distributed password cracking is one example. It is certain that creative blackhats are currently thinking up more possibilities.