[MUSIC PLAYING]
Establishing Persistence on Linux-- in this video,
we will be exploring the various techniques and models
that we can utilize to establish persistence on a Linux target
once we have gained access and elevated our privileges.
So again, this is going to be very similar to the Windows
video where we explored the process of establishing
persistence on Windows.
And of course, in this case, we will
be exploring some of the best techniques
that you can utilize when it comes down to, again,
ensuring that you have persistent access on a Linux
target.
So again, persistence essentially
consists of techniques that adversaries or attackers
use to keep access to systems across restarts, change
credentials, and other interruptions
that could cut off their access.
So once we've obtained an initial foothold
on the target system, that's really not enough,
because at any given point in time,
our connection could drop.
Or the credentials that we use to gain access
could be changed.
Or the system could be restarted,
or the system could be shut down.
And furthermore, if we gained access through the use
of or via exploiting a vulnerable service and that
service is then patched or fixed,
then that would essentially mean that we cannot access
the system again.
So once we've got access to a target system,
we need to ensure that we will continue
to have access to the system.
And that, of course, is facilitated
through persistence.
Now, the persistence techniques that we can utilize
will depend on the target configuration.
And this is more so in the case of Linux targets
because when you're talking about Linux targets,
there's going to be a lot of configuration
differences between Ubuntu, Debian,
as well as Red Hat, CentOS, fedora, et cetera.
And in terms of the techniques that we will be utilizing
or that we can try to utilize, we
need to be very cognizant of what distribution release
version is running on the target as well
as important information like the init system being used,
so on, and so forth.
So we can utilize various post-exploitation persistence
modules to ensure that we always have access
to the target system.
And we'll also be exploring some manual techniques
that we can utilize.
And of course, this is primarily in the case of Linux targets.
All right, so as for the lab environment,
we're going to be utilizing the same lab environment
we utilized when we were elevating our privileges
on a Linux target.
So we'll be gaining access via the SSH credentials.
We'll then elevate our privileges
via the chkrootkit vulnerability, after which we
can take a look at how to establish persistence
on that system so that we can have access to it whenever
we want to essentially.
So I'll start up the lab environment.
And I'll see you within the lab environment.
And we can get started.
All right, so I'm back within the lab environment.
And of course, the first step involves identifying the target
IP address.
So we can type in ifconfig, head over to the interface ethernet
1, and we just copy this.
And of course, the target IP is going
to be on the next IP address within the subnet.
So it's going to be the third IP.
So just copy that.
We will then say service Postgresql start.
And we'll also start up a msfconsole
as we will require the Metasploit framework
database in this case.
So there we are.
That's going to start the PostgreSQL database server.
It's then going to start up msfconsole for us, after which
we can create a workspace.
And in this case, I'm just going to call this Linux_persistence.
There we are.
And we'll set the global variable for the RHOSTS option
to the target IP.
So again, remember to change the 2 to a 3.
And we hit Enter.
And again, in this case, or as we explored previously
within the Linux privilege escalation video,
the lab documentation already provides us
with the SSH credentials that we can use to gain access.
So we will search for the SSH login module.
There we are.
And we can then say use.
Paste that in there.
And the only options that we need to specify
are the username and the password
because we already have them.
So I'm going to say set the username to Jackie
and set the password to "password."
And then we can hit Exploit or Run.
That is going to open up a command shell for us.
So if we type in sessions, you can
see that we get a command shell with the credentials we
specified.
We can upgrade that session into an meterpreter session
by saying sessions upgrade and then specifying
the actual session ID.
So we hit Enter.
That's going to give us a meterpreter session.
So we'll give that a few seconds.
All right, so we get a meterpreter session.
And that's going to be sessions 2.
And the privileges that we obtained
are still going to be the user Jackie.
So we need to elevate our privileges.
And of course, we have explored the process
of elevating our privileges within this lab environment.
And that is via the chkrootkit utility.
And primarily, what we're going to be doing is exploiting
a vulnerability within chkrootkit 0.49,
or versions prior to 0.50.
OK, so what we'll do is we will search for chkrootkit.
And we'll hit Enter.
And of course, this is the module right over here.
So we'll say use.
Paste that in there.
Show the options.
And we will set the session to session 2.
And we also need to set the path, the actual path,
to chkrootkit by saying set chkrootkit.
And we'll say /bin/chkrootkit.
We can then, of course, set the payload options.
And if we just hit Exploit, for example,
you can see that that will start up on--
it'll actually provide us with the ability
to modify the payload options.
So the default payload is the CMD Unix reverse payload.
We can set the LHOST option.
So I'll say ifconfig, and we'll copy our IP address there.
And we'll say set LHOST to the value of Ethernet 1
or the actual IP on the Ethernet 1 interface.
If we show the options again here,
you can see we also can configure the LPORT.
So we list out our sessions just to make sure
that we actually aren't conflicting
with any other sessions.
You can see that these sessions are not utilizing port 4444.
So that's good.
So we can hit Exploit.
And that's going to take a few seconds to probably a couple
of minutes because it's going to wait for the cron job
to execute which will consequently give us a command
shell, which we can then upgrade to an meterpreter session.
So we'll give this a few seconds.
All right, so after a few seconds,
we get the command session here.
And of course, we can cat out the contents of the flag,
but that really isn't necessary at this point.
What we'll do is we'll put this in the background.
And if we list out our sessions, we
want to upgrade session 3, which is
privileged, or that we currently have access to as the root
user.
We will say sessions 3.
We want to upgrade that.
So we'll say sessions upgrade 3.
And that'll give us a meterpreter session
with root privileges.
So we'll give that a couple of seconds as well.
There we are.
meterpreter session 4 opened.
So we say sessions.
You can see that we have two meterpreter sessions.
One of them is utilizing the user Jackie,
or one has access as the user Jackie, which
is an unprivileged user.
We then have the meterpreter session 4 here,
which has access with the root user or has root privileges.
So if we say sessions 4 and we say get user ID,
you can see we are currently the root user.
And that, of course, we actually determine that
through the user ID, which is set to 0.
Of course, we can say shell and then /bin/bash -i.
And if we say whoami, you can see
we are currently root, right?
So in order to essentially establish persistence
or in order to utilize some of the persistence modules
for Linux, you will require root privileges in most cases.
OK, so we can put this.
We can terminate that.
And we can head back into our meterpreter session.
The first technique we are going to be exploring
is a manual technique.
And it is the technique or the process
of creating a backdoor user that can provide us with access
whenever we require it, right?
Now, this will only work if the target server is running
SSH or a remote access protocol that can provide us with access
whenever we need access.
Consequently, the protocol should also
be able to provide us access, primarily
through a username and password.
So in order to create a backdoor user,
we can open up a shell session here.
And I'm just going to say /bin/bash -i.
And we currently have root privileges.
And we list out the current users on the system.
So if I say cat /etc/password, you can see that we have
the user Jackie.
We also have the user root here.
And the rest of them are service accounts.
Now, when it comes down to creating a backdoor user,
the first thing that you need to take into consideration
is the fact that the user should not or should
be as clandestine as possible and should blend in.
So what I would typically recommend
is actually providing the user name or the account username
as something as a name that is really
very difficult to identify.
So what you don't want to do is create a user or a backdoor
user with the username set to act or backdoor
access or backdoor or anything like that.
What I would recommend doing is creating
a user account that sort of looks like a service account,
right?
So what we can do in this case is we can say useradd.
And we can create a home directory
because I'll also be exploring the technique of creating
or setting up a SSH key so that we can authenticate to the root
user as well as other users without providing a password.
So I can say useradd -m.
And we'll just call this user FTP, right?
So we can make the account look like the FTP service account.
And again, make sure that an account
called FTP doesn't exist.
And in this case, it doesn't.
And then we can specify the shell as bin/bash.
Now, if you're utilizing or if you're
trying to make it as clandestine as possible,
then you probably want to set the actual terminal
session or the actual terminal for that user account
as user/sbin/nologin, because that's primarily how service
accounts are configured.
And of course, we can also specify the actual home
directory for this particular account.
But in this case, we'll leave it as the default.
And again, you can also say useradd -m.
So that's to create the home directory.
And then we can either say the home directory is
in /var/www/HTML, for example.
And that makes sense in the case of FTP.
So we can say useradd -m.
We'll just call the user FTP.
And then the shell, in this case, we'll just say bin/bash.
And we hit Enter.
So that's going to create the user.
We can then say passwd FTP to create a password for the user.
And we'll say password123 just to keep things simple.
Of course, I would recommend using something a little bit
more complex than that.
And we hit Enter.
And now if we say cat /etc/passwd,
you can see that we have the FTP account here.
And it actually looks like a service account.
And it blends in quite well.
Now, the other thing that I would recommend doing
is actually providing the FTP user account
with administrative or root privileges.
Right now, if I list all the groups
that the root user is a part of, you
can see it's part of the root group.
So if we add the FTP account into the root group,
then it will inherit the permissions associated
with the root group, which pretty much gives us
a root access, right?
So we can say usermod add group, and then we
say root and then the account that we
want to add to the actual root group.
In this case, we'll say FTP.
We hit Enter.
And now if we say groups FTP, we can
see that FTP is part of the root group.
So what we can do now in this particular case
is utilize this backdoor user to essentially authenticate
legitimately to the target system via SSH
whenever we need to gain access to the target system.
And of course, we're going to have administrative privileges
because we've just added the user account to the actual root
group.
All right, so that's one manual technique
that I would really recommend.
Now, of course, there's plenty of other techniques
that you can explore that we can also take a look at right now,
like the process of creating a persistent service or a cron
job, or my personal favorite, which
is adding an SSH key to the actual SSH
directory within the user's home directory for the user
accounts, like the root user as well as Jackie or FTP.
You can also modify the backdoor user's user ID
to make it look like it just wasn't created
or that it just was created a few seconds or a few minutes
ago or recently, because you can see that the accounts that
have just been created will get a user ID right over here.
That, of course, reflects the fact
that it was actually created the most recently
or was actually created recently.
So in order to do this, we can say usermod and then specify
the user ID that we want.
And in this case, we can say maybe a user ID like 15
and then specify the account name.
And now if we say you know cat /etc/passwd,
you can see that it now has the use ID of 15.
And then, of course, we can modify the actual group
that it belongs to or the actual group ID to,
of course, reflect that.
But in this case, we're really not going to get into that.
But again, the whole objective here
is to make the user account look as clandestine as possible
in order to avoid detection.
All right, so let's take a look at some of the persistence
modules that we can use for Linux targets.
So I'm just going to terminate this channel.
And I'm going to put the meterpreter
session in the background.
And we can then say search.
And the platform, in this case, is Linux.
And then we can just say persistence.
All right, so you can see that we have quite a few persistence
modules.
And they all utilize or leverage various elements
or various features within the Linux operating
system or the Linux kernel in order to establish persistence.
So you can see you have persistence via the Aptitude
Package Manager.
So we can try that out.
And of course, I'm not going to be going through all of them.
As I said, it really is important
that you, again, test them and understand
how your target is configured.
So we can copy that, and we can say use
and paste that in there.
Show options here.
And in this case, what we'll need to configure
is the actual session ID.
We can also specify the HOOKNAME and the backdoor name,
which is the name of the binary to write.
And in order to learn more about this particular module,
we can type in info.
And as you can see, it says "this module
will run a payload when the package manager is used.
No handler is run automatically, so you
must configure an appropriate exploit handler or multi
handler to connect."
Now, as I said, this is really not what we're looking for.
Because, again, we always want to have access
to the target system.
And we don't want to rely on instances or situations that
involve the execution of elements or utilities
like the package manager.
So I'm not going to be utilizing this particular module.
So we can say search and again list out
the assistance modules.
The one that I recommend testing out
is going to be the cron persistence module, which
allows you to set up a cron job that, again, will continuously
connect to your handler.
And of course, again, this is entirely up to you.
But in my case, this is probably my second recommended module,
primarily because cron jobs can easily
be detected by administrators on the system.
And if it looks suspicious, then of course,
they can get rid of that cron job.
And it may, of course, indicate compromise.
Or it may be an indicator of compromise.
So you want to be very, very assured
of what module you're using and the effects
and artifacts that it'll actually
leave on the target system.
So if I say show options, you can set the timing.
And in this case, the default timing option
is set to be executed every 60 seconds, or every one minute.
And then of course, we can set the session as well as
the username to run the cron or cron job as.
So I'm going to say set session to 4.
And we can then hit Run or Exploit.
We're going to hit Enter.
And in this case, it says a fail to open /etc/cron.allow,
/etc/cron.deny, et cetera, et cetera.
And then it says waiting 90 seconds for execution.
All right, now if we terminate that and show the options
in order to take a look at what payload is being used,
you can see that the payload being used in this case
is CMD Unix reverse Perl.
And if we list out our sessions, what we can do
is make sure that there isn't a conflicting LPORT here.
So we'll say LPORT is 4422 because it's
conflicting with our command shell.
And we'll set the LHOST to the IP on Ethernet 1.
So I'll say set LHOST.
And then we can hit Exploit.
And let's see whether this works.
Now as I said, this is not a guaranteed in terms of Linux.
On Windows, you have a better chance,
or you have actually a greater chance of success.
Because, again, Windows systems are fairly similar in
regards to the persistence techniques
that you can utilize.
However, with Linux, cron jobs, or you
may not have access to the actual crontab file.
As I said, you also want to be wary of the fact
that this could be detected quite easily.
So let's see if this does work.
I'm just going to wait for about 90 seconds
to see whether it'll actually execute the Cron job.
All right, so after about 90 seconds,
it looks like the actual payload or the module doesn't work.
And it says removing the cron entry from
/var/spool/cron/crontabs/root.
And of course, we can also test this out.
But in this case, it looks like it didn't work.
So I will need to take a look at some of the other persistence
modules that we can use.
Now, as I said, this may work on a different target.
But in this case, it didn't work.
And it's very important that you understand
how to utilize the other modules or rather the other techniques.
All right, the other one that we're going to be exploring
is similar to the Windows technique or the Windows module
that we used, which is through a persistent service.
So I'm just going to copy that.
And we're going to say use.
Paste that in there.
Show the options.
And we can specify the actual shell path, which in this case,
we know the shell path is probably under /usr/local/bin
or /usr/bin.
So we'll leave that as is.
And then you can specify the name of the shell file
to write, and then we can specify the actual session.
So I'm going to say set session to 4.
And then we hit Exploit.
And it'll probably tell us that we haven't selected a payload.
So we'll say set payload.
And we can use the Tab auto completion
feature to specify the payloads that we can actually
use in this case.
So we can utilize CMD Unix bind netcat reverse net cat
or reverse Python, reverse Python SSL.
So let's try out the reverse Python payload here.
And if we show the options, you can
see that we need to set up the actual LHOST and LPORT options.
So I'm just going to say set LHOST or the LPORT option
to actually the other port that we identified that was
currently open, which is 4422.
And we're going to hit Exploit.
All right, so as you can see, this fails here.
This particular module, if we type in info,
will essentially try and create a service on the box
and mark it for auto-restart.
We need enough access to write these service files
and potentially restart services.
The target init systems or the init systems
that this will work on are System V and also systemd.
And then it provides you the actual versions
of these distributions that this will actually work on.
So in our case, the system is running Ubuntu 18.04.
And in this case, as you can see,
the only versions you can see supported here
are Ubuntu 15, anything greater than or equal to Ubuntu 15.04.
However, in this case, it didn't work.
All right, so again, these are the init systems
that it will try and use.
So we can also say set target to systemd.
So let's try systemd and hit Exploit.
As you can see, it says exploit completed.
But no session was created.
So we can set the target maybe to systemd user just
to see if that works.
And as you can see in this case, it
doesn't look like it's working.
All right, so let's take a look at the model or the technique
that I recommend whenever it comes down to establishing
persistence on a Linux system.
And the reason for that is fairly simple.
Whenever we set up persistence, we also
want to be as clandestine as possible
in regards to actually being detected.
Now, the module that I'm referring to here
is the post exploitation module called SSH key persistence.
Now, the way this module works is it
will essentially set up a private and public SSH key pair
and will add the actual public key into the home directories
of all the user accounts on the system
and will then provide us with the private key.
And we can utilize that private key
to authenticate to any of the user accounts on the system
without providing a password.
So again, we never want to change the passwords
on the system in regards to the user account.
So again, we also have the ability
to change the root user password.
But again, that would be a very strong indicator of compromise.
So what we'll do is we'll say copy,
and we'll paste that in there.
We'll show the options here.
And we need to configure a few things.
One of the things we need to configure
is the Create SSH folder, which we want to set to true.
Because in some cases, the target system
may not have the SSH folder already created.
We then need to set the actual session here to session 4,
in our case.
And we can also specify the username or the user
to add an SSH key to.
By default it will add all users on the box,
which is what we want because we created the FTP user account.
And we also want this to work for the root user as well
as Jackie and the FTP account.
So again, to learn more about it, we can type in info.
As you can see, this module will add an SSH key
to a specified user or all to allow remote login via SSH
at any time.
Which is great, because again, this is very difficult
to detect because the SSH public key that's
been added to the home directory of the users
is something that is not frequently accessed
by the users on the system.
And again, this really doesn't leave any indicator
of compromise in regards to the process tree
or any other artifacts apart from the fact
that a system administrator can actually view
who is currently logged on.
But if we log in as the root user,
then that may not be suspicious at all.
Because, again, if they're logging as the root user
and we log in as the root user, then again,
we might be able to again avoid detection.
So what we'll do is we will hit Exploit.
And I'll just show the options just
to make sure everything is configured correctly.
And we'll say exploit here.
All right, so because we specified the module
to run or to create the SSH directory
or folder for all users as well as add the actual public key
to all the user account's home directory,
it will actually do that.
So it'll actually add the public key
to the authorized keys file under the home directory
under SSH and authorized keys.
And it does that for all user accounts as well as,
in this case, the FTP user.
So we can identify.
As you can see, the private key here
will be saved within the following directory.
And it provides us with the actual file name.
So we can say loot to access the private key.
As you can see, this is a OpenSSH Private Key.
So we can cat the contents of the file.
I'm just going to say copy, and I'll say cat.
Hit Enter.
And there's the private key here.
All right, so you may be asking yourself, well,
how can we utilize this to gain access to the target system?
Well, we just need to copy it.
And I'm going to terminate all my meterpreter sessions or all
the sessions that I have active on the target.
And I can just say exit yes.
That will terminate everything.
And we're back within the actual terminal.
We're not working within MSF console.
I'll create a within my current working
directory called SSH_key.
And I will paste in the private key here.
And I'll write in quit.
And I'll then provide it with the appropriate permissions
for an SSH private key.
So that's chmod 0400 ssh_key.
And then we can authenticate to the target
system via any user we want via SSH page, of course.
So I can say SSH.
We specify the key, the actual private key,
using the -i option.
And in this case, we'll say SSH key.
And then, for example, I can say root@ and then I specify
the target IP address, right?
So we actually need to identify the actual target IP.
So I'm just going to type in ifconfig.
And we know that it's on the third IP
address within the subnet.
So I'll say ssh -i ssh_key root@.
Paste in the target IP.
Remember to change the 2 to a 3.
Hit Enter.
It's going to say whether we want to accept.
We're going to say Yes.
And voila, we are logged in as root.
And we didn't have to provide the root password.
So we're not changing the root password.
We're just gaining access via SSH key authentication, right?
So that really is fantastic.
And now we have, again, access via a typical terminal
or a typical Linux command shell.
And of course, we can go through the process of upgrading this
if we wanted to.
But for continuous or for persistent access on the target
system, this is a fantastic technique
because we're not creating a service.
We're not creating a cron job, et cetera.
So again, I can say exit.
And if we try and log in to the user FTP here, we can say FTP.
hit Enter.
It's going to ask us for the user FTP
password, which we created.
So password123.
Hit Enter, and we gain access to the FTP user--
fantastic.
All right, so that is going to conclude
the practical demonstration side of this video.
All right, so that concludes the Linux post exploitation section
of this course.
In the final section of this course,
we will be exploring the Metasploit graphical user
interfaces.
More specifically, we will be taking a look
at how to utilize Armitage for information
gathering, port scanning, and enumeration,
as well as exploitation and post exploitation.
So I'll see you in the next section.