Taming the Wild Beast--Part One

Recently, I was asked to look at a pc owned by a church.  The machine had been running poorly and was being used for nothing more than playing music for the pastor while he worked in his office, as its performance was so bad it just wasn't good for much else.  This didn't start out as a malware investigation, per se, so some of the steps I initially took probably weren't appropriate for that.  However, after finding some interesting stuff, I decided to look into it further.

I set the computer up in my home lab and booted it.  The OS was Windows XP Home, service pack 2.  I noticed right away it was not running any antivirus.  Given the lack of recent Windows updates or antivirus, I figured I'd find some kind of malware.  A quick run with Malwarebytes Anti-Malware proved I was correct in that assumption.  In addition to a registry key, which I'll describe later in this post, it identified an infected file at C:\DATA\FILES\BEAST.exe.

I opened up My Computer and then the C: drive to take a look before doing anything else.  Strangely enough, no folder called DATA was there.  Enabling the display of hidden files also failed to show the folder.  Finally, unchecking the box to hide operating system files revealed my folder.  Inside DATA, as expected, was a folder called FILES.  I expected to find the BEAST.exe file in there, but much to my surprise I saw the contents of the Recycle Bin and no beasts in sight.  This is the first malware I've dealt with in quite awhile that puts itself in a brand new location it creates and then hides it with system attributes.

This was getting interesting for a malware noob like me.  Honestly, I found it ironic and kinda funny that "the beast" was in a church computer and wondered if an exorcism was more in order than a malware removal.  I had several friends on Twitter inquire as to whether the malware was running with PID 666.

Instead of imaging memory on the church machine, I decided to grab a copy of the malware and run it later in a controlled environment in order to grab a memory capture.  I haven't had time to do that part yet, but plan to do so in the next day or two.  I  shut the system down, imaged the disk and made a "super" timeline from it, all using the superb SANS Sift Workstation VM running in VMWare Workstation.

The Sift workstation is something I use all the time.  It has so many things included in it, so it makes getting things done much easier.  In this case, I used it for making the timeline, as well as browsing the filesystem in the image from the relative safety of the Linux operating system so as to protect myself from "the beast".  For those unfamiliar, a Super Timeline is created using Kristinn Gudjonsson's Timescanner from Log2Timeline, along with fls and mactime from the Sleuthkit by Brian Carrier and the regtime.pl perl script by Harlan Carvey.  It provided me with some interesting info which I'll talk about in part two.

During this time, I also extracted the registry files from the system32\config directory, as well as the ntuser.dat from the main user account on the system.  I find that I use Harlan's RegRipper on nearly every type of exam I do these days.  If you're doing forensics and not using RegRipper, you're shorting yourself because it provides an amazing amount of information in an easily readable format.  It, too, provided me with some very relevant information related to this exam and I will cover it all as well in part two.

This didn't start out to be a multi-part post, but I'm finding this one is already very long.  Therefore, I shall continue in part two as soon as I can.