Revision Date Notes
v1.0 31/05/20002 First revision of the document


This document is a technical advisory on "the-binary" - a Distributed Denial of Service (DDoS) attack tool. Key aspects of the-binary are covered as well as description of threats it poses, detection techniques and methods of defence. Additionaly a tool which is able to control the-binary was devised. Its source code is available in Appendix B.

Target audience

Technical audience wishing to gain in-depth knowledge what is "the-binary", how does it work, how to detect it and defend against it.


"the-binary" is another Distributed Denial of Service (DDoS) attack tool, similar to already known tools, suich as trinoo, TFN, TFN2k and others. It employs already known techniques, such as DNS reflection, DNS flood, fragments flood and TCP SYN flood. Those techniques are seen in real-world DDoS attacks for at least 10 years now.

Key aspects

The-binary can bu run only under Linux Operating System on Intel x86 platform. The-binary itself does not contain any "worm" or "viral" capabilites: it has to be run "by hand" by the attacker. Additionaly it has to be run as "root" user (to be exact with EUID 0) - otherwise it exits. The-binary tries to disguise in the system: it changes it's argv[0] to "[mingetty]". As a side effect it's impossible to kill the-binary using "killall" utility. Once run it can be controlled remotely from the network.

Control over the-binary

Analysed version of the-binary used IP protocol 11 as control channel. IP protocol 11 is assigned by IANA to Network Voice Protocol (NVP-II). Every command issued by the attacker is a single IP packet. The first byte of the payload has to be 0x02. Packet length has to be bigger than 200. If those 2 conditions are not met packet is silently ignored by the-binary. The content of every packet is crypted with a very simple algorithm (see Appendix A). Crypted contents begins on the 22th byte of the packet, counting from the start of IP header. Every packet generated by the-binary (returning command output or status) is also crypted with the same algorithm.

Available commands

The-binary recognizes 12 commands:
  1. status
  2. register controller
  3. execute command and return output to the attacker
  4. DNS reflection attack
  5. frag flood
  6. spawn a password-protected shell on port 23281
  7. execute command without returning output
  8. kill the current flooding process
  9. DNS reflection attack
  10. TCP SYN flood
  11. TCP SYN flood
  12. DNS flood
The difference between pairs (10,11) and (4,9) is very slight and the same effect as 10 and 4 can be achieved using 11 and 9 respectively.

"Status" command

The-binary returns information if it is currently performing any attack and what kind of attack it is.

"Register controller" command

This command allows the attacker to register a controller with the-binary. Every return information (generated by "status" or "execute command with output" commands) is sent to all registered controllers. This command has 3 possible modes:
  1. register only one controller (useful for testing) - packets are sent only to this address
  2. register one controller, other 9 are generated randomly - disguises real IP address of the attacker as every packet is sent in 10 copies
  3. register 10 controllers - of course any number of IPs can be real, other (fake ones) are used to protect attacker IP address. Due to a bug in the code the first address can be duplicated in another position. This bug manifests itself in 90% of the cases

"Execute command and return output" command

Sent string is treated as a command and is executed using csh shell. If /bin/csh is not available the command won't be executed. The output of the command is sent to all registered controllers.

"Execute command without returning output" command

It is exactly the same as the previous command but it doesn't try to send to the controller output returned by the command. Again if /bin/csh is not available the command does not get executed.

"Spawn a password protected shell" command

/bin/sh is spawned and its stdin, stdout and stderr bound to port 23281. After connecting to that port the attacker has to provide a password. The password is hardcoded in the-binary: "SeNiF", however it is trivial to change it inside the-binary.


Every attack can be issued against given IP address or hostname. If the attacker has provided hostname, every n-th iteration (where n is controlled by the attacker) the hostname is resolved again and the-binary attacks the first returned address. This technique allows to attack every IP address in case of round-robin DNS (i.e. hostname that resolves to more than one A record). In certain network configurations this can lead to saturation of all of the network links the target is connected to the Internet instead of just one. Attacks are run in separate processes. The PID of this process is remembered in the main process and a special command ("kill the current flooding process") has to be issued to end attack. Otherwise the attack runs endlessly.

"DNS reflection" attack

The-binary has a hard-coded list of 11418 DNS servers which are used as "reflectors" in this attack. A query is sent to all the hard-coded DNS servers with a spoofed IP address. After the query is sent to all DNS servers next query is chosen in an infinite loop. The spoofed IP address is set to the IP address of the target. DNS server sends the answer is back to the host, which IP number appeared in IP header, resulting in constant data stream to the victim, sent from all of the DNS servers on the list. It is hard for the attacked machine administrator to defend from this type of attack as the DNS server list is very broad so from the attacked host point of view it's getting attacked from more than 10000 hosts. This attack seems to be most dangerous of the attack contained in the-binary. Response returned by DNS server is in case of queries contained in the-binary almost 2 times bigger than the query itself, so the target can be flooded with data stream 2 times wider than the stream of queries sent by the attacker. Such effect is called "bandwidth amplification". Fortunately this part of the-binary is poorly written and 4 out of 9 queries are buggy, so they will yield only error response from the DNS server.

"Frag flood" attack

The-binary sends a constant stream of packets, which appear to the target host as fragments of bigger IP datagrams. Apart from saturating the target links it can also occasionally cause router to fail. The router could erronoeusly try to keep information about received fragments in order to assemble received packets into datagram. Because the number of received packets is huge and the other fragments of assembled datagram won't ever be received the router can exhaust all of the available memory and fail. Again bugs in the implementation of this attack seriously mitigate its effectiveness. Every packet is sent with the same source IP address (even though spoofed) and IP ID number so every router should silently drop every packet (except the first one) without trashing internal memory.

"TCP SYN flood" attack

A constant stream of TCP SYN packets is sent to the target. The source IP address can be random or given by the attacker.

"DNS flood" attack

This attack is similar to "DNS reflection" attack described above, however the queries are not sent to DNS servers on the hardcoded list but instead they're sent to one, given DNS server. The source address can be fixed or random. If it's properly chosen by the attacker the attack can cause DoS on 2 hosts: DNS server overwhelmed by the queries and the host which will receive answers from the server. When the source address is random only DNS server is affected.


On the local machine the-binary can be easily recognized as "[mingetty]" process without controlling terminal (? in TTY column). To check what IP protocols are registered on a given machine you can use nmap -sO (nmap is an open source network exploration tool and security scanner, see which lists all of IP protocols the machine supports. If you know that the machine shouldn't respond to anything except UDP, TCP and ICMP it could be a sign of possible compromise if it listens on another protocol. The communication between controller and the-binary is encrypted so it's impossible to provide static strings that would identify network traffic generated by the controller or the-binary. However logging all strange IP protocols that appear on the net could be a good idea. Warning: this detection technique can only be employed to unmodified versions of the-binary. One can easily modify the-binary to use other channel of communication to control its functions or change the process name.


Properly configured firewall should drop all IP protocols which are not known to be used inside the protected zone. This would prevent the attacker to control the-binary from outside but it would be still possible to control the-binary from inside. To prevent already existing DDoS attack tools, as well as future ones, from using reflection techniques and make the identification of attacker easier, ingress and egress filtering (see here and RFC 2827) should be implemented at ISP level. Additionaly ISPs should implement techniques which would allow to trace back real origin of sent packets regardless of their IP source address. This allows to track down attacking hosts amd make it easier to identify the real attacker.


Appendix A - Encryption algorithm used by the-binary

The algorithm is very simple: first byte of data is incremented by 0x17 and every next byte is incremented by 0x17 and by the value of the previous byte.

Appendix B - the-binary Controller

Available in source form in files.tar.