Dear Diary: AntiMalwareLab.exe File_Created

I have previously posted about the usefulness of parsing the NTFS Master File Table during static malware analysis.  The Master File Table ($MFT) is only one of the twelve metadata files in NTFS file system however. The $Extend object ($MFT Record Entry 11) is used for optional extensions to NTFS. Beginning with Windows 2000, Microsoft added change journaling ($UsnJrnl) to this list of NTFS extensions. $UsnJrnl is turned on by default in Windows Vista and 7, and records all changes that are made to the file system. It should be noted that changes recorded do not include what specific data changed, rather just the type of change and time stamp of when the change occurred.. This can still be useful however when attempting to establish a timeline of malicious changes to a system.

The $UsnJrnl is stored on the root of the volume in the \$Extend\$UsrJrnl file. The file has two $DATA attributes, the $Max attribute which contains general information about the journal and the $J attribute which contains the actual list of changes. Each journal record varies in size and includes an Update Sequence Number (USN). The USN is 64 bit in size and is stored in byte 64-71 of the $STANDARD_INFORMATION ($SI) attribute of the $MFT.  The following output is an example of the $SI XXD of a file named malicious.dll.

Searching a dd (raw) image for a suspected malicious file called malicious.dll with the The Sleuth Kit (TSK) tool “fls” produces the $MFT Record Number of the file.

fls -f ntfs -r /media/Passport/Images/Image001.dd | grep malicious.dll

 ++ r/r 1618-128-1:    malicious.dll

Using this entry number (1618) we can display the $SI attribute (type=16) from the $MFT record  $SI (type=16) with the TSK "icat" tool.

icat -f ntfs /media/Passport/Images/Image001.dd 1618-16 | xxd

The USN, in the above example, represents the byte offset in the $UsnJrnl (remember each record varies in size). It should also be noted that the $Usnjrnl is a sparse file, meaning it has a maximum size but old records are overwritten with zero's and any updates to it will be written to the end of the file and perpetually increase the USN (based on byte offset from the beginning of the file).

Microsoft MSDN has a fair amount of documentation on the structure of the $UsnJrnl $J file and what fields it stores. Additionally, Brian Carrier does a great job of breaking down the data structure and byte offsets in his book File System Forensic Analysis. The following is an example of a $UsnJrnl record structure.

We can obtain the $MFT entry address of the $Usnjrnl $J file by using the TSK "fls" tool (note: the $Extend Object will always be $MFT entry 11).

fls -f ntfs /media/Passport/Images/Image001.dd 11

Once the location of the $J file is obtained, the contents can be displayed by using the TSK "icat" tool as follows. Please note that the -h option skips holes in the sparse file.

icat -h –f ntfs /media/Passport/Images/Image001.dd 41455-128-3 | xxd

A quick search for our "malicious.dll" provides a good example of the structure a $UsnJrnl record.

Byte 40-43 is the USN_CHANGE flag and is well documented on MSDN. For reference purposes the following table summarizes the type of flags and their hexadecimal values recorded in the $UsnJrnl.

There are a few utilities and scripts available to automate the parsing of the records but for the purpose of this post I am using one I recently became aware of through the Windows Forensic Analysis Email list. The Windows Journal Parser (JP) is available for Windows, Linux, and Mac. JP pulls the allocated clusters from the sparse file and parses the records. Information pulled includes Time/Date of change, File/Folder Affected, Type of Change, and by using the verbose option (-v) it will add the $MFT Entry Number and Sequence Number. JP is able to parse a the $UsnJrnl from a live volume, dd image, or carved $J file and export to a variety of formats.

I recently came across a compromised Windows 7 system and had the opportunity to use JP during analysis. The following is the location, hash values, and Virus Total stats of the malicious (unsigned) process that was found on the system.

File name: VD90c_2121.exe
Submission date: 2011-07-21 14:13:39 (UTC)
Result: 14 /43 (32.6%)
MD5   : c8a695e4c411af859fa358eabb4127d1
SHA1  : 78e10150b3fd91b199adf0457a2e3902bc70eaf6
SHA256: 54e80b6d08bedf9210e6a0cead297a36d34f12170568c672e70ff6f750a69a00

After parsing the $UsnJrnl with JP, I searched for the aforementioned malicious process and was quickly able to obtain a timeline of changes made during infection.

Within a few minutes of analyzing the output from the $Usnjrnl I recognized some of the files and locations created as being similar of a malicious program I analyzed previously last November and outlined here. Hence significantly reducing the time necessary to find the origin, payload, and other infection locations on disk.

It should be noted again that $UsnJrnl records are not going to kept indefinitely. Moreover, if a file is deleted, related $MFT entries may be overwritten. More info on carving old $UsnJrnl records from unallocated space and other $UsnJrnl parsing utilities is posted over at the Forensics From the Sausage Factory Blog. I recommend you check it out.

Happy Hunting!

References:

Carrier, Brian (2005). File System Forensic Analysis. Addison Wesley.
.
Microsoft MSDN USN Record Structure.

Virtualizing Raw Disk Images

