Sunday Funday – Cutting across NTFS Volumes


Another Sunday Funday!

This time, we’re cutting and pasting across volumes. I decided to take a slightly different route than last week and just created two VHDs to cut and paste between. (I have no idea why I didn’t think of that last week, do all of the copying and pasting in one go and then be done with it. If there’s a hard way to do something, I will find it 🙂 ).

Test Plan!

I created a ‘copy’ VHD and a ‘paste’ VHD. I copied two of the files from last week into the ‘copy’ VHD and then used that on both tests. I mounted them on a Win7 VM and my Win10 (v1809) host and then did a mouse cut and paste.

There are two other ways that you can cut and paste files, which is using the keyboard and using the ribbon. These are most likely going to yield the same results, however, they haven’t been tested so I don’t know that for certain.

The operation is covered by the SANS ‘Evidence of’ poster, and as you can see Windows treats a cut/paste operation slightly differently to a CLI move operation. In both instances, the $FN timestamps will record the time of the move. In a cut/paste via Explorer, the $SI creation timestamps are preserved, however they are altered in a CLI move.

To vary things up a little bit, however, I tested three tools just to see what would happen.

  1. AccessData FTK Imager
  2. AnalyzeMFT
  3. MFTECmd


Good to have a hypothesis for these things. As it’s a cut operation, for the original I expect them to appear as deleted items in the MFT. Most likely there would be no updates to their timestamps, there could be an indication at the time of the cut, either in A/E timestamps, or maybe the Log/Journal (however checking them is outside of scope).

I don’t think there would be a time update on the original files at the time of the paste, as the OS should just delete the item. As per the SANS poster, a file deletion shouldn’t update any timestamps.

On the other side, I would expect to see what we know from the SANS poster, with the $SI MCE timestamps being inherited, and the $SI A and $FN timestamps indicating the time of the paste operation.


Test results can be found here

Overall, it appears that the cut/paste operation identified in the SANS poster holds true for Win7 and Win10. No changes were found on the original files other than they were deleted.

The newly pasted files kept their Created and Modified timestamps ($SI). All the other timestamps were updated to reflect the time of the move.

On Win10 the pasted items were given Object IDs, but they weren’t on Win7.

Other Things I noticed

The timestamp rounding was different between AnalyztMFT/MFTECmd and FTK Imager for some timestamps (one rounded up, the other down).

AnalyzeMFT has a column for “possible volume move”, however, it did not correctly identify the volume move operation in my test.

MFTECmd has a “copied” column, which did indicate that a copy took place, however, my test was inaccurate as I had copied items from my Desktop into the VHDs to begin with.



All of the tools worked well for this testing.

WinTeNTLM Issues


kitten cat rush lucky cat

Mini Cats! It will make sense later…

It’s not uncommon to be asked whether a user had a login password or to need it to login to a virtualised copy of a suspects computer. In the case of the later, you can usually just clear the password and proceed, but sometimes knowing the password may be important.

I played with a few tools that I had on hand to get a local user’s NTLM hash during Dave and Matt’s DFIR CTF at DEF CON and documented my findings (and finally got around to finishing this up)


Playing with the iOS Powerlog


I have recently started looking at the wealth of data that can be obtained from file system iPhone extractions; a lot of which has already been explored by Sarah Edwards in her iOS of Sauron presentation, and also recently in her post on the KnowledgeC database.

Based on that I decided to take a look at the powerlog PLSQL SQLite databases on a jailbroken iPhone running iOS 10.2. I would have to double check, but I don’t think this file will get exported from a standard backup, and as a result you’ll have to jail break the device to get at this file. (more…)

Zone Identifier == kMDItemWhereFroms?

A couple weeks ago at Techno Security I saw a presentation about examining cloud storage applications such as Dropbox. Whilst the presentation was great, the main thing I noticed was that when the presenter selected a Zone Identifier ADS there was more than the usual ZoneID=3.

Finally decided to do a little bit more digging!

For background on Zone Identifiers, you can see the paper by Paul Sanderson here.