Once again, I have been derelict in posting regularly to this blog. I enjoy writing and documenting the cool stuff I'm working on, but lately it seems there's been too many other things going on in life to post on a regular basis. One of these days, things will slow down and I can do more fun stuff, like testing, experimenting and blogging about it all. Until then, it's going to be on an "as I have time" basis. I had a few things I wanted to talk about today, so away we go...
Have you ever been examining a system and found it was just too "clean?" I'm not talking about the absence of cobwebs and dust here, but rather the absence of practically any signs of use at all?
I recently examined a computer that only had user created data on it from a couple weeks earlier up until the time it was brought to me. I knew the alleged illegal use of the machine had occurred several months ago, so this made little sense. I pulled the registry files and also did a time line of the system. Using RegRipper, I took a look at the SOFTWARE hive and found the install date for the Windows 7 OS was only a couple weeks earlier. I followed up by looking at the time line, discovering the $MFT was created within a short time of the OS install date shown in the registry. Just to be extra thorough, I also extracted the $MFT and used David Kovar's excellent AnalyzeMFT python script to create a csv listing of the master file table information. All the data I was seeing was in agreement, so I knew something was up.
I immediately suspected the "factory reset" utility had been run and wondered if the purpose had been to destroy evidence. Continuing to look at the time line, it was pretty clear that the factory reset had taken place. After doing a bit more investigation, it turned out that a non-suspect user of the computer had run the reset after the suspect had acquired a virus on the machine they hadn't been able to get rid of. While the intent of the reset wasn't malicious, it did wipe out a lot of information. File carving with X-Ways Forensics and the use of the Hstex tool that comes with NetAnalysis provided a considerable amount of recovered data to the case and I was able to conclude the exam soon thereafter.
And now for something completely different.....
I wanted to mention some good stuff I've read lately that I found valuable. Harlan wrote an interesting post on MBR Infectors. I've never run into one, so it gave me some good ideas on things to check for in future exams. Seems like I'm running into more and more malware situations lately, which I enjoy, so I'm always glad to read things like this.
I also read a tweet this morning that mentioned Cuckoo, a malware analyzer sandbox. I haven't had the opportunity to try it out yet, but from reading over the website, it looks like it could prove useful. I'll post further after I've had time to dive into it (sometime next century, possibly, with my life ;-) ) From the project website, here is a list of it's capabilities:
• Retrieve files from remote URLs and analyze them.
• Trace relevant API calls for behavioral analysis.
• Recursively monitor newly spawned processes.
• Dump generated network traffic.
• Run concurrent analysis on multiple machines.
• Support custom analysis package based on AutoIt3 scripting.
• Intercept downloaded and deleted files.
• Take screenshots during runtime.
I can definitely use this if it does all that. I am looking very forward to giving it a look.
Tuesday, March 8, 2011
Thursday, February 17, 2011
Interesting Registry Keys with FakeAV Infection
So there I was (don't you love it when a story starts like that?), arriving at work recently when I was asked to look at a co-workers laptop that was infected with a fake antivirus program. Another co-worker had already done what I would have done, in that he ran MalwareBytes (MBAM) on the machine. However, I was surprised that MBAM hadn't even detected the infection. Neither had the installed real antivirus, Microsoft Security Essentials.
Upon starting the laptop and logging, I was greeted by the fake antivirus, "AntiViraAv". Of course, it started pretending to scan the hard drive and began presenting the traditional dire warnings of fatal virus infection and so on. I had read about this one on the S!Ri.URZ recently, so I went back and read that post again. It said running MBAM would fix the problem, although in our case it hadn't. I ran MBAM again, along with Super AntiSpyware, but again nothing was detected. MBAM is usually my go-to program for stuff like this, so I was surprised that hadn't worked. I took the machine to my forensics office, removed the hard drive and attached it via usb cable to another machine and ran MBAM and Vipre Antivirus against it, again coming up empty.
I pulled the registry files and took a look at the HKCU\Software\Microsoft\Windows\CurrentVersion\Run key, finding an obviously suspicious entry listed showing "podnkiwd: "C:\DOCUME~1\<USERNAME>\LOCALS~1\Temp\lyxnxvrky\rciprogsika.exe." Okay, this isn't the interesting part. Lots of different malware programs insert something in the Run key.
But that's not what I wanted to tell you about.
I wound up finding two copies of the malware with identical MD5 hashes, one in the Local Settings\Temp folder called "6.129952833419995E7.exe" and the other in a newly created folder called "lyxnxvrky" inside the Temp folder .This new folder contained the "rciprogsika.exe" file referenced above and it is identical in every way, except its name, to the "6.129952833419995E7.exe." I decided to test the malware further to see what all happened. I submitted it to VirusTotal and found that only 17 of the 43 scanners there detected it. Based on that plus the fact MBAM didn't recognize it, I believe this is a newer variant of the AntiViraAV rogue AV. As of this writing, my submission is still the only one for this particular version at VirusTotal.
So you're probably wondering, what's the big deal. What was interesting to me may not mean much, but I hadn't seen it before. Seasoned malware experts and incident responders may have seen the other registry additions/modifications I'm about to describe, so this may not be anything earth shattering. You have been warned.
I set up a Windows XP virtual machine in VMWare Workstation and placed a copy of the "6.129952833419995E7.exe" file in the Local Settings\Temp folder. I ran RegShot, got my baseline and then executed the malware file. Nothing visible happened, unless you were looking in the Local Settings folder. However, all sorts of things were happening in the Registry.
Three new keys were created in the registry:
My intent now is to learn a bit more about those new registry keys and values.
EDIT: By the way, the MD5 for this file is c6a3a4477e17570a5c1da58e34312b4b
Upon starting the laptop and logging, I was greeted by the fake antivirus, "AntiViraAv". Of course, it started pretending to scan the hard drive and began presenting the traditional dire warnings of fatal virus infection and so on. I had read about this one on the S!Ri.URZ recently, so I went back and read that post again. It said running MBAM would fix the problem, although in our case it hadn't. I ran MBAM again, along with Super AntiSpyware, but again nothing was detected. MBAM is usually my go-to program for stuff like this, so I was surprised that hadn't worked. I took the machine to my forensics office, removed the hard drive and attached it via usb cable to another machine and ran MBAM and Vipre Antivirus against it, again coming up empty.
I pulled the registry files and took a look at the HKCU\Software\Microsoft\Windows\CurrentVersion\Run key, finding an obviously suspicious entry listed showing "podnkiwd: "C:\DOCUME~1\<USERNAME>\LOCALS~1\Temp\lyxnxvrky\rciprogsika.exe." Okay, this isn't the interesting part. Lots of different malware programs insert something in the Run key.
But that's not what I wanted to tell you about.
I wound up finding two copies of the malware with identical MD5 hashes, one in the Local Settings\Temp folder called "6.129952833419995E7.exe" and the other in a newly created folder called "lyxnxvrky" inside the Temp folder .This new folder contained the "rciprogsika.exe" file referenced above and it is identical in every way, except its name, to the "6.129952833419995E7.exe." I decided to test the malware further to see what all happened. I submitted it to VirusTotal and found that only 17 of the 43 scanners there detected it. Based on that plus the fact MBAM didn't recognize it, I believe this is a newer variant of the AntiViraAV rogue AV. As of this writing, my submission is still the only one for this particular version at VirusTotal.
So you're probably wondering, what's the big deal. What was interesting to me may not mean much, but I hadn't seen it before. Seasoned malware experts and incident responders may have seen the other registry additions/modifications I'm about to describe, so this may not be anything earth shattering. You have been warned.
I set up a Windows XP virtual machine in VMWare Workstation and placed a copy of the "6.129952833419995E7.exe" file in the Local Settings\Temp folder. I ran RegShot, got my baseline and then executed the malware file. Nothing visible happened, unless you were looking in the Local Settings folder. However, all sorts of things were happening in the Registry.
Three new keys were created in the registry:
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Associations
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments
- HKEY_CURRENT_USER\Software\g043oqxanu
- [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Download]
- RunInvalidSignatures = 0x00000001
- [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Associations]
- LowRiskFileTypes = ".exe"
- [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments]
- SaveZoneInformation = 0x00000001
- [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
- rqluxpqp = "%Temp%\lyxnxvrky\rciprogsika.exe"
- [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Download]
- CheckExeSignatures ="no"
My intent now is to learn a bit more about those new registry keys and values.
EDIT: By the way, the MD5 for this file is c6a3a4477e17570a5c1da58e34312b4b
Wednesday, January 19, 2011
A Brief Update
After a bit of an equipment failure, I'm rebuilding my test machine prior to doing the dynamic analysis of the BEAST. Hope to have it back up and running very soon.
I've been continuing to experiment with things I read about in the Malware Analysts Cookbook in my spare time. I set up INetSim on a Linux machine after reading about it in the book. After one brief test, it seems to work very well and should make dynamic analysis of malware files more interesting and productive. I'm still figuring out some things about it, but I'm very impressed with how easy it is to set up and configure.
I had planned to do some more work with INetSim today, but since the test machine I was going to execute the malware on bit the proverbial dust, I spent my time setting up a new Linux based internal mail server for the sheriff's office. The server is running Ubuntu 10.10 Server and uses Dovecot and Postfix for mail. It's also running Apache with Squirrelmail so the deputies can choose between using an email client, like Outlook, etc, or accessing their mail via a web interface. I finished getting it running tonight and all seems to be working well. Just have to get the user list and the IP address it will be assigned to and I can put it in service for them.
Finally, I'm no longer involved in writing a book. My partners and I were unable to work out some conflicts with the publisher, so we and the publisher have amicably parted ways. I hope to one day be involved in writing a book, but I think it just wasn't meant to be at this point.
That's about it for now. Hope to be back with another installment in my relentless pursuit of the BEAST in the near future.
I've been continuing to experiment with things I read about in the Malware Analysts Cookbook in my spare time. I set up INetSim on a Linux machine after reading about it in the book. After one brief test, it seems to work very well and should make dynamic analysis of malware files more interesting and productive. I'm still figuring out some things about it, but I'm very impressed with how easy it is to set up and configure.
I had planned to do some more work with INetSim today, but since the test machine I was going to execute the malware on bit the proverbial dust, I spent my time setting up a new Linux based internal mail server for the sheriff's office. The server is running Ubuntu 10.10 Server and uses Dovecot and Postfix for mail. It's also running Apache with Squirrelmail so the deputies can choose between using an email client, like Outlook, etc, or accessing their mail via a web interface. I finished getting it running tonight and all seems to be working well. Just have to get the user list and the IP address it will be assigned to and I can put it in service for them.
Finally, I'm no longer involved in writing a book. My partners and I were unable to work out some conflicts with the publisher, so we and the publisher have amicably parted ways. I hope to one day be involved in writing a book, but I think it just wasn't meant to be at this point.
That's about it for now. Hope to be back with another installment in my relentless pursuit of the BEAST in the near future.
Wednesday, January 5, 2011
Cyber Crime 101 podcast appearance
Just wanted to do a quick post and say I was interviewed by my friend, Joe Garcia, for his Cyber Crime 101 podcast. You can listen to his excellent show at www.cybercrime101.com and the specific show I'm on is at www.cybercrime101.com/episode-23-forensics-on-a-budget . Thank you to Joe for asking me to join him for the show!
Tuesday, January 4, 2011
Taming the Wild Beast--Part Two
When last we left our hero, he was trying to figure out how the BEAST got on a church computer. The BEAST being BEAST.exe on a Windows XP Home computer owned by a church. Since that time, I have spent time looking at the Master File Table, a Super Timeline created from the system and taken a look at prefetch files. I'd like to say after all that I had come to an "ah ha!" moment and I would know how the malicious file managed to get on the system. I would also like to say I was given a billion dollars, but that wouldn't be any more true than my saying I figured out where this file came from. But I digress...
As I said in the last post and above, I created my Super Timeline and started looking through it around the date and time this file appeared on the system (August 10, 2010 at 13:51:06). I noticed a flurry of activity all around that time, with the folders C:\DATA and C:\DATA\FILES, along with the files BEAST.exe and Desktop.ini being "born" then on the system. The two files were both placed in the C:\DATA\FILES folder. Also at the same time, more than 30 of the restore points on the system had new "ini" files added to them. All of those ini files were copies of the Desktop.ini mentioned above. Prior to that, a little unremarkable looking web browsing took place.
Next, I used the excellent AnalyzeMFT python script, created by my good friend, David Kovar, to parse the Master File Table. I wanted to compare the standard info file times to the filename info times, just to make sure no file times had been fiddled with. Nothing appeared out of line, so I moved on for the time being.
(Edited to fix something I didn't very clearly state at first)
Using X-Ways Forensics, I opened the drive image and looked at the Windows\Prefetch directory to see if there were any references to the BEAST. Sure enough, BEAST.EXE-3696224B had been there but was deleted. However, X-Ways was able to display it and tell me it had a total run count of 2 and last run date of 11/17/2010 08:42:55, which was quite awhile prior to my receipt of the machine.The MAC times were the same as the last run date/time. Because the file had been deleted, it did not show up in my timeline or MFT report.
So now what? Not to fear, there is always more to do when trying to figure these things out. While I still have no real idea beyond a basic theory how this thing got on the system, I will continue with part three after doing some more analysis, including executing the file on a stand-alone computer and doing a live capture, which will hopefully give me a better idea of what all was going on here. I have a computer similar to the actual victim system that I refurbished for just this purpose and plan to execute the malware on it. I will be capturing RAM and using RegShot along with a few other programs to see just what happens when the BEAST is executed. Sure, I could just submit the file to Joebox, Anubis or ThreatExpert and get a detailed report, but what fun would that be?
EDIT
After making this post, I went back and looked at things I previously missed. I went back to the timeline and looked for the date and time of the above mentioned prefetch file. I found that a registry key had its "creation" time updated to the same date/time. That key is HKEY_USER/Software/Microsoft/Windows/CurrentVersion/Explorer/StreamMRU. From the little bit of reading I've done about it, it seems that key is where Windows saves the size and location of a window when it is closed. Not too sure how this goes along with the malware yet, but I plan to find out!
As I said in the last post and above, I created my Super Timeline and started looking through it around the date and time this file appeared on the system (August 10, 2010 at 13:51:06). I noticed a flurry of activity all around that time, with the folders C:\DATA and C:\DATA\FILES, along with the files BEAST.exe and Desktop.ini being "born" then on the system. The two files were both placed in the C:\DATA\FILES folder. Also at the same time, more than 30 of the restore points on the system had new "ini" files added to them. All of those ini files were copies of the Desktop.ini mentioned above. Prior to that, a little unremarkable looking web browsing took place.
Next, I used the excellent AnalyzeMFT python script, created by my good friend, David Kovar, to parse the Master File Table. I wanted to compare the standard info file times to the filename info times, just to make sure no file times had been fiddled with. Nothing appeared out of line, so I moved on for the time being.
(Edited to fix something I didn't very clearly state at first)
Using X-Ways Forensics, I opened the drive image and looked at the Windows\Prefetch directory to see if there were any references to the BEAST. Sure enough, BEAST.EXE-3696224B had been there but was deleted. However, X-Ways was able to display it and tell me it had a total run count of 2 and last run date of 11/17/2010 08:42:55, which was quite awhile prior to my receipt of the machine.The MAC times were the same as the last run date/time. Because the file had been deleted, it did not show up in my timeline or MFT report.
So now what? Not to fear, there is always more to do when trying to figure these things out. While I still have no real idea beyond a basic theory how this thing got on the system, I will continue with part three after doing some more analysis, including executing the file on a stand-alone computer and doing a live capture, which will hopefully give me a better idea of what all was going on here. I have a computer similar to the actual victim system that I refurbished for just this purpose and plan to execute the malware on it. I will be capturing RAM and using RegShot along with a few other programs to see just what happens when the BEAST is executed. Sure, I could just submit the file to Joebox, Anubis or ThreatExpert and get a detailed report, but what fun would that be?
EDIT
After making this post, I went back and looked at things I previously missed. I went back to the timeline and looked for the date and time of the above mentioned prefetch file. I found that a registry key had its "creation" time updated to the same date/time. That key is HKEY_USER/Software/Microsoft/Windows/CurrentVersion/Explorer/StreamMRU. From the little bit of reading I've done about it, it seems that key is where Windows saves the size and location of a window when it is closed. Not too sure how this goes along with the malware yet, but I plan to find out!
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.
Subscribe to:
Posts (Atom)