Now things are a little bit different when we run a multi-session script or anything
that requires multi-use altogether, because that's where we start taking into account
the fact that we're going to have a single system or multiple systems listening to multiple
incoming connections or performing multiple outgoing connections.
Now it's at this point I want to kind of stress an important factor here. Not everybody's
going to have all the fanciest, danciest equipment out there, and you may have one
Kali system doing multiple listening jobs. And that's perfectly fine. Just keep in mind
that you have a resource limitation and also a bandwidth limitation. So too many jobs going
on at once can hinder the system. So when you create these scripts, just keep this in
mind. And also the fact you got to keep track of how many jobs or files that you're sending
out there. Now I point that out for a very specific reason, because in our lab here,
we're taking a look at the actual file that we have on our desktop from multi. Now this
is the script that we're using. I'm going to walk you through this here real quick,
because it's ever so slightly different than our single use script. And number one,
we're going to enter the handler module, and I will correct that typo here in a second.
We're going to do it once. So for every job that's about to follow, we're going to be
using the same exploit. The same exit on session is false. And in this particular case,
the same L host, because all jobs are going to be coming to this one Kali box right here.
So we can have multiple incoming sessions. The trick behind this is when we start getting
in the weeds for the next part, and that is listener one, which is our standard Windows
meterpreter going on port four, four, four, four. And we're going to set that L port to
four, four, four, four, along with having the payload set to what matches our MSF
Venom file that was created. In this case, dummy. And I see another typo in three,
I'll fix that in a second. Standard Linux meterpreter is our second payload.
We have this set up to match the payload that we sent over to Ubuntu. Now, if we haven't done that
yet, we should have, but I have one on the desktop ready to go. And the L port for this one is four,
four, four, five. So this is where we split up our listening capabilities inside of our Kali
system, because we want one connection coming in on one port and another one on the other.
Because if we have this set up to where all of them try to go back to the same one,
it's only going to catch whichever one comes in first. And this allows us to be able to keep
track of what it is that we sent out and what it is that's going to be connecting.
So if we have a job or a session that comes up and says session one is four, four, four, four,
we know that that's going to be a Windows variant or four, four, four, five going to be a POSIX
based system variant. So behind that, you also see on line nine and line 14 that we have run dash J.
Each one of these jobs needs to run in the background. Otherwise the script becomes
kind of irrelevant because it gets hung whenever we're trying to execute each one of these tasks.
So we want this to run in the background and we're just basically doing this to where all of it
flows. And now at the very bottom, you see a job dash L. This is just verifying that we have
everything in place and it shows you the jobs that are currently running and open for listening.
Now I'm going to zoom out here real quick and make a couple of changes for us real quick,
like on line three, I need to change that to four, five, and then on line one, I need to change
that S to a D and then save that for us. And what we'll do is inside of our terminal window,
we're doing the exact same thing, which is MSF console pseudo dash R and this time multi. Remember
I am already in a terminal window that is in that scripts folder. Now when we run this,
after we type in our Kali password, you'll see the MSF console is cranking up
and that cannot find the script multi. I wasn't in the script folder. My bad. So we're going to
exit real quick and go into CD scripts and run the same thing. And this time when MSF console starts
up, you see that all of our stuff is cranking up alongside with it. And we have the exit on session
false, all the other commands that have gone through there. And if any of them had messed up,
you would have gotten an error on this. So that being said, we get our job verification dash L,
because I zoomed out. When I zoom in, it pauses briefly and then it is running with two jobs in
the background. Now that's not necessarily to say that the sessions have connected yet. You could
always go in and type sessions and you see we have no active sessions. So I can go inside of my
windows here, break up dummy, go over here, and you see that a session has started inside of Kali.
Well, at the same time, I want to go into my POSIX-based environment, which is this
Ubuntu system in our lab, and I want to make sure that our dummy is running. That's okay.
So now since we're on the desktop, we'll say sudo dummy2, and that's running in the background as
well. And then you can see that we have stuff cranking up, and it may take just a second for
that to connect, but you see that the first one has. I'm going to pause here real quick and wait
for the second one to connect so we can see both of them. Oh, there, never mind. The session has
opened up on 013. Yeah, I'm going to pause and we'll be right back for the other one to connect.
Oh my goodness gracious. You're not going to believe it. I created the MSF Vennify with
the wrong IP address for the actual listener, and what you're seeing now is it actually connecting
on here. A little bit embarrassing, but what we have is the actual connection from 051,
which is the IP address I put in the dummy2 file on Ubuntu, and I'm going to leave that file on
the desktop for you to be able to explore yourself, and it's going to make that connection here to
0.53, which is what it should have been when I created the MSF Vennify file, and you can see
that we have that connection now, and when we run sessions, we can see that we have both of our
sessions active, and we didn't really have to do anything other than run our multi-script inside
of MSF console, and this is where the advantage of being able to run a script inside of Metasploit
or any other Metasploit activity comes into play.