Answers

1. Identify and explain the purpose of the binary.

The binary is an ELF file, implementing a remote backdoor. This backdoor is destined to be uploaded and installed on compromised hosts, where a Linux binary compatible system resides (Linux, FreeBSD, OpenBSD, ...). Once this backdoor is started on such a computer, the user can then remotely executes a set of different functionalities.

2. Identify and explain the different features of the binary. What are its capabilities?

The main feature of the binary is to offer a set of functionalities to the user, through a proprietary protocol. Those functionalities can be classified in 3 categories:

• Functionalities to manage the backdoor (initializing communcation settings - observing task currently executed).
• Functionalities to execute commands on the system where the backdoor resides (directly running a command on the host - binding a shell on a TCP port).
• Functionalities to start DDoS attacks (DNS, TCP, UDP, and ICMP floods).

3. The binary uses a network data encoding process. Identify the encoding process and develop a decoder for it.

The backdoor exchange data with a client by encapsulating its data in an IP payload, and filling the protocol field of the IP header with the value 11. The payload itself contains a byte representing a signature: this signature differs according to the direction of the packet. Packets from a client to the backdoor contains a signature "2", while packets from the backdoor to the client contains a signature "3". Typically, a client send "commands" to the backdoor, and the backdoor answers with a set of packets containing "answers".
Behind this signature byte, we find a data block, encoded with a relatively simple algorithm. Those data contains the effective "command" and possible arguments (from client to backdoor), or informations returned by the backdoor (to the client).

4. Identify one method of detecting this network traffic using a method that is not just specific to this situation,
but other ones as well.

On a classical network, only a small subset of all available TCP/IP related protocols are used. Among those, TCP, UDP and ICMP are the most widespread.
In our case, the backdoor uses a unusual protocol, numbered as 11 in the related IP header field: a traditional NIDS can usually be configured to directly generate an alarm once a packet with an unusual protocol is captured. Moreover, such unknown protocols can be easily blocked by a firewall, avoiding the risk to penetrate further in a network.
Finally, remember us that a well configured firewall must only allow traffic explicitly authorized.

5. Identify and explain any techniques in the binary that protect it from being analyzed or reverse engineered.

Except the strange protocol and its encoding mechanism, we can't truly speak about explicit techniques to protect it from being analyzed or reverse engineered.
However, the fact that the backdoor communicates with an unusual protocol can make the analysis more difficult. Concerning the binary iteself, the fact that it is statically linked can cause problems for the reverser, especially if the used disassembler can't recognize library signatures.
Concerning the debugging, the architecture used in classical daemons (who consists to forks child processes two times consecutively), sometimes bring to problems, because the debugger needs to follow the creation of child processes and debug them directly at the beginning of their execution. Fortunately in our case, strace worked perfectly.

6. Identify two tools in the past that have demonstrated similar functionality.

What makes this binary original is that it offers remote command execution, combined to DDoS attacks. Most of the existing backdoors only offer remote command execution (traditionally by binding a shell to a predefined TCP port), and let the user upload himself others tools to start a DDoS attack (remember Trinoo and all derived projects). Here, the DDoS attacks are directly included in the binary, and the user can receive the result of command executions through a protocol originally not reserved for such a particular usage. So, it is interesting to have a look at others tools who permit to exchange data using protocols not reserved for this usage.

The first tool to approach such a technic is surely Loki: it uses the ICMP protocol to create a covert channel and exchange informations. Now, we can find a lot of other tools using the same technic as Loki to run shell commands, transfer files, ...
The second tool, , CovertTCP, go a step further, and try to create a covert channel by encoding informations in header fields of TCP/IP protocols.

Bonus Questions:

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

Here, it is interesting to determine the skill level according to 2 different criterions:

• The used technics: Some technics presented in this tool are really interesting: for example, using spoofed IP addresses or decoys, and the use of an unusual protocol to exchange informations are interesting and original ideas. In the DDoS attack, the attack which consist to send fake DNS requests with spoofed source addresses corresponding to our target is also an interesting technic.
• The programming skills: On the contrary, the programming skills of the person who developed this tool aren't really impressive. For example, the method used to pass some arguments to DDoS functions aren't really interesting and coherent. For example, let's have a look at the prototype of this function:

  int __cdecl f_send_dns_SOA(char source_ip1,char source_ip2,char source_ip3,char source_ip4,int count,int source_port1,int source_port2,int use_hostname,char *hostname)

  We clearly observe that each byte of the IP source address is passed as one argument. This isn't a really powerfull technique... The same mechanism is used to pass the source port value.
  Also, we remark that a flag (use_hostname) indicate if for a given address, we must use the IP address from the byte arguments, or resolve the address from the hostname argument. Wouldn't it have been simplier to pass a null pointer or an empty string as hostname, to obtain the same effect?
  
  Concerning the DDoS commands, we observe a different structure associated to each command. Moreover, those structures usually are different on a relatively small set of bytes or arguments). Without any doubt, it would have been simplier to build a general structure, and use it for each command offered by the backdoor (as usual protocols tend to do).

However, those strange programming skills are perhaps an indication that the person who developed the tool cut and pasted source code from other tools, and tried to adapt all those code extracts into a coherent backdoor. Moreover, the fact that a function is unused (f_ip_checksum()) still consolidates our assumption.

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

Different advancements can be envisaged, at the different levels:

• As we mentionned it previously, no real anti-debugging tricks were used in this tool. Binary encryption is now a technic largely used in some domains, and applying such technologies to a backdoor can seriously complicate the analysis.
• Concerning the process itself, a lot of tools and rootkits now offer technics to hide the execution and the presence of their process in memory and on the filesystem.
• Finally, let's propose some advancements concerning the communication protocol: a strong cryptographic algorithm would render the interpretation of the traffic almost impossible (remember protocols such as SSL or SSH). But perhaps that the future of strong cryptography is something like steganography... Let's imagine an exchange protocol encapsulating data in perfectly valid HTTP traffic, HTML pages, or inocent GIF pictures ... ;)