You may have noticed a slight change in location and that's because the power
is out at my original recording location and
I've decided to go outside and we're taking the show on the road, so to speak,
but are really
out in the backyard, but that's okay.
What we're taking a look at now is creating a malicious DLL through MSF venom.
Now I have the code for this below and you may notice that there's two
variations.
One is for 32 bit and one is for 64 bit.
One for 64 specifically states in there X64 and I wanted to explain before we
got too deep with the weeds on this.
You see, there are still operating systems and programs out there like MSF or
Microsoft Office that run 32 bit
because the modern processors run at 64 bits and can operate on either or where
a 32 bit processor or program can only operate in 32.
No forward compatibility, so to speak, right?
Well, the reason that we have to account for this is because during the
reconnaissance phase of our pentesting life cycle,
you may have found that there are some 32 bit OS's or programs out there for us
to be able to exploit.
And while that's not ideal for the organization, it could be a budgetary
measure on their part because, you know, if it works, why change it?
Just things to keep in mind that if you run across those, don't be afraid to
look for modules inside of MSF venom, which we're going to be diving into here
shortly,
that may adapt or account for both.
That being said, boom, check a lock.
I'm here inside of Meta or Metasploit MSF venom inside of our lab for Kelly.
Now, I want to point out that real quick that I have ran the first code as MSF
venom with nothing else behind that.
And it gave us all the options and flags for the command itself.
The reason I did this is because if you're just now using this for the first
time and for whatever reason, you've floated it, you've installed it, you haven
't ran it yet.
It needs to build a database.
You've seen this in previous skills, but running that command by itself allows
it to be able to do that kind of a forcing mechanism to where taps the Kali
repository or wherever you have it set at to be able to download all the
modules for the actual MSF venom.
So whereas you run it afterwards, you don't have to do that or you could just
do infrequent updates as you desire.
And when you do your pseudo app update upgrade, it's kind of wrapped up inside
of that as well along with the actual Metasploit itself.
Now, that being said, I do have here the actual command.
And again, this is inside of our code box below.
See here that I have MSF venom and we're going to be walking through this step
by step.
See, we're creating a DLL that's going to be a fake and malicious for us to be
able to remote back into this terminal and MSF venom is going to call upon the
payload dash P of windows slash X 64 or you could leave that part out if you're
looking for a 32 bit system slash beater, preater.
And that's how I'm pronouncing it and I'm sticking to it.
Slash reverse underscore TCP and reverse TCP is key to what we want to do here
because that's going to create a reverse connection to us over TCP.
Why TCP over UDP? You ask?
I'm actually glad you asked that.
See TCP as we know in networking is a lock.
It has that three way handshake and has all the sequence orders and all that
other great stuff.
It allows us to be able to maintain a connection no matter the speed or
reliability of the network.
So long as it does get connected, it's going to try to maintain all sequential
packets of that connection.
So that way nothing gets out of order.
And if we miss something, it'll rescind it to us by packet.
So that's really good for us when we're pen testing and doing something like a
reverse show because it allows us to be able to go through and send a command
and let's say DIR and ensure that not only does the command get sent, but that
we get all
results back.
And that may pause while it's waiting for one of those packets to get back in
order, but it will what it does, it'll send everything to us and make sure that
we're actually good to go.
Just something to keep in mind, whereas UDP is I like to equate UDP to like a
bowl of wet noodles.
You throw all of them at the wall and you see which one sticks.
Whatever sticks is that UDP packet that just happened to make it.
And when we're running pen testing, TCP is our preferred method and things like
this because it allows us to be able to ensure that commands are being sent
back and forth.
I'm glad we had that little side talk there for a second, but back to our lab
here.
The next part is the L host, meaning listening host, which is going to be us.
And if you're lost on which one this is, just run an IF config.
But for ours, it's going to be 192.168.0.53 and you'll notice that that's eth
one here on this lab.
Our listening port is going to be next with 4444 and we'll come back to that in
just a second.
Dash F is going to be our file type of DLL.
Again, we'll come back to that just in a second and our dash O output is going
to be evil dot DLL what we're actually naming the file.
Now, I do want to point out that we are taking a look at this inside and we ran
it from 2D slash desktop.
Yes, I know what that little wiggly line is.
The that's important because when we execute this file or this command, it's
going to create that evil dot DLL what in the present working directory, which
is till D slash desktop, which is short for
Home Cali desktop and it'll put it on there.
So when we run this, it's going to think about it for just a second and then
actually create it here on the desktop and the lower left like it just did.
Now there's a couple of things that I want to go over real quick in concerning
what this actual command does.
First and foremost, the dash F for DLL is initiating the actual files type.
Now in Windows, we know that we have to have file extensions on everything like
DLL dot com dot bat dot says I'm sure I'm showing my age here.
But that DLL forces whatever we're doing to not only have the file extension
because we added that in the output name, but also to include DLL magic numbers
in the file header itself.
So even if we were to name it evil dot text and later on, we ran this with the
run DLL command that it would still execute as a DLL because in the magic
numbers of the file header, it's still indicating that it is in fact a DLL.
And in addition, the next part I wanted to make sure that we understood is that
no matter how many of these we send out as far as you know that reverse shell
payload inside of whatever malicious file we make for MSF venom.
We also need to account for the fact that those are
for everyone that we send out, we need to anticipate everyone I'm coming back
to us to be able to make that connection, meaning that we have to have
listeners available.
So we have one pentesting system here that we're using inside of our lab.
Realistically, we would want to have at least one or two systems set up to
receive those reverse shells that are coming back to us.
Now, the beauty behind this is that they don't have to be overly complicated.
They could be dummy terminals or anything you could even run it on a Raspberry
Pi.
It doesn't have to be complex because most of the processing of our commands
are going to be done on the system that we've infiltrated because that's where
the commands are being sent to.
Those are two big important things that I want you to remember whenever you're
creating these DLLs.
And because we've created the DLL as such and it's already here on our desktop,
now the next obstacle that we face is as pen testers is getting to the desired
system or systems.
Now, we've covered skills already talking about file delivery and infiltration
and getting it to that target system.
So this skill is not going to be covering that.
So when we go into the next part of this, we're just going to have it magically
appear on our Windows system and I'm going to leave it up to you.
To refresh some of those skills that you have already to be able to see if you
can get it on target systems.