CERT® Incident Note IN-99-07The CERT Coordination Center publishes incident notes to provide information about incidents to the Internet community.
Distributed Denial of Service ToolsUpdated: 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
OverviewWe 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:
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.
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.
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".
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
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)
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.
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.
%d.%d.%d.%d ICMP Error sending syn packet. tc: unknown host 188.8.131.52 mservers randomsucks skillz rm -rf %s ttymon rcp %s@%s:sol.bin %s nohup ./%s X.X.X.X X.X.X.X lpsched sicken in.telne
SolutionsDistributed 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:
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.
AcknowledgmentsThe CERT/CC would like to acknowledge and thank our constituency and our peers for important contributions to the information used in this Incident Note.
This document is available from: http://www.cert.org/incident_notes/IN-99-07.html
CERT/CC Contact Information
Phone: +1 412-268-7090 (24-hour hotline)
Fax: +1 412-268-6989
We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from
Getting security informationCERT publications and other security information are available from our web site
email@example.com. Please include in the body of your message
* "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office.
Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement.
Conditions for use, disclaimers, and sponsorship information
Copyright 1999 Carnegie Mellon University.