I have heard a lot of people ask about how to forensically handle raw (dd) disk images of systems that have been encrypted with whole disk encryption. Both PGP and Truecrypt support the use Recovery/Rescue ISO's to decrypt drives without booting the OS (Note: an administrator pass phrase is still going to be required). So if you could boot the raw image in VMware, for example, then you could mount the ISO and decrypt the image.

One Windows tool, Live View, can be used to convert dd images to a vmdk (Virtual Machine Disk Format) file. Live View was created at Carnegie Mellon University in 2009 but it unfortunately has not been updated since then. Consequently, there is no support for modern versions of Windows or VMWare Workstation or Server.

Fortunately, Tasos Laskos, expanded on their work and created the raw2vmdk utility. Raw2vmdk is an open source, OS independent (requires JRE 1.6.0_18 or higher), command line utility that can create a vmdk file with the appropriate disk type parameters that will allow you to boot directly from a dd image.

The readme outlines the syntax of the utility (Note: if disk type is not specified then it defaults to IDE).

java -Dtype=<ide|buslogic|lsilogic|legacyESX> -jar raw2vmdk.jar <raw image> <vmdk outfile>

Note the syntax of the slashes when running the command on a Windows system.

java -jar raw2vmdk.jar D:\\data001.dd D:\\data001.vmdk

Once run, the analysis and creation of the vmdk file only takes a few seconds.

Raw2vmdk creates a properly formatted vmdk with the appropriate path to the raw image, disk type, and parameters.

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=5c643bba
parentCID=ffffffff
isNativeSnapshot="no"
createType="monolithicFlat"

# Extent description
RW 156301488 FLAT "D:\data001.dd" 0

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "7"
ddb.longContentID = "bf304434123a064225efde635c643bba"
ddb.uuid = "60 00 C2 91 8e 73 27 62-43 58 3b f8 05 ae 2e a0"
ddb.geometry.cylinders = "1023"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "19"
ddb.adapterType = "ide"

The monolithic flat disk type is a pre-allocated disk type that is stored in one file. This format also supports raw dd images. Once the creation of the file is complete, create a new virtual system as you normally would within Vmware Workstation or Server and point the hard disk to the newly created vmdk file.

You should now able to boot your image within VMware (assuming it includes the boot partition). A word of caution, however. Always follow IR and Forensics best practices and use a second copy of your raw image. I also like to create the virtual system and vmdk in a separate folder from the raw dd image, so if the VM is accidentally deleted it does not also delete your raw disk image.

Happy Hunting.

Herding Cats: Windows Object Access Analysis on a Budget

I recently had to deal with a lot of archived Windows Security Logs (evtx files) spanning a fairly lengthy period of time. The evtx binary was introduced with Windows Vista and can be found on all modern version of windows. The author of EVTX Parser has posted his work on documenting the evtx file structure here and has created a utility called EVTX Parser that will parse evtx binaries and store them as xml. A good overview of his research and tool is posted in a slide deck from the SANS Forensic Summit in 2010.

There are a few additional free tools available to search and filter Windows event logs if you don't have a log management product. While the Windows event log supports the import of multiple evtx files, I can tell you through experience that the MMC will puke if you feed it a large amount of files. Moreover, there is limited support for many of the xpath string functions such as "contains" and "starts-with" which can be hindrance. All the same, I managed to come up with some useful expressions to query Object Access logs from Windows 7 and 2008 R2 Server.

Microsoft provides a decent spreadsheet on Windows Security Event ID's and some documentation on the schema of events. Looking at the XML of a few events, however, will certainly give you what you need.

When dealing with object access logs, you are going to need to distinguish between the types of access granted on the file system and registry. After much googling and experimentation I managed to scrape together the following Access Mask values and their associated bit wise equivalents used in the Windows Event log. These are the permissions that were exercised on the audited object(s).

1537 (0x10000) = Delete
4416 (0x1) = ReadData(or List Directory)
4417 (0x6) = WriteData(or Add File)  (0x2 on Windows 2008 Server)
4418 (0x4) = AppendData (or AddSubdirectory)
4432 (0x1) = Query Key Value
4433 (0x2) = Set Key Value
4434 (0x4) = Create Sub Key

So for example if you need to write and expression to see all successful and failed modifications by a particular user on files and folders.

<querylist>
<query id="0" path="Security">
<select path="Security">*[EventData[Data[@Name='SubjectUserName']='bugbear' and [@Name='AccessMask']='0x6']]</select>
</query>
</querylist>

After playing with different variations of this query, I began to get creative during dynamic analysis of the Renocide worm and its effects on the System32 and HKLM registry keys. After enabling auditing on both objects, I came up with the following query to produce all changes made by the payload and malicious process. Note: the syntax when working with an externally saved evtx file.

<querylist>
<query id="0" path="file://C:\Worm.evtx">
<select path="file://C:\Worm.evtx">*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and EventID=4663 and (Task = 12800 or Task = 12801)] and EventData[Data[@Name='ProcessName']='\Device\HarddiskVolume2\02MAY2011\scffog.exe' or Data='C:\Windows\System32\csrcs.exe']]</select>
</query>
</querylist>

This produced some interesting logs I used for further analysis.

