Welcome to the Linux persistence section of this course.
In this section, we're going to be exploring
the process of establishing persistent access
or on or to a Linux system that you have compromised.
In this specific video, we're going
to be exploring the process of establishing persistence
via the use of SSH keys, right?
So before we actually get started
with the practical demonstration, let's
get an understanding of how SSH this works in terms
of authentication, right?
And when I'm making a reference to persistence via SSH keys,
if you have never used or configured
as I say to yourself, then you might be a little bit
confused, right?
Now, in order to understand this,
we need to understand where Linux is typically deployed
and how SSH is typically used, right?
So Linux is typically deployed as a server operating system.
And I'm specifically referring to the deployment
within an enterprise or corporate environment.
I know that you can install Ubuntu as a desktop operating
system.
I know you can use Linux as a standard desktop or laptop
operating system without any problems.
However, in a corporate or enterprise environment,
Linux is typically deployed as a server operating system
to host specific web applications, databases,
services, et cetera.
As a result, Linux servers are typically
accessed remotely via services or protocols, such SSH.
Now, I'll give you an example here.
Let's say you've been assigned to perform a penetration
test on a client's network.
And in addition to the actual client's network,
they also provide you with details regarding
their public-facing infrastructure,
like their website as well as a few web applications that they
host for their customers.
And these web applications or websites
are going to be typically hosted on a Linux server, right?
So that is public-facing infrastructure.
Now, if we exploit that web application that's
being hosted, and we gain access to that Linux server,
then what happens here is we've compromised
a part of the company's digital infrastructure.
But that's really not part of the internal infrastructure,
right?
So that server is essentially exposed to the internet,
whereas the internal systems are part of an internal network
and may not or really cannot be accessed externally or via
the internet.
That's perfectly fine.
Now, given the fact that Linux servers are typically deployed
or Linux is typically deployed as a server, that
means that in most cases, the server
is either going to be deployed on the Cloud,
on AWS or Azure or Linode, for example,
or it could be deployed on a company-owned data center
somewhere around the world.
And as a result, in order to access
these Linux servers remotely, the protocol of choice
is going to be SSH.
So whenever you compromise a Linux system,
I can almost guarantee that if it's public-facing,
you are going to have SSH running on that target system,
right?
Now, if SSH is enabled and running on a Linux system
that you have compromised, you can
take advantage of the SSH configuration
to establish persistent access on the target system.
And you might be a little bit confused here.
You might be thinking to yourself,
well, OK, SSH authentication utilizes a username
and password combination.
Well, in addition to a username and password combination,
SSH can also utilize key-based authentication, whereby
the end user or the person wants to connect
to the Linux server via SSH does not
utilize a username or password.
They instead utilize a private key, right?
So the way this typically works is
let's say I am a system administrator,
and I've been told to set up a Linux server.
And I'm the only one who should have access to that server.
And I don't want to utilize password-based authentication
primarily because of the threat of brute force attacks.
Well, I can generate an SSH key pair, right?
And I can then transfer the public key onto the Linux
server and consequently use my private key for authentication
with that server.
The caveat here is that the individual with the private key
can log onto that target system.
Without the private key, no one can get in.
So even if I lose it, I pretty much cannot get in unless I
actually physically head over to the system,
and then reconfigure or change the password manually.
So nowadays, you'll typically see
that Linux servers will have key-based authentication
enabled for the SSH service, which
allows users to access the Linux system remotely
without the need of a password.
So after gaining access to a Linux system,
we can transfer the SSH private key of a specific user account
onto our system and use that SSH private key
for all future authentication and access.
The objective here is to try and see
whether we can find any private key that is already
available on that Linux server.
And we can then transfer it to our system
and use that private key for authentication
to the Linux system.
And this is important in the context of persistence
primarily because a user account password can be changed,
which means if SSH authentication to the Linux
server utilizes a password as well
and if the user account password is changed,
then you're going to be locked out.
However, if you have the private key,
then you essentially maintain access to the target system.
Now, as I said, you might be a little bit confused
when I gave you an example of me setting up an SSH key pair
and saying I transferred the public key onto the server,
that's just one example.
In most cases, you can also generate a new key pair.
And you can also transfer that public key onto the Linux
server that you've compromised and use the private key
that you've generated.
Alternatively, you can also find,
in some cases, private keys that have been stored on that Linux
server to access other servers, and so on and so forth.
This video has a lab environment attached to it,
so all you need to do is just fire it up.
Now, the way we're going to be going through it, this lab
environment is set up in a way where
we are going to be provided with a terminal-based Kali Linux
system.
And then we need to log in to the target system via SSH.
Therefore essentially simulating the stage of exploitation.
Once you have gained access to the target system,
we can identify the private key, transfer it over
to our Kali Linux system.
And I'll then take it from there and show you a few really cool
things that we did in the lab environment
to show you what can happen if the user account
password that you have compromised
or the user account that you compromised
has its password changed.
So I'll see you in the lab environment.
All right, so I'm back within the lab environment.
And as you can see, we are currently
on the Kali Linux system.
That, of course, is denoted by the root@attackdefense here.
So the first step is going to involve
identifying the target IP address, which we
can do by typing in ifconfig.
There we are.
And we take a look at the interface ethernet 1.
This is our Kali Linux IP.
In you case, it's going to be different.
All you need to do is just copy this value here and change
the two to a 3 at the end.
And that's the target IP address.
So once that is done, we can actually
log onto the target system via SSH.
So this is going to essentially simulate the exploitation
phase.
And again, the reason we are doing it this way
is to showcase how SSH works in addition
to showing you how you can establish persistence
through SSH keys.
So we can say SSH.
And let's say we compromise the student account.
So I'm going to say ssh student@--
I'll paste the target IP.
Remember to change the 2 to a 3, and we can hit Enter.
The password for the student account
is just password, so do keep that in mind.
I'll hit Enter.
And you can see, we have logged on as the student account.
The operating system or distribution is Ubuntu,
and the distribution release version is open to 18.04.2 LTS.
The actual hostname of the system is victim-1.
All right?
So let's clear that out.
And let's list out the contents of the student's home
directory.
So if I list out the contents of the home directory,
you can see that we have a few folders here, right?
So you have the ssh folder.
This is the dot configuration folder.
And we have a binary here called wait.
Now, I'll explain what this binary does.
This was set up to show you or to simulate
what would happen if the user account password was changed,
right?
So if I kept the contents of the wait binary,
you can see that will say delete this file
to trigger the connection reset.
And it says delete it only after planting the backdoor.
So we essentially going to be doing that.
So once we're done, we will delete the actual wait binary
here.
And that is going to change the student account's password
to simulate the fact that the account's password has
been changed.
After which, it will also display a flag for us here.
All right?
So what we need to do now is if we take a look at the ssh
directory, so I'll say cd ssh.
Within this directory, we have the private key here.
All right?
So whenever you generate a key pair,
if it's generated on the system, whenever you generate
an associated key pair, you'll have the private key
and the public key.
So this is the private key here because when you generate a SSH
key pair with ssh-keygen or the ssh-keygen utility,
it'll generate two files.
One of them is going to be called id_rsa.
That's the private key and id_rsa.pub or dot public,
which is the public key.
In this case, we're able to see that we
have a private key here, right?
And if we cut out the content of the private key,
you can see it says this is the content of the private key.
So it says begin RSA private key and end RSA private key.
Now, if we list out the other contents within this directory,
we also have the authorized keys file,
which contains the authorized keys for specific private keys,
et cetera, which by this point, you should already know.
So what we need to do is we need to copy this id_rsa private key
onto our system.
So how can we do this?
Well, we'll go back into our Kali Linux system here.
And we can utilize the scp utility,
which allows us to download a file
or to transfer a file from the target system
to our Kali Linux system via SSH.
So we can say scp student@, and we paste in the target IP.
I'll change the 2 to a 3 there, and then we
use a colon to specify what file we want to download.
So we're downloading the file from the home directory
of the student account.
So we use the tilde icon, forward slash dot ssh.
That's the directory.
And we're downloading id_rsa.
And we want to download it or copy it into this directory.
So I'll use the full stop there.
Hit Enter.
It's going to ask us for the student's password.
So that is just password.
Hit Enter.
And you can see transferred successfully.
We should now have it on our Kali Linux system.
There we are, id_rsa.
And we can now provide it with the necessary permissions
that you typically associate with a private key, which
is chmod 400 and id_rsa.
All right?
So now that is done, what we can do
is we can log back into the system via SSH.
So I'll say ssh student at the target IP
and log in with a password now.
And we can get rid of the wait binary, right?
So we can say remove wait.
Now, before you remove this binary,
make sure you've downloaded the private key, as this will
essentially reset the connection and change the student
account's password, essentially preventing you from logging in.
So I'll say remove wait.
And after a few seconds, you'll see that the connection
will be reset.
There we are.
So we try and log in again with the same credentials.
So ssh student at the target IP, and I type in password.
You will see that password is not working anymore.
So this will set up to simulate what
would happen if you gained access to a Linux target
system.
And if you didn't set up assistance,
then you would essentially be locked out.
So it really doesn't matter what you exploited initially to gain
access to the target system.
After you gain an initial foothold,
always be sure to make sure that you can always gain access,
or you can always access the target system whenever you want
or have persistent access to that target system.
But it really doesn't matter because we
copied the private key.
So to log in with the private key
without providing a password because we
don't need to know what the new student user accounts
password is, if we have a private key, we can say ssh,
and we say -i and specify the name of the private key, which
is id_rsa.
We then say student@ and specify the target IP or change the 2
to a 3.
Hit Enter.
And we're logged on to the target system
without providing a password.
It doesn't matter whether the user account
password was changed.
We pretty much have access.
So this is something that, again, is quite important.
Now, as I said, this really isn't the typical flow
that you would utilize if you are trying to essentially set
up assistance via SSH keys.
What you would ideally do is you would generate an SSH key pair
on your Kali Linux system.
You then keep the private key on your Kali Linux system
and transfer the public key onto the target system in the home
directory of the user account in the ssh directory,
and you add it under authorized keys, right?
So that's typically how you do that.
And there's multiple ways you can do that.
But as I said, this lab environment
was there to show you how dangerous a private key is
because a private key is essentially
like a key to a-- it's like a master key to a huge locking
system, and it essentially unlocks everything.
And the best part about this is we
don't need to know when a user account password is changed.
We don't need to know what the new password is.
We pretty much gain access to the target system
whenever we want.
So again, if we ever tried to access it
without the private key, it'll ask us for the password.
And because we don't know the new password,
it'll tell us that that password is incorrect.
However, if we have the private key,
we gain access whenever we want.
So if I list of the contents of the student's home directory,
you can now see that we have the flag file here.
So I'll just get the flag, which confirms that we've
completed this lab environment.
All right?
So that is going to conclude the practical demonstration
side of this video.
All right, so that was how to establish persistence
via or through the use of SSH keys.
We are now going to move on to the next persistence
technique within this section.
And that is going to involve establishing persistence
through the use or through the actual
or taking advantage of cron jobs and the cron
functionality, where we can essentially
have a reverse shell.
We can essentially establish or set up a reverse shell
and have it connect back to our listener
during or at a specified duration.
And we can customize the schedule for that.
So I'll be seeing you in the next video.