Daily Blog #130: Detecting Fraud Sunday Funday 10/27/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:

Detecting Fraud SetMace by David Cowen - HECF Blog

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

Detecting Fraud SetMace by David Cowen - HECF Blog

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:

Detecting Fraud SetMace by David Cowen - HECF Blog

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

Detecting Fraud SetMace by David Cowen - HECF Blog

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:

Daily Blog #129: Detecting Fraud Sunday Funday 10/27/13 Part 2 - Timestamp changes

Detecting Fraud Part 2 - Timestamp 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:

Detecting Fraud Part 2 - Timestamp Changes


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

Detecting Fraud Part 2 - Timestamp Changes

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:

Detecting Fraud Part 2 - Timestamp Changes

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:

Daily Blog #128: Detecting Fraud Sunday Funday 10/27/13 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:

Detecting Fraud - Time Changes - HECF Blog

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.

Daily Blog #127: Sunday Funday 10/27/13 Winner!

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:

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

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

Original File


Sunday Funday by David Cowen - Hacking Exposed Computer Forensics Blog
Sunday Funday by David Cowen - Hacking Exposed Computer Forensics Blog

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)


Sunday Funday by David Cowen - Hacking Exposed Computer Forensics Blog
Sunday Funday by David Cowen - Hacking Exposed Computer Forensics Blog



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

Sunday Funday by David Cowen - Hacking Exposed Computer Forensics Blog
Sunday Funday by David Cowen - Hacking Exposed Computer Forensics Blog


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

Author Changed




Sunday Funday by David Cowen - Hacking Exposed Computer Forensics Blog

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.

Sunday Funday by David Cowen - Hacking Exposed Computer Forensics Blog

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

Also Read: Daily Blog #126

Daily Blog #126: Sunday Funday 10/27/13 - System Detection - Microsoft Word 2007 Challenge

System Detection - Microsoft Word 2007 Challenge

Hello Reader,
          It's Sunday Funday time again!Let's switch up these contests to something a little more internal investigation focused, these fraud cases are more common than you may think!

The Prize:

  • A signed copy of the new book

The Rules:
  1. You must post your answer before Monday 10/28/13 2AM CST (GMT -5)
  2. The most complete answer wins
  3. You are allowed to edit your answer after posting
  4. If two answers are too similar for one to win, the one with the earlier posting time wins
  5. Be specific and be thoughtful 
  6. Anonymous entries are allowed, please email them to dcowen@g-cpartners.com
  7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post

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
Also Read: Daily Blog #125

Daily Blog #125: Saturday Reading 10/26/13

Saturday Reading by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
       It's Saturday! Time to rock out with your dongle out as we get down to some forensic goodness.

1. We had the third and final IR roundtable on the forensic lunch yesterday, watch it here http://www.youtube.com/watch?v=7UZnJ5m5aLc and make sure to tune in live next week 11/1/2013 at noon central.This week we covered the end of the IR lifecycle with remediation, how to communicate with teams during an IR and more.

2. If you use both Encase and IEF make sure to read this post on creating logical evidence files from the data recovered by IEF so it can be brought in directly, http://www.forensicfocus.com/News/article/sid=2108/.

3. Lance Mueller has a good post up listing out those tools he makes use of and establishing a hierarchy of tools in his arsenal, http://www.forensickb.com/2013/10/what-tier-2-tier-3-tools-do-you-load-on.html, its a good way to think about the tools you use and please comment on Lance's post if you use any additional tools.

4. I read the cyb3rcrim3 blog but only really include it here with it involves an interesting civil case, this week we have a winner http://cyb3rcrim3.blogspot.com/2013/10/the-contractor-login-and-computer.html. This case involves a dispute between a contract developer and his client and the rash steps he took when he didn't receive payment, namely locking his client out of the system he developed for them. This is a good read with many implications for those of you freelancing out there to remind you not to give in to that bad idea.

5. If you are doing IR and want to be able to search for possible exploits to known ports/errors within logs on systems you are triaging Corey has a new custom Google search for you called Vulnerability Search http://journeyintoir.blogspot.com/2013/10/re-introducing-vulnerability-search.html.

6. Lastly this week a short article from DFI News talking about ways to become a more credible witness, http://www.dfinews.com/articles/2013/10/gain-credibility-courtroom, I'll want to talk about this more next week :)

Stay tuned for another Sunday Funday tomorrow!

Also Read: Daily Blog #124

Daily Blog #124: Forensic Lunch 10/25/13 - Discussion with James Lohman and Kyle Maxwell

Discussion with James Lohman and Kyle Maxwell

Hello Reader,
              We had another great forensic lunch today, this time we finished out the IR roundtable series with James Lohman and Kyle Maxwell joining us to discuss the end of the IR lifecycle. From dealing with aggravated attackers, working with worried clients to best practices in remediation we got some great facts and opinions out there for you to consider. Please give it a watch and try to join us live next week when we return to digital forensics topics!



Daily Blog #123: Svchost Persistance Question Answered

Svchost Persistance Question Answered

Hello Reader,
            After getting our stock XP VM license up and activated I did some testing today with the svchost key found here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost The purpose of my testing was to determine what would be required to enable persistence using the Service Host facility. This came about after this weeks Sunday Funday answer and Harlan Carvey's follow on question. After doing my testing this is what I can say.

1. The svchost key determines grouping for which services will run under which svchost process, but it does not attempt to call out to the path for any executable. Instead svchost is looking into the services key found in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services to find the information needed to find and execute the service. 

Result: Svchost on its own is not a persistence mechanism

2. You cannot create just a stub service in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services and expect it to run from svchost. The service must be correctly registered and seen by services in order for svchost to execute it. 

Result: Currently I do not see a way to half create an executable service that will not be listed in services, this requires more testing to find what the criteria is for a executable service.

3. You cannot append a ; to the ImagePath key and get a second command to execute, for instance I appended the following: ; %SystemRoot%\system32\test.bat to the ImagePath value for DHCP found in the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dhcp\ImagePath which was only met with a service that failed to start.

Result: Currently I do not see a way to load a second program within a legitimate service stub, this also needs further test

So there you are, I am going to play with this a bit more and bad guys can still use the method Harlan Carvey documented on the secure works blog to hide as a legit service. Otherwise my testing just lead to execution failures and dead ends, which is good for the analyst! 

Did you find something different? Leave a comment or email me dcowen@g-cpartners.com