I skimmed the packets and immediately started to ascertain what had happened, which I will explain in detail below.

[logs cut short due to repeated patterns]

Something worth noting in this packet are the "@" symbols above; hexadecimal (0x801c4011) is NOP instruction code for the Sparc architecture. The more familiar NOP slide being 0x90, however, will only work on i386 machines. What exactly is a NOP slide? It's a means of padding the buffer in an exploit where it is not immediately known where code execution will begin. If the exploit points to any place in the NOP padding, the CPU will follow the NOP slide into the executable code.

I then used tcpdump to output all the hex dumps of each packet sent to this specific destination IP into readable format.

Piecing together "The Big Picture"

As I went down through the logs I found the packet responsible for executing code on the server:

Code executed:

As we can see, the exploit makes use of the Korn shell by creating a file within the /tmp directory called "x". Within this file, it creates an inetd.conf style entry and starts the inet daemon, using the file "/tmp/x" as its configuration file. This spawns a root shell on the ingreslock port (1524/tcp). The ingreslock port has had a history of exploit shells bound to it, including, but not limited to, rpc.cmsd, statd, and tooltalk. As you can see, dtspcd is in good company.

The first step in our analysis is complete. We have now discovered how the intruder managed to gain access to the system. We can now take a second look at the logs, taking in all relevant information regarding port 1524/tcp where the intruder is sure to have opened up some sort of raw connection (most likely telnet) to issue commands on the server.

This packet shows us the commands that were run when the intruder made a raw connection with port 2514/tcp.

Code executed:

Obviously, this was an automated command, which was executed once a raw connection was established with the compromised system. We can tell this from the time-stamps on each Snort packet. We know the command was issued at exactly, 14:46:18.398427, as seen in the above packet dump. As evident from the logs, the command was then processed and executed, all in under a single second, at 14:46:18.901413.

The packet dumps below explain more:

This packet follows the automated command above.

Executed Comands

I have provided only a few of the numerous commands executed by the intruder. The following are some of the manual commands issued within an interactive shell. I can decipher the automated and manual commands due to the session duration as each command is executed.

Manual commands were then issued once the automated commands were executed. Each command and reply are shown below:

FTP Session Analysis

The above text was then further broken down using Ethereal Follow TCP Stream option.

As we can see, the intruder established an ftp connection to a remote machine and retrieved a file called "sun1". Once the ftp connection was closed, the intruder then modified the file permissions of the sun1 file and renamed it to /bin/login as seen by the session dump above.

To take a closer look at this, I again used tcpdump to output all the ftp-port packets into readable format.

Judging by the intruder's last commands, it looks like some form of edited /bin/login program, obviously trojaned with a backdoor of some sort. I then decided to take another look at the Snort logs using Ethereal to reproduce the sun1 program, which allowed me to conduct a further analysis on what the program was.

Retrieving "sun1" Binary File

Using Ethereal's TCP Recovery feature, I opened up the Snort binary file, right clicked on one of the FTP-DATA packets, and selected "TCP Stream" from the Ethereal options. Once complete, I then saved the file under the name of "sun1" in ASCII format.

Analyzing the Binary

Once I saved the binary, I analyzed the file command by running:

We know that the sun1 file was compiled on a SUN Operating System with all extra debugging information removed, which could have been used to aid us in using the strings command, but for what purpose was this binary file retrieved? Let's find out.

Also, notice how the file is statically linked. This tells us that this binary doesn't call upon any libraries on the host system and can be run independently: the code is fully mobile from system to system. First, let's give the strings command a try to see what we can pick up. We can do this by issuing the following command at our console.

We get quite a large output from this command, roughly 1245 lines total. While scrolling through the printable character sequences produced by the strings command, the following lines caught my eye.

Going on the above information, I attempted to export pirc into a DISPLAY variable in bash using the following command. -bash-2.05b$ DISPLAY=pirc, running the binary with truss, a system command designed to trace system calls' specified processes or programs. I did not have a Sun box to run the binary file on in order to gather additional information.