If filtering multiple archived evtx files you can import the files into the mmc event viewer, create a view including them, and filter on that view. But dont expect to be able to work with a large amount of data. In fact, Microsoft will generate a warning if you attempt to import more than ten evtx files. Fortunately, there are faster and more flexible alternatives. Microsoft Log Parser will parse the binary (specify evt as the input type). Specifying a wild card in the filename will parse multiple files located in a specified folder and Log Parser also provides additional flexibility by allowing the use of statements such as "LIKE". The following are valid data fields that can be used when parsing evt/evtx binaries.

Note: If filtering by user you will need to use the SID and much of the event data, such as access masks, are combined as a string in the "Message" data field. The following is an example of a query that will pull events from multiple evtx binaries that contain the specified WriteData and Delete Access Mask values.

LogParser.exe -i:evt -o:csv "Select * from C:\Logs\*.evtx where EventID=4663 and (Message Like '%Access Mask: 0x6%' or Message Like '%Access Mask: 0x10000%')" > C:\Logs\Out.csv

Another alternative is Windows Powershell. The following is a similar example as the one given above (all WriteData and Delete Access Masks) using the Get_WinEvent and Where_Object Cmdlet'.

 get-winevent -path "C:\Logs\Comp1.evtx", "C:\Logs\Comp2.evtx" | where {$_.Id -eq "4663" -and $_.message -like "*0x10000*" -or $_.Id -eq 4663 -and $_.message -like "*0x6*"} > C:\Logs\Out.csv

 Using "| Format-List" provides a view of the data fields available for use with the "Where" statement.

While not ideal, the IT Practicioner or Incident Responder can certainly wrangle with evtx files without a SIEM or Log management system. The recent release of the Verizon DBIR report (2011) included a statement on page 60 that notes an interesting but not unexpected finding.

"...discovery through log analysis and review has dwindled down to 0%. So the good news is that things are only looking up from here..." - Verizon DBIR 2011

Happy Hunting!

Updated May 19, 2011

I intentionally did not provide any detail on enabling Object Access auditing in Windows since there is a fair amount of documentation available on that. In retrospect, however, I did want to mention a few things and share a few tips.

First, choose what Accesses you audit carefully. Accesses such as "List Folder/Read Data" are very noisy and will only increase the amount of logs you have to parse and may fill up the event log completely so it begins to overwrite itself (note: there are settings for the size of the log too).

Second consider what user or group you audit access for carefully. The "Users" group may be fine for auditing access to files stored on a file server but consider using the "Everyone" group if auditing changes made by malicious code. This group will include the System account.

Lastly, enabling auditing of changes to the system folders or registry may become resource intensive and non-manageable in a production environment. Use with caution. That said, I do believe it can be useful during analysis of malicious code. I would include a few more locations than just the System32 and HKLM however. The C:\Users, C:\ProgramData, and HKCU keys come to mind.

Renocide Worm: Hiding in Plain Sight

I recently came across a sample of Renocide which has been circulating for some time now. Microsoft recently published some of its infection numbers on the MSRT blog if you are interested. The malicious code takes advantage of the auto run settings in Windows and spreads via mapped drives and USB storage devices. Virus Total shows decent coverage by the AV industry. While not particularly unique, I did note something interesting when I parsed the NTFS $MFT table during analysis. The malicious code seems to manipulate NTFS $MFT Timestamps on several malicious files it creates in the %windir%\System32 folder. The following screen shot is the $MFT attributes for the process csrcs.exe which the payload creates.

csrcs.exe (MD5: 989460dc5f8ac5c886078f50720d71e8)

There a few things that struck me about the time manipulation. While it is not unusual to find the $SI born (creation) and modified attributes altered, I have never seen the $FN Born attribute changed. A closer look at the hex values of the $SI Born Attribute revealed something else.

The $SI Born time of "20e6 980c a303 ca01" converts more specifically to 2009-07-13 06:16:55.938000 . The usec value is not zero which is unusual. My first thought was that the date/time values were copied from another file but while the date mirrors other system files, the time correctly coincides with the time of infection. Things that make you go hmm.

An Overdue Rant: The RSA Compromise

OK I haven't had a good rant in a while on the blog, so be warned, there may be some pent up rage in the paragraphs ahead. Read on at your risk.


I do not usually write posts on the latest compromise as I always feel there is enough coverage, speculation, and commentary from smarter people than I. There is a lot of speculation about the recently announced RSA breach both on the technical details of the compromise and on who may have been behind the attack. Yeah everyone is throwing three letter acronyms around again. The Digital Underground Podcast recently posted a great discussion on the technical side here and there as been some good posts on mitigation techniques.

The part I really have issue with is RSA's lack luster disclosure of this compromise. Some have suggested that they should be praised for publicly announcing the breach. I'm not sure when we set the bar so low. Since when is posting a written notification with vague details and little to no information on when and what was compromised and who is affected become acceptable?

A lot of organizations have paid a lot of money to increase the security of their information systems and data by purchasing the RSA SecureID solution. Don't forget even if your not a customer of RSA (Disclosure: I am not) it is still your family's data being protected by such solutions. In short, I find RSA's actions post compromise disgusting and inept.

