In this episode,
we're going to talk about file analysis and how to
go through the process of identifying malware and appropriately responding.
We're going to take a look at both dynamic
and static analysis and the differences between them.
We're also going to talk about file integrity and how to use hash values to ensure the
integrity of our files both at the operating system
structure as well as from the application structure.
We're also filing,
going to look at strings and how strings are utilized
to go through our systems and really go through and
search different aspects of our operating system or our file
structure to identify different malicious activity that may be ongoing
throughout this episode.
What you really need to take away from it is that cys
A expects you to have not only a theoretical concept of it
but a practical standpoint.
This is divergent from what you may have seen in security.
Plus,
as we go through these take into account
that we're only covering the theory right now.
In the next episode,
we're going to get our hands dirty and actually look at it from a perspective
of practical standpoint file analysis is the examination
of the file to understand the behavior,
the purpose and the potential impact of the system.
More often than not.
When we do file analysis,
we perceive that there may be an issue within the file structure.
This could be because of a bug,
it could be because of another application interfering with the file structure.
Or if all things go bad,
it could be because a malicious actor gone in
there and is messing with that file structure.
File analysis is done in really two points,
either a static analysis or a dynamic analysis.
We're gonna talk about both those.
One way to identify static analysis is through signature analysis.
Every file on your system has a specific signature through the
file header or what's commonly known as the magic number.
This signature provides information about the file type and
can help determine if it matches the expected format,
whether it's in TFS or a fat format.
This signature really provides us a clear viewpoint of if the file is changed or not.
The next analysis type is considered metadata and a metadata analysis.
We're extracting and analyzing the information embedded in the file.
When we look at pictures,
we often identify the metadata in terms of if there's a GPS coordinate,
what type of pixelation is occurring so on and so forth.
But in files, we're looking at the actual data as in what's the author's name.
When was the file created?
Has it been revised or changed recently,
all that metadata can lead us to whether or not the file is changed.
And if so how it has changed.
The third type is a file structure analysis. In a file structure analysis.
We're looking at the internal components such as headers or sections,
we're looking at data segments to identify,
have there been changes to that and any abnormalities that may exist.
When we're looking at a file structure analysis,
we're more looking to see if the data has moved or changed
in such a way that doesn't make sense for the actual file.
The last type of static analysis is considered entropy static analysis.
In this type, we're looking at the R
of the data.
If I see a data that hasn't had a lot of
randomness to it or it's very set up and repetitive,
that's indicative of a malicious content within that file structure.
If it has a lot of randomness,
that means that the file is most likely sincere
and doesn't have that malicious content attributed to it.
Remember when we see a lot of
repetitive numbers or repetitive information within an entropy
analysis that leads to be indicative of
malicious content associated with that specific file.
The second type of analysis is called dynamic analysis.
When we sandbox something we're really taking the file structure and
we're protecting other systems or other network features from that environment
in a sandbox environment, we're closing it up, it doesn't have internet access.
It's usually set up in a virtual capacity
to where if something happens in that environment,
we can just delete the entire thing and it doesn't have any harm to our other systems.
In a dynamic analysis.
We're going to actually start the file,
we're going to open it up and let the program run the way that it would normally run.
We're going to identify what happened. Did it involve other applications?
Is it affecting the operating system?
Is it doing a lot of things that it shouldn't be doing?
Or is it working the way it should work in a file structure?
We're looking at the same perceptions that we would
normally look in a static or dynamic code analysis.
They're very similar in that we're looking to see what happens
when we open or run that file in that environment.
The other aspect is behavioral analysis,
much like the sandboxing environment where we're going through
when we're securing the system and behavioral analysis,
we're looking at how it behaves in
the environment that it's operating currently in?
This means that I can run the file structure and I can identify,
did it touch other applications?
These are very similar in their degree.
But remember in a sandbox environment,
we're shutting it off from the rest of our network,
we can still run the behavioral analysis
in that sandboxing environment which we described.
But we can also don't have to necessarily sandbox it
sometimes we don't perceive the threat to be that great.
And we can run the behavioral analysis through our indicative machine,
meaning that the file is there and we're just going to run it to see what happens.
I don't recommend this structure.
Usually we move it to a sandbox environment after isolating that machine.
But sometimes we may perceive that the value based off of
that machine and its capacity of the information doesn't make sense.
We'll just isolate the machine and then run the file directly from it.
File integrity is where we go into play and we're measuring different files.
Remember if I update a machine or update to the
latest operating system or even update the latest software,
the file structure could change, we could be adding more information to that file.
We could be deleting old versions of that file in any case it could change.
But what about my operating system or what about
a file structure that I didn't give permission for it
to change if we're not writing new data to it
and it's a core portion of the operating system.
Um or the application, I'm running,
the file structure should remain unchanged and the file should remain unchanged.
This is where we talk about file integrity.
The integrity of the file should not change unless I give it a patch or
I'm updating the software or something is happening
within my system that makes it change.
In this aspect,
we can actually go through and measure if something change it to report to our
system because the integrity of that file
changes and we track that through hashing mechanisms
through hashing,
I take an individual file or multiple files and I hash
each individual file separately that gives me a hash value.
If that value changes, I know that something within that file has also changed.
This is where file integrity checks take place.
Now, we haven't talked about hashing yet.
So let's show what it really looks like on Cali.
I'm just going to show you real quickly what a hash looks like.
And what happens if we change a file within our system and run a new hash.
Let's take a look at that now.
So here
I am on my Kali box,
I'm gonna go ahead and open up a terminal real quick and let me blow this up.
So you can actually read it.
The first thing that we need to do is actually
create a file or a document in which to hash.
I'm going to create one right now. I'm just going to use a program called leafpad.
It's much like notepad that you might see on a Microsoft Windows machine.
It does the same thing.
So I'm going to name my file and I'm just going to name mine Total
sim just like that
I've created my file. It opens up right here
and here you can see that I can type whatever I want in. I'm gonna put,
I'm going to pass
my sea
Ys A plus exam with
flying colors. Thanks
Dr K
exclamation marks four of them just to be safe. We're gonna save this
right here and I'm gonna go ahead and close it now.
If I do an L si can see this right here.
My totalsem document and I'm gonna run a hash on that.
I'm gonna run a basic MD5 hash by typing MD5 sub
and then the file I want
to hash
I press enter and you can see here that it gives me a hash value for MD five.
Now, I could do this on a shaw as well. I could do a sha
256 sum. And again, I can run it on
the file total seminars. Oops
hold hold, let's do that tab T just like that. And again, you can see here that the shaw
is actually quite a substantially larger than our MD5.
Now, let's go back into that same file. I'm gonna go leafpad total seven.
It's gonna open it back up and I'm only going to change one thing.
I'm just gonna delete this one exclamation mark. That's all I'm going to do.
I'm gonna resave it
and again, it's received, let's rerun that sha 256 sum for that hash value.
I want to point out that all I did was erase one exclamation mark and look
the shaw value. The hash value has changed
if we were identifying this through automated means we
would know that something changed right off the bat because
this was our baseline hash for that file and it
now has changed when we reran the hash value.
Now we can set up our system to rerun hashes on an hourly basis every 10 minutes.
It doesn't really matter how often we do it.
We just want to do it at least 24 hours every
24 hours to prove the integrity of our file system.
Let's go back and change the file to its original content.
I'm gonna open up again that leafpad totalsem
gonna go in there and again,
I'm gonna go back to the very end and re add that one exclamation mark.
Let me go back there and save it again.
Here we go.
And I'm going to run that 256 to total sum
and look at that.
Our hash value is back to the original hash value that we
had because the value has changed back to the original point.
This is where hashing comes into play where it
provides us a good signature of the files.
And if the integrity changes, it will notify us.
I want to go on to strings and talk a
little bit about what they are and how they're utilized.
Strings are a utility that we utilize to analyze
binary and executable files within our core structure.
This provides us a good segue into understanding
what's going on in terms of search capability.
This means that I can go through and actually look
at registry keys and find out if malware has inadvertently
change our registry keys from our original operating system.
Now, it doesn't sound like much. But this could be an invaluable tool.
If I'm trying to define or identify
potential malware within my core operating system,
we're gonna go through registry strings from a
hands on perspective later within this course,
if I have file names on my system,
I need to be able to search and make sure that
those file names correspond directly to the program that's associated with.
I want you to imagine that you're programming a big
game and you've got a lot of files on your
computer system that are pulling into this program to allow
your character to move from point A to point B.
If that file name suddenly changes, you've ruined the entire program.
That's a problem with file names changing.
If we have a file name that we want to make sure that it doesn't change,
then our pathway of strings will allow us to
go through and search for those individual file names.
It could also lead us to other malware. If I take a file name and I
input it or I change it very slightly.
Let's say that I have a file name called operating system.
I have this original file.
It's for the original operating system and it has all
kinds of configuration and required files injected within it.
If I'm a malicious user, I can rename that file name to file names dot
Does it just file names with a period at the end?
I then create a new folder that's called file names.
This poses a problem within our security infrastructure
that malicious actor can then inject that file names folder with all kinds
of malicious activity and change the code that was originally perceived within it.
They didn't delete the file names folder,
they just change it and they substitute it with their version of that file names,
folder.
This poses problems.
The next portion is path
if I have a path that's attributed to a
specific file name and that path changes it again,
could ruin the program.
But what if I divert that same path over to a
different file that has malicious code in jetted within it?
You see the problem, these strings really provide us a gate
way into understanding where things are and how to get to them.
Host names are no different.
If I go into a hostname and I change the hostname from
what it was originally Ie Chet's computer over to Dave's computer.
I've changed the name.
This could pose problems when we're intersecting across our network
IP addresses. And of course,
URLS encryption keys, these all have a similar function.
Let's get to encryption keys because I want to kind of touch on this one a little bit
encryption keys.
Make up a key fundamental portion of any system within our network,
communicating with another system in a secure environment.
If a malware gets into or a malicious user
gets into our encryption keys and we're using a PKI
structure,
they might now have access to our private key.
That means that all that communication that was embedded within our systems,
that we perceive to be very secure is no longer secure.
They can now intercept that information that we deem to be
encrypted and decrypted without even actually being on the machine.
If you remember your days from security,
plus your public private key infrastructure plays a major
role in our secure transmission of encrypted information from one
system to another by having that private key be
exploited or taken advantage of or grabbed or stolen.
We have a major problem.
They don't actually have to read that encrypted messages on that system.
Once they have that private key,
they can grab that information through a man in the
middle attack and they'll be able to read it,
remove it and even change it at will because they have that private key.
In this episode.
We talked about file analysis and how
the differences between static versus dynamic analysis.
We talked about the importance of static analysis and how
it really provides us not only with metadata but signature
analysis and those different analysis types to ensure that malware
or malicious users don't take advantage of our file structures.
We talked about dynamic analysis and the use of
sandboxing and how we can utilize behavior analysis to
identify if something is occurring from malicious user or
malware to intercept or change that file structure.
We also touched on file integrity and how file and
can be utilized through hashing values to ensure that files don't change
from their regular or authorized viewpoint
without patching or software upgrades.
Finally,
we talked about strings and how strings can be utilized
to search functions across our systems and how malicious actors can
change file names and change path to provide access to their
own malware without actually deleting anything off our core system.
This provides them a different pathway to avoid integrity checks.
We've identified how encryption keys are utilized on our file structure
and how those encryption keys can be utilized by malicious actors
within your cys A plus exam.
You need to remember that all the things that we covered throughout this episode
are potentially part of your exam and the questions that you may face.
However, they're going to be scenario based.
You should expect to see the differences between static and dynamic analysis.
You should also expect to see questions on
integrity and the usage of hash files to ensure that file integrity hasn't changed.
Finally,
you should probably expect to see some questions very roughly or
very high level on strings and how to utilize those strings.
Don't worry,
we're going to go into strings at a much
more in depth level further along within this course.