Introduction
Nettitude recently obtained a sample of some malware intended to run on GNU/Linux-based servers, with the purpose of turning its host into a cut-out for anonymous forwarding of messages between other machines. We have seen no evidence of it causing direct harm to the machine on which it runs (beyond the unauthorised use of some network bandwidth). However the harm to others could be considerable, and there are practical, ethical and reputational reasons why server administrators should seek to avoid their machines being abused in this way.
The file that we examined has a filename of ‘dl20spy_0aP’, a length of 15321 bytes, and an md5sum of 491196F3B83DDF07FA5DFBD8DAAF3871. It appears to be unknown to most current anti-virus products, but is identified by CYREN and F-PROT as ‘ELF/SpyLock.A’.
The code was compiled using GCC for the x86-64 processor architecture, and is dynamically-linked against five shared libraries (libc, libsrdc++, libm, libpthread and libgcc_s). Compatible versions of these libraries must be present on the host system for the malware to run, however these are very common libraries which change rarely. We would expect the code to run on almost all extant x86-64 GNU/Linux-based systems.
The program does not appear to contain any mechanism for propagating or persisting itself, nor has it any benign functionality for disguising its true purpose. It is not therefore a virus, worm or trojan, and would be of little use to an attacker without some separate means for injecting it into the target system – for example, by exploiting a vulnerability in a website.
When, by whatever means, the program is executed, it opens two TCP ports for listening: 6661 and 6662. These are within the range that is reserved for ‘registered ports’ (1024 to 49151). Officially they are unassigned, but unofficially they are often used by Internet Relay Chat (IRC) servers. The program does not need to run as root to make use of these ports – any user will suffice. This is convenient if running it in the context of a web server because no privilege escalation is needed.
As it happens, IRC was historically a favourite protocol for controlling botnets, because traffic routed via third-party IRC servers is difficult to trace. Security-conscious network administrators consequently tend to be quite suspicious of unexplained traffic on IRC-related ports. This particular piece of malware does not however appear to make any use the IRC protocol or infrastructure, so there is no obvious reason why it would need to use these particular port numbers. That makes them a slightly odd choice for someone trying to keep a low profile.
The explanation appears to be that the author has no interest in keeping a low profile. Connect to port 6662 and the program helpfully logs to stdout that it has ‘Got connection from victim’. Not subtle, and in fact there are seven instances of the word ‘victim’ in plain view within the executable. There is no attempt at obfuscation, or preventing the use of virtual machines or debuggers.
After such refreshing openness it was disappointing to learn that the party connected to port 6661 is referred to merely as the ‘client’, but this is presumably the port that would be used by the attacker. This is not to say that the attacker would necessarily connect directly – there may be additional layers of indirection – or that we should always believe log messages printed by malicious software.
It is interesting that both ports listen for connections rather than dialling out:
On the victim side this has the benefit of allowing for NAT, and supporting multiple victims without knowing their IP addresses in advance. On the client side it avoids leaving any evidence in the executable that would allow the attacker to be traced, and allows the attacker to move to a different IP address if need be. That would be useful if making connections from another hijacked host which the attacker might lose control of.
The message format is straightforward: a 32-bit little-endian length field, which specifies the number of bytes in the payload, followed by that payload. For example, if the payload was a 7-byte ASCII string containing the word ‘example’ then the resulting message would be:
Messages are forwarded verbatim from client to victim and from victim to client, but not immediately. Instead they are queued, with one message sent to each destination in exchange for each message received from that destination. If there is nothing to be sent then this is represented by a message with an empty payload. We were able to verify these findings by writing a test program which sends messages back and forth using the malware as a cut-out.
The circumstances under which we obtained this malware did not allow us to observe any control traffic. Furthermore, since the malware does not appear to process the message payloads in any way, there is nothing in the executable that can be analysed to learn more about the nature of the traffic. However, the combination of the two open ports and the message format described above should be sufficient to act as a reasonably specific indicator of compromise.
Potential uses for the malware include control of ransomware, spyware, botnet members, or any other activity where there is a need for anonymised communication with a victim of some sort. If you find one of your machines running it then you can be thankful that you are (probably) not the victim yourself, but you will the first port of call for anyone attempting to trace the perpetrator.
Conclusion
An experienced investigator ought to know that this type of redirection is very common, however it is not far-fetched to imagine that you might have your connection cut off by your ISP, or come under investigation by law enforcement, or be publically accused of negligence for allowing your servers to be abused in this way. Also remember that next time the target could be you, so spare a thought for others by not letting your computer be commandeered in this way.
To contact Nettitude’s editor, please email media@nettitude.com.