While knowing the technical details of the compromise would benefit the security community by giving everyone an opportunity to learn where things went wrong, the reality is we will probably never know the details and this is OK with me. What needs to be done, on the part of RSA however, is to step up and fix where things went wrong, notify those clients affected, and offer them replacements or fixes for the technology they already purchased. Thus far the advice given by RSA is nothing more than best practice and common sense. I would like to think those implementing RSA's authentication solutions are probably already familiar with such administration controls.

To use a bad analogy. This is the equivalent of a new home owner hiring a Master Locksmith to replace all the locks in their new home with a more secure solution, only to have the locksmith keep a copy of the keys and tell the customer at a later date that the key has been stolen and the customer should go buy a bigger guard dog or better alarm system at their own expense. Would this be acceptable?

Not the greatest analogy but I did say their were more intelligent people than I posting about this didn't I?

The truth is, everyone gets owned at some time or another. It is the actions of the compromised organization during the aftermath that will distinguish it from other competitors. Asking other security solution providers to sign an NDA to learn more about the compromise is not looking out for the best interests of your customers.

/Rant

Updated June 01, 2011

It appears that there may have been several attacks against U.S. defense contractor's that leveraged information from the RSA compromise. Last Friday, Reuters reported that there was a breach at Lockheed Martin Corporation. On Monday, Wired reported that L-3 Communications had also been targeted and leaked memo suggested the attackers were using inside information on their SecureID system gained by the RSA hack. Today, Fox news is reporting a possible attack against Northrop Grumman. With all these reports flooding the internet it is difficult to know how much is based on fact but I did want to share a gem of a quote from the Wired report.

Asked if the RSA intruders did gain the ability to clone SecurID keyfobs, RSA spokeswoman Helen Stefen said, “That’s not something we had commented on and probably never will.”

Updated June 7, 2011

It appears RSA has updated their Open Letter to RSA SecurID Customers. The update provides verification of the Lockheed Martin attack and offers long awaited replacements of SecurID tokens, although for what appears to be a limited subset of SecurID customers. Thanks to Wim Remes for the heads up on the updated post.

Pauldotcom Security Weekly: I am Talking about What?

On Thursday March 24, 2011 I will be presenting the tech segment on Episode 236 of PaulDotCom Security Weekly. The segment will cover the use of NTFS MFT timeline forensics in the static analysis of malware. This is a geekier version of my NAISG BOS presentation back in January and will cover some additional tools and technique's. The podcast begins around 8:00 PM and a live feed is available at http://www.pauldotcom.com/live. So if you are around, kick back with a beer, cigar, and listen live! I am looking forward to it.

Updated March 24, 2011 3:30 PM

As part of the tech segment this evening, Mark Mckinnon of RedWolf Computer Forensics has release the Windows beta of mft_parser which supports $MFT $SI and $FN bodyfile output from both the CLI and GUI. Big thanks to Mark from the Incident Response and Forensics community.

Shmoocon or Bust

What would you do to get to Shmoo?

Woke up at 4:00 AM                  
2.5 hours shovelling snow
1 hour to get to train station
1 hour on local commuter rail to BOS
2 minutes to find my train to PVD cancelled
1 hour on on first commuter rail to PVD
Finding my 12:50 train to DC only five minutes late = priceless

In about four hours I will be at Shmoocon and it will to be Epic. This years schedule contains a lot of fresh blood and new faces (which is not a bad thing IMHO). The schedule is so packed with goodness, that I am going to have to make some tough decisions on which sessions to attend. In addition, the after hours action is packed full of awesomesauce. There is the return of Firetalks on both Friday and Saturday evening, Podcasters meetup (including free booze), Jason Scott is previewing his new documentary called Get Lamp on Saturday evening (first computer program I wrote was a text based Adventure game on my TI99-4A), and of course there are the parties and meet-ups that will certainly include scotch and cigars.

On Friday we begin with, Gone in 60 Minutes: Stealing Sensitive Data from Thousands of Systems Simultaneously with OpenDLP with Andrew Gavin. Leveraging enterprise defense products = sexy in my book. Following that there are several cool sessions including a long awaited update from Johnny Long (who is back in the states for the con), and keynote by Peiter "Mudge" Zatko of DARPA.

On Saturday, I am hoping that Jon Oberheide and Zach Lanier has the cure for my much anticipated hangover with their talk; TEAM JOCH vs. Android: The Ultimate Showdown which will highlight their work on subverting the Android OS. I plan to follow-up with Hard Drive Paperweight: Recovery from a Seized Motor! being delivered by Scott Moulton. Scott is a super smart dude who never disappoints. I am guaranteed to learn something there.

Printers Gone Wild! with Ben Smith is in the next slot. Next I need to make some of those tough decisions I mentioned earlier. There is Attacking 3G and 4G mobile telecommunications networks with Enno Rey & Daniel Mende and An Evite from Surbo? Probably an invitation for trouble with Trent Lo aka "Surbo" from i-hacked.comhttp://www.i-hacked.com/. There is no doubt that mobile tech has definetly come of age and consequently will become a target but Trent is also a smart, entertaining dude. Then in at 16:00 there is Defeating mTANs for profit with Axelle Apvrille and Kyle Yang (mTAN = one-time bank password by SMS) and G W Ray Davidson's talk on designing a network for a conferance entitled ShmooCon Labs Goes To College. Both decisions will most likely be down to the wire. On Sunday, the talk that seems to be on averyone's agenda is Georgia Weidman's Transparent Botnet Control for Smartphones Over SMS in which she will release POC for a sms controlled botnet.

