Home Archives for October 2013

13 Part 3 - SetMace

Detecting Fraud SetMace by David Cowen - HECF Blog

Hello Reader,
Yesterday we reviewed the timestomp tool and showed how simple MFT analysis can defeat it. Today we are going to go into the newest version of setmace v1006 which not only can modify the STDINFO timestamps but the FILENAME timestamps as well.

I'm not sure how widely known setmace is but I will tell you that its very good at what it does as we'll see in the screenshots below. Prior versions of setmace did some tricks with file moving to reset the FILENAME timestamps but in version v1006 it actually modifies the physical disk itself leaving very few traces of its actions. Setmace will work on NTFS and FAT file systems.

Things to understand

What it does

Setmace will access the underlying physical disk and modify the $MFT directly changing the timestamps you specify (STDINFO or FILENAME or both) or cloning them from another file. Since this is direct physical disk access there are no $logfile or USN entries that show these changes.

What it does not do

It does not change the MFT record number, sequence number or find other artifacts pointing to it. That does not mean that future versions couldn't be modified to further obfuscate the original timestamps.

Capabilities by OS

Windows XP

On a Windows XP system setmace can reset timestamps on a file on any volume as XP's security model did not restrict access to the physical disk. Further since Windows XP does not have a USN Journal by default the only way to prove the original timestamps of a file will either be through the $Logfile or shell items pointing to the file.

Windows Vista/7/8

On a Windows Vista/7/8 system setmace cannot access the physical disk of any system volume, but it can access the physical disk of non system volumes. In my virtual environment I created two additional partitions one which i ran setmace from and the other where i stored the files whose timestamps i reset.

What does it look like?

After setmace runs this is what the STDINFO timestamps look like:

This is what the FILENAME timestamps look like for both the 8.3 and Unicode filenames:

I've used 1-1-1970 here to make it easy to spot that this is a fake timestamp but notice something here, the milliseconds here are set. This is another standard forensic analysis technique to detect timestamp modification, finding files where the milliseconds are set to 0. In this instance our suspect could set the full timestamp value to any date/time desired or clone a valid file. Scary stuff

The USN Journal contains no entries as the timestamp alteration occured outside the filesystem driver, we do have an entry from the usage of the file prior to its timestamp alteration that we can gather a last true usage time from:

The $Logfile contains the original timestamps of these files from its creation:

However there is no entry in any of the filesystem journal logs we normally rely on that would detail the fact that a timestamp change occured, it would be up to the analyst to look for indicators.

What indicators are left?

Don't lose hope, this isn't a blank check just yet for undetectable timestamp alteration. We still have several analysis points left that can reveal past true timestamps of this file:

Shell Items contain timestamps, compare them to the MFT to determine if MFT creation date is different. Examples of Shell item containers include

LNK Files
Shell bags
Jumplists
Other registry keys being identified but that I don't have in front of me :) Sounds like a good post for next week.

MFT entry and sequence numbers, is the file outside the range that it should be in to be created at that time?
Registry MRUs
System restore points

Vista/7/8 - Shadow copies - Compare MFTs
XP - Restore Points - Parse LNK files for shell items

Any activity taken place through the filesystem driver prior to the timestamps change will still be in the $logfile and USN
Prefetch of the setmace execution

Now having said this, not every analyst will think of these things. This will require an additional steps in your process to look for these kinds of indicators and likely won't be the first thing you check for. Setmace will modify timestamps but it doesn't eliminate any of the IOCs/Artifacts you are already looking for.

I am going to be looking deeper into setmace to see what other artifacts of execution exist, I'll follow up on this on a later blogpost. Until then get some rest, these anti-forensic tools will only get better and you will have to do get better as well to keep up.

This is a 3-part series and here are all links to the entire series:

Detecting Fraud Part 3 - SetMace

Detecting Fraud Part 2 - Timestamp Changes

Detecting Fraud Part 1 - Time Changes

