Before we get started, the one thing that we haven't done so far is actually make a dummy file
for Ubuntu or POSIX based systems. And I've been kind of saving it up until we get to something
like this. So that way we can walk through the steps together because it is slightly different
than when we actually did it for our Windows system inside of MSF Venom. So let's hop on
over for a second. And I already have it pulled up here. I'm going to move it in center of the
screen and then zoom in for us here. And as always, commands are below for when you want
to be able to copy and paste. What we're doing is the still pseudo MSF Venom, and we're still
doing a payload with it. But the payload is different this time. Before we used Windows
x64 beta breeder, and now we're going into Linux because it's a generic Linux payload.
Now I also have in here x64. And the reason for that is, is because I know the target system,
our Ubuntu virtual machine is 64 bit. You could leave this option out and go straight into
beta breeder and it would kind of auto detect if it was 32 or 64. This has just been proven to be
a little bit more reliable in my use over time. So it's just habit at this point, especially if
you know what the target operating system is. And we kind of do. In the future, you may decide
to create more than one of these dummy files and kind of hope that one of them works based on which
type of operating system they have. And that's okay too. The rest of it's the same beta breeder,
reverse TCP. And you may be wondering, why do I always use TCP? Well, that's because TCP is a
reliable protocol for communications to and from an actual target. It has that three-way handshake
with it and ensures that we don't miss any data going back and forth. And by that, I mean, let's
say we sent a command and got response back like sysinfo. And if it was UDP, the command would go.
And for whatever reason, there's a hiccup in the communications. And I would only get partial of
the data back. So I like to make sure that it's TCP. So that way, if I am doing things that require
commands to be sent to and from and look for specific responses, then I want to make sure that
they get back and forth like they're supposed to. Now, the rest, some of this is the same,
like the listening host and the listening port. And I do want to remind you that you can only
have one listener per port, multiple listeners per IP address, but one per port. So we are setting
this to 4444 as a default as far as our practice is concerned. But if you wanted to run more than
one listener at a time, you would have to set up, because our Windows dummy EXE is quad four,
like this one right here. Let's say we set Ubuntu to 4445 as an example. But for now,
we're just going to leave it as is. And if you run MSF console, trying to listening to both at the
same time, it won't work. It'll be first come first serve something to consider as well. But the more
listeners that you have on the same one system, the more resources it takes up. So it might be
something you want to allocate across different systems or have more resources for your Kali
system. Now this is going to be a little bit different because before our file type was like
EXE and DLL. Well, here we're going with ELF, and we're not talking about ELF on the shelf. It's
too early for that. Take your Christmas stuff down in the stores. But ELF is the standard executable
format inside of POSIX-based systems. And for our output file, we're using dummy.ELF as well. Now,
we already know, especially at this point in our learning, that executable files, or files in
general, inside of POSIX-based systems don't have to have a file extension. This is basically for us
to be able to keep track of it and use it as a practice target. So adding .ELF to it just indicates
for us, the learners in this particular situation, that it was created as .ELF, and that's something
we can keep a note of. Now, one thing that we have to add to this that we didn't have to inside of
our Windows was the &&pseudochmod755 dummy.ELF. The reason we're adding this is because in Windows,
when you go into MSF Venom and say file type executable, Windows knows, based on the actual
magic numbers in the file header, along with the EXE extension, that it is an executable file. So
whether you run it by double-clicking on the desktop or inside of command prompt or PowerShell,
Windows can associate that with an executable and run it for you.
POSIX-based systems are a little bit more complicated in this matter because you have to
tell the file that it is executable. Addendum. Mini addendum, and that's why I'm down here and
not up there. Yes, I know another studio and more on that later, but I wanted to kind of correct
myself and make a quick adjustment to what's actually going on in the terminal window above
for our secondary command of chmod being 755. Now in the neat little text box that's going to be to
my right, I'm going to address the file permissions that we have in different numbers real quick
because 755 is for the other users and groups on the system of the POSIX-based
operating system that we're using this file on. Now, if I have a 5 in any one of those groups,
you can see over to the right that that allows read and execute permissions for that file.
So making it 755 here means that the owner has full permissions up the top. You can see read,
write, execute being triple one bit all across and read, write, execute, and those fives are read and
execute. Why just fives? Well, they don't necessarily need that additional to get in there
and for write. We're just only allowing the groups, which is the middle number and others,
which is the last number to be able to read and execute this file. Now I have a picture below
is for what happens if you don't set these bytes correctly and just have it come straight out of
MSF Venom. So the picture on the left will be without the executable checkbox on it. Basically
something along the lines of a four, a two, a one, a zero, or even a six. So it has all the
other permissions in some cases, but no executable whatsoever. Now the one on the right has that
checkbox marked, tongue twister there, and has us with the ability to be able to go in and execute
that file regardless of whether we're the owner, the group, or other users inside of that POSIX
based system. So just something to think about, and you can even further expand on this if you
were to do an LS-LA inside of your terminal to see the further file properties and permissions
set on that particular file that you create or any other file for that matter. So once that's
done we can basically just send it over to the Ubuntu system, however we decide. Now in this
case I've mounted a folder from the actual Hyper-V Adept Lab system that we log into for this lab,
and it's in the share folder on the desktop. But I've added it to the desktop on the Ubuntu
system already, so that way you know it's already there.