Here is a quick bit of work I did on it after getting ahold of some samples last night from reading the Doctor Web report. Didn't go debugging it or disassembling it yet as I am meant to be studying for exams...
Sample Hashes, Architectures, and Filesizes.
Code: Select all04f691e12af2818015a8ef68c6e80472ae404fec SPARC (32 bits) 49kb
8e93cfbaaf7538f8965080d192df712988ccfc54 Intel (64 bits) 56kb
cd274e6b73042856e9eec98d258a96cfbe637f6f Intel (32 bits) 39kb
466d045c3db7c48b78c6bb95873b817161a96370 SPARC (32 bits) 50kb
a11bda0acdb98972b3dec706d35f7fba59587f99 SPARC (32 bits) 49kb
When I read over the AES and SHA-1 decompliations outlined in the Dr. Web posting, I had a hunch that there was something familiar at play here. So after running strings and having a quick look over the output, I was not too surprised to notice that there were references to tshd in the output. TinySHell, or 'tsh', is a fairly old and yet still not-too-well-known little backdoor which grants remote command execution, shell (PTY) access, command execution, and file transfer capabilities over a encrypted reverse or bind connection. As mentioned in the Dr. Web analysis, it uses AES-128-CBC with SHA-1 used for signing.
The communication-encryption code used in tsh can be found in "pel.c" and "pel.h" in the tsh git repository, and quickly checking the function names available in the Rekoobe sample and checking for "pel_server_init", "pel_send_msg", and other "Packet Encryption Layer" functions from tsh confirm our suspicion that this backdoor is at least somewhat based on tsh. To further confirm our suspicions, checking the command-codes from the tsh source code with the Dr. Web analysis, we find the following when we compare their extracted commands to the ones listed in the program source code.
Code: Select all#define GET_FILE 1 // Upload a file to the command and control server (cmd == 0x01)
#define PUT_FILE 2 // Download a file (cmd == 0x02)
#define RUNSHELL 3 // Reverse Shell (cmd == 0x03)
Furthermore, we find that various objects/variables used in tsh are also used in the malware sample - "CONNECT_BACK_DELAY" and the like.
So far, the majority of the code in there is accounted for by comparing it to tsh. However, there are some important differences.
So what is not from tsh?
It seems to have some code in there to allow it to connect back via a proxy, and some of the code seems to be referring to a magic UDP packet. It also has code to handle proxy-auth (doing HTTP CONNECT tunnelling), and it uses an xor encoded configuration file instead of having its variables hardcoded. I guess finding out what these functions is going to wait until I can be bothered actually going at it in a disassembler and have the free time to do so. Anyone elses input here is highly valued as its probably going to be a while before I get to do that.
Link to tsh on Github:
https://github.com/creaktive/tsh