The binary is a sophisticated hybrid tool capable of carrying out Distributed Denial of Service attacks using several different techniques. It is also capable of acting in the manner of a remote system monitoring tool via a feedback command and can act as a remote shell with no feedback. There is also an unidentified function to the binary that emables it to act as a server to some unidentified protocol allowing direct interaction between either the hacker or an IRC Bot. The individual capabilities are explained below and in the analysis (the section called What are these other buttons for? in "wtfu4 - Meltdown"). When invoked the binary opens a listening process on port 11 using the RAW TCP protocol.
We believe the binary to be part of an unidentified rootkit that has been used in the compromise of a RedHat 4.0/4.1 system. This was identified by a combination of the statically linked libraries and the compiler version used, both apparent within the strings output of the binary as shown in the analysis (the section called First Impressions Count. in "wtfu4 - Meltdown"). This would need confirming using the logs of the compromised system.
For this section we will take each of the identified functions of the binary in turn and explain their significance. Firstly, we have identified that the binary is capable of accepting and acting upon remote command sequences, sometimes sending encoded response packets to a seemingly random selection of IP addresses. The three commands and their activity is summarised below.
the section called Command 3 in "wtfu4 - Meltdown" is a remote system interrogation tool and can be used to analyse the running system using standard system binaries or other binaries installed as part of the compromise. The snort analysis released by the project confirms this is the case with an incoming request to run the command rpcinfo -p 127.0.0.1 and an outgoing response containing the results of running the command (see section the section called Command 4 in "wtfu4 - Meltdown").
the section called Command 6 in "wtfu4 - Meltdown" is a puzzler in that we don't know exactly what it is for. What we do know is that it launches an additional server process on port 23281 (at least on the test system) that responds positively to a telnet request. This appears to be another backdoor into the system and is likely to act as a means for the hacker or an IRC bot to control the trojan in an interactive manner. The communication between the client and the new server process also appears to be encoded using the same technique identified below (Q: 3.).
the section called Command 7 in "wtfu4 - Meltdown" is simply a cutdown version of the section called Command 3 in "wtfu4 - Meltdown" which allows the attacker to run system commands remotely but not to actually get any feedback directly. The could be the means of shutting down the attack when there is a risk of discovery, or simply to cease the attack because the attacker has felt the target has had enough ;}.
Next up, the binary is capable of being remotely activated for certain commands - we found this by accident. the section called Command 2 in "wtfu4 - Meltdown" appears to be an activation command for whatever the section called Command 1 in "wtfu4 - Meltdown" appears to be doing. the section called Command 1 in "wtfu4 - Meltdown" appears to be a remote reporting tool of some description. When we had activated this using command 2 we did see some netwrok traffic, but using the decoder developed during our investigations we didn't find anything of substance in the transmitted packet. Interestingly, the first 3 packets of the snort trace released from the honeynet team contained command 2 sequences. All three packets appeared to contain the same payload when we analysed them.
Last up, but certainly not least, is the actual destructive capabilities of wtfu4 The binary is capable of carrying out 6 different Denial Of Service attacks (most probably distributed across a large number of clients) as described in detail in the analysis command summary. The commands capable of this are: the section called Command 4 in "wtfu4 - Meltdown" (either a reflective DNS attack or a devious ICMP attack, due to the network configuration we were unsure which), the section called Command 5 in "wtfu4 - Meltdown" (Ping of Death using fragmented ICMP packets and a spoofed source address), the section called Command 9 in "wtfu4 - Meltdown" (also a reflective DNS attack), the section called Command 10 in "wtfu4 - Meltdown" (spoofed SYN Flood attack with serious volumes - 2.5Mb in a few minutes), the section called Command 11 in "wtfu4 - Meltdown"(another SYN Flood attack, but using significantly larger volumes. This attack on a loopback interface seriously impaired functionality of the analysis machine within 2 minutes.) and the section called Command 12 in "wtfu4 - Meltdown" (a late contender due to a schoolboy coding/interpretation error by _0bfu5cati0n - a seriously large volume, 25Mb in approxiamately 1 minute, of DNS requests. We believe this is a Reflective DNS Amplification attack).
In conclusion, this appears to be a well constructed piece of software. Its capabilities as shown above are extremely powerful and was written by a knowledgable individual or group of individuals to carry out serious disruption to somebodies network. It would certainly impede, if not temporarily destroy, the internet presence of whoever it was targetting. In today's fast moving world, attacks by weapons such as this can cause severe financial loss and has led to the closure of some internet presences. A very serious and cleverly written tool. All the attacks described above were done from a single instance of the trojan, there is no saying that for a trojan sat on a larger bandwidth connection the Black Hat hackers haven't built in capability to spawn multiple instances of the attack code, and there was some evidence for that inthe netstat output from the commands.
3. The binary uses a network data encoding process. Identify the encoding process and develop a decoder for it.
The deciphering of the decoding process has been described fully in the analysis (the section called I want you to listen in "wtfu4 - Meltdown"), but we will summarise what we believe the encoding process is here. The decoder and a client capable of encoding can be found in the src/ subdirectory. Both these programs are primitive due totime constraints imposed from the rest of the analysis, but it would be possible to write a decoder that took a full tcpdump packet and decoded it - currently a filename is passed which cantains only the data section of the packet to make sure we were decoding the correct part of the message. It would also be reasonably straight forward for someone familiar with Ethereal and other tools to be able to write a plugin decoder using this as a basis.
The encoding process was reasonably trivial once we had got our head round the decoding code properly. The first 2 bytes of the packet data were always the same 02 00 and these can be used to detect the packets (see Q: 4.. The rest of the packet is encoded. The encoding process starts with the 2nd byte 00 and adds 23 to it before casting it as a char (1 byte) into the encoded buffer. The first three bytes of the encoded buffer will be :
dest[0] = '\002'; dest[1] = '\000'; dest[2] = (char)(dest[1] + 23);
The next byte to be written into the encoded buffer is the value of the previously encoded byte added to the numerical command value added top 23.
dest[3] = (char)((int)dest[2] + 23 + (int)command);
The next round of the encoding is repeated for the remaining length of the buffer to be encoded. It involves taking the value of the previously encoded byte, adding it to the value of the byte to be encoded and adding 23 as shown below.
for (i=0; i<len; i++) { dest[i+4] = (char)((int)dest[i+3] + 23 + (int)data[i]); }
That is all there appears to be to the encoding process. The decoding is slightly more difficult, but involves taking the last value of the buffer and the next to last value of the buffer, subtracting the two and then subtracting 23. If the result is less than 0 a loop is entered adding 256 until it is greater than 0. The decoder is described in more detail in the section called I want you to listen in "wtfu4 - Meltdown".
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.
Since the activity of this particular trojan is largely onto the systat port of a server, one that would be rarely used in a production environment we would assume, then any activity to that port should be alerted using the following generic rule:
alert ip $EXTERNAL_NET any -> $HOME_NET 11 (msg:"WTFU4-Generic"; classtype:unusual-client-port-connection; priority:2; sid:1000002; rev:1;)
If you wanted to identify this by using a network monitor such as snort you could create the following rules:
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"WTFU4 Client to Server"; content:"|0200|"; ip_proto:11; classtype:attempted-dos; priority:2; sid:1000001;) alert ip $HOME_NET any -> any any (msg:"WTFU4 Server Present"; content:"|0300|"; ip_proto:11; classtype:successful-dos; priority:2; sid:1000002;)
These rules have been tested against the tcpdump released by the HoneyNet team and also against a live production system to test for false positives - hopefully :) These rules were successful in identifying the inbound and outbound data packets of the trojan but didn't yield any false detections in the live environment.
Of the attack packets for the various activated commands we should be able to detect all of them using the following rule:
5. Identify and explain any techniques in the binary that protect it from being analysed or reverse engineered.
We will try and keep this brief, but there are a lot of additions to this nice piece of software that didn't help us in discovery of it's functions. Firstly the binary has been compiled with -O3 - most likely to optimise certain routines, but this indirectly obscures its function. It has been statically linked with the runtime libraries which prevents using the command ldd -d the-binary. This would have told us instantly the libraries that wtfu4 required to function. wtfu4 has also most likely been compiled with some additional flags - particularly -Wl,-static -s -Wl,-nostartfiles -Wl,-nostdlib which aid in obscuring where the start point is and allows the binary to be linked against non-standard libraries. More information can be found in the article A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux.
wtfu4 also uses the fork() system call very heavily which made debugging difficult, but not impossible. While there are large areas of the data segment of wtfu4 identifiable as points where something useful may be happening, the author's liberal use of system like strings and network language in these areas results in it being difficult to distinguish between the data region of wtfu4 and data regions imported from the use of the --static directive. We thought certain strings we had seen in the network traces after activating wtfu4 were, in fact, part of the resolv library that had been statically linked. This is most likely not the case and they are in fact part of wtfu4's functionality.
Finally, it may be that areas of the data segment are encoded and spread liberally around to prevent identification of IP addresses, etc. We suspect that the section called Command 2 in "wtfu4 - Meltdown" may be rearranging parts of the data segment each time it is executed. The use of remote command sequences to write the data section would be the work of an advanced programmer.
It is clear to us that the author of this software has taken great care to try and avoid the full purpose of this software being discovered. Even after the analysis we have conducted here there are still lots of unexplored areas of code that could be doing some interesting things with memory areas.
As mentioned before, we believe the binary to be a type of DoS/DDoS tool, therefore we feel that the two tools that have shown similar, but not exact, functionality are mstream and stacheldraht. These are similar in either their function or how they were created. It is probably closer to the mstream trojan as they share a number of attributes (e.g both fork, both use /tmp to hold their files etc), but the new binary is a much more complex and well constructed hybrid.
We can conclude that the individual(s) who developed this tool were very highly skilled as the file is very difficult to reverse engineer and debug. Even when we had developed a decoder we still had the difficulty of trying to decipher the actual commands that are used to get the binary to carry our its orders. We believe they are also very familiar with the concepts of tcp/ip and udp as he instructs the binary connect to a raw socket, rather than just binding it to a specific port, to enable it to hide itself easily from beginners to system administration. wtfu4 is a very complex and intriguing binary and still carries significant secrets in our opinion.
As to what advancements we could see in the future, I believe they will be more complex hybrids based on this version. These will be much smaller binaries, with even more information stripped out, making these much harder to debug and reverse engineer. There are a number of ways this could be done, including encrypting the data areas and also by carrying executable segments that can be loaded from a temporary file. The following links explain this in more detail - Armouring the Elf binary and A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux.