From China with Love? (Part 2)

In part 1 of this series, I detailed an intrusion to my SSH honeypot. If you didn't read part 1, you might want to for background info before reading this one.

Linux forensics/incident response is a new thing for me. I've never had occasion thus far to conduct a "real" investigation into a Linux machine. This "intrusion" into my honeypot inspired me to conduct my own attack and investigation so I could learn more about the subject. I'm a noob to this stuff, so if you see things I did wrong or could have done better, I'd be delighted to hear constructive criticism from you.

Given my lack of experience with Linux based investigations, I've searched for information on the subject but haven't found a lot. I read the excellent book by Chris Pogue, Unix and Linux Forensic Analysis DVD Toolkit a few years ago and still refer to it from time to time. A note to Chris, I'd still love to see a second edition of the book! But I digress...

I began by creating a new Ubuntu Server 12.04 server virtual machine. I installed openssh-server so I could connect to the VM from the host and placed the VM network settings to Host Only. I also set a password for the root user, so I could log in immediately with root privileges, just as my honeypot attackers had done.

I installed Inetsim on my host machine and placed a copy of the file my attackers had downloaded to my honeypot to the "fake" files so I would be able to download it in the VM. Prior to starting my attack, I configured Inetsim to be listening on the Host Only network and started the program. I also started tcpdump, using the -i option to listen to the host only, vmnet1 adapter and -w to output a .pcap file. Finally, the time to attack had arrived.

With my virtual machine running and logged out, I opened a terminal on the host machine (Ubuntu 14.04 LTS) and typed the command:

ssh root@172.16.126.131

I was greeted by the usual warning that the system can't identify the authenticity of the host I'm trying to connect to and wanting me to verify I really wanted to do it. I hit Y and the host was added to the .ssh/known_hosts file. After entering the password, I was in and ready to do my nefarious deeds.

I decided to type in all the same commands my honeypot attacker had, with a couple of exceptions. When I got to the point of downloading the file, I decided to just make up a fictional URL instead of using an IP address with port number, as the real attacker had done. I also decided to simply execute the file once downloaded instead of using the nohup command so I could be a little more sure I would see everything in my memory capture. I may do it again later with the nohup command and compare the results of memory analysis.

After going through all the commands the real attacker had, including downloading the .bash_root.tmp3 file to the /tmp directory and running it, I entered the ps x command, just to see what I could see before logging out. I noted the downloaded file was running in memory as expected. I then logged out and disconnected from the ssh session.

My initial plan was to conduct the attack on a virtual machine, then pause it and collect the .vmem file for memory analysis, followed by grabbing the .vmdk file for disk analysis. However, that didn't seem very realistic, so I changed my plan.

For the memory collection, instead of using the .vmem file, I decided to use Hal Pomeranz' Linux Memory Grabber script (lmg). lmg makes use of Joe Sylve's excellent LiME, a loadable kernel module which allows the collection of RAM from a Linux or Android system. lmg also makes use of Volatility and dwarfdump to create a Linux profile of the system for use with Volatility. I have used LiME by itself before with good results, but I wanted to try lmg and see how it worked automating the collection of memory and the creation of the Volatility profile.

I followed the directions for setting up lmg on an 8 gb thumb drive, but had some problems getting lmg to setup properly. Hal was kind enough to help me with it and I was able to use it for this investigation. I won't go into how to set it up here. You can read the install directions on the lmg Github page. I added a static version of dwarfdump and a freshly downloaded copy of Volatility 2.3.1 to the thumb drive and tested it on a non-infected system with positive results.

I went back to the virtual machine, logged in as root and mounted the lmg thumb drive. The simple command ./lmg -y started the script and it executed with no problems. lmg captures RAM and saves it in a capture folder on the thumb drive. As noted previously, it also automatically creates a Volatility Linux profile and saves it to the thumb drive as well. The VM only had 1 gb of RAM, so this process didn't take long. Once it was complete, I shut the VM down.

I next went to the VM folder on the host machine and used dc3dd to make a copy of the .vmdk file. Kinda silly, I guess, but I wanted to do things semi-realistically. I could have booted the VM again to a live CD and imaged it that way, but decided I would save a little time.

So now, I have a RAM capture, a disk image and a .pcap file. I'll be taking a look at the RAM capture first with the awesome Volatility and post about that in part 3. I will also post the Linux profile to my Linux Volatilty Profiles Github page soon.