Hello Reader,
Yesterday we went through detecting system clock changes on Windows 7, today we are going to talk about timestamp changing using two different utilities, timestomp and setmace.

Why two timestamp changing tools? They have two different approaches, timestomp and its variants use a Win32 API call to change timestamps that allow them to adjust STDINFO attribute timestamps but not FILENAME attribute timestamps within the MFT. setmace on the other hand can change both and its use is currently not detectable by comparing the STDINFO and FILENAME timestamps. Let's get into it. None of the information in this post is new but I hope to frame it in such a way that it is easy to understand and approach if you don't have a low level understanding of MFT operations.

Initially I was going to cover both tools in this post, but there are enough details and new gotchas between the two to justify taking the time to split this between two posts. Today we will cover timestomp running through meterpeter on a compromised xp host.

Timestomp

Timestomp and other timestamp modification programs that work like it make use of the win32 api to reset timestamps located in the STDINFO MFT attribute for a file. STDINFO contains the timestamps shown to you within explorer and most non forensic file utilities. This method of timestamp modification has a simple detection mechanism that has been a staple for IR and forensic investigators to detect.

Step 1. Grab the MFT from the file system
Step 2. Parse the MFT (I used our ANJP tool)
Step 3. Compare the STDINFO creation/modification and access times to the FILENAME creation/modification and access times.

If the times in step 3 do not equal you have a file with a possibly altered timestamp.

Step 4. Validate your assumptions and make sure the file wasn't distributed by a vendor with a bad timestamp.

Here is an example, we created a file called 'test.txt'. We then used timestomp to reset the timestamp of that file to 0 which in timestomp terms is 1601-01-01 and the STDINFO creation dates look as follows:

When you look at the FILENAME attribute of the same file you will find the original timestamps:

So the comparison here is pretty obvious, not only because without the possibility of time travel there is no computer file being created in 1601 (Oh man, Time travel forensics!) but also because this file named:

is user created and not part of a system package or other vendor delivered weirdness that you can find. In my testing I found a lot of 0 date FILENAME attribute files within the system32 directory which surprised me.

Let's not stop here though, let's talk about why these things exist. When a file is created in NTFS the first thing that is created is a File record. This file record maintains the basic header needed for NTFS to be able to reference and find the file. The second thing created is the STDINFO or standard information attribute which contains metadata about the file, MAC timestamps, etc..., but not the name of the file itself. Instead the name of the file and an additional set of timestamps is kept in a separate attribute called FILENAME.

The first FILENAME attribute will contain the 8.3 version of the files name (so called because it allows 8 characters in the name and 3 in the extension). If the file name is longer than 8 characters in the name or 3 in the extension then a second FILENAME attribute will be created that will store it and another set of timestamps. There can be even more FILENAME attributes but I haven't found any documentation yet that states all the possible mechanisms that generate additional ones. If you have please leave a comment and let me know.

Tomorrow we will show how setmace works and how using journal forensics we can overcome what is a very effective methods with some limitations on newer platforms.

This is a 3-part series and here are all links to the entire series:

Detecting Fraud Part 3 - SetMace

Detecting Fraud Part 2 - Timestamp Changes

Detecting Fraud Part 1 - Time Changes

Detecting Fraud - Time Changes - HECF Blog

Hello Reader,
Let's talk about system clock changes which is one of the areas not covered by this weeks Sunday Funday winning answer. Often times when creating fraudulent documents a suspect will change the date of the system in order to make the document appear to be generated at an earlier time. If you've done these cases on Windows XP you've probably read Steve Bunting's old blog regarding this, http://www.stevebunting.org/udpd4n6/forensics/timechange.htm. However the event ids and sources have changed since XP and since this challenge focuses on Windows 7 I thought it would be useful to show what clock changes now look like.

Windows 7 has a lot more logging turned on by default, as such clock time change events are logged. The entry will be found in the 'Security' event log and the source will be 'Microsoft Windows security auditing'. The task category is 'Security State Change' and the Event ID is 4616. Here is an example:

