My First Malware Analysis

For some reason I was thinking about one of the first malware analysis/reverse engineering attempt I did. It was about 7 or 8 years ago (wow) and I was looking at a RedHat 6.2 web server. I had been given an account there from a local business in order to make sure the security of the server was up to par.

I tried to recreate this as much as possible to give a visual reference. Since I'm going by memory I'm sure I missed something so please forgive me.

While looking over the server I noticed there was an interesting account in /etc/passwd with a UID of 0 named toor. For those not in the know, a UID of 0 on a *nix box is the super-user account on the system. The games user, which no one should be able to log in as, had a password assigned to it. Soon, I found a directory named "..." in /dev, and within that directory were a number of tools.


Additionally, while most of the system logs had mysteriously disappeared, those that were left had a number of messages stating the server was in "promiscious mode". This server had been compromised.


This was really my first attempt into forensics and at the time there were no computer forensic resources available to non-LE folk (or at least I didn't know of any). In other words, looking back I did a number of things I wouldn't do now.

I copied the tools down to my local computer and started looking it over. The files I remember were:

• A psybnc IRC eggdrop
• A sniffer which would scan traffic for credentials and save them to a file. A file was also present which contained a few credentials which had been captured.
  
• A number of log cleaning utilities
  
• A rootkit.tgz file which contained compiled binaries and not source code.

The rootkit tgz file was the most interesting to me since I had never run across one before. Through some research, I discovered that it was LRKv5 (Linux Rootkit version 5) and had downloaded the source code. (You can still download the source code for it today.)

Through reading the files which came with the source I found that the rootkit would backdoor the login process (and a number of other files) such that anyone could log in or become root by knowing a secret, hard-coded password. I had the overwhelming urge to figure out what that password was. The default password of "satori" did not work, so I had to come up with a way to figure it out.

So, I started to reverse the backdoor program in order to determine how to find the password. I still use these techniques when RE'ing malware today.

I ran strings on the program to see if I could pick out the password. Nothing jumped out at me as a potential password, but I did see a number of gcc and glibc version numbers within the binary which told me it had been compiled on a RedHat 6.2 box. In my mind, that meant I could take the source, change the password to something I knew and look for it in the binary. With any luck, I could look in the same place on the rootkit'd server and find the attacker's password.

So thats what I did. I changed the password in the source code to a password which I knew and compiled the login binary. Due to the way the binary stored the backdoor password, strings did not see it.

I opened up the binary in a hex editor and started searching for my password. Eventually, I was able to find the password and record its offset. In the picture below. the password starts at offset 0x196f and the each letter is a few bytes after.


I grabbed the backdoor'd file on the compromised server, threw it in a hex editor and found what looked like it could be the attacker's password. (In the picture below the password is "pebcak".)


To test it, telnet'd to the compromised box and logged in as a normal user with the backdoor password...successfully! I then su'd using the backdoor password and I was root! Needless to say, I sat there for a few minutes with my eyes wide open that it actually worked.

Would this work now on a modern Linux system with the same type of rootkit? Possibly.

In a few days, I'll post part two of this where I analyze what I did wrong forensically and how it should have been handled.