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.

The Hack without a Hack - Part 3

Yes, I've finally started to update my story. If you've forgotten what has happened, check out part 1 and part 2.

With a few quick Google searches Bill was able to find a few programs which would reveal any passwords which were hidden behind asterisks in Windows programs. More often than not, these "hidden" passwords were just being hidden from view and were decoded behind the scenes within the program. A number of programs are available which will reveal the hidden passwords and Bill found one he liked - Password Spectator (http://www.refog.com/passwordrecovery/).

A quick install and one click later and the password was revealed: "banklogin". Lame, Bill thought. It almost deserves to be broken into.


Bill opened up a telnet session to the trading machine, logged in as "trader" and began exploring the server. The server was a Debian Linux 4.0 server. From the routing tables on the machine it appeared to have a direct connection to the third party service, probably through a frame relay connection. This allowed for real-time trading to take place.

Bill couldn't tell if the third party service had access into this server, but running the "last" command, which displayed the last users to have logged on and where they came from, he did not see any connections from the other company.

Bill was logged in as user "trader". There were two other user accounts on the system: "admin" which was probably used to administrate the application and "root", the super-user account for the system. Bill's account appeared to have very little access on the system which meant he would not be able to install a sniffer unless he obtained root access.

However, since this was a 3rd party system the administrative passwords the bank normally used did not work for root. Bill tried a couple of common passwords with no luck. Quickly, though, he cursed himself for trying. Upon examining /etc/syslog.conf, the UNIX file which dictates what log messages go where, he found that any error messages were sent back to the 3rd party and to a system which he did not have access to. This meant that all of the failed password attempts he just tried were logged on another system - if anyone was watching those logs then he was sure to be discovered. Bill had to get root access quickly so he could cover his tracks.

Having administered various UNIX and Linux systems in the past, Bill knew where to look in order to find system weaknesses. After a few minutes of searching, Bill found his path to root in /var/spool/crontabs.

So, if anyone is reading this, what else could Bill have done to get the trader password? Any thoughts on how he'll get root access?

The Hack without a Hack - Part 2

The XStart file was a configuration file used to login and start the trading application (located on another server). The file kept the user ID, password and method of entry into the server, and with it, Bill could log in as Louis. A plan started to formulate in his mind.

Bill knew that the traders remotely logged in to the server to run their trading application. All traders went through this server to a third party service. He didn't know much more than that, other than that was the application the traders were constantly in - exchanging money on their clients behalf. Bill began to ponder how much money actually went through that server on a daily basis. It had to be in the millions.

If he could get on that server and set up some type of sniffer, there was a good chance he could start pulling down account numbers and such. From there, who knows what type of money he could get? Bill had long ago decided that if he found a way to make some quick money at the bank he would. He had every indication that he would have no problem getting away with it. Besides, even if it was noticed it would be under Louis' ID and he would get fired.

With his plan in mind, he downloaded the file to his computer and unmounted the drive. Already having Exceed loaded on his computer, he started the XStart program and loaded the trader's file.

Immediately, the window which popped up in front of him told him the server's address, the trader's user ID and the protocol used to log in. Unsurprisingly, TELNET was used. For a bank, Bill thought, they sure skimped on security where they could.


Bill wanted to log on to the server to see what was on there but he knew that he couldn't just run the XStart file. If he did, it would launch the trading application and Louis would get kicked off as it only allowed one of the same login at a time to be on. That would alert him something was wrong and things could go down from there. If only he could get the password from the file.

Opening up the XStart file proved un-fruitful. It was some kind of binary format and didn't appear to store any type of clear-text password anywhere in the file. There had to be another way, Bill thought. Within a few minutes of searching Google, he had his answer.


Anyone want to venture a guess as to what Bill found?

The Hack without a Hack - Part 1

As a tribute to Security Monkey I am going to start publishing my own "case" files. However, instead of looking through the eyes of an investigator I am going to look through the eyes of an attacker. My goal is to give a different perspective to attacks in order to help understand why some attacks occur as well as how they occur. This first one is called "The Hack without a Hack".

Bill sat at his computer and cursed his job once more. To say he was unhappy was an understatement. Just three months ago he had been the head of the helpdesk of a large transportation corporation. Now, due to "cutbacks", he was the one-man personal help desk for a bunch of whiny traders at a national bank...and making $30,000 less a year. It couldn't get any worse.

His phone rang. He realized it just did.

------------------

Twenty minutes later Bill came back to his desk, swearing under his breath. Stupid traders, he thought. Bill hated the traders but this one, Louis, was the worst. Always having idiotic problems with his computer which wouldn't happen if he didn't download so much crap. This time was no exception.

Louis' computer had frozen and after a reboot he only let Bill look at the computer for five minutes before he had to get back "to the market". Kid was probably 10 years younger than him and made triple his salary. Man, how he would love to do something to him.

Bill had figured out the problem after seeing an icon in the desktop that wasn't supposed to be there. Louis had once again downloaded some new application to stream market reports to him. The problem was it was written poorly and had crashed the machine. Of course, due to the "market being open" Bill was only allowed to get the PC back up and running (a reboot) and then had to leave.

Unbeknownst to Louis, however, Bill had gotten the local administrator password to his machine. It wasn't hard - the company had the same administrator password on every computer. With the password, he could mount Louis' drive remotely to see what else the he had installed. Maybe he could even find something he could anonymously send to internal security to get Louis fired. He smiled at the thought as he began looking around.

Within minutes, Bill found something that piqued his interest. Within the trader's home directory on the system he found the trader's Hummingbird XStart file to the remote trading server.


So, any thoughts as to what Bill could be planning?