The-binary appears to be principally a remote-attack access vehicle, intended to provide remote command execution and reporting to the attacker or program which placed it. It is possible that the supplied binary also includes facilities for talking to copies of itself located on other compromised systems, however I did not find any substantial evidence of such behavior.
In order to be of maximal use to an attacker of course this code needs to run with r
execve("./malcode", ["./malcode"], [/* 13 vars */]) = 0 personality(0 /* PER_??? */) = 0 geteuid() = 501 _exit(-1) = ?
The binary opens a raw network socket using protocol 11 (NVP or network voice). This socket is used as a control link for a remote attacker. The control link uses a simple encoding to hide its traffic from casual inspection.
Once activated over this control channel, the binary will accept commands over the open socket, and will open connections to send its responses using essentially the same socket interface.
The choice of IP numbers for this reporting is, as near as I can tell randomly selected at activation and does not change within an instance. It seems likely that this method was chosen by an attacker who has the ability to sniff packets traversing his target's network connections.
The binary accepts and transmits data in the following form:
byte | value(s) | useage |
---|---|---|
00 | 02|03 | command |
01 | 00 | n/a-fill? |
02 | 00-ff | stop-difference |
03 | ?? | unknown? |
04-stop | encoded | payload/ command |
The test-data provided by the challenge includes control packets sent to the binary. These seem to consist of 2 'wakeup' commands, followed by a shell-command. The shell command will be run anytime it is asked for, however the network-replies are only initiated if the 'wakeups' have been sent priorly.
The easiest way to decode the incoming data is to modify the test system to force the malware to show it's plaintext. Observing that the malware executes its commands using 'csh' I accomplshed this by replacing /bin/csh with the following shell script.
echo $$ $* >> /root/.log
exec $3 $4 $5
Analysis of the data flowing in and out of the malware showed that the encoding consisted of "plainbyte=this byte+const - (prior byte+const)modulus 256". In order to fulfill the requirements of the challenge / contest I wrote the following 'C' program. Using this will require extracting the data from a network sniffer and stripping off the IP header.
/* the-binary-decode.c */
#include
void main (){
int s,c,i,l,o,t;
c=getchar();
c=getchar();
l=getchar();
s=getchar();
c=getchar();
o=c-72;
putchar(o);
t=c;
while ((c=getchar()) != EOF){
if (c-t == l) { /* */
break;
}
if ( t <= 136 ){
t+=256;
}
i=(c-(t+136))%256 - 143;
putchar(i);
t=c;
}
}
Intererestingly this does not correctly decode the network-replies provided as check data. I am not certain whether this is due to an error in the binary's encoder (What I take to be a stop byte is encountered in the message body), or whether I missed a nuance of the encoding. At any rate, fiddling with the input is adequate for this data, and the decoder works correctly on the data which I generated from the binary in live operation.
The binary's traffic can be captured with the snort rule:
alert ip any any <-> any any (msg:"Illegal protocol"; ip_proto: 11; )
Better would be a rule which captures all unused protocols (252/254) within most LAN environments.
Another approach would be to watch for identical-content packets in general. The binary sends identical content packets to several locations (as a solution to using a , so an IDS configured to notify of duplicated packets would be a workable solution.
On execution the binary takes some steps to make its presence less likely to be observed. It starts by immediately executing a fork() which is probably intended more to make program tracing difficult. The next step it takes in hiding itself is to overwrite the name in the process table as "[mingetty]". This seems to only affect the 'ps(1)' command, lsof for instance, and most of the entries in the /proc/[pid] tree see the correct command name.
The binary may undertake additional methods such as overwriting its data in memory. However in keeping with minimizing expenditure I did not undertake a disassembly analysis at the level to find this.
The use non-connected sockets makes it easy for the attacker to spoof the source IP address. This may provide a degree of anonymity, or this attack may be specifically intended for cases where the attacker has the ability to sniff packets traversing the targets connection.
The choice of libc 5.3 may be intended to make reverse-engineering more difficult. I suspect that available decompliers are more focussed on current versions of Linux / gcc.
Adore, RST (remote shell trojan)
I would guess that this intruder has a moderately high skill level. The code seems to have been grafted onto netcat, and while it does not present a polished interface it seems to be an original work.
Based on the choice of /bin/csh I might guess that the author of the binary has worked in BSD.
A Google search for 'trojan' and 'nazgul' turns up some interesting matches. No comment on whether there is a relationship :-)
I expect it's safe to guess that improved data-hiding and the use of flexible tunneling would be reasonable steps from where this binary has
Copyright © 2002 FW Systems LLC, All Rights Reserved