SecureArtisan

My Road to Digital Forensics Excellence

Archive for June, 2012

The malware made you do it?

Posted by Paul Bobby on June 25, 2012

I was having a conversation with a co-worker about various things and the topic of the trojan defense was raised. He started chuckling. I asked why, and he dismissed it as the far fetched final gasp of air muttered by the unfortunate soul facing the consequences of his actions. Well perhaps not as dramatically stated as that, but you get the point. I told him I disagree with that sentiment 100%, and proceeded to tell him why. Upon reflection I figured this is something to blog about and invite any comments in the event I’m completely off base with this.

TL;DR – You are not as in control of the content of your hard drive as you think you are, especially with respect to the content managed by your web browser.

TL;DR #2 – Any process that generates artifacts from computer initiated actions aswell as human initiated actions is a candidate for the malware defense.

So when you think about the trojan defense, what comes to mind? Like my buddy I bet most people who dismiss the trojan defense imagine some sort of malware that secretly makes use of your internet connection and downloads CP to a hidden folder just waiting for law enforcement to discover it. Well that’s not too unreasonable, maybe ransomware or extortionware designed specifically for financial gain, but that’s not what I’m thinking about. Or how about this, malware that plays solitaire, or does your homework, or watches movies, or is a cyber-yenta using your IM program? All this stuff in a corporate environment that creates a case for mischarging – did they malware do it? Of course not. But again that’s also not what comes to mind when I think of the malware defense as it is not appropriate for those types of scenarios in which activity is generated by human initiated actions.

Let me ask a couple of rhetorical questions. Do you believe it’s possible for malware to alter the contents of your hard drive? I would hope the answer is yes. Unless it’s some proof of concept code or experimental code, most malware can and does manipulate your OS, which leads to manipulation of the hard drive. Do you accept the possibility that malware can introduce new content to your hard drive? Again, the answer should be yes. Thirdly, of the set of malware is there a subset that is specifically designed to intercept, hijack or otherwise interfere with the normal web browsing process of your OS and its web browsers? The answer is yes, there is a group of malware that is designed to manipulate normal web browsing processes, for example, BHOs, activex, flash, even exploiting the normal function of your browser by, say, opening up multiple tabs when you click ‘home’, tabs which may contain thumbnail pages of clickthrough content to objectionable websites.

Malware doesn’t even have to be on your computer. Imagine one day visiting CNN.com and discovering that a disgruntled employee decided to deface the website somehow. Your browser dutifully renders the website request content to be delivered to you, over the network, rendered in memory or virtual memory and ultimately stored on your hard drive in your caching mechanism. Perhaps the web page is ‘too big’ to fit in your browser and you would only see the content if you scrolled down to view it. Has that content already made it to your hard drive? Of course… There are accelerators and other browser add-ins that can cause all sorts of content to be transmitted over the network, rendered/processed in memory and stored all on your hard drive, giving the appearance of the end user specifically requesting such data.

So do you see where I’m going with this? It was at this point that my co-worker realized what I was hinting at. You are not as in control of the content of your hard drive as you think you are, especially with respect to the content managed by your web browser. The malware doesn’t have to specifically ‘go out and get badness’, no, on the contrary, by interfering with your web browsing process, malware can cause all sorts of content to inadvertently be deposited on to your hard drive.

Have you ever executed Sysinternals’ Process Monitor and watched all the activity go by when the OS is supposedly ‘idle’? It’s mind boggling the amount of stuff that goes on. Put on top of that web browsing and you get what is, in my opinion, the ‘noisiest’ thing you can do with an operating system. Data read/written to network sockets, read/written to memory and read/written to the hard drive. Even the OS can cause web browsing traffic to occur – really gumming up the works when it comes to discerning human-initiated versus computer-initiated traffic. And all the while, malware, designed to interfere with normal web browsing processes, generating its own traffic.

Let’s take an example from the corporate world. Imagine an employee walking by your cube and sees porn on your screen. They contact the ethics officer who subsequently opens a case. Technical assistance is requested to discover any evidence that can substantiate and the analyst finds pornography in the temporary internet files area of the hard drive. Is the employee fired just because it’s there?” Good lord I hope not, in fact the analyst shouldn’t even submit any report based solely on the presence of content only (note this might raise your hackles, but I’ve read/observed cases from both corporate and law enforcement in which this is exactly what happens). Rather the analyst needs to provide a narrative describing how  the content got there in the first place. Perhaps a mistyped search term or URL? Perhaps a compromised web advertisement place holder? (you’ll need your manual reconstruction skills for that one, and the next). Perhaps a compromised website in general? Perhaps malware on the local computer? Perhaps the individual really is seeking inappropriate content. The key to this investigation is accurately describing the actions that caused this content to be placed on the computer.

So, is the trojan defense actually plausible? You bet it is, for specific scenarios of course. Web Browsing being the most common. So I would caution anyone against dismissing the malware defense too quickly simply because it sounds too fantastic or unrealistic. Another scenario that comes to mind is P2P.

Update: 7/7/12 http://www.net-security.org/malware_news.php?id=2177 (a real CP ransomware story. how about that)

Update2: 8/14 http://www.fbi.gov/news/stories/2012/august/new-internet-scam/new-internet-scam?utm_campaign=email-Immediate&utm_medium=email&utm_source=fbi-top-stories&utm_content=129647 (FBI alert regarding ransomware)

Posted in State of Affairs | Leave a Comment »

Windows 7 CD/DVD Burning

Posted by Paul Bobby on June 4, 2012

Plenty has been said about the “did they burn data to CD/DVD” question for Windows XP – but a recent case required me to answer the same question but this time for Windows 7. So has anything changed? Is it easier, harder? Well let’s find out.

