Monday, December 27, 2010
Quick Update
I was reminded by a friend today that it had been quite awhile since the last post here. With all of the family obligations at Christmas time, I simply haven't had enough time to put part 2 of the Beast post together yet. I hope to get it out sometime this week. Thanks for checking in!
Friday, December 17, 2010
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.
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.
Sunday, November 28, 2010
Just a Quick Post
I was reading Harlan's blog tonight and saw his reference to Corey's blog post about timeline analysis and using the Calc spreadsheet program in OpenOffice.org to view the timeline. He had run into the 65,000 row limit in Calc when his 100,000+ line timeline was truncated.
He got around that by testing a release candidate for OpenOffice 3.3, which does support a million rows. Version 3.2.1. is still the actual current version, but apparently 3.3 will be out soon. I went to the OpenOffice site tonight to try to download a copy of the release candidate, but all the links to the RC were taken down in preparation for the release of RC 7, so I wasn't able to check it out.
I ran into the 65,000 row issue awhile back while reviewing the output from Mark Menz's MFTRipper program. Given the low budget outfit I work for, I don't have Microsoft Office, which started supporting more than a million rows with Office 2007. I did some searching at the time to find the answer to my problem and came up with a version of OpenOffice called Go-OO. The version of Calc included with it has support for a million rows.
That's all I have right now, but thought I should get this out there in case anyone else was in the same boat.
He got around that by testing a release candidate for OpenOffice 3.3, which does support a million rows. Version 3.2.1. is still the actual current version, but apparently 3.3 will be out soon. I went to the OpenOffice site tonight to try to download a copy of the release candidate, but all the links to the RC were taken down in preparation for the release of RC 7, so I wasn't able to check it out.
I ran into the 65,000 row issue awhile back while reviewing the output from Mark Menz's MFTRipper program. Given the low budget outfit I work for, I don't have Microsoft Office, which started supporting more than a million rows with Office 2007. I did some searching at the time to find the answer to my problem and came up with a version of OpenOffice called Go-OO. The version of Calc included with it has support for a million rows.
That's all I have right now, but thought I should get this out there in case anyone else was in the same boat.
Wednesday, November 24, 2010
Back on track
A day later than planned, but I'm finally back on here and adding some content. I've gotten a lot of positive feedback regarding starting the blog and I really appreciate that.
A great deal is going on in my life these days with regards to digital forensics and it's really exciting. First, not many know this, but I'm co-writing a book with two very good friends, Brad Garnett and Joe Garcia. The title will be The Basics of Digital Forensics. We just recently got started, so lots to do yet. We're trying to write the book we wished we had back when we were first getting started. More on this later!
Next, I got a surprise phone call from the local junior college a few days ago asking if I'd be interested in helping develop and teach a computer forensics course. I'm very excited by the possibilities and plan to meet with them next week to discuss it further.
Meanwhile, I continue reading the Malware Analysts Cookbook in my spare (ha!) time. Kudos to Michael Hale Ligh, Steven Adair, Blake Hartstein and Matthew Richard for creating this excellent book. I'm only up to chapter 7 at this point, but I'm finding it very interesting indeed. I like the writing style and the exercises and examples are very well done. I do wish I had a background in programming, especially javascript and Python, just so I would better understand some things I've read so far. However, the way the book is written helps make up for my lack of programming knowledge.
Finally, I repaired my sisters computer recently when it had a rogue defrag program on it. This is similar to the rogue antivirus programs, but instead of bogus virus infection reports, the rogue defrag pretends to scan your hard drive and finds all sorts of dire problems with the drive and the file system. What it's really doing during the "scan" is installing itself to your hard drive, complete with program group in the All Programs listing and icons. They only want $80 to register the defrag so it can fix the physical errors on your hard drive...what a deal!
Prior to starting the removal process, I imaged RAM using windd and then imaged the hard drive. I created a Super Timeline from the drive image, though I haven't had sufficient time since doing it to really look it over. I also used the excellent Volatility Framework to look at the memory image. I was able to find some interesting info in that, which I'll detail in a near-future blogpost, along with other details of the malware I found. But for now, it's late and I'm tired, so I'm ending this post here. I hope everyone has a great Thanksgiving!
A great deal is going on in my life these days with regards to digital forensics and it's really exciting. First, not many know this, but I'm co-writing a book with two very good friends, Brad Garnett and Joe Garcia. The title will be The Basics of Digital Forensics. We just recently got started, so lots to do yet. We're trying to write the book we wished we had back when we were first getting started. More on this later!
Next, I got a surprise phone call from the local junior college a few days ago asking if I'd be interested in helping develop and teach a computer forensics course. I'm very excited by the possibilities and plan to meet with them next week to discuss it further.
Meanwhile, I continue reading the Malware Analysts Cookbook in my spare (ha!) time. Kudos to Michael Hale Ligh, Steven Adair, Blake Hartstein and Matthew Richard for creating this excellent book. I'm only up to chapter 7 at this point, but I'm finding it very interesting indeed. I like the writing style and the exercises and examples are very well done. I do wish I had a background in programming, especially javascript and Python, just so I would better understand some things I've read so far. However, the way the book is written helps make up for my lack of programming knowledge.
Finally, I repaired my sisters computer recently when it had a rogue defrag program on it. This is similar to the rogue antivirus programs, but instead of bogus virus infection reports, the rogue defrag pretends to scan your hard drive and finds all sorts of dire problems with the drive and the file system. What it's really doing during the "scan" is installing itself to your hard drive, complete with program group in the All Programs listing and icons. They only want $80 to register the defrag so it can fix the physical errors on your hard drive...what a deal!
Prior to starting the removal process, I imaged RAM using windd and then imaged the hard drive. I created a Super Timeline from the drive image, though I haven't had sufficient time since doing it to really look it over. I also used the excellent Volatility Framework to look at the memory image. I was able to find some interesting info in that, which I'll detail in a near-future blogpost, along with other details of the malware I found. But for now, it's late and I'm tired, so I'm ending this post here. I hope everyone has a great Thanksgiving!
Sunday, November 21, 2010
Welcome
Welcome to the new Digital Forensics Blog! You're probably thinking we don't need another forensics blog and you might be right. Still, I find there are times I'm researching some forensic and/or malware artifacts and learn something I think is worth sharing.
My plan to keep this blog focused on computer and malware forensics, as those are my primary interests these days. In addition to this, I also write for the SANS Forensic Blog but thought I'd start my own for when I want to write about something that doesn't really fit in there.
I intend to add some actual content today or tomorrow, so in the immortal words of Paul Harvey, stand by for news! I welcome comments, but try to be nice ;-)
My plan to keep this blog focused on computer and malware forensics, as those are my primary interests these days. In addition to this, I also write for the SANS Forensic Blog but thought I'd start my own for when I want to write about something that doesn't really fit in there.
I intend to add some actual content today or tomorrow, so in the immortal words of Paul Harvey, stand by for news! I welcome comments, but try to be nice ;-)
Subscribe to:
Posts (Atom)