In this module,
we're going to talk about how you interpret the Metasploit
framework output and what the different components are.
As we look here at the overview,
the first thing you see is what we're going to investigate,
and that's the module output.
We want to get a better understanding of the structure of the modules
and the information we can leverage for our attacks.
The better we do this, the more successful our attacks will be.
The next thing we'll do in this module is clarify the exploit content.
We'll review the different settings and details within an exploit and
how to understand what these options represent.
Some of these you have already seen, but there's a lot more to take a look at,
and we'll do that here.
The last thing we'll look at are the module scanners within the tool.
We can integrate Metasploit with a variety of scanners.
But in this module,
we'll review the different scanners that are
located within the auxiliary module.
Different scanners give us the capability to extract additional
information that you're going to need when you're performing a test
as an assessment to produce a deliverable,
and that deliverable is a report.
In this first section,
we're going to get to know more about the modules and explore
how they integrate within the framework.
We will start here with the Metasploit architecture.
The first component to discuss is the filesystems and the libraries.
The filesystem is laid out in an intuitive manner and is organized by directory.
Some of the more important directories are data.
The data directory contains editable files used by Metasploit to
store binaries required for certain exploits,
word lists, images, and more. Documentation, as its name suggests,
the documentation directory contains the available documentation for the
framework. The lib, or the library, directory contains the meat of the
framework codebase. And then we have the modules.
The module directory is where you'll find the actual modules for exploits,
auxiliary, post, payloads, encoders, NOP generators,
and a slew of others.
The modules are the main focus that we want to review in this section.
We'll have much more on these later.
Then we have the Metasploit object model. In the Metasploit
framework, all modules are Ruby classes. Modules inherit
from the type‑specific class.
The type‑specific class inherits from the MSF module class as a shared,
common application programming interface or API between modules.
And then we have the mixins and the plugins to
complete the Metasploit architecture.
The mixins are what makes Ruby the code of choice for
Metasploit. It used to be written in Python,
but the mixins allows it to extend and gives it more capability, at
least that's what the Metasploit designers believed, and that's why
they have converted all the code to Ruby. Since we're talking
object‑oriented architecture here, mixins include one class into another.
It's a little bit different.
There's some similarities to inheritance, but it's a little bit different.
And mixins can override a class's methods.
You're encouraged to read more about the mixin capabilities,
and the plugins work directly with the API.
They manipulate the framework as a whole. Plugins hook into the event subsystem.
They automate specific tasks that would be tedious to do manually.
Again, that's the extensibility. Plugins only work in the MSF console.
They can add new console commands, and they can extend
the overall framework functionality.
Again,
this gives Metasploit popularity as well because we can build
Metasploit and write our own modules for it as well.
We now have the module types.
We have the auxiliary, encoders, exploits, NOPs, payloads, and post.
Our main two modules we want to concentrate on are shown
here. We first have the auxiliary modules.
These auxiliary modules include port scanners, buzzers, sniffers, and more.
Then we have the exploit module, and these are used with the payload. As
you've seen in the previous sections, this payload can be anything that we
want to select, and there are many of them.
There are some modules we want to discuss here, and
the first of those is the payload.
This is the code that runs remotely. We'll briefly
cover the three main payload types, singles, stagers, and stages.
Metasploit contains many different types of payloads,
each serving a unique role within the framework.
So when you look at the various types of payloads available and
you get an idea of when each type should be used, inline or is
non‑stage is a single payload containing the exploit and full
shell code for the selected task.
Inline payloads are, by design, more stable than their
counterparts because they contain everything all in one. That
comes at a price, and that price is in size.
So some exploits won't support the resulting size of these payloads.
And for those, we use other types of payloads.
Then we have stager payloads.
These work in conjunction with stage payloads in
order to perform a specific task.
A stager establishes a communication channel between the attacker and the victim
and reads in a stage payload to execute on the remote host.
Then we have the encoders, and these help us avoid detection from the
different defenses that are in place as shown here. As we've seen
throughout the course, we have different types of encoders we could use
to try to get past the defenses. And then next, we have the NOPs,
otherwise known as a no operation, and that is the assembly instruction
that does exactly what it says, no operation.
We use this to help us increment the instruction pointer.
As we see here, there are different instructions for
the different hardware architectures.
Intel instruction is a hex 90, as an example. We are now
ready for a demonstration. In this demo,
we explore the different structure and components of the
framework modules. Enjoy the demo.