So what did we learn about the binary file? Apparently, the sun1 file is some sort of backdoored login program. When the intruder gained access to the system, he renames the original /bin/login to /usr/lib/libfl.k and replaces it with the sun1 binary. It is hypothesized that the sun1 trojan/wrapper of /bin/login will not log connections using the backdoor password.

On checking the recovered file using strings(), we can see that the file is somehow linked to a "/usr/lib/libfl.k" file, the original login program. To me, it seems that the file checks for a specific setting on the DISPLAY variable, in this case, I believe the key to be "pirc", which activates the backdoor and drops the user into a root shell. Otherwise, the program dumps the user at the original login program.

I decided to have a quick search for the source code to this binary file, in hopes of retrieving additional information. I went to Packet Storm and conducted a search for "rootkit trojan DISPLAY pirc". The following was the first result that turned up:

UNIX/penetration/rootkits/ulogin.c 4d5c12f579e07686a1b350c0064601f4
Universal login trojan - Login trojan for pretty much any O/S. Tested on Linux, BSDI 2.0, FreeBSD, IRIX 6.x, 5.x, Sunos 5.5,5.6,5.7, and OSF1/DGUX4.0. Works by checking the DISPLAY environment variable before passing the session to the real login binary. Homepage here. By Tragedy

It seems obvious from the description above that this ulogin.c program is indeed the sun1 binary that was recovered from the Snort logs.

The following is the source code from ulogin.c found on Packet Storm.

Final Binary Analysis

As we can see in the source code, the attacker is to issue the following commands in order for this backdoor to work correctly.

from bourne shell (sh, bash) sh DISPLAY="your pass";export DISPLAY;telnet host

Using this information, we can begin to guess how this backdoor dumps the user at a root shell. Since the backdoor calls on the original "login" program, it's safe to say, if the DISPLAY variable isn't set to the correct parameters, it will pass you back to the original login program specified in the source code of the exploit by the following line.

By looking at the payload from the exploit once the buffer-overflow was successful we can see the command(s) executed by the intruder.

Reference: FTP SESSION ANALYSIS

The above command(s) were issued and we saw how the intruder created a root shell running on port 1524 (ingereslock port), using inetd. We can see four (4) different commands being executed within the above command string. If we break them up, we can then decipher which commands did what.

This command uses the Korn shell to create a file called /tmp/x with a one line entry of an inetd configuration file. The file /tmp/x contained the inetd configuration entry of "ingreslock stream tcp nowait root /bin/sh sh -i".

It then attempts to start inetd using /tmp/x as its configuration file.

This tells the system to stall for 10 seconds to allow the inetd process to restart when being restarted with its new configuration script.

This command simply removes the /tmp/x file which is being used as the inetd configuration file from the tmp directory once inetd has restarted.

Conclusion

The need for increased vigilance in learning forensic analysis with and without IDS logs continues to grow. The reality of this industry remains the same, despite the continued changes and advancements in the types of tools hackers will use. The fact remains that Snort and other IDS solutions are currently limited to signature-based detection. If an unknown exploit is used against a network that is being monitored, the only evidence from the crime scene made available are system and application log files. As a result, it is critical to ensure that logs remain sanitized by storing them remotely for follow-up investigations.

By monitoring one's system logfiles and utilizing intrusion detection systems such as Snort on both large and small production networks, systems administrators can gain additional coverage and photographs to go back and look at when something occurs.

Tools Used Within This Analysis

tcpdump - Tcpdump prints out the headers of packets on a network interface that match the boolean expression

Ethereal -Ethereal is a GUI network protocol analyzer. It lets you interactively browse packet data from a live network or from a previously saved capture file.

File - The file utility conducts three sets of tests; filesystem tests, magic number tests, and language tests printing out the file type.

Strings - For each file given, GNU strings prints the printable character sequences that are at least 4 characters long and are followed by an unprintable character.

Truss - The truss utility traces the system calls called by the specified process or program.