- My name's Lee, as you heard, and we're gonna
talk about some MAC times today.
We're talk a little bit about Windows MAC times.
And how screwing them up, and your interpretation
of them of them is really not a good idea
and then we're gonna talk about how the Mac MAC times
can help you in your investigations.
So this is me
I've just recently started with SANS a few months ago.
This is great and I love working there
and while people enjoy gonna live events,
I work in the OnDemand side, so take
some OnDemand classes too.
By the way, the weight loss,
the challenge for that was just to cover up
the tape worm infection.
(audience laughing)
So let's start with Windows timestamps.
Some of you are gonna think, why we talking
about this, we already know about this.
Well, there's a lot of people who think they know about this
so just pay attention please, we've already
locked the doors anyway.
So Windows, most Windows systems use and NTFS
as we know, and NTFS has the MFT and in the MFT
each file and folder has got its own entry.
In that entry we'll expect to see, two sets of time stamps
standard information attributes, and file name attributes,
and we'll get to them in just a second.
This is what I ripped off from Rob,
the SANS poster which everyone got a copy of
so you have no excuse.
That one you have collecting dust in your drawer,
you can throw away now and hang this one up on your wall.
The best part of this, in my humble opinion,
is this top corner and here you'll see we have separated,
we have the standard information attributes
and here we have eight different scenarios
where these items can and will change.
Standard information attributes
is typically what you'll see if you use
off the shelf forensics software like EnCase, X-Ways, FTK,
those kinds of things.
Seldom do they show the second set of dates and times,
the filename attributes, which is a shame because
as you can see, you'll have a bit blurred out now.
But, the standard information attributes
and the filename attributes behave very differently.
which can be a little bit confusing at times
but more often than not, this is gonna
be key to an investigation.
So I want to share just a quick example
with you a case I worked on recently.
Some of you may be familiar with this type of scenario
We have a guy who works at a company
and he decides to leave the company, go to a competitor.
Now, in this particular case this guy
didn't return the computer, his work computer,
to his original company until one week after he left.
Which raised suspicion.
So he sent his computer back, the original company
had it forensically analyzed and they found two things.
The first thing
is that laptop had thousands
of deleted it work related files on there,
which is not a good start.
The second thing they found was that the
there was an external hard drive plugged in
just two days before the laptop was returned.
And through their analysis of the link files
and the jump place in the MRU's they were able to determine
that there were quite a few files on this USB hard drive
that shouldn't have been there.
Files which had the same names and occasionally
dates and times as those found on
the deleted files found on the laptop.
So they obviously weren't very happy
and I apologize for the language.
So they were very happy about this,
they got a lawyer involved and they sent
a request back to this guy and they asked
we want this external hard drive.
And so the guy obliged, he sent it back
and further analysis was done.
And the analyst found that unfortunately
every single one of those deleted files
from the laptop existed on this external hard drive
so this was a bit problematic.
And what they,
the conclusion that they came to
after they spoke to their employees,
was that this guy was not very technically adept.
He was not
an every day computer user.
People said he could do his email, search the web,
do some spreadsheets stuff, but that was it.
So the most interesting thing about external hard drive
was not that all these files existed on there,
but the time stamps associated with the created time
was preserved at the time copy.
This event happened in December of last year.
If you refer back to you SANS poster,
you'll see that file copying or drag and drop,
preserves only one time stamp, the last written time.
But in this case, the last written time
and the creation time are both preserved.
So, given that this guy was not hugely into computing
and these dates and times had been preserved,
the forensic analyst made a bit of a conclusion,
and that is that in the week that he had this laptop
he took into his new place of work,
they had an IT person at this company
load up some specialist copying software,
copied those files on to the external hard drive,
deleted those files and then sent the laptop back.
Interesting hypothesis.
They did, after they got the results of this analysis,
they sent notice to the new company,
and they basically added them to the list of defendants.
Not happy at all with this scenario.
So, what did they do?
Well, they went and hired a forensic analyst
of their own and that's where I come in.
And so I took a look at the external hard drive
to start with and I saw, pretty much,
the same thing as the other guy, that all the created
and last written times were exactly as they were found
on the deleted files, so potentially yeah
I mean you could say that specialist copying software
was used here.
But then if it was, why only half the times preserved
why not the other half?
Maybe some settings, maybe not, well, let's have a look.
So I went and look at the filename attributes
and they were all exactly the same.
They all reflected the time that
this transfer of data took place.
So now I've got eight MAC times to look at,
so I went back to my trusty SANS poster.
And knowing that the last written and the created time
were preserved, but all of the other dates and times
were updated, we could narrow this
down potentially to a volume file move.
Now two questions from this,
what's a volume file move and why potentially.
Well, volume file move really,
really straightforward and simple.
It's, you have a window open over here for one drive,
you right-click and select cut you over
to another drive you right-click and select paste.
That simple, it's a cut and paste.
Now, if that's the case then all this stuff about
the specialist copying software is all in their heads.
And that's what we wanna prove.
Now, why potentially, well, we've only looked
at half of the evidence we only looked
at the external hard drive, so let's
take a look at the laptop.
Well if this is a cut and paste, the key thing
we're gonna look at here is we want to see
that a cut is gonna delete the files
at the exact same time that they're copied
to the external hard drive.
So, we want to find out when those files were deleted.
Now here's the rub,
is that file deletion
and people always say this isn't true,
file deletion is not recorded in the MFT.
The time that a file is deleted you will not find
from the from the MAC times.
And I get people saying, anyway I posted this the other day,
and I got like a flood of emails, this not true,
it's not true, it's true, okay, just deal with it.
(audience laughing)
So we want to look somewhere where we're gonna
get these file deletion times from.
So we're stepping out of the MFT for just a moment,
and we're gonna look at the USN Journal.
And so here we've got all the stuff
from the filename attributes, all the dates and times,
and we wanna make sure that for each file,
each and every single one of these thousands of files
that when it was appeared on the USB hard drive
is the exact same time that it was deleted from the laptop.
And because I'm standing up here talking about this,
you probably already figured out they matched up perfectly.
So we now went from our hunch that this was
a cut and paste to it was definitely a cut and paste.
So we went and we also looked for evidence
of the specialist copying software being used
and as you may well have guessed, there was nothing.
So we went back to the court we said look,
this is the evidence we have, the court agreed,
the opposition was forced to concede,
they removed my client from the list of defendants.
So they were very very happy about this.
So, the one thing that I just wanna touch on quickly
is that frequently, when we do investigations
we find one thing and it sets us on course.
Now, good investigators will alter course
when they see more evidence.
I'm not gonna say bad investigators,
because it happens to everyone but probably
less experienced investigators will not course correct
when they see evidence which contradicts what they believe.
It's so important that we let the evidence
speak for itself and that we just become the mouthpiece.
We can't let
our own agendas affect
what we put in our reports.
So that's the end of that.
That's the Windows piece wrapped up.
It's so vital that we we understand
how time stamps work and how they're manipulated
because I spoke to another very experienced
forensic investigator after I did this case
and explained what happened.
He's like, you know, I don't think I would have seen that.
So use that poster, it's awesome.
So that leads us on to Mac MAC times.
and Mac OS uses HFS+, at least it does for now,
it's gonna change for SSD drives very shortly,
but HFS+ has something called the Catalog
which is likely MFT for NTFS.
Once again each file folder has its own entry
in that Catalog.
and for each file folder's entry
there are a set of MAC times.
There's Created, there's Written, there's Accessed
and there's Record Change.
And these are all stored in HFS+ 32-bit values.
Then Apple kinda went off the rails a little bit
and they added another time stamp.
This is called the Added date.
And when you look at these first four in the Catalog
they're all nicely together in a nice little section
one after the other all nice and neat.
But then right of the end of the Catalog record
for a file crammed in at the very end,
is something called the added date.
And this added date, is not even in the same format
as the others this is crammed in as a UNIX 32-bit value.
Now for a company that's so hung up on aesthetics
and design this is really crap.
So, I love Apple, but this is stupid.
I'm so yeah, I mean for for obvious reasons
This has been referred to as the Jon Snow value.
(audience laughing)
And the whole reason I've went through all this testing
to figure this out is because I want you to recreate
the same kind of thing we see on
the Windows SANS forensic poster for times
and do the same thing for the Mac.
So I'll run through just a few examples
because I'm gonna go over time anyway.
We'll start with file creation,
as you can see for file creation
the four regular time stamps updated
but that last Added date is not populated
at the time of file creation, you know nothing Jon Snow.
File Modification, the creation time doesn't change,
the Added time doesn't change, but the other three do.
And then we get on to something a bit more complicated.
File duplication, file duplication in Mac OS
can be done in one of 2 ways.
And you can right-click on a file,
select copy, right-click and select paste.
That's a huge four mouse clicks.
That's just not Apple's way, so you can right-click
on a file and select Duplicate.
And the same thing will happen, a new file will appear.
So only two mouse clicks, that's right Microsoft, suck it.
(audience laughing)
I love Microsoft really honest.
But here's the problem, our case that
we talked about earlier on with a Windows machine,
if it had been a Mac system we run into a problem,
because the volume file move and file duplication
change the exact same timestamps.
So it means that you have to dig in really really deep
to try and figure out whether it was actually a move
or file duplication that had taken place.
So that's the finished chart.
This will go up on the on the SANS website.
After the Summit is over so don't worry
about getting a picture right now.
And then what happens when you start to introduce
other file systems, well, this is where it gets really fun.
So, we'll start with FAT because Mac OS has got
built in support for read and write to and from FAT.
So with FAT, whenever you create a file
also whenever you move a file and bearing in mind
that copying and moving are the same thing.
Created, Last Written are inherited from the original
and Access Date is updated to the time,
or updated to the date that the copy was made.
What about the other way around,
well it is pretty much the same except that
there's just more values.
So the Created, Modified, once again Inherited
everything else updates the time of copy.
Now there is a bit of an issue here
is that if you've got a file, picture.jpg,
and you copy that from your MAC onto the USB
which is formatted as FAT, and then you then
take that drive, plug it in somewhere else
and you access that file
that file access time gets updated.
Which means you no longer know when that file
was put on that drive because the Access Date
was the only thing telling you when that file was copied.
Well there's some good news.
And you may have seen this if you operate
between Windows and Mac quite frequently.
Is that what have you copy a file from HFS+
to a FAT file system,
not only do you get the file
that you copied but you also get ._ file
which has almost the exact same name.
Now that file contains various pieces of metadata
you can take a look at, but the interesting thing
is that because that's not being copied from anywhere
that's a brand new file being created on the fly,
That the created time of that file will equate
within a few seconds, of the created time
of the original file was copied onto the drive.
So great stuff to know.
What are NTFS?
Well, Mac OS had got native read from NTFS
so let's start with that.
It's exactly the same as with FAT.
Created, Modified, a preserved everything else updated.
And what about going to NTFS?
Well you can do this in one of three ways.
The first way is that, this may come as a surprise
to a lot of people, Mac OS actually
has a native NTFS driver built in to the operating system.
You can enable this by going to a certain .plist
and adding a value and it will almost guarantee
the screwing up of anything you have on an NTFS drive.
I would advise is heavily against using that.
The second thing you can do is that you can use
the open source tools which are out there.
But here's the thing, you gotta install
like three or four different things
and then as soon as one of those updates
or the operating system updates, everything breaks
and you have to start again, so it can be time consuming.
The third option which is the one I choose because I'm lazy.
Is using a paid product to do that.
Tuxera, Paragon, things of that nature, I use Tuxera.
So you use those, you transfer a file from HFS+ to NTFS
this is what you expect to see, same thing
as you would for volume file move on Windows.
Created, Last Written, preserved, everything else updated.
No, if you copy to NTFS
using something like Tuxera
or Paragon or one of the open source alternatives,
you do not get the ._ files.
The reason is is because the metadata contained
within those will be natively adopted by NTFS.
So, just watch out for that.
Another complication,
this one really needs to be addressed.
Is that we talk about file access.
Now, as we're aware in Windows this
was pretty much turned off from Windows Vista onwards.
Still active on Mac OS so you may think this is great.
I know when the user last open this file.
No you don't not, from this value,
this value can be updated a number of different ways.
One of them is being indexed by spotlight.
Another one is that the user right-clicks
on the file and says Get info, that will update this too.
But there's also other issues,
I'm gonna walk you through now.
I'm sorry this might be a little bit small
for people to see but, you can see, if you're
close enough you can see here and I'm gonna
run a stack command on a specific file.
And on this file, we see this file was last accessed
on October 17th but in the GUI, the GUI's reporting
that it was last opened on October 12th.
Doesn't make much sense.
So I closed the file, opened it again, closed it again.
Ran Stat again, the exact same thing.
The Access time had not updated.
But the GUI updated to the date and time
that I'd opened the file.
So this left me a bit confused.
I know this is not in the Catalog anywhere,
I mean I looked hard for this.
So I ran the MDLS command.
MDLS pull in all the metadata for a given file.
And I found some really cool stuff,
more than I expected to see.
The first thing is just KMDItemLastUsedDate.
Which corresponds exactly to the Last opened date
that we saw in the GUI.
But more than that we've got these
other two cool things down the bottom.
The first one is this KMDItemUseCount which allegedly
gives the number of times the file's been opened.
One problem is this increments by one or two,
just depends and I have not figured out
what that depends on yet, but we'll figure it out.
But the other cool thing is KMDIemUsedDates,
this is an array, so if you have a user says,
I don't know about that file, I don't know how it got there.
It was nothing to do with me.
Well, why have you opened it several times?
Now unfortunately this only resolves to the day
if you can see the time is kind of blanked out.
But still very very useful for us to know.
And then, as I was looking at this,
I found some other cool stuff.
KMDItemUserModifiedDate, this one, also very very cool.
another array and this will tell you
all of the times that the file was saved.
Now I haven't quite maxed out how large this array is yet.
But, not only do you get the date and time
these files were opened but you also get this other
handy little array down at the bottom which tells you
which user was responsible too.
So, once again, very very handy.
I had no idea about that file, I've never touched it before.
Well you've opened it this date
and then you saved it this time and this time,
are you sure you didn't know about this?
I think they change the story pretty quickly.
And then finally we come to something which puzzled me
for the longest time.
We have an array for Created Date.
Why do you need an array creation?
You create a file once.
Another one of those stupid Apple things.
Well anyway,
and this,
I didn't figure this out
I'll be honest, this was Nicole who spoke earlier today
helped me with this by doing some
her independent testing on this.
I don't know why they do this,
but Apple.
So, in order to get this to work, let's say
you have a file sitting on your desktop.
You open and save a file, this doesn't update.
You Save as, over top of that same file,
this doesn't update.
If you have another file that's on another drive
or in another folder, you open that and then save
over the top of the file on your desktop
this gets updated.
Why would you wanna track that?
I don't know, Apple.
So thank you Nicole for helping helping me out with that.
Now, just something to bare in mind here,
is that depending on the file type this,
the three arrays we've looked at can behave differently.
Okay so if you have like a native Apple app
that you're using like text edit or preview
or something like that, you close those
and it automatically saves stuff.
You will see that the modify time will be updated
every single time you close it out.
If you're using Microsoft Office and you save a file
this does not get updated.
If you do Save as and save over your existing file
this does get updated.
So that might change in future versions,
we'll just have to wait and see.
Yeah and that that's pretty much everything
I've got for you today.
Just to recap, just wanna make sure
that everyone knows you gotta know your Windows times.
If you don't know your Windows times,
you're gonna get called out.
The Accessed in on Mac OS does not necessarily
mean use accessed, so bare that in mind too.
And then, finally, do not twist the facts
to fit your story,
just let the evidence speak for itself.