Targeting OpenSSH.
In this video, we're going to be taking a look at how
to target the OpenSSH server or service that's
running on the target system.
So we'll be taking a look at the various tools and techniques
that can be used to essentially gain access
to the target system via SSH.
And yeah.
So again, we're using the same lab environment.
And remember, if you terminated your lab environment,
then you need to obtain the target IP address again,
which I've already highlighted during the port scanning
and enumeration video.
So do check that out if you're having issues with that.
With that being said, I'm just going
to switch over to my lab environment,
and we can go through the process
of targeting the OpenSSH service and consequently
gaining remote access to the target system.
So I'll see you then.
All right?
So I'm back within my lab environment.
And again, as I said, we're targeting OpenSSH,
so that was running on the default SSH port on the target.
So I've just performed a service version detection
scan and the default script scan just
to highlight the exact version of OpenSSH that's
running on the target.
So
In terms of targeting SSH, it doesn't really
matter what product or what service.
It could be OpenSSH.
It could be libssh, et cetera.
What's important to consider is the operating system
that it is running on.
And in this case, we know it's running on a Windows system.
So just keep that in mind in regards to the type of access
that you will get once we obtain legitimate credentials.
Now, another thing to take into consideration
is the fact that we were able to obtain legitimate credentials
in the previous video.
Now, as I said in the context of services like FTP and SSH,
they utilize user accounts on the Windows or Linux systems
for authentication.
So the only thing that might change in certain cases
is the actual password, but we were
able to identify in the previous video--
that we were able to identify the following accounts.
So we identified a account called vagrant.
And of course, the administrator account
on Windows, which as we know is very, very important,
and it is really the most privileged account
on a Windows system.
And of course, we were able to identify the password for both.
For both of them, the password was vagrant.
So again, we can perform a brute force attack on the SSH server.
However, we also need to be efficient with that.
And given the fact that we have identified two user accounts,
then we can perform the brute force
to identify whether the passwords are
different for the SSH service for these two user accounts.
Now, before we do that, OpenSSH has a few vulnerabilities.
However, most of them really affect OpenSSH version 7.2.
So if we perform a query with searchsploit,
and we say OpenSSH 7.1, for example.
You can see that really the only two
exploit or the exploit files that
are available for this specific version of OpenSSH running
on the target is the username enumeration Python script that
allows you to perform user enumeration, which
in this case, we really don't need.
Apart from that, we don't have any other exploit
that can, again, provide us with anything that we don't already
have.
So again, to perform the brute force with hydra,
it's very, very simple.
We simply say hydra.
We're not going to perform a brute force on the username.
So we'll just say the username will start off
with the user vagrant, and we'll see whether there's
been any change there.
And then of course, the password list, we can say user, share.
And in this case, we'll use the actual metasploit wordlists
under the wordlists directory.
And we can say unix_users.txt or password.
And then we specify the target IP, which in my case,
I've already identified and copied.
And we know that the protocol in this case is SSH.
And we can hit Enter, and let's see what we get.
So that's going to begin the brute force there.
And let's see whether we're able to identify
whether the password is different or the SSH service.
So we'll give this a couple of seconds,
and then we can also do this for the administrator account.
So I'm just going to let this complete.
All right?
So after a couple of seconds, we can
see that the password for the user account vagrant
is just vagrant, so that's a really bad thing from the point
of view of the administrator that's
responsible for managing the security of the target system.
So that means we can gain access to the target system via SSH
as we have obtained legitimate credentials.
However, given the fact that we're a penetration tester,
we really want the prized asset, which
is accessed via the administrator account that
will then provide us with elevated privileges right out
of the box.
So instead of saying vagrant, we can perform a brute force
for the user administrator.
And of course, make sure to save these credentials offline.
And again, I'm just going to give this a couple of seconds.
It shouldn't take too much time.
All right?
So the brute force is complete, and it
looks like for the administrator account,
there aren't any valid password, which is, again, slightly weird
because for the FTP service, the administrator account
password was vagrant.
So again, now that we've identified
that we can log in with the use of vagrant or the user account
vagrant, we can actually log in.
And to do that, we can say ssh, and then specify the user.
So vagrant@ the target IP.
And this will provide us with initial access on the target
system, and that's what we were looking
for as a penetration tester.
So I'll hit Enter.
It's going to ask us whether we want to continue connecting,
so I'll say yes.
It's going to ask us for the password, so we'll say vagrant.
And if correct, this should provide us
with a bash session or a Bourne shell session, which
is slightly weird because we are working on a Windows system,
but that's what I had wanted to highlight early on.
Indeed, you can see we get a Bourne shell session.
So if we say ls -al, you can see we're currently within--
let's see pwd.
We're currently within the C drive on the users,
vagrant, which is exactly what we want.
And of course whoami.
We can see that we're currently the user vagrant.
And then of course, we can say net localgroup administrators,
which is a Windows account, so we probably cannot do that,
and there might be a few compatibility issues there.
But the main thing is that we've obtained access
to the target system.
So you can see if you type in any Windows native commands
like dir, that will probably not work,
which is why I did not type in the net localgroup
administrators command.
So we've got access to the target via SSH,
which means we've pretty much owned
this system at this point.
However, I also want to try and see
whether we can gain access with the administrator account
because that really is what we're interested in.
All right?
So we can see administrator.
Let's try vagrant-- permission denied.
OK, so that's what I wanted to highlight here--
is that even though we were able to identify
the password for the administrator account
for FTP, in certain cases-- and this is good security
practice on the side of the administrator, is they've
disabled access SSH logins into the administrator account,
which is, as I said, something that's very good.
Now, we can continue with access via the standard Bourne shell,
or we can obtain a Meterpreter session
with the already obtained credentials here.
And all we need to do is open up MSFconsole.
So I'll split this vertically here or just open up a new tab,
and I'll say msfconsole.
And we can use the SSH login module.
And once we get a standard session
or a standard reverse shell, we can upgrade that
into a Meterpreter session.
So I'll search for the module ssh login,
and we'll use the first one.
That's the auxiliary module, so we
can say use 0 and show options.
So there's a few options that we need
to set-- the username and the password
because we're not performing a brute force.
I'm going to say username is vagrant,
as that's the only account that we can log in with.
And the password is also vagrant.
And then we need to set up RHOSTS option.
That's the target IP.
So I'll say set RHOSTS.
Paste in the target IP.
And then we have a few other options that we can configure.
And of course, we're not performing a brute force.
What we can do is, do we have the password file and the user
files set?
No, those are all on set, so that's good.
And we can just hit run.
And in this case, it looks like we were able to log in.
And it opens up an SSH session.
So there we are, SSH session 1 open.
So if I say sessions, you can see we get a standard shell.
So I can say sessions 1, and you can see that works out
I believe just fine.
Indeed it does.
So I'll put this in the background using Control and Z.
And we still have the session active,
so I can upgrade this possibly to a Meterpreter session
by saying sessions upgrade session ID, which is 1.
Hit Enter.
And it looks like it's saying the target is
running on an unsupported architecture such as Windows
ARM.
So again, that makes sense because the actual shell
that we have access to right now will not allow us to do that.
So another technique that we can utilize
is, of course, the ability to generate a payload
with MSFvenom-- a Meterpreter payload,
and then transfer it over to the target system via our SSH
access.
So I can say sessions 1.
And we can then download it to the target system.
Execute it.
And that will consequently provide us
with a Meterpreter session.
But as I said, that's not really necessary at this step
because we've already gained access to the target system.
So if we try and log in again here,
I'm just going to say vagrant, and that will give us access
to the target system.
And we can navigate around the file system.
Although, we are going to be limited in
regards to what we can do because we are currently
using the vagrant user.
That is a non-privileged user account.
So that is how to gain access or how
to target the OpenSSH service.
Now, if you want to obtain a standard Windows command
session or command shell--
your typical Windows CMD session, that
can easily be done by saying bash, and you hit Enter.
There we are.
So that will open up your CMD, and you can now
run Windows command.
So net localgroup administrators, just
to verify that this user is not a part of--
or is actually a part of the local administrators
group, which means that at this point,
if I say whoami and privs--
sorry, that is whoami.
Let me just type that in correctly-- whoami
privs or priv.
There we are.
So it looks like we have the following privileges,
but they are all disabled apart from a couple of them.
And in terms of elevating our privileges,
we would typically need to bypass UAC or utilize
another privilege escalation technique.
And this is something that we'll be
exploring within the post-exploitation course.
But for now, you can see that the current user is
unprivileged, but we're still been able to get access
to the target system and even though this
is to an unprivileged user at this point.
With that being said, that is going
to conclude the practical section or demonstration
side of this video.
All right.
In the next video, we're going to be taking a look at how
to target the SMB service or SMB server that's
running on the target.
So we're going to be exploring multiple techniques, not just
limited to your standard authenticated command
execution techniques that involve already
obtained credentials.
We'll explore a few other techniques
that can be used to exploit the target via SMB
and consequently gain remote access.
So I'll see you in the next video.