Windows 7 comes with built in support for burning CD’s and DVD’s. A tool called Windows DVD Maker is provided to end-users as part of the Windows 7 operating system. This guide highlights artifacts that indicate if/when a blank CD/DVD was inserted in to the drive, and also how to determine what was burned to that media.

The Event Log

Windows 7 records information in 40+ event logs, not just the original big three (System, Application and Security). Several tests of burning data to DVD show that with under my current environment’s build and GPO configuration, the only event that gets written to a log is:

Event ID 133. Source "cdrom"

And this gets written to the System Event Log only. While there is no supporting data for this event at EventID.net or in the Microsoft Knowledge Base, testing has shown that this event occurs when the burn button is clicked in Windows Explorer. Simply adding non-blank discs does not trigger this event.

image

The description, "locked for exclusive access" shows that the ‘burn’ process has actually started.

The Registry

The following key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CD Burning\StagingInfo

contains a KvP that resembles this:

Volume{77add596-7a9e-11e1-9114-806e6f6e6963}

image

The value "StagingPath" is significant. It shows the folder on the volume that is used to ‘stage’ files prior to committing them to the disc.

Once we have a file on an NTFS volume to look at, we can resort to standard file system forensics to figure out what, if anything, existed in this folder. (Remember, even folders are files to NTFS)

The Forensics

Deleted Files

When parsing an NTFS volume using Encase, the tool automatically assigns all deleted files, with intact MFT records, to the appropriate parent folder.

In other words, when you navigate to this folder using Encase, you may see deleted files in that folder. If they are in the clear, then you got very lucky and found a burning session in progress. Any file present in this folder, clear or deleted, is/was staged there as part of a burning session.

INDX Data

Remember, every folder in NTFS is a file. What does the "file" for the "\burn" folder contain? It contains a binary record structure that the Windows OS uses to display the contents of that folder called an INDX record. Here’s a sample:

image

The OS maintains the contents of this file on a real-time basis: as files are added to the folder, the content of this INDX is updated. As files are removed, the contents of this INDX are updated. Even though the folder is currently empty, it looks like there is some ‘leftover’ data in this file. Encase can parse this out for you using an enscript under Examples->Index Buffer Reader. Here’s a partial screenshot of what the output can look like:

image

The output shows that a file was present in this folder (you have a filename) and corresponding timestamps for that file show you when this occurred. It also comes with size information and MFT record information.

MFT Records – $LogFile

What is the $Logfile? It contains information used by NTFS for faster recoverability. The log file is used by Windows Server 2003 to restore metadata consistency to NTFS after a system failure. The size of the log file depends on the size of the volume, but you can increase the size of the log file by using the Chkdsk command. Source Microsoft KB Article (The Logfile is of course used in more than just Server 2003).

This file contains several useful artifacts, but the one we want are the MFT records. Encase has an enscript to parse this file, it’s under Case Processor.

image

Once parsed, your case will contain a series of bookmarks (sometimes 100s of the things), one bookmark for each MFT record found in the $LogFile. What do we want to look for in these bookmarks?

MFT records contains lots of useful information, but the piece we are looking for is called the "Parent MFT Record #". This associates a file with a particular parent folder, and that is basically how things are kept organized. So let’s find the MFT record for the "\Burn" folder.

image

The MFT record # for the Burn folder is 75485. Note make sure you select the right folder. You want the MFT record for that second ‘burn’ folder, not the first.

So, make your own Condition under the Bookmarks view called "Comment contains" that finds any comment that contains the parent MFT record #, and ta-da, you now have a list of files that once existed in that folder. Why? Because every MFT record also stores the MFT number of its parent folder.

MFT Records – The Journal File

What is this journal file? The USN Journal (Update Sequence Number Journal) is a system management feature that records changes to all files, streams and directories on the volume, as well as their various attributes and security settings. The journal is made available for applications to track changes to the volume.[12] This journal can be enabled or disabled on non-system volumes[13] and is not enabled by default for a newly added drive. Source Wikipedia article on NTFS

This information is stored in a file called $USNJRNL, in the folder C:\$Extend. The files comes with two streams, and the one that contains the data we really want is:

image

Encase does not have a built-in enscript for parsing that file, but there are some scripts out there, along with standalone tools that can parse the Journal file. My favorite comes from TZWorks and is called Windows Journal Parser. Get it. Here is a sample output from this tool, already filtered to include files whose parent MFT ID matches that of the "\burn" folder:

image

The highlighted piece is the hex value for the parent MFT. Any entry that has this same parent MFT hex value once existed in this folder, therefore the data was burned, or staged for burning.

So that’s it? Any problems?

One thing I can think of, what if the user starts staging data in that folder but changes his mind and deletes it? Can I prove the actual burn took place? It looks like Event ID 133 occurs when the burn button is clicked, so if you can correlate this event to MFT records showing content in that folder, then it’s a solid conclusion to make. And I’m beginning to suspect that staging is not the write word to use. Continue reading.

If you look at the output of the USNJRNL parse, you’ll see that the file was copied and deleted all within the same second – I’d like to think that that indicates a successful burn. Some further testing is needed there – but it appears that staging doesn’t occur as I traditionally think of staging: as you select files and folders, place that data in the burn folder until you click Burn. That’s inefficient, instead it looks some sort of data structure is maintained in RAM to hold pointers to the data you wish to burn, and the actual commit to disk process involves taking each file, one at a time, and writing to the Burn folder, then to Disc, then deleting from the Burn folder.

I welcome any additional information you may have, especially if you have noticed different behavior or discrepancies in my write up.

Posted in Forensics | 1 Comment »