[LOGO WHOOSHING]
Generating Payloads With Msfvenom.
So welcome to the client-side attack section of this course.
Now that you've essentially explored
the process of performing information gathering
enumeration, as well as vulnerability scanning,
we can begin exploring exploitation.
And the first type of exploitation
or the first attack vector that we will be exploring
our client-side attacks.
And in order to perform a client-side attack,
we will need to know how to generate the Metasploit
framework payloads.
And in order to generate these payloads,
we will be utilizing a utility called msfvenom.
So let's get started first and foremost
by understanding what client-side attacks are
and how they differ from host-based attacks
or service-based attacks.
So a client-side attack is an attack vector
that involves coercing a client to execute a malicious payload
on their system that consequently connects back
to the attacker when executed.
Now, client-side attacks will typically
utilize various social engineering techniques
like generating malicious documents
or malicious portable executables
in the case of Windows and, in some cases,
in the form of a Debian package for Linux.
Now, client-side attacks, and this
is where the difference comes into play,
take advantage of human vulnerabilities
as opposed to vulnerabilities in services
or software that's running on the target system.
So depending on the way the target operating
system or the target system has been configured,
you'll need to, again, structure or coordinate your attack
accordingly.
So I'll give you an example here.
If the target system that you're trying to attack
or you're trying to gain access to
has been configured as a server, so, for example,
it's running Windows Server, and it's
used to host business-critical applications or web server,
for example, then our attack vector
would be a host-based attack or a service-based attack,
whereby we will be trying to find vulnerabilities
within the services that are running on that system.
Now, if the target system that you're trying to attack
has been configured to run as an end-user operating system,
so let's say you're trying to target an employee
laptop or an employee workstation,
then you'll need to change your attack vector
to a client-side attack, where your job will be to,
first and foremost, generate a malicious payload either
for Windows or Linux.
And then secondly, you can utilize social engineering
techniques like, again, essentially
generating malicious documents or making the payloads look
as enticing as possible so that you are essentially
trying to convince the client or the target employee,
in this case, to actually click on that payload.
So this is where social engineering comes into play.
Now, we are not going to be covering
the various social engineering techniques within this course,
as that is beyond the scope of this course.
But a simple example or a scenario
would be that we generate a Windows payload with msfvenom.
Once we have generated the payload,
we can then inject the payload into another legitimate Windows
executable, therefore, making it look legitimate.
And then we can distribute this to the client or the target
employee either through email or maybe
through another type of communication channel.
And once it's on their system, they will click on it
and consequently execute the payload.
Now, when they execute the payload,
we need to be ready with a handler or a listener
rather that will essentially receive
the incoming connection.
And once they, again, execute it on their target system
and once we have the listener set up,
we should be able to receive the reconnection back
from the target system, and consequently, gain access
to the target system.
Now, one thing to keep in mind is
that given that the client-side attack vector involves
the transfer and storage of a malicious payload
on the client system, primarily being on their disk,
we also need to be cognizant of antivirus detection.
So, again, because we're essentially
trying to send a payload or trying to get a target employee
or individual to download a malicious payload
and then execute it on their system,
we need to be aware of the fact that their system could
have an antivirus solution installed
that could consequently detect or find
that this particular payload is malicious
and prevent the target individual from executing it.
So we'll also be exploring the process of encoding payloads
with msfvenom.
And then finally, to wrap up this section,
we'll be exploring the process of essentially generating
or injecting our payloads into a legitimate executable
to make it look as enticing as possible.
So we've talked a little bit about what msfvenom is,
or rather we've--
I've given you a basic description.
But really, it's a very simple tool to understand.
msfvenom is a command-line utility
that can be used to generate and encode Metasploit Framework
payloads for various operating systems,
as well as web servers.
Now, if you've used the Metasploit Framework for,
probably, I would say, before the last five years,
then you would know that msfvenom is really
a new utility and is a combination
of two previous utilities known as msfpayload and msfencode.
So msfpayload was used to generate payloads,
and then msfencode was used to encode payloads.
They were two separate utilities,
but now they actually joined into one called msfvenom.
And msfvenom is part of the Metasploit Framework.
It's a Metasploit Framework utility,
and it comes pre-packaged with Kali Linux,
so you don't have to actually download it or install it
manually.
Now, we can-- in this particular scenario,
we can utilize the MSF--
we can utilize msfvenom to generate
a malicious meterpreter payload that can then be transferred
onto the client target system.
Once executed, it will connect back to our payload handler
and provide us with remote access to the target system.
And I'll also be explaining what a handler is
in the context of a meterpreter payload.
So now that we have an understanding of what
we are going to be doing and what we are essentially
going to be covering within this section, let's get
started with the first practical section,
which is how to generate payloads with msfvenom.
All right, so I'm back on my Kali Linux VM.
In this case, you don't need a lab environment
to follow along with the techniques.
As I said, this is a client-side attack,
so we essentially just taking a look
at how to generate payloads.
So, in terms of running msfvenom,
it's fairly simple to understand or rather to use.
We can just type in msf and then venom.
Hit Enter.
And as you can see, that will open up the documentation,
and it gives you an idea of what this tool is
and what it's used for.
So, as you can see, it says msfvenom
is a Metasploit standalone payload generator.
And it's also a replacement for msfpayload and msfencode.
So it gives you some usage examples here,
and you can take a look at all of the options here.
Now, I'm going to be explaining some
of the key elements of msfvenom that you need to understand.
As you know previously, during the earlier section
or the introduction section of this course,
I briefly explained the two types of Metasploit Framework
modules available.
One of which was a staged payload,
where the payload would essentially be sent into parts.
And then you have the non-staged or inline payloads,
where the payload is essentially sent along
with the exploit as a whole.
And with msfvenom, you can generate both
of these types of payloads.
But before we do that, if you want
to list out the available payloads,
you can generate with msfvenom.
You can type in msfvenom and then list out the payloads.
So I can say list payloads.
Give that a few seconds, as there are quite a few payloads
here.
So, as you can see, this will provide you
with a list of all available payloads
that you can generate with msfvenom.
And as you can see, there are quite a lot.
However, in this course and in this case,
we're going to be focusing primarily
on the meterpreter payload.
And as we already know, the meterpreter payload
also allows you to specify the target architecture
of the target operating system.
So you can generate a x64 payload,
which is a 64-bit payload.
You can also generate a 32-bit payload,
where, again, if I can actually identify this or actually
find it here, I should be able to show you that.
And then, of course, I'll explain the difference
between a staged meterpreter payload
and a non-staged payload.
So, again, if hopefully, I can find
the Windows meterpreter payload here.
This is the one, so this is a standard 32-bit payload.
And msfvenom allows you to specify the target operating
system architecture when generating a payload.
So now, let's explore or understand the difference
between a staged payload and a non-staged payload
in the context of how they differ in terms of their name
because, again, when generating a payload,
you need to specify the exact type of payload
that you want to generate.
So if we take a look at a quick example here.
I'm just going to scroll down a little bit here,
and hopefully, I can find an example that will actually work
or that will make sense.
So let's take a look at this one here.
So, as you can see, this is a meterpreter payload.
So let's start off with the target operating system.
So whenever you're specifying a payload,
you start off by specifying the operating system with which,
in this case, is Windows.
Now, Linux also has its own meterpreter payloads,
and I'll get to them in a second.
And then you specify the target operating system architecture
or the actual architecture, or rather the type of payload
you're trying to generate in regards to the target operating
system architecture.
So if I generate a 64-bit payload,
I cannot run the payload on my 32-bit operating system.
So you need to be very cognizant of that.
And then, after that, we specify the payload type.
In this case, as you can see, this is a meterpreter payload.
And then, after this, you specify the protocol
that you want to use to actually connect back to the attacker
operating system.
So this will, again, depend on your own use
case and the target environment that you
are going to be deploying your payloads on.
So a good example of this is whenever
you're trying to, again, utilize the reverse HTTP
or HTTPS payload.
This is very good if you are trying
to mask the connection as legitimate because, remember,
this is a reverse connection, which means,
once this payload is executed on the target system,
it will connect back to the attacker system.
And in this case, it will go through an HTTP or an HTTPS
port, which, again, will help mask
the activity as a connection to another port on an attacker
system will be extremely suspicious.
So that's, again, in the context of TCP.
So, again, the type of protocol we will use
will depend on what your requirements are.
Now, this is a staged payload.
And the way you can tell the difference
is because you're specifying meterpreter,
and then there's a forward slash,
and then you specify the protocol that you want to use.
Now, an example of a non-staged payload is one here.
As you can see, this is where you specify the operating
system--
the operating system architecture, and then
you specify meterpreter.
However, instead of there being a forward slash,
you can see that it says right over here _reverse HTTP.
So this is, as you can see, a non-staged payload.
And this over here is a staged payload,
and it gives you an example of what this payload is used for.
So you can see it says this will inject the meterpreter server
DLL via Reflective DLL Injection,
and this is staged, of course.
And this will require Windows.
There we are.
Windows XP service pack 2 or newer.
So it'll give you an idea of what
target operating systems this will work on
in the context of Windows.
And this will tunnel the communication over HTTP.
Now, in the case of TCP, and I'll just, again, explain this
really quickly, you can see it will connect back
to the attacker based on whatever port we specify.
Now, we also have Linux payloads,
and they look exactly the same, except, of course,
the operating system is specified differently.
So let me see if I can find one through the list
here as that is quite important.
There we are.
So we have the Linux payloads here,
and this is the 32-bit meterpreter payload.
This is a staged payload, as you can see here.
And then, of course, you have your non-staged payloads.
Hopefully, I can find them here.
Your non-staged Linux payload.
So there we are.
You can see Linux x64 meterpreter
that's a staged payload, and then this
is the non-staged payload.
So they look very, very similar.
So let's get started, and we'll explore a little bit
of the functionality.
So whenever you're trying to generate a payload
with msfvenom, you type in msfvenom,
and then you specify the target architecture.
This is not always required, but it is quite useful.
So if I want to generate a 32-bit payload,
I can type in x86.
And then, after this, I specify the actual payload
using a hyphen P.
So if I want to generate a Windows payload,
let's start off with Windows, I can say, again, Windows,
and then I can specify the target architecture.
But in this case, it's a 32-bit payload.
So I can say windows/meterpreter/reverse_tcp
or HTTP or HTTPS, depending on your own requirements.
I can also specify a non-staged payload if I want.
So we are specifying the payload.
Now, we need to specify the attacker's information.
So what IP address will this payload connect to?
So, in order to do that, we're going
to say LHOST is equal to-- and this
is where you specify your Kali Linux VM IP or your Kali Linux
IP.
And in my case, that is 10.10.10.5.
And in the case of TCP, we can specify the actual port
to connect back to, or rather the port
that the payload will connect back to.
And in this case, I'm just going to say 1234 just
to keep things simple.
Now, this is where the important part comes into play,
and that is the output format.
So we can generate this payload or essentially output,
or generate this payload and output it into an exe file
so that it can directly be executed on the target system.
In order to do this, we specify the format option,
and then we say exe.
And then we can output it and say we want to output
it onto my desktop.
So I'm going to say home/kali/Desktop.
And in your case, you can change the actual storage directory.
And I'm going to store it into a folder
that I created called Windows Payloads.
And then I need to provide it with a name.
So I'm going to call this payload--
I'm just going to say payloadx86.exe.
It's very important that you specify the extension here.
So I'm going to hit Enter.
Give that a few seconds.
As you can see, it's going to say no platform was selected,
so we can specify the platform.
But in this case, because we are highlighting the payload
that we want to use, which is a Windows meterpreter reverse TCP
payload, it's going to say--
it's going to utilize the platform specified
from the payload.
It's then going to say no encoder specified
outputting the raw payload.
The payload size is 354 bytes, and the final size
of the portable executable is 73,802 bytes.
So if I head over onto my desktop
and under Windows Payloads, you can
see that it generated the payloadx86.exe.
So you can now transfer this over to the target system,
or you can essentially set this up in a social engineering
campaign and somehow get the target employee or the person
you're targeting to download it and then
execute it on this system.
However, before they execute it, you need to set up a handler.
And before we actually get into how to set up a handler,
let's take a look at how to generate
another type of payload or rather changing
the actual architecture of the payload that we're generating.
So to generate a 64-bit meterpreter payload,
I'm just going to head over here into the previous command.
And we're going to change the architecture to x64.
And then, as well as in the payload,
we are also going to say this is an x64 meterpreter payload.
We're going to leave the LHOST and the LPORT options the same,
and we're going to output it into the exe format
and save it as payloadx64.exe.
So it's really that simple in regards to, again,
changing the architecture.
So I'm going to hit Enter.
That is, again, going to take a few seconds.
All right, as you can see, that again
generates a 64-bit meterpreter payload,
and it outputs it into the file name that we specified.
So, again, it gets the actual platform
from the actual module or the payload that we specified.
And then it says the final size is 671 or rather 7,168 bytes.
So if we list out the contents of the Windows payloads
directory, you can see that we have the payloadx64.exe, which
is suitable for 64-bit versions of Windows.
And the 32-bit payload here can be
executed on both 32-bit versions of Windows
as well as 64-bit versions of Windows.
So it's entirely up to you in regards
to what to actually what type of payload
you want to generate in terms of the architecture here.
Now, I've talked about the output format,
but I didn't take you through all of the output formats
available.
You can list out the output formats
available by typing in msfvenom.
And then, if I say list and say formats,
that will provide you with a list of formats
that you can output your payloads into,
and we'll give this a few seconds here
because there are quite a few.
And they are sorted based on executable format.
So these are the formats that can be directly executed,
and they are sorted based on the target operating system
and/or platform.
And in the bottom here, you have the framework
transform formats, which allow you
to output the payloads into either a Python file, a Ruby
file that can then be modified later, or even a hex
file if you want.
So you can output your payloads into any of these other formats
here.
However, if you want an executable file,
so you can output it into an Asp file,
ASPX, ASPX-EXE, DLL file for Windows.
So if you are trying to generate a malicious DLL file,
you can do that.
If you're trying to generate a malicious Linux binary,
you can use the ELF option.
If you are trying to generate a malicious Linux shared object
file, you can use the Elf shared object option.
If you are trying to generate a Windows executable,
you can say exe or exe-only, exe-service, exe-small, et
cetera, et cetera.
And then, of course, you have your other options here
for Java or Java web servers.
So you have your JAR file, JSP file.
You can also generate MSI files for Windows
as well as OSX or Mac OSX app files for execution
on MacOS targets.
And you have various other output formats
that are executable.
So now that we've explored that, let's
try and take a look at how to generate
Linux payloads with msfvenom.
And the process is, again, exactly the same.
The only thing we're changing is the target operating system,
and of course, the actual meterpreter payload.
So, again, what we're going to do
is I'm just going to take a step back,
and I've also created a folder on my desktop called
Linux Payloads.
That's where I'm going to be storing the Linux payload.
So whenever you are generating a Linux payload,
you have the ability to output it
into a binary file or an ELF file, which can both be
executed again immediately.
So, in order to generate a Linux payload,
we're going to say msfvenom, and then you
can specify the architecture if you want.
Although, that's not required because you're
going to be specifying the architecture
within the actual payload type.
So if I'm generating a 32-bit Linux payload,
I say Linux and then x86.
And then I specify the actual type
of payload, which, in this case, is meterpreter.
And then I can specify the protocol
to use, which, in this case, is going
to be a reverse TCP connection.
And then the LHOST option.
This is where you specify the attacker's IP address or the IP
that you want the payload to connect back to.
So 10.10.10.5.
This is my Kali Linux IP, and then
you specify the port to connect back to.
So 1234, in this case.
And then you specify the output format as ELF
because we're outputting this into an extensible linking
format for Linux.
And then, in terms of the output,
we're going to save this on my desktop under Linux Payloads,
and we can then provide it with the name.
So I'm going to say payloadx86, and you can then provide it
with the ELF extension, or you can output it directly
into a binary.
So I'm just going to--
I'm not going to provide any extension because the binary
can directly be executed.
So I'm just going to hit Enter.
That is going to generate a staged Linux 32-bit meterpreter
payload for us, and I will give that a few seconds.
There we are.
As you can see, it gets the actual architecture
from the payload here if we don't specify it explicitly.
And it also gets the platform from the payload.
So really, the most important thing
that you'll need to specify whenever
generating a malicious payload is the actual payload type.
And within the payload type, ensure
that you specify the target operating system as well
as the architecture if that's something
that is important to you.
So, as you can see, it outputs the payload into an ELF file.
And if we head over into the Linux payload directory,
you can see we have the actual payload here.
And because we are running this--
we are running Kali Linux.
We can actually execute this directly.
So let me provide the actual binary
with executable permission.
So I'm going to say chmod plus x and then hit Enter.
And now, I can execute it by providing the actual execution
option here within the command line, which
is a full stop and a forward slash.
And then I can specify the actual payload here
and hit Enter, and that is going to execute it.
As you can see, it provides us with no output.
And the reason nothing is happening
is because we haven't set up a listener or a handler
to receive the reverse connection.
So we'll actually explore that in a few seconds.
So I'm just going to terminate that.
And in terms of generating a 64-bit Linux payload,
the process is, again, very, very similar.
So I'm just going to change the output file to payload x64.
And then, as for the actual type of meterpreter module,
we are then going to change this into x86-- oh, sorry, into x64,
and that's pretty much it in regards
to changing the target or the operating system architecture,
or rather the payload architecture here.
So I can just hit Enter.
All right, as you can see, that outputs it
into an ELF file or a binary, in this case.
And if I list it out, you can see
we also have payload x64 right over there.
So we have generated our payloads.
Now, in terms of transferring them onto the target,
that is, again, going to depend on the type
of social engineering technique that you will utilize.
In my case, we are going to, again, transfer the Windows
payload first to a simple Windows 7 system
that I've set up to demonstrate this.
So, in order to transfer this Windows payloads
onto the actual target Windows 7 system,
I'm going to navigate into the Windows payloads directory,
and I'm going to set up a simple web server within this folder
to serve these two payload files.
And then I'll head over onto my Windows 7 system
and then download the payloads from the Kali Linux web server
that I'll set up.
So, in order to set up a simple web server to host these files,
I'm going to say sudo python m.
So we're using a Python module called SimpleHTTPServer,
and I'll host this on port 80.
So, once I hit Enter, I will be able to access
all of these files on the Kali Linux IP on port 80.
So, as you can see, it's going to serve an HTTP web
server on the Kali Linux IP on port 80.
However, we also need to set up the handler
to receive the reverse connection back
from the target system.
Now, this can be facilitated within the Metasploit Framework
console.
So I'll open up a new tab here, and I'll open up the Metasploit
Framework console there.
So I'll type in msfconsole and give that a few seconds.
Now, the reason we're utilizing the Metasploit
exploit/multi/handler is because whenever
we're dealing with payloads that are advanced like a meterpreter
payload, we need an appropriate listener
to actually handle the reverse connection or the connection
that we receive from the target system.
So, in order to use the multi/handler,
we're going to just say use and then multi/handler.
And once we specify the multi/handlers,
you can see it's going to say using the configured payload.
We need to change that because we
need to set up a listener for the meterpreter payload.
And in this case, the payload that we're
going to be using first, or that we're
going to be awaiting connection back from,
is the Windows x86 payload that we generated.
So this is where you would specify
the actual payload option that you had used to generate
your payload with msfvenom.
So if you are trying to wait for a connection back from
a payload that you generated, and in this case,
a Windows x86 payload, I would say Windows and then
meterpreter/reverse_tcp.
And now, as you can see, it's going to set the payload.
If I show the options now, I now need
to set the LHOST option or the IP address
that we configured to-- we configured our msfvenom payload
to connect back to.
So we'll say set LHOST to 10.10.10.5.
And then set the LPORT that we had also
configured with msfvenom when generating
our Windows payload, which was 1234,
in the case of all of them.
And then, once we are ready, we just hit Run.
So now, as you can see, it's going
to say started the reverse TCP handler on our Kali Linux IP
on port 1234.
So now, it's listening for a connection from the target
system whenever the payload is executed.
So we can now head over to the Windows system.
So I'm just going to switch over to the Windows 7 system.
So I'm back on the Windows 7 system,
and I've navigated to the directory of the web server
that we hosted, which is on the Kali Linux IP address,
which is 10.10.10.5.
And I have the two payloads here.
So I'll download payload x86 because we set up
the multi/handler for that particular payload type.
So I'm going to click on it and hit save.
And I'm going to save it within the Downloads directory here.
And there we are.
As you can see, it's going to say download completed.
And if we navigate to the Downloads directory now,
we can execute it.
There we are.
Run.
And that's going to execute and not provide us with any output,
and we should receive a reverse connection on our handler now.
So I'm going to switch back to Kali.
So I'm back on Kali.
And as you can see, I received a reverse or a meterpreter
session from the target system.
As you can see, meterpreter session one opened,
and we got a connection back from the target Windows 7
system, which has the IP 10.10.10.7,
and it connects back to port 1234.
And we now have access on the target system,
and this is what a client-side attack looks like.
Now, again, we haven't explored the process
of antivirus evasion and, more specifically,
encoding our payloads.
We're going to be exploring that in the next video.
And again, you can repeat this process for the Linux payload
as well.
So, again, if I try and get a reverse connection on the Kali
Linux system, which is kind of funny because, again,
I already have access to the system,
but I can terminate my session by hitting--
by essentially, saying Control+ C and/or exit.
So I just hit Exit.
That is going to shut down that session.
And because we're still utilizing the multi/handler,
I can set the payload to Linux/x86/meterpreter/reverse
tcp, and then just hit Run.
And then I can execute the Linux payload just
to show you that it does work, there we are, Linux payloads,
and I can execute payload x86.
Hit Enter.
And as you can see, we get a meterpreter session.
So, again, that's how to generate payloads with msfvenom
for both Linux and Windows.
And now, in the context, or in the case of transferring them
onto the target system, that's something
that we can probably explore in another course--
in a social engineering course.
However, in the next video, we'll
be exploring the process of encoding these payloads
to avoid antivirus detection.
And then, after that, we'll also be
exploring the process of how to inject
a payload into a legitimate Windows executable, which
can also help with the legitimacy aspect of things
to essentially trying to make the actual executable
or the payload look as realistic as possible
and avoid any detection in terms of suspicion from the end-user.
So I'll switch back over to the slides.
All right, so that was the process
of generating Windows and Linux payloads with msfvenom,
as well as utilizing or setting up a handler in order
to receive the connection.
In the next video, we'll be exploring
the process of encoding Windows and Linux
payloads with msfvenom.
So I'll see you there.