[MUSIC PLAYING]
The Metasploit Framework, so welcome to the exploitation
frameworks section of this course.
In this section, we're going to be taking a look at two
of the most popular, widely used exploitation frameworks
out there, one of which is the Metasploit framework.
In the next video, we'll be taking a look
at how to set up and use PowerShell
Empire for exploitation.
So this video is going to be focused
on how to utilize the Metasploit Framework for exploitation.
However, before that, I'm going to give you
an introduction to the Metasploit Framework,
and I'm going to contextualize its use
in the case of a penetration test,
more specifically, the exploitation
phase of a penetration test.
Now, I actually want to preface this video by telling you
that I've already covered the Metasploit Framework in depth
within its own course.
So if you'd like to learn more about the Metasploit Framework,
or if you're unsure of what I am doing
within the practical section in this video,
then do refer to that course.
And I would actually recommend going through that course
before you go through this course.
With that being said, let's get started
by getting an understanding of what the Metasploit
Framework is.
Now, the Metasploit framework, also known as MSF,
is an open source, robust penetration testing
and exploitation framework that is
used by penetration testers and security researchers worldwide.
It provides penetration testers with a robust infrastructure
required to automate every stage of the penetration testing
lifecycle, or the exploitation lifecycle.
So why am I covering exploitation frameworks?
Well, number one, you're going to be coming across them quite
a bit, and more so with the Metasploit Framework.
As you progress with your journey
as a penetration tester, you'll also
be introduced to exploitation frameworks
like PowerShell Empire.
PowerShell Empire really cannot be classified as just
an exploitation framework.
It is also used as a very able command and control
server, or AC2 server.
So why are we focusing on exploitation frameworks?
Well, as this description just stated,
exploitation frameworks are used to automate the exploitation
phase of a penetration test and to streamline it.
So we've taken a look at how to find exploits online,
how to fix them, how to compile them,
and then how to run them manually.
And from that process, you can see why we would actually
need an exploitation framework that
automates that entire process.
And there are various reasons for that.
Number one, the process is entirely streamlined,
and if the exploit module is well developed, then, again,
you'll pretty much be able to tell whether the exploit works
or doesn't work by just running it against the target.
Now as I said, this is not something
that I recommend doing unless you've
performed the necessary information
gathering, enumeration, and vulnerability detection.
And secondly, exploitation frameworks like Metasploit
will essentially handle the actual reverse shell
part of the exploitation process really well,
in that they provide you with modules like the Meterpreter
payload.
By this point, you should actually
be familiar with Meterpreter and how to use it.
It's really just an advanced reverse shell
over your typical reverse shell, either through CMD.EXE
or PowerShell.EXE, or in the case of Linux,
your standard bash session or bash shell.
All right, so again, that's really
the two main reasons why exploitation frameworks
are important.
Now, by no means are they a replacement
for manual exploitation and testing.
That is something that I still recommend
that you do before you switch over
to an exploitation framework.
Now, in addition to being an exploitation framework,
the Metasploit Framework is much more
than that, in that it can perform,
or it can be used to automate and streamline,
the entire penetration testing methodology, so
from information gathering to enumeration,
vulnerability scanning, exploitation,
post-exploitation, as well as privilege escalation.
However, for this video, we're primarily
focused on the exploitation phase.
And of course, as you already know by this point,
the Metasploit Framework is also used to test and develop
exploits and has one of the largest database of public
tested exploits in regards to the exploits
being tested and being in a modular style
or fashion, in that every exploit is handled
in the form of a module.
And again, from the final description within the slide,
you can see that the Metasploit Framework
is designed to be modular.
All right, and that modularity is
something that's very important because it
allows for new functionality to be implemented with ease.
So again, if we just go back to our previous scenarios
that we explored in the previous sections,
whenever we're using public exploit code,
it's essentially an exploit file that contains all the code.
And in some cases, you need to compile it.
In other cases, like Python scripts or Python exploits,
you can just run them against the target.
What the Metasploit framework does
is it essentially turns that exploit code into a module.
And in order to develop a Metasploit exploit module,
you need to do that using the Ruby programming language.
Now as I said, this is not something
that we'll be focusing on within this course,
but that's basically what the Metasploit Framework is
used to do.
And in order to understand how to use the Metasploit
Framework, you actually need to get an understanding
of the essential terminology that
is pertinent to the Metasploit Framework.
So firstly, we have the interface.
So what is an interface?
Well, an interface is essentially
the method of interacting with the Metasploit Framework.
And the most popular interface available,
and the most functional in terms of the functionality that is
offered to you, is MSF Console.
So you might have heard of that before.
If you've come here from the Metasploit Framework course,
then you should be familiar with this.
We then have a module.
All right, so a module is essentially
a piece of code that performs a particular task.
An example of a module is an exploit,
as I stated in the previous slide.
What is a vulnerability?
A vulnerability is a weakness or flaw
in a computer system or network that
can be exploited by an exploit or in the case of Metasploit,
an exploit module.
What is an exploit?
An exploit is a piece of code, or module
in the case of the Metasploit Framework,
that is used to take advantage of a vulnerability
within a system, service, or application.
So if you remember when we were searching
for exploits with Searchploit and with ExploitDB,
we were able to identify that some of those exploits
have a Metasploit module available.
And that's really what this is in reference to.
So you can either load that Ruby file manually,
or it is already part of the Metasploit Framework,
and you can just load it within MSF Console and use it.
We then have payloads.
So what is the payload?
Well, a payload is a piece of code delivered to the target
system by an exploit with the objective of executing
arbitrary commands or providing remote access to an attacker.
So this is where things start getting interesting,
and this ties into the previous section, when
we were talking about shells, bind shells, reverse shells, et
cetera.
A payload is typically what will provide you
with a reverse shell.
And again, the reason why most of the payloads
are reverse shells, or provide you with a reverse shell,
is primarily because once the exploit takes advantage
of a vulnerability, the payload is then executed on the target.
And that payload essentially contains the attacker's IP
address, and a connection is made to the listener.
Now with the Metasploit Framework,
and when you'll be utilizing Meterpreter payloads,
for example, you don't use a standard Netcat listener
to receive the connection.
You actually need to set up a multi-handler.
A multi-handler is a specific Metasploit module
that allows you to set up a listener for Metasploit
Framework exploits or Metasploit Framework payloads.
It can also be used to receive Netcat connections or just
a connection from a standard reverse shell
from the attacker system, or rather from the target system.
But it's really for the purpose of payloads
that essentially exist, or that are used, with the Metasploit
Framework.
We then have a listener.
A listener is essentially a utility
that listens for an incoming connection from a target.
And that ties into your multi-handler.
So again, those two are pretty much the same,
but you will actually see how this all
works when we'll take a look at the practical section.
All right, so this is the Metasploit Framework console.
If you've already gone through the course
and you've taken a look at the Metasploit Framework course,
you should be familiar with it.
The Metasploit Framework console is also known as MSF console.
It is an easy-to-use, all-in-one interface
that provides you with access to all the functionality
of the Metasploit Framework.
So in terms of penetration testing with the Metasploit
Framework, as I've said, the Metasploit Framework
can be used to perform and automate
various tasks that fall under the penetration testing
lifecycle.
In order to understand how we can leverage the Metasploit
Framework for penetration testing,
we need to explore the various phases of a penetration
test and the respective techniques and objectives.
In order to do that, we can adopt the penetration testing
execution standard, which I've mentioned before,
as a roadmap to understanding the various phases that make up
a penetration test and how Metasploit can
be integrated into each phase.
And the following table highlights
each of those phases.
And on the right, you can see we have the Metasploit Framework
implementation column.
That highlights what types of Metasploit Framework modules
can be used to achieve, or to perform,
a specific functionality within each penetration testing phase.
So for information gathering and vulnerability scanning,
you can use Metasploit Framework auxiliary modules,
and this is the section we are interested in this video,
and in this course, which is exploitation.
And in the case of exploitation, we
will be utilizing Metasploit Framework
exploit modules and payloads.
You then have post-exploitation, privilege escalation,
and of course, persistence modules.
So for post-exploitation, you can
utilize Meterpreter or the various post-exploitation
modules available.
And the same goes for privilege escalation.
You can utilize the Metrepreter or
the various post-exploitation modules
pertinent to privilege escalation.
And with maintaining persistent access,
there are various persistence modules that you can use.
So in this video and in the practical demonstration,
we are primarily going to be focused on exploit modules
and payloads right over here.
All right, so now that we have an understanding of that,
we can get started with the practical demonstration.
So this video has a lab environment attached to it,
and we're going to go through it as we
would if we were performing a typical black box penetration
test.
So this is just like a mini penetration test,
but it will highlight how to utilize the Metasploit
Framework for exploitation.
So just fire up the lab environment,
and I'll see you within the lab environment.
All right, so I'm back within the lab environment,
and you'll be provided with the target IP address.
So that's very important.
So that's the only piece of information
that we have regarding the target system.
So we'll copy that.
And of course, the first logical step
would be to perform an nmap scan to identify
open ports and the respective services,
as well as the service version of those services
that are running on these open ports.
So we really don't know what operating system
is running on the target so that's
what we're trying to find out.
So what we can do, first and foremost,
is perform a simple nmap scan on the default port range.
So that is 1,000 of the most commonly scanned or used ports.
And we can then say we want to perform some service version
detection based in the target IP.
So I'll just hit enter.
Now, this is going to take a couple of seconds
to a couple of minutes so I'm just
going to let this complete.
All right, so the nmap scan is complete.
And as you can see from the open ports and services,
we can pretty much tell that it's running Windows.
And again, we aren't sure about the exact addition of Windows,
but we do know that it's running Windows Server and any version
from Windows Server 2008 R2 to Windows Server 2012.
All right, so we can also perform an operating system
detection scan, but again, for now,
let's just focus on the current services that are running.
So we can see that on port 80, we
have a web server, the Apache HTTPD 2.2.23 web server.
And it looks like it's hosting a web application that's
developed in PHP so we'll take a look at that in a second.
We also have a MySQL port here, which is currently open.
But it's saying unauthorized, which means that we pretty much
cannot access or authenticate with the MySQL server remotely.
We then have an RDP port here, so 3389.
So that means we can access the target system via RDP.
However, given the fact that we don't
have any legitimate credentials, that really isn't feasible.
So let's take a look at the only service
here that actually looks like it can be exploited,
or that we can actually test.
And that is the web application that's
running on the web server.
Now, as a beginner penetration tester,
you may be tempted to perform vulnerability detection scan
on the actual web server technology.
In this case, that is Apache HTTPD.
However, before you do that, I actually
want you to explore the web server and the web
application that's being hosted on that web server.
So we can access the web server by opening up Firefox here.
And I'll paste in the target IP.
There we are.
So it looks like we have a re-director.
And let's see what web application is
running on the target system.
All right, so it looks like the web application has loaded,
and it looks--
again, we can see that we have a login page here.
And the name of the web application is ProcessMaker.
It looks like it's registered, and that
means that it probably is a professional product developed
by a company.
If we take a look at the copyright at the bottom,
we can see that it's developed by a company
called Colosa, Inc. All of this information is very important.
Now, in order to gain access to this particular web
application, we either need to log in,
or we can view the page source to learn more about it.
And in specific, the information that we're looking for in order
to identify vulnerabilities that affect
this specific version of ProcessMaker
is the exact version that is installed.
So it looks like this tab crashed, and I'm just
going to zoom in here.
There we are.
So let's restore that again.
And if we take a look at the source,
we can see that it's your basic HTML with a bit of CSS
and JavaScript, as well.
And we really aren't able to identify any version
information.
So we can't really tell what version of ProcessMaker
is running on the target system.
So what's the next logical step that we can perform?
Well, we can see that we have the ability to log in,
but we don't have any credentials.
So as a penetration tester, the next step
would be to essentially search online
for resources pertinent to default credentials
for ProcessMaker.
So in some cases, systems may be configured,
and administrators don't change the default credentials
for a third party solution like ProcessMaker.
Now, this lab doesn't have internet access
so I'll just switch over to my browser on my main system.
And let's see if we can identify the default credentials.
All right, so I'm back within my browser.
And as you can see, I've just performed a quick Google search
for ProcessMaker default credentials.
And on the official process make a wiki,
we can see that we have a bit of a description here.
So it says if ProcessMaker was just installed and logging
in for the first time, enter the following credentials
to log in as the administrator.
So it looks like the default credentials
are admin and admin.
So let's actually test this out.
So I'm just going to minimize that,
and we'll head back over into the lab environment here.
And we can actually see whether that will work.
So we'll say admin, admin, and we're
going to log in with the default workspace, which is workflow.
There we are.
So I'll not save that password, and it looks
like the login was successful.
So you can now see how our vulnerabilities can actually
be quite dynamic in regards to what application
is running on a target system, or what service is running.
So always be sure to be extremely
comprehensive in understanding what application this
is, whether it has default credentials, how it works.
In the case of ProcessMaker, this is essentially
a workflow designer.
And you can, again, deduce that by taking a look at the tabs
here.
But remember, we still haven't identified
the actual version of ProcessMaker
that's running on the target.
So I'm just going to restart Firefox there.
And hopefully, this time it doesn't crash on me.
So we are back on the admin tab here.
We go home, we can see that we can access--
that looks like various cases there.
We have the designer.
This is the workflow designer.
We also have dashboards and admin.
All right, so if we take a look at admin,
and we'll give this a couple of seconds to load up.
So if we take a look at the admin tab, on the left,
we have a sidebar that has settings, plug-ins, users,
and logs.
If we take a look at users, you can
see that this is the user that we logged in with,
and the default credentials have not been changed.
So the administrator was really, really lazy here.
If we scroll to the bottom, we can
see that we have system information.
And indeed, if we take a look at process information,
we can see we are able to enumerate
the exact version of ProcessMaker that's running,
which is 2.5.0.
And does it have any upgrades or patches?
Never upgraded, so on and so forth.
And it, of course, is utilizing a database,
a relational database.
And in this case, it's utilizing MySQL.
And that's why when we perform the nmap scan,
we essentially were able to find that a MySQL database
server is running.
So you're now starting to get an understanding of how
various components that are being hosted on a system
tie in together.
So that's why there is a database.
It's for the purpose of this web application.
So now that we've identified the exact version of ProcessMaker,
we can start searching for exploits
pertinent to this specific version.
So I'll open up my terminal again here,
and we can launch, or perform, a searchsploit
scan for ProcessMaker.
And because I don't know how the ProcessMaker exploits are
actually titled, I'll just hit enter without providing
the service version.
And it looks like we have a plug-in upload Metasploit
module.
We also have ProcessMaker 3.0.17.
And that's not what we're interested
in because the version that's running on the target is 2.5.
And it looks like we have ProcessMaker
open source, authenticated PHP code execution.
Remember, this is very important.
Authenticated means that in order
for this exploit, or Metasploit, module to work,
we actually need legitimate credentials.
And in this case, we do so this actually
looks like it could work.
Now as I said, this lab doesn't have online internet access.
What one would typically do is also
use the w option to display the ExploitDB links
so that you can go through the exploit code online.
Alternatively, if we wanted to access, or just
get more information regarding, a Metasploit module
what we could do is--
I'm just going to terminate that there.
And we can perform the search without providing the ExploitDB
links.
We can get the source, or we can copy the Ruby Metasploit module
and analyze it, or we can just open it up where it is.
But what I'll do is I'll head over into my desktop here,
and I'll say searchsploit.
And we'll just make a copy and analyze it locally.
So that is 29325.
So 29325, there we are.
And we can then open it up with vim or the text editor,
so 29325.rb.
And let's get an understanding of what
this Metasploit module does.
So we can see that it's developed in Ruby.
What I'm interested in is the description section
of the Metasploit module.
So it tells us that this module exploits a PHP code execution
vulnerability in the neoclassic skin for ProcessMaker
open source, which allows any authenticated user
to execute PHP code.
The vulnerable skin is installed by default in version 2.
whatever and cannot be removed via the web interface.
So it looks like this module might work against version 2.5.
The only way to test this is to actually utilize the Metasploit
Framework and then utilize this particular exploit module.
So I'm just going to remove the actual exploit
that I copied over because this module is
designed to be executed with the Metasploit Framework.
So in order to start up the Metasploit Framework,
we're going to say service postgresql start.
That's going to start the PostgreSQL database service
because the Metasploit Framework typically
interacts with the PostgreSQL database
on the back end for storage of workspaces
and exploit-related data.
So I'll hit enter, and then I'm going to say MSF console.
All right, so that will start up the infamous MSF console
interface.
That will allow us to essentially test
whether this exploit works.
All right, so that's loaded up, and what I'm going to do
is I'm just going to create a workspace
for this particular exploitation.
And this is a practice that I recommend that you do.
So we'll create a workspace for this particular activity
so we can essentially segregate our different projects
that we're working on.
So I'll create a workspace and call it ProcessMaker.
And we're currently utilizing the process make a workspace.
And as I said, this will ensure that your various engagements,
or assessments, as a penetration test
are sorted and kept separate from the other ones
that you do.
So for every new engagement, always create a new workspace.
So now, we can search for the actual exploit.
So we're going to say ProcessMaker.
And it looks like we have the actual exploit right over here.
So this is a PHP exploit.
Remember, it's taking advantage of the web server,
or the web application, that's running on the target.
So exploit/ multi/HTTP/processmaker exec,
and the rank is excellent.
And we can load it up.
So I'm just going to say use.
And I can say use and specify the ID of the exploit,
or just copy the name.
That's what I'll do here.
So I'll just copy that there.
So I'll say use, and we're currently using that exploit.
So I can say show options to learn more
about what options need to be configured in order to utilize
this exploit module.
We can see that we need to provide the password.
So we need to provide the legitimate credentials
for access to the ProcessMaker you know dashboard or admin
panel for that matter.
And in this case, the module has been
configured to utilize the default credentials,
so admin for the password and admin for the username.
So we don't need to change that.
We then need to set the target IP
address, which we can do by configuring the RHOSTS option.
So I'm just going to copy the target IP.
There we are.
And I'm going to say set RHOSTS and paste in the target IP
there.
We can then change the target port or the port on which
the web application is running.
In this case, we know it's running on port 80.
So we leave that as is, and it doesn't
look like we need to configure any other options.
So we can hit exploit, and this should provide us
with a Meterpreter session.
So I'll hit enter.
And as you can see, it authenticates as the user admin
with the password admin.
It then sends the PHP payload, and this
is a reverse shell payload.
So there we are.
Payload is sent successfully.
It retrieves the file, sends the stage
because that's how stage Meterpreter payloads work.
And of course, I've covered this in the Metasploit Framework
course.
And we get a Meterpreter session one opened.
So we now have essentially obtained initial access
on the target system.
So again, we are currently within the following directory.
So we are currently within C Users administrator AppData
and the ProcessMaker directory.
So let's navigate to the root of the Windows file system.
So we're currently within the C drive,
and if we list out the contents of this,
we can see that we have a flag, which, again,
was the challenge for this particular video,
or for this particular lab environment.
So you can cut out the content of flag.txt.
So I'll say cat flag.txt, and that'll print out the flag.
So from this point onwards, you can
start performing local enumeration,
or the typical activities pertinent to post-exploitation.
But again, I just wanted to showcase
how you can utilize the Metasploit
Framework for exploitation.
And I also wanted to show you how
everything that we've learned so far all
ties into exploitation, irregardless of whether you're
performing manual exploitation or automated exploitation
with the Metasploit Framework.
Now, there's one more thing that I
wanted to highlight before I end the practical session,
and that is the fact that this particular version
of ProcessMaker did not have a manual exploit code available.
And the only exploit code available that essentially
worked against the version that was running on the target
was a Metasploit Framework module.
So in certain cases, you may be forced
to use the Metasploit Framework for exploitation.
But as you can see, it's much better
than utilizing public exploit code.
And the modules work really well and you're
provided with a Meterpreter session out of the box.
OK, so that is going to conclude the practical demonstration
side of this video.
In the next video, we're going to be taking
a look at PowerShell Empire.
More specifically, we'll be taking a look
at how to get it set up on Kali Linux
and how to utilize it for exploitation.
And again, so it's going to be really, really cool.
If you're not familiar with the PowerShell Empire framework,
then definitely check out the next video.
So I'll see you there.