Total estimated time to get to the con = 15 hours (and worth it). See you in a few hours Shmoocon

NAISG: Leveraging NTFS Master File Table Timeline Forensics in the Analysis of Malware

What is in your incident response kit?

Next week I am delivering a talk at the Boston Chapter of National Information Security Group (NAISG) on Thursday January 20, 2011. I will be speaking on the use of NTFS Master File Table Timeline Forensics in the Analysis of Malware. The meeting and talk is open to everyone and more information can be found here. If you are in the Boston area come down and check it out. NAISG will post the talk and slides at a later date and I will make sure I link back to it here.

Updated: February 1, 2011

NAISG has posted the video for my presentation here. The slide deck can be found on Slideshare here. I also wanted to say thank you to NAISG Boston chapter for having me. It was a blast!

The More Things Change The More They Stay The Same: Reading "The Cuckoo's Egg"

What rock was large enough that I somehow was unaware of this book's existence the last 20 years of my life?

I just finished reading The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage by Cliff Stoll. The book is based on the true account of Cliff Stoll's experience tracking a hacker through a laboratory computer network at Berkeley in the mid 1980's. The author quickly finds himself in a year long obsession that involved military targets, several US government agencies, and law enforcement from multiple continents.

The story completely sucked me in. The amazing part is more than 25 years later, with the exception of bandwidth and the shear number of targets, not much has really changed. Detective book fans will enjoy it. Security geeks will love it. Incident Responders should be required to read it.

Not Just Another Analysis of Scareware

Introduction to our Sample

The initial infection came to my attention from an end user. He had reported all Google searches from his browser seemed to be forwarding to hxxp://findgala.com and he was getting warnings about malware on his computer. The system infected was a reasonably up to date Windows 7 notebook. The system was missing the latest patch for Adobe Flash (v 10.1.102.64). The user did not have administrator privileges, the windows firewall was enabled, Internet Explorer 8 with the default of medium/high security was set for the Internet Zone, and Symantec Endpoint 11.X was installed with up to date definition files. Note that Windows UAC was NOT enabled.

A quick assessment of the system determined it had been infected with some form of scareware. All existing desktop shortcuts had been removed and two shortcuts named "Computer" and "Internet Security Suite" remained. These pointed to "C:\ProgramData\891b6\ISe6d_2229.exe /z" and "C:\ProgramData\e6db66\ISe6d_2229.exe /hkd" respectively. The folder containing the executable was marked hidden and I noted the process was running via TACKIST /SVC. An icon running in the system tray when accessed presented the following screen.

Symantec Endpoint Protection seemed to be neutered by the infection as did several other Windows tools including Task Manager. Initial searching on the internet for the title of the malware only pulled links to legitimate Anti Malware products including CA, Zone Alarm, and Verizon's Internet Security Suite service.Virus Total returned the following analysis. Here is a summary of the file submitted:

File Name: ISe6d_2229.exe
File Type: Windows 32 bit Portable Executable
MD5: 699ebebcac9aaeff67bee94571e373a1
SHA1: ed763d1bc340db5b4848eeaa6491b7d58606ade2
File size: 3590656 bytes
First seen: 2010-11-14 01:20:29
Last seen: 2010-11-16 15:52:22

My general impression of the GUI was this was a well designed piece of code. I imaged the system with dd and instructed the desktop engineers to wipe the system and reset all the user passwords. This proved to be a mistake on my part as I did not verify my image before they wiped the system. Later I found myself unable to boot the raw image in VMware after converting it to a VMDK with Raw2VMDK (blue screen on loading the OS).

Static Analysis

I began with static analysis of the file system by mounting the image with FTK Imager Lite. I exported the Master File Table and parsed it with analyzeMFT . With the estimated time of infection obtained from the victim I was able to pinpoint the file's created and modified during the initial infection.



The initial few files listed in the MFT caught my attention first.

Record	Type	Parent	Filename
63861	Folder	602	e6db66
63915	File	2755	TASKKILL.EXE-8F5B2253.pf
63926	File	2755	SETUP_2229[1].EXE-11C68EE8.pf
63923	File	63861	ISe6d_2229.exe

The two prefetch files should give a hint of the name and location of the payload. I use Prefetch Parser to parse the C:\Windows\Prefetch folder to obtain some more details:

Record	File	Times Run	UTC Time
SETUP_2229[1].EXE-11C68EE8.pf	SETUP_2229[1].EXE	1	Sat Nov 13 01:16:53 2010
TASKKILL.EXE-8F5B2253.pf	TASKKILL.EXE	1	Sat Nov 13 01:16:53 2010
RUNDLL32.EXE-80EAA685.pf	RUNDLL32.EXE	1	Sat Nov 13 01:17:16 2010

Further analysis of the .pf files gave me the location and names.