You can see that the event records the previous and new times, in this case my clock was 9 minutes behind and I set it forward. If the clock were to be changed back you would see the new time be earlier than the previous time.

If you wanted to quickly determine if a user had changed the system clock recently this is the best place to quick filter for Event ID 4616. The security log for a workstation on my system goes back two months and there would be additional copies of it in the shadow copies and possible freesspace if you can recover event log entries from freespace.

So that is a pretty simple way to detect when the system clock for the entire system is changed, pretty easy huh? Tomorrow we will going into individual files timestamps being altered.

This is a 3-part series and here are all links to the entire series:

Detecting Fraud Part 3 - SetMace

Detecting Fraud Part 2 - Timestamp Changes

Detecting Fraud Part 1 - Time Changes

Sunday Funday by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
Another Sunday Funday behind us and a another challenger who came with a great writeup full of testing and description. This weeks winner Andy Dove is now a two time Sunday Funday winner and brought some good testing this week. I plan to spend this week delving into the host based artifacts outside of Office that Andy didn't cover.

The Challenge:

An employee has been terminated after a lengthy workplace investigation. After being terminated the employee has come back with a lawyer stating that a word document on their work computer will exonerate them and that they are suing for discrimination. The document appears to be a memo written by the employee's manager to the ex employee with derogatory language toward their race. The employee's manager has stated that they never wrote the document and they believe it be fraudlent.

If the employee was issued a Windows 7 system with Microsoft Word 2007 what would you do to determine:

Which system the document with authored on
Who was the author
What was the last author
If the time stamps have been altered

The Winning Answer:
Two Time Winner Andy Dove!

Nice to be back to Forensics for this week’s challenge. My first port of call in this particular situation is to look at the Metadata embedded into each Office File. This can be viewed quite simply using the Windows File Properties dialog. Of particular interest in this particular case are the internal author and timestamp fields. These internal timestamps are completely independent of the file system values and are not affected by utilities such as “Touch” which change MAC times. To illustrate this I have done the following:

Created a file in Word 2007
Copied it onto a FAT32 formatted SD Card.
Copied onto a different user account.
Edited the file on the new account.
Edited the file again and changed the Author using MS Word.

After each step I have displayed the properties and taken screenshots.

Original File

Note that in this document the internal creation time precedes the file system time. This is because the document was created within word, edited and then saved, rather than generating a new document from the Explorer right click menu.

Copied File (Unedited)

Here the file system times are again quite different to those held internally. Had this process taken place over hours or days rather than minutes this difference would highlight the document had likely been copied over onto the machine. Here the Author and Last Saved By fields also reflect the original values. Possibly of note is also that the the NTFS Modified TimeStamp value has also changed due to having been stored on a FAT32 system where the timestamp is stored with less precision.

Copied and Edited

After editing the Last Saved by field has been updated to show a new user has worked on the document.

Author Changed

Here I have edited the author field to make it look more likely that it was created by the second user.

Where was the Document Created?

In MS Office 97 a GUID based on the MAC address of the computer which created the document is embedded within the file. This is only added at creation time and is never changed on subsequent saves. I have examined all the embedded XML files in my test document and have not been able to find a similar artefact within the Word 2007 files. In this case I would revert to traditional forensic methods such as the examination of Jump Lists, Link Files, Prefetch Files and Volume Shadow Copy analysis to try and find evidence of the original file.

Interestingly the Windows file properties dialog isn’t your friend here. Although it shows an entry for computer (See below) switching to another machine and then displaying the properties will show the new computer rather than the one on which the document was created. The document shown below was created on a machine called PIGLET.

Examination on a non-Windows Machine

If examining the files on a non-windows machine it would be possible to view the embedded information by treating the file as a zip, unpacking it and opening the doc\Props\core.xml file. In the case of my original document this clearly shows the same information as shown previously:

AndyAndy1 2013-10-27T14:56:00Z 2013-10-27T14:57:00Z