[LOGO WHOOSHING]
Windows Privilege Escalation: Token Impersonation
With Incognito.
In this video, we are going to be exploring
the process of elevating our privileges on a Windows system
through the use--
through the technique of impersonating access tokens,
and this will be facilitated by an inbuilt meterpreter
module called incognito.
Now, before we can actually get started
with token impersonation, we actually
need to understand what a Windows access token is
and how it's used, why it's used,
and how we can abuse Windows access tokens to elevate
our privileges.
So, first and foremost, what is a Windows access token?
Well, a Windows access token is essentially
a core element of the authentication process
on Windows, and they are created and managed
by the Local Security Authority Subsystem Service, also known
as LSASS.
So if you've ever opened up the Task Manager on a Windows
system and headed over to the Services tab,
you might have noticed a small service
or a service called lsass.exe running.
So that is the Local Security Authority Subsystem Service.
And that service is essentially responsible for creating
and managing Windows access tokens on Windows.
So our Windows access token is essentially
responsible for identifying and describing
the security context of the process or thread running
on a system.
Simply put, an access token can be
thought of as a temporary key akin to a web cookie that
provides users with access to a system or network resource
without having to provide credentials
each time a process is started, or a system resource
is accessed.
So the reason Windows access tokens
are implemented into Windows is to essentially eliminate
the process of having a user to essentially enter
their password or their credentials
whenever they want to start a process
or whenever they want to start a program.
Right now, the way this is done is whenever you authenticate
successfully to Windows, you will
have an access token generated by the winlogon.exe process.
And the access token will essentially
include the user identity or the user account,
as well as the privileges associated with that account.
So this token is then attached to the userinit.exe process,
after which all child processes started by a user
will inherit a copy of the access token from their creator
and will run under the privileges of the same access
token.
So let me just give you a simple example here.
So if we didn't have Windows access tokens implemented
within Windows, what would happen
is, whenever you log on to your Windows system,
you would essentially type in your username and your password
and log in.
And then whenever you wanted to start up
a program like a simple user LAN program like your browser
Firefox, Google Chrome, et cetera,
you'd also have to enter a password or your username
and password combination to start it up because again,
whenever you're working with privileges and permissions
on an operating system, you need a way
of essentially implementing access control.
But this is really not associated
to use access control.
In this case, what you're trying to do is set up
the actual privileges and the security context of a process.
So whenever you start up a program,
you would essentially have to enter your username
and password.
Now Windows access tokens, or where they come into play here
in terms of authentication, is whenever you log in to Windows,
the winlogon.exe process will generate a Windows access
token for you.
And that Windows access token will essentially
contain your user account.
So your user identity, as well as the privileges
associated with that particular user account.
That token is then going to be attached
to the userinit.exe process, which
is used to start up processes or programs for a particular user.
So all child processes started by the user
will then inherit a copy of the access token from their creator
and will run under the privileges of the same access
token.
So, that way, the processes that are running
under the privileges of a specific user
can be identified, and they're kept separate.
So it's really, really-- is a vital part
of the Windows operating system and a core element
of the authentication process on Windows.
Now, let's explore a little bit about how Windows access
tokens are sorted.
Now Windows access tokens are categorized
based on the varying security levels assigned to them.
So these security levels are used
to determine the privileges that are
assigned to a specific token.
So an access token will typically
be assigned one of the following security levels.
You have the impersonate access tokens as well as the delegate
access tokens and will actually take a look at them
when we have access to the target system.
So the impersonate-level tokens are
created as a direct result of a non-interactive login
on Windows, typically through specific system services
or domain logon.
So whenever you see an impersonate access token,
they have typically been created as a direct
of a non-interactive login.
You then have your delegate-level tokens,
which are created through an interactive login on Windows
primarily through a traditional login using the Winlogon
process or through remote access protocols like RDP.
So whenever you see a delegate access token,
again, you should know that they were
created as a direct result of an interactive login on Windows.
Now, in terms of how we can abuse them,
impersonate access tokens can be used
to impersonate a token on the local system and not
any external systems that utilize the token,
whereas delegate-level tokens pose the largest
threat as they can be used to impersonate tokens
on any system.
So this will all make sense once we actually
get onto the target system.
Now, before we actually get started
with the practical section, we need to understand or get
an idea of the privileges required in order
to impersonate an access token.
So the process of impersonating access tokens
to elevate privileges on a system
will primarily depend on the privileges assigned
to the account that has been exploited
to gain initial access, as well as the impersonation
or delegation tokens available.
What this means is that, in order
for us to elevate our privileges through token impersonation,
we need to have the following privileges assigned
to our account.
Furthermore, we also need to have
impersonation or delegation tokens available on the system
that we can use to impersonate.
So the following are the privileges
that are required for a successful impersonation
attack.
We primarily need the SeImpersonatePrivilege.
So this privilege essentially allows a user
to create a process under the security
context of another user, typically
with administrative privileges.
So the SeImpersonatePrivilege will essentially
allow us to impersonate the access token of another user
account.
And we already explored how to enumerate
the privileges assigned to our current account
and with meterpreter as we did previously.
That can be done by typing in the get privs command,
and that will essentially list out whether or not
you have the SeImpersonatePrivilege assigned
to that particular user account.
And of course, we'll explore this as well.
Now, we I briefly mentioned the incognito module because this
is the meterpreter module that we are going to be utilizing
to essentially list out the available access tokens that we
can impersonate, and it will also
facilitate the actual impersonation process.
So incognito is a built-in meterpreter module
that was originally a standalone application
and allows you to impersonate user tokens
after successful exploitation or once you've gained access
to a target system.
So we can use-- we can utilize the incognito module to display
a list of available tokens that we can impersonate
and consequently perform the actual token impersonation.
So let's take a look at how this can be done.
So just fire up the lab environment,
and we can get started with the actual process
of elevating our privileges through token impersonation.
All right, so I'm back within the lab environment,
and we already have the target IP specified
for us, which is great.
So we can copy that.
And I'm going to open up a terminal session here.
I'm going to maximize that and increase
the font size so you can actually see what's going on.
I'm then going to start up the PostgreSQL database service
so that we can actually interact with the Metasploit Framework
database.
And I'm going to also start up msfconsole while we're at it,
and that will save us a little bit of time.
So that's going to start up the PostgreSQL database
server for us, and then start up msfconsole.
So let's just wait for this to start up.
There we are.
That starts up relatively quickly.
What we're going to do now is create
a workspace for all our activity,
and I'm just going to call it impersonate
because that's what we're dealing with, in this case.
We can then, of course, check the workspace
we are currently working in.
And it's impersonate, which is great.
We then need to set up the global variable for the RHOSTS
option to the target IP.
And the reason we are doing this is
to essentially prevent us or alleviate us
from having to type in the target IP
whenever we load in a module.
So this is a great time saver.
So I'm going to hit Enter.
And we now want to perform an Nmap scan on the target system
to identify what services are running on the target system
that we can consequently exploit to gain access, after which we
can then begin exploring the privilege escalation process.
So I'm going to be utilizing the db_nmap
command to perform the Nmap scan from within msfconsole.
And this command will consequently
save the Nmap results within the Metasploit Framework database
in our current workspace.
So I'm going to perform some service version detection
and will paste the target IP and hit Enter.
So I'm going to give this a couple of seconds
to a couple of minutes to complete.
All right, once the scan is done,
we can see that, on port 80, we have the Rejetto HFS
or HttpFileServer version 2.3 running, which
we have exploited previously.
So this is going to be our attack vector.
So I'm going to just search for the exploit module.
And in this case, we know that it's called Rejetto,
and there we are.
That's the Rejetto remote command execution
exploit module.
So I'm going to copy it, and we're going to paste it.
And we're going to say use and hit Enter.
As you can see, the default payload
is the 32-bit meterpreter payload.
We're going to set that to the 64-bit meterpreter payload.
So I'm going to say set payload, and I'm
going to say Windows x64 meterpreter reverse TCP.
And of course, you can use whatever protocol,
or you can use whatever connection type that you want.
We are now going to show the options.
And you can see that the RHOSTS option is already
specified for us because we set up the global variable value
for the RHOSTS option.
The target port where Rejetto HFS is running
is port 80, which is correct.
We don't have SSL running, and the target URI
is the root of the webserver.
And of course, we can confirm that
by pasting in the target IP, so within our browser
and navigating to port 80.
So we can just hit Enter.
And as you can see, it's currently
running at the root of the web server.
So we don't need to configure anything
else apart from the LHOST and LPORT options here.
And these, of course, the payload options.
And in this case, I'm going to leave them as the default.
So I'm just going to type in exploit or run, whatever
you're comfortable with.
And in this case, we should get a meterpreter session
on the target system.
There we are, meterpreter session one opened.
Fantastic.
OK, so the first thing we want to do
is we can perform some local enumeration.
And in this case, we can see that the target operating
system is Windows Server 2016.
It's a 64-bit version of Windows Server,
and the payload type or the meterpreter
payload architecture or session is the 64-bit meterpreter
session.
So that's great.
So we don't actually need to migrate to another process
in order to get a 64-bit meterpreter
session as we already have one.
The next thing we want to do is enumerate
our current privileges or the actual user
account that we have access to.
We can type in get user ID, and this tells us
that we have the anti-authority local service privileges.
So you need to make the distinction
between anti-authority system and anti-authority local
service.
Anti-authority system means that we
have system privileges or the highest privileges associated
with a user account on Windows.
And then local service means that we
have the privileges associated with a local service account.
The reason we have access to a local service account
is because we exploited a service, and in this case,
the service that we exploited was the Rejetto HFS or Http
File Server service.
So we get the privileges associated with that service.
We can also enumerate our current privileges
to see whether we can perform token impersonation by typing
in getprivs.
And as I mentioned within the slides,
we require the SeImpersonatePrivilege in order
to perform token impersonation.
So we can see that this--
we currently have this privilege,
which means we can perform token impersonation
and consequently elevate our privileges.
So again, just to verify that we don't
have any administrative privileges beforehand,
I can try and perform a command like hashdump, which requires
administrative privileges.
And as you can see, it's going to tell us
priv_passwd_get_sam_hashes: operation failed:
the parameter is incorrect, which
essentially fails because we don't
have sufficient privileges.
We can also try and navigate to the administrator's user
directory.
So we can say cd Users and under administrator, you
can see operation failed, access is denied.
So we definitely need to elevate our privileges,
and that's what we're going to be doing now.
So now that we've done or essentially verified
that we don't have administrative privileges,
to begin with, we can begin exploring
how to utilize the incognito module.
So when I mentioned that the incognito module is built
into meterpreter, what I mean is that you can easily
load it by typing in load incognito and hit Enter.
It's going to say loading extension incognito,
and it's going to say success, and that's pretty much it.
Now, we can utilize incognito within meterpreter
to list out, first and foremost, the access
tokens available on the system.
So we can say list tokens and say
we want to list out the user access tokens,
and we hit Enter.
And as you can see, it's going to give you the output,
and it's going to be sorted based on the various access
token categories or security levels
that I highlighted within the slides.
So you have your delegation tokens as well as
your impersonation tokens.
Now, remember what I said.
Impersonation tokens are created as a direct result of logging
in or authentication through a non-interactive prompt
or a non-interactive session.
So you can see that we have no impersonation tokens available,
and delegation tokens are created
as a direct result of an interactive logon,
like either through Winlogon or through remote protocol
like RDP.
And in this case, you can see that we
have two delegation tokens available
that we can impersonate.
We have the administrator delegation token,
which is essentially-- which will essentially provide us
with the privileges associated with the administrator account.
And then we have the anti-authority local service
delegation token available.
So if we impersonate the administrator delegation token,
we can essentially get the privileges associated
with that user account, and that's
exactly what we want to do.
So just copy the delegation token name.
There we are.
And in order to impersonate it, we
can type in impersonate token, and we
can then place the actual token name within quotation marks
and then hit Enter.
And it's going to say delegation token available
successfully impersonated the user administrator.
So if we type in getuid now, you can
see that we now have the privileges of the administrator
account and we have successfully been
able to elevate our privileges.
And of course, we can verify this by typing in hashdump,
and in this case, it's going to fail primarily
because we need to migrate to a different process.
And the reason we need to do that
is because the current process tree--
the current process that we're currently operating in or under
is still has the access token associated
with the anti-authority local service account.
So we can list out this is available here,
and we can migrate to explorer.exe.
So I'm going to say migrate, and we can then
specify the process ID of explorer.exe, which is 3544.
So I'm going to say migrate 3544.
And now, if we type in hashdump, you
can see we get the actual user count hashes here,
and we've successfully elevated our privileges.
And of course, we can now access the contents
of the administrative folder.
So we head over into the root of the C drive.
And then, under, the user's directory and under
the administrator directory, you can see we now have access,
well, whereas previously we didn't.
So that is how to elevate your privileges on a Windows system
through token impersonation.
And of course, we've taken a look
at how to do this through the incognito module, which
is extremely helpful.
The reason I've covered this technique
is because of its viability and the fact that you will
be utilizing this technique when you work within Windows
environments or whenever you're conducting a penetration
test because it works irregardless
of the version of Windows as long as their impersonation
tokens or delegation tokens available,
you can always impersonate them.
And of course, in order to do that,
you need to make sure that you currently have
the SeImpersonatePrivilege.
So this is the first prerequisite,
after which if you have access tokens on the target operating
system, you can essentially impersonate them
using the incognito module.
So that is going to conclude the practical demonstration
side of this video.
In the next video, we are going to be exploring
the process of dumping hashes as well as clear text passwords
from memory with Mimikatz.
And we'll also be exploring the Kiwi module, which
is essentially a meterpreter module for the four Mimikatz
that, again, can allow us to essentially perform
all of the password and hashdumping
from within the interpreter.
So I'll see you there.