21 hours 43 minutes
module eight Getting a shell. Now, what
the different types of shells
are learning objectives are to understand the difference between a bind shell and a reverse shell,
explain the difference between a good shell and a bad shell and know why architecture matters when it comes to shelves.
So you've seen me get some shells on some boxes, finding some exploits and getting shells.
What happens next is
typically, you know, SCP land or P W. K. Is we need to escalate privileges
further to become root or system if it's a Windows box, in order to do that, we need to have a stable shell in order to do things and interact with the machine, we need to have a stable shell. You'll find some shells are unstable or they die and that's because of different things. Sometimes the architecture of the box is different than the shell that we have.
Sometimes we're not calling the shell correctly, or we're trying to use a bash shell, and the Lennox machine doesn't even have bash. They have shh, they have a shell. And we don't know that we need to kind of figure out what is on that box that we can actually get a foothold on it.
And also how we can exploit privileges
or or escalate privileges, I should say, um, which does in some cases require that we're able to pseudo if it's atlantic Spox
or that the architecture matters. I was talking about that with, with medicine Floyd is the architecture really matters. So you'll find that if you don't have a good shell, your functionality is greatly reduced.
So what's the difference between a bind shell and a reverse shell?
A bind shell is good when the victim doesn't have a firewall up. So basically the victim will open up a port, a listener port. So we've used some kind of exploit and we have the victim open up a port, a listener port and we attach ourselves to that using interpreter or Net cat or End cat.
And that's how we connect to the box with a direct connection from us as an attacker directly to that open port on the victim machine. If there's a firewall up, that makes it a whole lot harder because a firewall will block all incoming traffic except from well known ports. Right from ports like 80 or 443,
they're expecting web traffic and things like that.
A reverse show on the other hand, is a lot safer because what happens is we're having a victim reach out to our machine so we create a listener locally on our box and the victim will attach itself to us.
So this is a lot more useful when a victim has a firewall up.
But I've seen many cases where a bind shell will work. It is more stable than a reverse shell. So that's why I say if a payload fails
with an interpreter, maybe you need to change it up. Maybe you need to make the TCP reverse shell a bind shell. But typically your reverse shell is going to be a lot more effective than a bind shell because most machines now have a firewall up.
so you'll see here this is the example that the victim doesn't have a firewall and the bind shell works fine with this exploit. M. S. Said that this is eternal blue here. So as you see, started buying handler here against 44444 So the victim has put 4444 open
and we're attaching ourselves to it.
The problem becomes when the target has a firewall up. So I did this locally in my lab, I took the firewall down the bind shell worked fine. I put the firewall up
and it failed. So you'll see on the left that says exploit completed, no session was created because the firewall is up
but using a reverse shell and you'll see the payload on the right side. Windows. Matoba, reverse TCP, we have a session open up because the victim machine is connecting to us through the firewall and they're able to do that with this reverse shell.
So how do we, aside from interpreter, how do we figure out how to make a reverse shell work? Because reverse shells are our preference right on the victim machine. If we have remote code execution, we want to use a reverse shell and one that I found that to be very useful and just found this out recently.
There's no one on the bottom of that list. Reb shells dot com. And you'll see
an image of that on the right hand side is you can kind of pick
what you want to use. Is it net cat? Is it python? Some other tried and true ones or pen test monkey
and high on coffee. I use these often.
Of course you have to know what is on. Natively on that machine. So what I'll do is I'll put a web shell on a web server like this. This is a web shell
And I'll issue different commands like Pearl v. So I know if I get this output, this is Pearl five.
That my reverse shell. I can use a reverse shell using PERL.
Um if I do python tack tack version, then I see a version of python. I know whether to use python two or three, but I know that python is on that box.
If I don't see that. I know there's probably something I shouldn't try when it comes to reverse shelves.
So if you do get a web show like this or have a foothold at least initially with remote code execution, try to enumerate the box like that is figuring out what kind of languages are are on it. Even check if PERL or python will work.
All right. So, you'll see here that I'm like I said python using python, python, reverse shell in both of these cases. And when I use Ben S. H. And you see all I have is is a dollar sign for the command prompt.
And the other is I have been bash the born again shell. And you see it's a lot nicer to look at as dub, dub, dub data, quick start. So, I already know what user I am. I'm dub Dub dub data on the box quick start. And it looks a lot nicer. So just know when you're using uh been shell or bin bash,
you expect to see. And from here, you can tell that
bin bash in this case looks a lot nicer for us.
That's also to say, don't blindly just copy and paste,
know what you're invoking. No, if you're invoking bin bash, Corbyn Shell and if that box even has it, of course, it's not gonna work if it's a Windows box, Windows doesn't have that on it.
So what's a bad shell?
A bad shell? If we do Sudo L Which is one of my basic privilege escalation techniques, is figuring out whether what Sudo privileges I have,
it says it doesn't give me any output. As you can see here. I do Sudo attack. L. Nothing happened. So I echo, this is an awful shell
because some of these privilege escalation techniques, you need to be able to see the output and you'd be able to have use Sudo or some of these require Sudo privileges to execute the privilege escalation. So that's to say that this is a very bad shell because I can't see my output and I can't use Sudo.
so you'll see this this output to is in medicine ploy. You see that I have a command shell,
but it will when I do so Ellis is no t t y present.
Now ask past programs specified.
So again, I'm limited time limited in what I can do because I don't have a very useful shell.
So what's a good shell?
As you can see here, I can use Sudo, then I can use the admin's password. Unfortunately not in the in the pseudo group,
but at least I'm able to do that and see the output of it. So good shells allow us to use Sudo where we can see output, which is gonna and and tap completion. Ultimately, if we have ssh, like, like I said before, ssh is probably the best shell you can have. So um in this case, since I have an ssh,
since I've used Ssh to log in this box,
I have the most stable shell that I can.
my interpreter shells are also very useful. Um
I say that I preface that by saying it does depend. PHP shells are not the best, in my opinion,
but in this case,
um the interpreter shell is useful
because we can do things like pivot to other systems, other hosts
and that becomes very useful in things like e c p p T and capture the flags and things like that is now we have additional functionality due to the fact that we have an interpreter shell, we can do a whole lot more than we can if we had, like, let's say, a net cat shell.
Also know your architecture. I'll say I'll say this in the P W K labs,
there's a certain box where um, I had an X 86 net cat shell on it and it was an X 80 for architecture
and my shelter, I I couldn't do privilege escalation because I had the wrong net catch shell on it and ultimately had to
get an interpreter shell and migrate processes for it to work.
So that's also important for local exploits, suggestion, like I explained in medicine flight where if you have the incorrect architecture, you're not going to get the correct exploits that this module suggests.
Um, also this is both of these are useful, but things in SCP be careful because it counts as a module, but if you run the auto run script process dies quickly, you can do this post windows. Imagine manage migrate and as soon as you get um, interpreter session on that box, it will automatically migrate
to another process before whatever process you're on
So again be very, very, very careful because that is a module in and of itself.
So in somebody you should understand the difference between a buyer and shell and a reverse shell. Explain the difference between good shell and a bad shell and know why architecture matters when it comes to shells.