SETUP_2229[1].EXE-11C68EE8.pf     
\USERS\%USERNAME%\APPDATA\LOCAL\MICROSOFT\WINDOWS\TEMPORARY INTERNET FILES\CONTENT.IE5\G4KYBRHH\SETUP_2229[1].EXE

TASKKILL.EXE-8F5B2253.pf 
\USERS\%USERNAME%\APPDATA\LOCAL\MICROSOFT\WINDOWS\TEMPORARY INTERNET FILES\CONTENT.IE5\G4KYBRHH\ANPRICE=85[1].HTM

RUNDLL32.EXE-80EAA685.pf
\PROGRAMDATA\E6DB66\ISE6D_2229.EXE

It does appear the sample originated from the web. Unfortunately, I could not locate SETUP_2229[1].EXE or ANPRICE=85[1].HTM in the image. Most likely overwritten after several days of use post infection, I moved on the parsing the Internet browser history by using MiTeC Windows File Analyzer and began parsing the last few web sites and searches completed by the user. Unsuccessful in locating the source of the payload, I was not able to verify if it was delivered via a vulnerability or user interaction.

I moved on to use the MFT to locate all files associated with the infection and export the hashes. Here is a summary files found in the /[root]/ProgramData folder:

MD5	File
cd407baa9a55b9c303f0c184a68acc5c	\E6DB66\6139ba67beb5a1febb1e8cfc73a42e9c.ocx
699ebebcac9aaeff67bee94571e373a1	\E6DB66\ISE6D_2229.EXE
2e317d604f25e03b8e8448c6884f64e3	\E6DB66\ISS.ico
3ee5ee57af2f62a47d2e93e9346b950f	\E6DB66\mcp.ico
be44f801f25678e1ffdd12600f1c0bc7	\ISKPQQMS\ISXPLLS.cfg

The following summarizes files found in the /[root]/users/%username%/ folder:

MD5	File
2b7509a2221174a82f6a886bbdd2e115	\Desktop\Computer.lnk
fb16300f2f9799376807b13ad8314ca2	\Desktop\Internet Security Suite.lnk
fd00cfeecc333aedc56fd428f2b9b5ba	\AppData\Roaming\Internet Security Suite\Instructions.ini
4635f17db7d2f51651bebe61ba2f4537	\AppData\Roaming\Microsoft\Windows\Recent\ANTIGEN.dll
6032703c3efc5f3d3f314a3d42e2a500	\AppData\Roaming\Microsoft\Windows\Recent\cb.exe
12ddf77984d6f2e81a41f164bea12a1c	\AppData\Roaming\Microsoft\Windows\Recent\cid.sys
81c9ad6037c14537044b3e54d8b84c99	\AppData\Roaming\Microsoft\Windows\Recent\ddv.exe
f28c20c6df79e9fe68b88fb425d36d57	\AppData\Roaming\Microsoft\Windows\Recent\eb.sys
6274e77cd16d6dbec2bb3615ff043694	\AppData\Roaming\Microsoft\Windows\Recent\energy.drv
a3342f285bfb581f0a4e786cc90176d2	\AppData\Roaming\Microsoft\Windows\Recent\energy.sys
1ac2fb2dbd0023b54a8f083d9abbf6db	\AppData\Roaming\Microsoft\Windows\Recent\exec.exe
2dc3df846ff537b6c3e6d74475a0d03d	\AppData\Roaming\Microsoft\Windows\Recent\FW.drv
a32f789b1b6f281208fa1c8d54bf8cdc	\AppData\Roaming\Microsoft\Windows\Recent\gid.dll
b48d1cc8765719a79a9352e2b8f891ef	\AppData\Roaming\Microsoft\Windows\Recent\hymt.exe
532c6465f4dd9c7bce31b7a7986e3270	\AppData\Roaming\Microsoft\Windows\Recent\hymt.sys
f941f6eedf5b33a0b49b9787d5f0dfc2	\AppData\Roaming\Microsoft\Windows\Recent\kernel32.sys
2ff0c3a804b85d3e7e6487d9bece6416	\AppData\Roaming\Microsoft\Windows\Recent\PE.dll
454f06575c9214f7b9cb01c606fd72fe	\AppData\Roaming\Microsoft\Windows\Recent\PE.sys
243b5a8a95bb4f8822790b8f0c81b82a	\AppData\Roaming\Microsoft\Windows\Recent\ppal.exe
9d34330ec68d148cc5701d6cd279c84c	\AppData\Roaming\Microsoft\Windows\Recent\SICKBOY.drv
493fc17532f9b6ac330dbdb3a01a5361	\AppData\Roaming\Microsoft\Windows\Recent\sld.drv
d0d210a62cb66ff452e9a5cfc8e8f354	\AppData\Roaming\Microsoft\Windows\Recent\SM.sys
a2ca707ee60338ac5ec964f7685752ba	\AppData\Roaming\Microsoft\Windows\Recent\std.dll
a1e25ab2f19565f707d85e471f41e08f	\AppData\Roaming\Microsoft\Windows\Recent\snl2w.dll

