In this lesson,
we're going to talk about metadata
and how it can be used inside
of your incident response investigations.
Now when you talk about metadata,
this is data about data,
or data about a file or application
or other thing.
Most commonly you're going to see metadata
include things like
the file name, the file size, the file type,
the creation date, the modification date,
the last access date, who owns the file,
the checksum associated with the file
and things like that.
So let me go ahead
and show you some metadata about a file
called invoice.pdf
that we suspect is malicious or suspicious,
and we're using it as part of our investigation.
So we take this file called invoice.pdf
and when we give this to a malware analysis person,
they're going to go ahead and reverse engineer that,
and figure out is there any malware inside of it.
Because often, these PDFs will have malware embedded inside
of them because it's a common attack vector
that's used by criminals.
Now, when we have something like invoice.pdf,
usually we're going to see this as part of a phishing campaign.
Somebody's going to send an email to your organization
and say, "Hey, here's your overdue invoice.
"You need to pay it today."
And somebody will click on that
and open the file to look at the invoice.
And when they do, it looks like an invoice,
but there's also some hidden malware in there
that could actually run on your system,
and infect the system and take hold.
And that's why this is really effective.
So what kind of metadata can we use from this file
to be able to block this from the future
once we know it's malicious?
Well, the most commonly used thing is going
to be the MD5 or SHA-256 checksum.
Remember, these checksums serve as a digital fingerprint
to uniquely identify this file including
the malware it contains.
So we can use this as a way to add this into our system
and use these file hashes
as something that can be checked
as something that entering in or out of our network.
And if it sees that hash,
it will block those files
from being downloaded to the future.
So if one person on our network fell
for this phishing attack,
we want to make sure nobody else does as well.
And we can do that by blocking these hash values from being
able to be executed or opened on our systems.
Some other things we'll see is the file name,
the file size and the file type.
For example, the file name says invoice.pdf,
which is fine.
But if we saw the file type,
wasn't a PDF document
and instead it was a ".doc" or an ".exe" type of document,
that would be a mismatch
between the file extension of PDF and the file type.
In Windows, we use the three characters
after the "." to identify the file type.
But in Linux and Mac systems,
that is not actually needed.
And so instead, it looks at the first couple of bytes inside
of a file to determine what file type it is.
So if we look inside this file based
on the first couple of bytes
and we determine it's actually a file
that includes a JPEG or an executable,
or a batch file
or something like that and not a PDF,
but the extension says ".pdf"
that would also be something
that's suspicious and we can learn that from the metadata.
Other things we can look at is the creation modified
and access dates.
If we look at these dates
and they're not in alignment with
what we would expect,
that would be something
that we would be worried about.
For example, if the creation date
of this file was actually 2012,
but I received the invoice today,
that probably is not an accurate file
and it would be something I want to block,
and treat as suspicious or malicious.
Similarly, if I look at the file and it was created modified
and access just a few minutes ago,
that can also be suspicious.
Now, in the case of an invoice,
it probably wouldn't be
that suspicious because I would normally create my invoice
and send it to you immediately after creating it.
And so you'd expect the creation, modified,
and access date to be all within a couple of minutes
of each other as we see here.
The other thing we can look at is the owner of the file.
Who is the user who created or owns this file?
And so if we found this file was malicious
and we found out that Joe was the person who started it,
then we can go and say,
"Hey Joe, why do you have this malicious file?"
And he might say,
"Oh, well I got an email earlier
"from a vendor and I clicked on it to pay the invoice,
"and that's why it got created on his
"system as him as the owner."
And that would be something we can explain
away during our investigation.
But these are all things that we can use
as part of our investigation.
It's more data about this file,
and where it's been and what it's doing.
In addition to that, we could see the file path.
If this is located in the C:\TEMP\ directory,
that would be something that is suspicious or malicious
because a lot of times malware tries to run from
that Temporary Directory as opposed
to running from a trusted directory
like a user's document folder.
Again, these are things that are all pieces of a clue
and nothing by itself is going to tell us
that this is malicious,
but it does give us additional
pieces of information that we can then use
as we're looking at these files
and use them as part
of our indicators of compromise inside
of our investigations.