Child pages
  • CERT Incident Note IN-99-07: Distributed Denial of Service Tools

Pages in the Historical section of this site are provided for historical purposes, they are no longer maintained. Links may not work.

Skip to end of metadata
Go to start of metadata
The CERT Coordination Center publishes incident notes to provide information about incidents to the Internet community.

Distributed Denial of Service Tools

Updated: January 15, 2001 (changed RFC 2267 to RFC 2827/BCP 38)
Updated: December 8, 1999 (added DSIT Workshop paper and IN-99-05)
Thursday, November 18, 1999


We have received reports of intruders installing distributed denial of service tools. Tools we have encountered utilize distributed technology to create large networks of hosts capable of launching large coordinated packet flooding denial of service attacks.

We have seen distributed tools installed on hosts that have been compromised due to exploitation of known vulnerabilities. In particular, we have seen vulnerabilities in various RPC services exploited. For more information see the following CERT Incident Notes:

IN-99-04, Similar Attacks Using Various RPC Services
IN-99-05, Systems Compromised Through a Vulnerability in am-utils

Two of the tools we have seen are known as trinoo (or trin00) and tribe flood network (or TFN). These tools appear to be undergoing active development, testing, and deployment on the Internet.



Trinoo is a distributed tool used to launch coordinated UDP flood denial of service attacks from many sources. For more information about various UDP flood attacks, please see CERT Advisory CA-96.01. A trinoo network consists of a small number of servers, or masters, and a large number of clients, or daemons.

A denial of service attack utilizing a trinoo network is carried out by an intruder connecting to a trinoo master and instructing that master to launch a denial of service attack against one or more IP addresses. The trinoo master then communicates with the daemons giving instructions to attack one or more IP addresses for a specified period of time.

  1. intruder -------> master; destination port 27665/tcp
  2. master -------> daemons; destination port 27444/udp
  3. daemons -------> UDP flood to target with randomized destination ports

The binary for the trinoo daemon contains IP addresses for one or more trinoo master. When the trinoo daemon is executed, the daemon announces it's availability by sending a UDP packet containing the string "*HELLO*" to it's programmed trinoo master IP addresses.

daemon -------> masters; destination port 31335/udp

The trinoo master stores a list of known daemons in an encrypted file named "..." in the same directory as the master binary. The trinoo master can be instructed to send a broadcast request to all known daemons to confirm availability. Daemons receiving the broadcast respond to the master with a UDP packet containing the string "PONG".

  1. intruder -------> master; destination port 27665/tcp
  2. master -------> daemons; destination port 27444/udp
  3. daemons -------> master; destination port 31335/udp

All communications to the master on port 27665/tcp require a password, which is stored in the daemon binary in encrypted form. All communications with the daemon on port 27444/udp require the UDP packet to contain the string "l44" (that's a lowercase L, not a one).

The source IP addresses of the packets in a trinoo-generated UDP flood attack are not spoofed in versions of the tool we have seen. Future versions of the tool could implement IP source address spoofing. Regardless, a trinoo-generated denial of service attack will most likely appear to come from a large number of different source addresses.

We have seen trinoo daemons installed under a variety of different names, but most commonly as

  • ns
  • http
  • rpc.trinoo
  • rpc.listen
  • trinix
  • rpc.irix
  • irix

Running strings against the daemon and master binaries produces output similar to this (we have replaced master IP address references in the daemon binary with X.X.X.X)

trinoo daemon trinoo master
%s %s %s
trinoo %s
Aug 16 1999
trinoo %s [%s:%s]
... rest omitted ...

Tribe Flood Network

TFN, much like Trinoo, is a distributed tool used to launch coordinated denial of service attacks from many sources against one or more targets. In additional to being able to generate UDP flood attacks, a TFN network can also generate TCP SYN flood, ICMP echo request flood, and ICMP directed broadcast (e.g., smurf) denial of service attacks. TFN has the capability to generate packets with spoofed source IP addresses. Please see the following CERT Advisories for more information about these types of denial of service attacks.

CA-96.01, TCP SYN Flooding and IP Spoofing Attacks
CA-98.01, "smurf" IP Denial of Service Attacks

A denial of service attack utilizing a TFN network is carried out by an intruder instructing a client, or master, program to send attack instructions to a list of TFN servers, or daemons. The daemons then generate the specified type of denial of service attack against one or more target IP addresses. Source IP addresses and source ports can be randomized, and packet sizes can be altered.

A TFN master is executed from the command line to send commands to TFN daemons. The master communicates with the daemons using ICMP echo reply packets with 16 bit binary values embedded in the ID field, and any arguments embedded in the data portion of packet. The binary values, which are definable at compile time, represent the various instructions sent between TFN masters and daemons.

Use of the TFN master requires an intruder-supplied list of IP addresses for the daemons. Some reports indicate recent versions of TFN master may use blowfish encryption to conceal the list of daemon IP addresses. Reports also indicate that TFN may have remote file copy (e.g., rcp) functionality, perhaps for use for automated deployment of new TFN daemons and/or software version updating in existing TFN networks.

We have seen TFN daemons installed on systems using the filename td. Running strings on the TFN daemon binary produces output similar to this.

Error sending syn packet.
tc: unknown host
rm -rf %s
rcp %s@%s:sol.bin %s
nohup ./%s


Distributed attack tools leverage bandwidth from multiple systems on diverse networks to produce very potent denial of service attacks. To a victim, an attack may appear to come from many different source addresses, whether or not IP source address spoofing is employed by the attacker. Responding to a distributed attack requires a high degree of communication between Internet sites. Prevention is not straight forward because of the interdependency of site security on the Internet; the tools are typically installed on compromised systems that are outside of the administrative control of eventual denial of service attack targets.

There are some basic suggestions we can make regarding distributed denial of service attacks:

  • Prevent installation of distributed attack tools on your systems

    Remain current with security-related patches to operating systems and applications software. Follow security best-practices when administrating networks and systems.

  • Prevent origination of IP packets with spoofed source addresses

    For a discussion of network ingress filtering, refer to

    RFC 2827/BCP 38, Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing

  • Monitor your network for signatures of distributed attack tools

    Sites using intrusion detection systems (e.g., IDS) may wish to establish patterns to look for that might indicate trinoo or TFN activity based on the communications between master and daemon portions of the tools. Sites who use pro-active network scanning may wish to include tests for installed daemons and/or masters when scanning systems on your network.

  • If you find a distributed attack tool on your systems

    It is important to determine the role of the tools installed on your system. The piece you find may provide information that is useful in locating and disabling other parts of distributed attack networks. We encourage you to identify and contact other sites involved.

  • If you are involved in a denial of service attack

    Due to the potential magnitude of denial of service attacks generated by distributed networks of tools, the target of an attack may be unable to rely on Internet connectivity for communications during an attack. Be sure your security policy includes emergency out-of-band communications procedures with upstream network operators or emergency response teams in the event of a debilitating attack.

In November 1999, experts addressed issues surrounding distributed-systems intruder tools. The DSIT Workshop produced a paper where workshop participants examine the use of distributed-system intruder tools and provide information about protecting systems from attack by the tools, detecting the use of the tools, and responding to attacks.

Results of the Distributed-Systems Intruder Tools Workshop


The CERT/CC would like to acknowledge and thank our constituency and our peers for important contributions to the information used in this Incident Note.

Copyright 1999 Carnegie Mellon University.

  • No labels