I also noted that the hosts file had been modified at the time of infection. The following is a sample of entries that had been added (note: additional countries root domain entries for the top search engines were also added but are not included in this analysis for simplicity's sake):

74.125.45.100 4-open-davinci.com
74.125.45.100 securitysoftwarepayments.com
74.125.45.100 privatesecuredpayments.com
74.125.45.100 secure.privatesecuredpayments.com
74.125.45.100 getantivirusplusnow.com
74.125.45.100 secure-plus-payments.com
74.125.45.100 www.getantivirusplusnow.com
74.125.45.100 www.secure-plus-payments.com
74.125.45.100 www.getavplusnow.com
74.125.45.100 safebrowsing-cache.google.com
74.125.45.100 urs.microsoft.com
74.125.45.100 www.securesoftwarebill.com
74.125.45.100 secure.paysecuresystem.com
74.125.45.100 paysoftbillsolution.com
74.125.45.100 protected.maxisoftwaremart.com
69.72.252.252 www.google.com
69.72.252.252 google.com
69.72.252.252 www.google.no
69.72.252.252 www.google-analytics.com
69.72.252.252 www.bing.com
69.72.252.252 search.yahoo.com
69.72.252.252 www.youtube.com

Using bintext to pull the strings from ISe6d_2229.exe provided a few interesting things of note. Specifically a company and product name of "limnol" and file and product version of "1.1.0.1010". Searches for this reference with some added keywords found some additional submissions to virus total but nothing that was not already known from my earlier submission.

There were also strings associated with a Microsoft Windows manifest file. Such a file can be embedded in software by the developer to instruct Windows Vista and Windows 7 on what Privileges the software needs to run as. The default setting of "run as the user" was obtained from the strings:

<security>
<requestedprivileges>
<requestedexecutionlevel level="asInvoker" uiaccess="false"></requestedexecutionlevel>
</requestedprivileges>
</security>

I continued the analysis by taking a look at the Windows registry. This was done by exporting the HKCU and HKCM hives from the raw image and using both RegRipper and MiTeC Windows Registry Recovery to analyze the entries. The HKCU Run key contained an entry to autostart the executable on startup.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
"Internet Security Suite"="\"C:\\ProgramData\\e6db66\\ISe6d_2229.exe\" /s /d"

In addition, I was able to verify that the registry contained an entry for findgala.com under:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\SearchScopes]
"URL"="http://findgala.com/?&uid=2229&q={searchTerms}"

The [HKEY_CURRENT_USER\Software\Internet Security Suite] key contained several subkeys within it. The entries here seemed to be similar to the contents of the Instructions.ini file found earlier in the appdata folder of the user profile. This file resided in a hidden folder with the same name as the registry key. I have listed one entry as an example here.

[HKEY_CURRENT_USER\Software\Internet Security Suite\23071C180E1E]
"3016131C2F0B18311F0CF4D5EBEEE1"="4746574B4E544E4D4F4FA0B0B8B2B5BFB7BEA8D9C7"
"23071C180E1E31180D0CE1E6E7"=""
"2205012C0A1F2814131A"="4746574B4E544E4D4F4FA0B0B8B3BDBFB2B7A8D9C7"
"3A160B0D2E090534100CF4F3F7E0F0ECE9E9"="4746574B4E544E4D4F4FA0B0B8B2B5BFB7BEA8D9C7"
"3A160B0D3C1E19192E3BCD"="4746574B4E544E4D4F4FA0B0B8B3BDBFB2B7A8D9C7"
"3A160B0D2F0B181C0A1A"="4746574B4E544E4D4F4FA0B0B8B3BDBFB2B7A8D9C7"
"3A160B0D34140E101F13D5F1E6E2F0E0"="4746574B4E544E4D4F4FA0B0B8B2B5BFB7BEA8D9C7"
"3E22081D1B0F19"="46"
"24181415181A1F16"=""
"2205012C0A1F1D091B2DF5EFC1ECF1EBF2"="46"
"3E1E1C1D1F15290D1A1EF4E4C1ECF1EBF2"="46"
"3B1E0A0B15093F120B11F4"="46"
"3218151813154C"=""
"23071C180E1E"="46"

Lastly, the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\] key had several entries for what appeared to be legitimate software, tools, and other forms of malware. Entries included; taskmgr.exe, rtvscan.exe (Symantec Endpoint Protection), and dozens of other programs. All legitimate and illegitimate software was being blocked via an entry for debugger with a value of "svchost.exe".

Dynamic Analysis

I began dynamic analysis by first attempting to infect a virtualized Windows 7 system in my lab (Note: all initial attempts were with administrator privileges with UAC disabled). Running the executable seemed to generate a runtime error, so I attempted to run it from the command prompt with the /hkd switch found in the desktop shortcut during static analysis. Process Monitor was used in an attempt to capture all file, registry, and network connection changes during infection. The following error was displayed;

Thinking it picked up on Process Monitor, I tried again but without procmon.exe but I was presented with the same error. It seemed that this sample was VM aware. Again I attempted to infect a clean install of Windows 7 on physical hardware with procmon.exe and again, I was met with failure. I turned to utilizing CaptureBat to monitor file and registry changes during install. Infection proceeded but I noted my sample used for analysis had been removed. On further inspection, it appeared that a .bat file was the culprit. The contents of the file were as follows;

