Bind Shells-- in this video, we're
going to be getting an understanding of what
bind shells are and how they can be set up or facilitated
with Netcat.
And we're also going to be getting
an understanding of why reverse shells are
preferred over bind shells.
All right?
So let's get an understanding of what's
happening in the background or what a bind shell is, really,
from a connection perspective.
Right.
Now, before we do that, I've been
mentioning this term shells.
And within penetration testing, you'll
typically hear of reverse shells, bind shells,
Meterpreter shells, command shells, et cetera.
So what is a shell?
Well, a shell is essentially a program or utility
that allows you to execute commands
on an operating system, or a system for that matter.
And a remote shell is essentially
just a shell that allows you to execute commands on a system.
However, the remote shell allows you to do so remotely.
So what is a bind shell?
Well, a bind shell is a type of remote shell
where the attacker connects directly
to a listener on the target system,
consequently allowing for execution of commands
on the target system.
All right?
So if you take a look at this diagram here,
you can see that you have your attacker system--
that's red on the left--
and you have your target system--
that's blue on the right.
And in order for a bind shell to be obtained,
a Netcat listener must be configured
on the target system.
And that Netcat listener must be configured
to execute a shell depending on the type of operating system
that's running on the target.
So let's take a look at a simple example.
If the target is running Windows,
then the Netcat listener must be configured to execute a shell.
And in the case of Windows, that will typically
be cmd.exe or PowerShell.exe.
Right?
So what happens is, once that Netcat listener is
set up and configured to execute a shell, any Netcat client--
or any client for that matter-- that connects to that Netcat
listener will be provided with a remote Command Prompt
session or a command shell, if you will,
or even a PowerShell session if PowerShell.exe has
been configured to be executed.
So again, if we go back to the previous video
where I highlighted the -e option within the actual Netcat
documentation, the -e option allows you
to execute a specific program.
Now, in the context of penetration testers
or adversaries or attackers for that matter,
the -e option is typically used to specify a shell.
Again, in the context of Windows, as I said,
that will typically be cmd.exe or PowerShell.exe.
If the target system is running Linux,
then the Netcat listener must be configured to execute a shell.
And on Linux, we know that we have multiple shells.
The default shell is bin/bash, or you
can use bin/sh, which is the Bourne shell.
You also have usr/bin/zsh or Z shell.
And again, it's essentially the same process.
Now, one of the things that you will constantly hear
and you'll actually find out for yourself
is that reverse shells are much better than bind shells.
Well, why is that?
Well, let's take a look at this diagram here.
What's the problem from the perspective of an attacker?
Well, for one, we actually need to set up a Netcat listener
on the target system.
How do we do this if we don't even have access
to the target system?
Well, you can see that that poses a potential issue.
The second issue with bind shells
comes from the perspective of network security.
Now, on most operating systems like Windows and Linux,
inbound traffic--
that means traffic that's coming into a system--
will typically be blocked by the firewall or any other security
systems or mechanisms that have been put in place, which
means that, if Windows Firewall is enabled on a target system,
a bind shell will probably fail if it's incoming to a port that
has actually been blocked or a port range that
has been blocked by Windows Firewall, for example.
Right?
And that really isn't something that an attacker
will be too pleased with.
And this is where the whole idea of the reverse shell
comes into play.
So let me just explain where a reverse shell is different,
and it all comes down to the connection type.
So in the context of a reverse shell,
the roles are switched in that the target now
connects to the attacker's Netcat listener.
So a Netcat listener is set up on the attacker system,
and then the target actually connects to that.
So again, this connection is then flipped,
and that is where you have a reverse shell.
The reason for that is because, again,
outgoing traffic from a system, again,
is rarely blocked by a firewall or by any security mechanism,
whereas inbound traffic is usually very suspect.
And you can actually test this out for yourself.
If you open up a Windows system and just take
a look at the inbound traffic currently,
it's going to be significantly less.
And that's because there's very rarely a reason for there
to be an incoming connection to a standard workstation system.
Now, if it's a server, then that's totally different.
That really would not be an issue.
But even in that case, inbound traffic is usually limited
and is controlled by a firewall, so only specific ports
will be accepting inbound connections.
So that is the difference, at a very high level,
between a bind shell and a reverse shell
and why reverse shells are preferred to bind shells.
So again, the connection is fairly simple.
All right.
So now that we have an understanding of what a bind
shell is and how it works, we can actually
get started with the practical demonstration.
So again, we're going to be utilizing the same lab
environment that we used in the previous video.
So just fire up the lab environment
and we'll get started.
So I'll see you within the lab environment.
All right, so I'm back within the lab environment.
And by this point, you should be familiar with how it works.
We have the attacker machine and the target machine,
which is running Windows, Windows Server
2012 to be specific.
And again, just disregard the vulnerable service
that is running on the target because we're not really
focused on exploiting it.
We're primarily focused on utilizing Netcat to set up
bind shells and reverse shells.
So you'll also be provided with the target IP address, which
will change from the previous time you ran the same lab
environment.
So just keep this file open.
The first step, of course, that we need to perform
is we need to transfer over nc.exe onto the Windows system.
As I said, this is not ideal, but it's something
that we have to do in order to understand
how to set up a bind shell.
So what I'll do is I'll open up a terminal here,
and I'll just zoom in so you can see what I'm doing.
And I'll head over to the directory
that contains nc.exe on the Kali Linux system.
So that's under user, share, Windows, binaries.
And within this folder, we have the nc.exe file here.
So we're going to set up a web server with the Python module
SimpleHTTPServer, and we're going to host it on port 80.
Right?
And this will allow us to download the nc.exe file
onto the target system.
So I'll hit Enter.
We now need the Kali Linux IP.
So again, just open up a terminal and type in ifconfig
and your IP address is going to be attached
to the interface Ethernet I. And of course, in your case,
it's going to be different, but just copy the value there.
And we can now head over to the Windows system.
So in order to transfer it, we can
use the technique we used in the previous video
where we downloaded it with a utility called certutil.
The other technique that I wanted to highlight
was through the web browser.
So if I just open up a new tab here
and I open up the Kali Linux IP on port 80,
you can see that we get a directory listing for the web
server that we set up.
And all the files within the folder that we were hosting
are available, so we can download nc.exe.
We're going to add this website.
We're going to say it is safe.
And we're just going to take a step back here
and download nc.exe, and I'm just
going to click on Save there.
And you can see it's going to tell you
that the publisher could not be verified.
That's fine.
It's now under the Downloads directory,
so I'm just going to open up cmd right over here, so
Command Prompt.
And what I'm going to do is I'm just
going to increase the font size and just change the background
color really quickly.
All right, so I've adjusted the font size
and I've just changed the background color as well as
the font color there.
So again, if we head over into the Downloads folder,
we should have nc.exe, so there we are.
And let's take a look at the first scenario, right?
So let's assume that we are following the flow that
is recommended by this lab where the Kali Linux system is
the attacker and the target system
is the system running Windows.
So let me just terminate the actual web server there,
and I'll navigate to my home directory there.
So in order to set up a bind shell,
the target system needs to have a Netcat listener set up.
Right?
And not only that.
It needs to be configured to execute cmd.exe.
So if we open up the documentation again here,
you can see that you have the -e option.
So that allows an inbound program
to be executed, which again, as it says, is very dangerous.
And you'll see how dangerous this is in a couple of seconds.
So we'll set up a Netcat listener on the target system.
So we'll say nc.exe -nvlp.
This is on TCP.
And the port we will essentially set up the listener to run on
is port 1234.
However, because we want to obtain a bind shell
and we want to be able to execute commands
on the target system, we will execute cmd.exe.
So again, what this means is that, whenever
a client connects to this particular listener,
cmd.exe will be executed and the target or the attacker system
will be provided with a command shell or a Command Prompt
session.
Right?
So I'll hit Enter.
And we have set up the listener, so we'll head over
to the attacker system.
So remember, if we want to connect
to a particular target on a particular port, we say nc.
And we'll say nv for no DNS resolution and verbose output.
We then get the target IP right over here.
And then we specify the port to connect to,
and that's pretty much it.
Once we hit Enter, we should receive a bind shell.
There we are.
So you can see Netcat connected and the cmd.exe is executed
and we have now gained access to the target system remotely
via a bind shell.
So I can say, who am I?
You can see we are currently the administrator user.
I can list all the contents of the Downloads directory
or the Downloads folder.
And you can see we have nc.exe here.
So what we've just done from a penetration tester's point
of view is we have obtained remote access to the target
system via a bind shell.
And of course, this is very different
when it comes down to a reverse shell.
So again, this can also be done both ways in that you
can actually connect to a Linux system
and obtain an actual bash shell or a Bourne shell
if you wanted to.
So let's actually try that out.
So I'll terminate the Netcat connection there,
and I'm back on my Linux system here.
And the actual listener has been terminated,
which is what we want.
So let's say we are just going to flip the actual roles now,
so this is going to be the attacker system.
So the Windows system is going to be the attacker system
and the Kali Linux system is going to be the target system.
So on a Linux target, you would need to, again,
set up a listener with Netcat.
So we can say nc and then nvlp.
Right?
And what you need to do then is specify the port,
which we already know.
However, instead of saying execute,
which we can do as well, we can use the -c option, -c,
to execute a shell.
And then we specify the shell that we
would like executed once a client connects,
so we can say bash.
There we are.
So nc -nvlp listen on port 1234 and execute
the following shell.
And this option is reserved for Linux systems.
So we'll get the Kali Linux IP address here
as we will require it because we are connecting to the Netcat
listener from the Windows system.
So I'll hit Enter, and it's going to listen on that port.
And now, on the Windows system, we can say nc.exe.
And remember, we're connecting to the listener, so -nc.
And then we specify the target IP and the port is 1234.
We hit Enter and it looks like we are obtaining--
sorry, that was my mistake.
We're not using -nc.
We're using -nv, verbose output.
So we hit Enter and it looks like we've
obtained a bash session.
The only way we can confirm this is by typing in ls.
And indeed, we have obtained remote access
to the Linux system.
We can then probably type in bin/bash -i
to obtain a full-on bash terminal.
But in this case, it doesn't look like that has worked,
so we can just use our current bash session.
So for example, I can say, who am I, or I can get my ID here.
And we currently have root access
and I've essentially gained access to the Linux system.
So that is how to obtain remote access on a target
system via a bind shell.
It really is very simple to understand.
And of course, you can see why penetration testers
and adversaries actually prefer a reverse shell, more
of which will become apparent in the next video
when we will be exploring reverse shells in depth.
OK?
So that is how to set up a bind shell,
and this is going to conclude the practical demonstration
side of this video.
In the next video, we will be taking a look
at how reverse shells work, and we'll
be taking a look at how to obtain a reverse shell
with Netcat, after which we'll also be exploring
a reverse shell cheat sheet that will essentially
simplify the process of obtaining a reverse shell.
And again, I will clarify how a reverse shell
can be obtained without too much reliance on Netcat itself.
All right, so I'll be seeing you in the next video.