The Metasploit Framework Architecture.
Now that we have an understanding
of what the Metasploit Framework is and how it works
and the key terminology surrounding the framework,
we can begin exploring the various components that make up
the Metasploit Framework.
Furthermore, we also need to start
exploring the various modules that are available to us,
how they work, where they're stored.
And we also need to take a look at the storage
locations of the said modules.
And we will also be exploring the file system structure
for the Metasploit framework and where all the relevant data is
stored.
So to get started, let's begin by taking a look
at the Metasploit Framework architecture.
Now, this diagram essentially provides you
with a top-level overview of the Metasploit framework
and essentially highlights the various components that make up
the Metasploit Framework.
Now, we have already explored interfaces,
as they're covered right over here or laid out here.
So we already know what the Metasploit Framework console
is, what the MSF CLI is, the Armitage graphical user
interface as well as the web interface.
So we already have an understanding of that.
What we are primarily focused on is the modules.
Now, the Metasploit Framework categorizes
modules into the following categories.
So we have exploit modules, we have payloads,
we have encoders, we have NOPS, and we have auxiliary modules.
Now, before we start exploring what each of these modules
does, we need to understand what a module is
in the context of the Metasploit Framework.
So a module, in the context of the Metasploit Framework,
is essentially a piece of code that
can be utilized and executed by the Metasploit Framework.
Now, when we talk about the libraries, which
is the second element here that we are really not going
to get into because, again, it's beyond the scope of this course
and really isn't required as a prerequisite in order
to utilize the Metasploit Framework--
so when we're talking about the libraries,
the Metasploit Framework libraries
are essentially used to facilitate
the execution of modules without having
to write the code in order to execute said modules.
So modules or the Metasploit Framework libraries
are essentially like shared objects on Linux or DLLs
on Windows.
So they essentially allow you to extend functionality or contain
the code required to extend the functionality
or to essentially initiate functionality,
like creating a TCP socket, et cetera, et cetera.
So that's as far as you should know right now.
As I said, all of this will be demystified as we progressively
move forward.
Now, let's begin by taking a look at the Metasploit
Framework modules in depth, starting off
with exploit modules.
All right, so exploit modules are
modules that are used to take advantage of a vulnerability
and are typically paired with a payload.
So it's very important to understand that.
Now, what is a payload?
Because exploits are paired with payload.
So what exactly is a payload?
A payload is a piece of code that
is delivered by the Metasploit Framework to the target system
and is then executed on the target system
after successful exploitation.
So let me just go over that a little bit here.
An exploit module is paired with a payload, right?
So it's very important to understand that distinction.
An exploit is essentially used to take advantage
or to exploit a vulnerability.
The payload is the malicious code
that is executed on the target system
after successful exploitation.
So if I can use a simple analogy, when
the exploit and the payloads are paired together,
what happens is when I hit execute
or when I hit run on the Metasploit Framework console,
the exploit essentially takes advantage of the vulnerability
and then executes the payload on the target system.
The payload is then again utilized to either execute
arbitrary commands on the target system or, in this case,
to provide us with a reverse shell.
So the exploit isn't what gives us a reverse shell.
The payload is what gives us a reverse shell
or additional functionality.
So as I said here, an example of the payload
is a reverse shell that initiates
a connection from the target system back to the attacker.
All right?
So I hope that makes sense.
What's an encoder?
An encoder is really essentially used
to encode payloads in order to avoid antivirus detection.
So given the fact that the payloads contain
the malicious code that is executed on the target,
we will need to have various ways of various tools
that we can use to encode these payloads in order
to avoid antivirus detection on the target site.
Because, for example, Windows targets will typically have
Windows Defender installed.
And as a result, if we don't encode a payload,
it may be detected, and we will not get our reverse connection
back.
So we need to find various tools or we
need to utilize various encoders to help
us avoid antivirus detection.
An example of this is the shikata_ga_nai encoder
that is used to encode Windows payloads.
We will be covering payload generation
and encoding as we progress.
For now, that's really all you need to know.
What are NOPS?
NOPS are essentially used to ensure
that payload sizes are consistent and are also
used to ensure the stability of a payload when executed.
So you really don't need to read too much into what NOPS are.
Again, as I said, their main purpose
is to ensure that payload sizes are consistent
and ensure that the target system is stable
when the payload is executed in order to prevent the target
system from crashing.
So the NOPS are there to ensure that the payloads are
stable when they're executed in order to avoid
any potential crashes on the target side of things.
Now, what's an auxiliary module?
An auxiliary module is a module that's
used to perform additional functionality, like port
scanning and enumeration.
So an auxiliary module is essentially any module that
isn't or cannot be paired with a payload.
That's the quickest and simplest way
of understanding the distinction between an exploit payload
and an auxiliary module--
or rather, an exploit module and an auxiliary module.
So an example of an auxiliary module
is a portscanner module or an enumeration module,
so on and so forth.
And we will be exploring them in depth
as we progress into the information-gathering phase
of this course.
Now that we have an understanding of the Metasploit
modules, let's explore payloads.
Because as you can already tell, they're quite important.
Because they are responsible for giving us
either remote access to the target
or essentially allowing us to execute
commands on a target system after exploitation.
So the Metasploit Framework will provide you
with two types of payloads that can be
paired with an exploit module.
One of them is called a non-staged payload.
The second one is called a staged payload.
Now, the type of payload that you'll use
will depend on the target system and the target infrastructure
as well as your requirements.
And as I said, we will be exploring
where and when you should be utilizing
each of these payload types.
So starting off with a non-staged payload,
a non-staged payload is a payload
that is sent to the target system
as a whole along with the exploit.
This will make sense in a few seconds.
What is staged payload?
A staged payload is a payload that
is sent to the target system in two parts.
Aha.
So this is where the difference comes into play.
Now, as I said, don't worry about why we're splitting
the payload into two parts.
All you need to know now is the distinction.
So when we're talking about a staged payload,
the first part, known as the stager,
contains the payload that is used
to establish a reverse connection back
to the attacker.
So when we're utilizing a staged payload,
the first part is sent.
The first part, known as the stager,
is responsible for initiating a reverse connection back
to the attacker.
And then it downloads the second part
of the payload, which is known as the stage, and executes it.
Now, the stage is responsible for either executing
arbitrary commands on the target system
or for providing us, for example, with a reverse shell
or a Meterpreter session.
So let's take a look at stagers and stages.
So, as I said, the stager are typically
used to establish a stable communication
channel between the attack and the target,
after which the stage payload is downloaded and then executed
on the target system.
The stage payload is essentially responsible for providing us
with a reverse shell or a Meterpreter session.
So that's the second part.
The stager is the first part and the stage is the second part.
So that's the difference there.
As I said, don't worry if this sounds
a little bit intimidating.
It'll make sense as we progress.
Let's talk about the Meterpreter payload,
which is arguably one of the most popular Metasploit
Framework payloads.
So the Meterpreter payload and Meterpreter
comes from the word meta-interpreter,
is an advanced multi-functional payload
that is executed in memory on the target system,
therefore making it difficult to detect on the target system.
So, again, this payload really isn't
downloaded to the target system or is not executed on disk.
It is executed in memory.
And as a result, no traces of the payload
are left or are found on the target system, which, again,
is great in avoiding detection.
And in regards to its functionality,
it communicates over a stager socket
and provides an attacker with an interactive command interpreter
on the target system that facilitates
the execution of system commands,
file system navigation, keylogging, et cetera.
So it essentially provides an attacker
with a really interactive reverse shell
on the target system.
The attacker can then use the Meterpreter session
to navigate the file system, download or upload
files from the target, execute arbitrary commands
on the target, as I said, navigate the file system,
perform post-exploitation techniques,
perform privilege escalation, extract hashes,
et cetera, et cetera.
And we will be covering the Meterpreter payload in depth
once we reach the exploitation and post-exploitation phase
of this course.
Now let's talk about the Metasploit Framework file
system structure.
So the Metasploit Framework file system
is organized in a simple and easy-to-understand format
and is organized or categorized into various directories.
So we can access the Metasploit Framework file system on Linux
by navigating to the usershare Metasploit Framework
directory, after which you'll be able to view
all the various folders and files under it.
And I'll be explaining all of these directories
in a few seconds.
So that's essentially how it's sorted.
When we talk about the Metasploit Framework module
locations, Metasploit Framework stores modules under
the following directory, so it's stored under
the /usr/share/metasploit framework/modules directory,
and we'll get to this in a second.
And user-specified or custom modules
can be stored under the following directory.
So it can be stored under your current user's home directory
under the dot ms4 folder under modules.
So now that we have an understanding of how everything
works, the various elements that make up the framework, how
modules work, where they're stored.
Let's take a demo and actually explore
the file system in depth and get an understanding
of how everything is stored.
All right, so I'm currently on my Kali Linux VM.
And I'm just going to take you through where
everything is stored.
So by default, Kali Linux has the Metasploit Framework
pre-installed.
So I don't need to install it, but I
will be covering that process.
We can navigate to the default storage directory where
the Metasploit Framework is stored by navigating
to the /usr/share/metasploit-framework
directory, which you can also do via your file browser.
So if I use my file browser here and I
navigate to the file system, I can head over
to the user folder.
And under that, I'll go under the share directory.
And then I can search for the Metasploit Framework folder
here.
So I can say Metasploit.
And there we are, there's the Metasploit Framework directory.
And voila, this is where the Metasploit framework
is stored on Linux.
And as you can see, we have quite a few directories.
But we are primarily interested in the modules folder
right over here.
So if we double-click on the modules folder,
you can see that we have all the various that I
covered within the slides.
We have auxiliary modules, we have encoders,
we have exploits, we have NOPS, we have payloads,
and we have the post-exploitation modules,
which, again, we will cover when we actually
get to post-exploitation.
So if we take a look at auxiliary modules,
you can see that they're furthermore
sorted into their own subcategories
based on the type of tasks or functionality that they offer.
So, for example, if we are performing
information gathering, then we would typically
look under scanners.
And under scanner, again, it's sorted into various folders
based on the type of scanning we are performing.
So, for example, if I want to perform FTP scanning,
these are the various Metasploit modules
associated with FTP scanning.
If I want to perform some discovery,
I can click on discovery there.
The discovery auxiliary modules are used
to discover hosts on a network.
So, for example, we have ARP or arp_sweep, the arp_sweep module
as well as a few others here.
So let's take a look at a few others
in order to get a full view or understanding of what's
going on.
So let's say I want to perform some SMB enumeration.
I can take a look at the SMB folder here.
And you can see these are the various SMB auxiliary modules
that allow us to enumerate information
from SMB on a target.
Now, as I said, this is not how we will
be utilizing these modules.
We will be able to load these modules with the Metasploit
Framework console.
But for now, I'm just covering the structure.
So if I navigate back to the modules here,
we can take a look at exploits.
So exploit modules are sorted based on the target operating
system or the target software, either a browser
or the mobile operating systems.
As you can see, we have Android, Apple iOS.
As for the operating systems, we have Linux, Solaris, Unix,
Windows.
We also have MacOS as well as OpenBSD and FreeBSD.
So, again, this categorization is fantastic
because it allows us to, again, find
exactly what we're looking for.
So if I'm looking for a Linux exploit, I can click on linux.
And then it is further sorted based on the service
or the type of exploit.
So if I'm targeting MySQL on a Linux target,
I can click on the mysql directory here.
And these are the two exploit modules
available for MySQL on Linux.
If I'm targeting FTP, these are the various FTP exploits
for Linux.
So we have proftp, et cetera.
Now if we take a look at Windows, for example--
let's just explore that here.
And I'll get to the multi folder in a second.
But the windows folder contains, again,
exploit modules that are designed for the Windows
operating system.
And again, it is further categorized
into the services or the applications or programs that
are associated with Windows.
So, for example, we have typical pieces of software,
like the browser, email.
We also have the network filesharing system here.
MS SQL, these are the various MS SQL exploit modules available.
And you get the idea.
So all of this will, again, make sense
once we actually begin interacting with the Metasploit
Framework console.
And, again, you can also explore the NOPS modules as well as
the encoders here, which allow you
to encode payloads for different operating systems.
And in this case, you can see we have the operating systems
architecture specified here.
So if we're looking for 32-bit encoders,
these are the encoders we can use here.
And there we are.
We have the shikata_ga_nai encoders
that's utilized or used to encode Windows payloads.
So that is essentially the structure
or the file system structure for the Metasploit Framework.
And that's where you can find all the Metasploit Framework
modules.
Now, if you want to load your own custom modules,
you can do that by navigating to your home directory.
In my case, it's the Kali user.
I can then navigate into the dot ms4 folder.
So I'll just show the hidden files here.
And you can see it right over here, dot ms4.
And within this, I have my own custom modules directory
where I can add my own custom Metasploit Framework modules.
And I can, again, sort them based on operating system
or program or service.
So that is how the Metasploit Framework
is organized and structured.
So now that we've explored that-- again,
you can go through this with the terminal as well.
So, again, if I navigate to the modules directory
here under the Metasploit Framework directory here
and I list it out, you can see we have the same content.
And, again, you can go through it with your terminal as well
as your file manager.
So that should give you a good understanding
of where everything is stored and where specifically
the modules are stored and how everything
is structured and organized.
And, again, that will come in handy
when we'll be searching for specific modules, specifically
the auxiliary modules and the exploit modules.
And we'll take a look at how this categorization is
extremely helpful when we'll be looking
for exploit modules for Linux or Windows.
That being said, I'm going to switch over to my slides now.
Now that we have an idea of how the Metasploit Framework is
sorted, organized, and the various elements that make up
the framework as well as the different types of modules,
how they work, and how they can be used,
we can move on to the next step, which
is to take a look at how we can utilize the Metasploit
Framework for penetration testing.
So I'll see you in the next video.