MD5                                                        FileName
329e8a313f20cd8b4ebf67642331c007    \Users\bugbear\AppData\Local\Temp\del.bat

:Repeat
del "C:\Users\bugbear\Desktop\e6db66\ISE6D_~1.EXE"
if exist "C:\Users\bugbear\Desktop\e6db66\ISE6D_~1.EXE" goto Repeat
del "C:\Users\bugbear\AppData\Local\Temp\del.bat"

I also noted the name of the files and folders associated with the malware seem to vary on each infection. Verification of hashes proved that it was indeed the same malicious program however. File and registry monitoring verified the findings from the static analysis and I noted some additional changes as well. It appeared the rogue software attempts to disable UAC by editing the following registry keys;

registry: SetValueKey C:\Users\bugbear\Desktop\e6db66\ISe6d_2229.exe -> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin
registry: SetValueKey C:\Users\bugbear\Desktop\e6db66\ISe6d_2229.exe -> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorUser
registry: SetValueKey C:\Users\bugbear\Desktop\e6db66\ISe6d_2229.exe -> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA

Additional registry entries in HKEY_Current_User were also modified. Including the Internet Explorer proxy and wpad settings under [HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings]. Additionally, rather than modify the host file directly, the executable seemed to create a temporary host file, remove the old one, and replace it with this new version.

file: Write C:\Users\bugbear\Desktop\e6db66\ISe6d_2229.exe -> C:\Windows\System32\drivers\etc\host_new
file: Delete C:\Users\bugbear\Desktop\e6db66\ISe6d_2229.exe -> C:\Windows\System32\drivers\etc\hosts
file: Write C:\Users\bugbear\Desktop\e6db66\ISe6d_2229.exe -> C:\Windows\System32\drivers\etc\hosts
file: Delete C:\Users\bugbear\Desktop\e6db66\ISe6d_2229.exe -> C:\Windows\System32\drivers\etc\host_new

Typical "features" associated with scareware seemed to be included with this sample. The rogue software begins a "scan" of the infected system immediately upon execution. Scan results display "infected" files located in [root]\Users\%username%\AppData\Roaming\Microsoft\Windows\Recent\ folder identified during static analysis.

Please note, no attempt was made to identify these files as legitimate malware by myself, although that may be an interesting exercise for another time. Not unlike an episode of the Soprano's, the victim is intimidated into buying protection and is offered several opportunities to buy a subscription. Multiple subscription options are available.

At one point my lab system spewed a blood curdling scream from its speakers before displaying yet another option to "protect" oneself (a little over the top if you ask me). My favorite feature goes to Chat Support however.

I do not think Jane appreciated my bluntness. Network connections for both the subscription service and chat support sessions were collected with the following script which leverages the netstat command.

 for /L %1 in (0,0,0) do netstat -anob>>C:\netstat.txt

Both IP addresses associated with the subscription service and chat support sessions were registered to hosting providers here in the US. The strangest behavior observed however, was captured with Process Explorer and Wireshark post infection. Multiple instances of ping.exe running under cmd.exe were noted. Upon examination of the packet capture, it appeared the processes were spewing ICMP and SYN packets to two IP Addresses registered to .RU domains.

Soon after this behavor was noted. The executable associated with the infection was mysteriously removed from the system. Attempts to duplicate this behavior later failed.

Further analysis of the infection and sample was done without administrator rights and with UAC disabled. No edit of the hosts file or registry keys in HKLM were noted, however. The malware still setup shop within the ProgramData and User Profile locations noted with the earlier analysis but the fact the user with the original infection had no administrator rights and the host file and HKLM keys were modified remains a bit of a mystery. One might speculate, the original payload might behave differently.

Further Google searching utilizing these findings led me to Microsoft's Malware Protecton Center write-up on Rogue:Win32/FakeVimes. Although Virus Total had not indicated such, it would seem our sample has had many aliases and upgrades.

Lessons Learned 

All in all I learned a lot and had fun analyzing the sample (it beats watching sitcoms). Few things I noted for future analysis attempts.

• Always verify your images and keep the original copy if possible (aka don't be a dumbass Tim)
• Static file forensics techniques can be very useful during malware analysis
• Have multiple tools that can perform similar tasks is sometimes needed
• Fear is a powerful marketing angle and the bad guys are getting better at it
  

Feel free to ping me if you would like a copy of the sample. I would be more than happy to trade notes with others.

Update: Questions Unanswered

Updated on December 30, 2010.

Curt Wilson was kind enough to comment on my analysis earlier this week. He brought up an interesting tidbit that I had missed. The title of error message displayed when attempting to perform dynamic analysis in a virtualized environment references Themida, a known packer used in malware. The following screen shot obtained from Google images is telling:

According to the results of my initial Google searches, Themida has been around for some time. There are some scripts available for OllyDbg to unpack executables using this tech so I hope to continue down the rabbit hole.

Moreover, I think the files placed in the recent folder of the user profile is worth a quick look, as is the payloads of packet captures. Looks like I have some interesting commutes ahead of me on the train. Until Part II of the analysis, Happy Hunting!