Access token impersonation.
Now that we've explored two Windows privilege escalation
techniques that essentially exploit
inherent vulnerabilities within the Windows operating system,
and, of course, in the case of kernel
exploits within the Windows kernel or Windows NT,
we can turn our attention to another privilege escalation
technique that takes advantage of inherent vulnerabilities
within Windows.
And that, of course, involves the Windows access tokens.
More specifically, we'll be taking a look
at how we can impersonate a Windows access token that
belongs to a privileged user, therefore
essentially inheriting the privileges associated
with that elevated or privileged user account.
All right.
So before we get started with the practical demonstration,
let's get an idea of what Windows access tokens are.
All right, so Windows access tokens
are a core element of the authentication
process on Windows and are created and managed
by the Local Security Authority Subsystem Service,
also known as LSASS.
And again-- so if you've ever opened up
the Task Manager on a Windows system
and you see an application or service called lsass.exe,
that is the Local Security Authority Subsystem Service.
All right.
Now, a Windows access token is responsible for identifying
and describing the security context of a 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.
All right, so you might be a little bit confused.
Well, let me just explain this or elaborate
further so that you can get a clear idea of what an access
token is.
All right, so an access token is generated
by the winlogon.exe process every time
a user authenticates successfully,
and that access token includes the identity of the user
account that is just authenticated
and the privileges of the user account
associated with the thread or process.
So whenever you start up your Windows operating system,
you will be prompted with a login page that
is handled by winlogon.exe.
So whenever you type in the password for the user account
that you're logging into, winlogon.exe will essentially
generate an access token, and this access token
includes the identity of the user account
as well as the privileges associated with that user
account.
Now, 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 access tokens are essentially used to restrict access
in terms of what users can execute and what they cannot
execute primarily because they essentially specify that these
are the privileges associated with this particular user
account.
So again, going back to the userinit process here,
you can see that the token is attached to userinit.
Now, userinit is the process that is
used to create other processes.
So, for example, if I log on to a Windows system,
Windows will generate or rather user-- or winlogon.exe
will generate an access token, and it will then
be attached to userinit.exe.
So whenever I try and open up a browser, for example, Firefox,
that process will be executed with the access
token or the privileges associated with that access
token, and that essentially prevents me
from accessing Firefox under any other privileges.
So in terms of how they work and their categories,
Windows access tokens are categorized
based on varying security levels assigned to them.
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.
So you will typically see that you have two types of Windows
access tokens.
You have your impersonate-level tokens
and your delegate-level tokens.
So your impersonate-level tokens are
created as a direct result of a non-interactive login
or logon a Windows system, typically
through specific system services or domain logons.
So whenever you see an impersonate Windows access
token, just know that they were created
as a direct result of a non-interactive logon
onto the Windows system.
You then have your delegate-level tokens,
and these are typically created through an interactive login
on Windows, primarily through a traditional login
through winlogon.exe or through remote access
protocols such as RDP.
All right.
Now, impersonate-level tokens can
be used to impersonate a token on a local system
and not on 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.
All right, so just keep that in mind.
And, as I said, you might be a little bit confused,
but this will make sense as we progress
through the practical demonstration.
All right, so now that we have an idea of what Windows access
tokens are and how they work, let's
take a look at a closer look at Windows privileges.
So every user account has Windows privileges
or privileges assigned to them, and these privileges
essentially determine what this user can do or can't do,
and, of course, we've explored this in previous videos.
For example, whenever we got a Meterpreter session
on the target, and we typed in getprivs,
this would display the list of Windows privileges assigned
to this account, and from those privileges,
we were able to identify what we can and cannot do.
Now, the process of impersonating access tokens
in order to elevate our privileges on a system
will primarily depend on the privileges assigned
to the account that has been exploited in order to gain
initial access, as well as the impersonation
or delegation tokens available.
So the following are the privileges
that are required for a successful impersonation
attack.
So in order for you to impersonate another Windows
access token, you need to have one of the following,
but primarily the Se impersonate privilege assigned to the user
account that you currently have access to.
So you have the SeAssignPrimaryToken privilege.
This essentially allows a user to impersonate tokens.
SeCreateToken allows the user to create an arbitrary token
with administrative privileges.
And then SeImpersonatePrivilege, this
allows a user to create a process under the security
context of another user, typically
with administrative privileges.
All right, so these are the privileges
that are required in order for you
to impersonate a Windows access token.
And, of course, in this case, we are primarily
looking for access tokens with administrative privileges
or access tokens that belong to users
with administrative privileges.
All right.
Now, in order to perform access token impersonation,
we are going to be utilizing a Meterpreter
session on a target, and more specifically, we
will be utilizing an inbuilt Meterpreter
module called incognito.
All right, so incognito was originally
a standalone application, and what it does
or the way it works is it essentially
allows you to list the available impersonation or other access
tokens available that you can impersonate,
after which you can also use it to impersonate
a specific access token.
Now, it's very important to actually specify this.
In this particular demonstration or in this scenario,
we are only going to be taking a look
at how to list the available access tokens available
and how to impersonate them.
And the whole process of token impersonation
really involves two techniques.
The first technique we will be exploring
in this video and the second technique
will essentially involve utilizing
exploit code or an executable, or really, the attack,
as it's called, is the potato attack,
in order to get an NT authority system access token generated
so that you can impersonate it.
However, in this case, as I said,
we're only going to be utilizing the currently available access
tokens, and we're going to be impersonating them in order
to elevate our privileges.
We will be covering potato attacks in the privilege
escalation course because we will
be diving deeper into these privilege escalation
techniques in that course.
But for now, we're only going to be taking a look
at one of these techniques.
All right, so this particular video has a lab environment,
so fire it up, and you can follow along
with the demonstrations.
So I'm going to fire up my lab environment,
and I'll see you within the lab.
All right, so I'm back within the lab environment,
and I already have the target IP provided for me,
so I'm just going to copy that, and, of course, in your case,
it will be different.
And the first step will, of course,
involve obtaining initial access on the target system
and, in this case, we're also going
to be exploiting the Rejetto HTTP file server service that's
running as we did previously.
So we can perform an Nmap scan on the target
in order to identify or verify that the HTTP file server is
indeed running on port 80.
So I'll give this a couple of seconds.
There we are.
You can see that we have a web server on port 80.
So we can open that up within our web browser.
So I'll paste the target IP there,
and you can see on port 80, we have the Rejetto HTTP file
server version 2.3 running, which already has a very, very
powerful Metasploit module that we
can use to exploit it and gain a Meterpreter session.
So I'll start up the PostgreSQL Database Service,
and I'll also start up MSF console.
All right.
There we are.
And, of course, this will just take a couple of seconds.
OK.
And we can search for the module, so it's Rejetto,
and we are going to use this one right over here,
so exploit/windows/http/rejetto hfs exec.
All right, so we'll say use module 0,
and the default payload is set to
windows/meterpreter/reverse_tcp.
You can change that to a 64-bit payload if you want.
However, in this case, we'll just
use the default configuration.
So I'll say show options.
We need to configure the payload option,
so you'll need to set up your Kali Linux IP address, which
is already set in my case, and the port or L port
option, which again, in this case,
I'll leave it as the default. We then need to set up the target
IP, so we can say set RHOSTS and paste in the target IP.
And that's pretty much it in regards
to customizing this module or preparing it for exploitation.
So I'll just hit exploit, and this should provide us
with a Meterpreter session.
So we'll give this a couple of seconds.
There we are.
Sending stage, and you can see we get a Meterpreter session
immediately.
All right, so now that we've obtained
a Meterpreter session, what we can do is if we say sysinfo,
you can see that this is a-- the target is running Windows
Server 2016, and the build number
is provided right over here.
The operating system architecture is 64-bit,
and we currently have a 32-bit Meterpreter session.
So, in addition to this, we can also migrate our Meterpreter
session into a different process, and, of course,
in this case, I would typically recommend Explorer.
So I can look for the process ID for the explorer.exe process,
and I can say migrate, so migrate 3512.
There we go.
And in this case, you can see it tells us access is denied,
and that's because we currently have access
to an unprivileged user account.
So I can say get user ID.
You can see we are currently NT authority local service, so we
currently have access via service account, which
is, by default, unprivileged, and we can confirm this
by saying getprivs.
There we are, and you can see these are the only privileges
that we have.
However, if you pay close attention,
you can see that we have the SeImpersonatePrivilege, which
pretty much means we can utilize this Meterpreter
session or this particular user account
to, essentially, impersonate other access tokens available.
All right, so as I said, we are going
to be using the incognito module.
So you can load the incognito module
by saying load incognito.
That is going to load it, and, in this case,
it tells me that my Meterpreter session has died,
so I'll run the exploit one more time.
That is primarily because I tried to migrate to a process.
So we'll give this a couple of seconds,
and we should receive the second Meterpreter session.
There we are.
And I'll just say load incognito.
There we are.
Load incognito was successful, and now we can say list tokens,
and we'll use the user option here
to list the user account access tokens.
And you can see that we have delegation tokens
and impersonation tokens.
So remember, delegation tokens were
created as a direct result of an interactive logon,
and impersonation tokens were created as a direct result
of a non-interactive logon.
So in terms of the access tokens available,
we have the administrator account access
token, which again, will provide us with elevated privileges,
and then we have the current user account access
token, which is NT authority local service.
So in order to impersonate this particular access token here,
we can copy the name of the access token,
and we can say impersonate token.
I'm just going to put in the name of the token into--
or I'm just going to encapsulate the name with double quotation
marks, and we can say impersonate token,
and we hit Enter.
And you can see delegation token available.
Successfully impersonated this particular user account.
And if I say get user ID, you can
see we currently have elevated our privileges to that
of the administrator account.
If I say getprivs, you can see that it'll
tell us operation failed.
Access is denied.
So I can, again, just search for the Explorer process,
so pgrep explorer and I can migrate to 3512.
There we are.
So let me just type that in correctly, 3512.
All right, so if I say getprivs now,
you can see that we have an elevated session because we
have additional privileges that are associated
with an administrative account.
And, of course, I can say get user ID and, in this case,
we still have access to the administrator account.
All right, so we have successfully
been able to elevate our privileges
through the use of access tokens,
and we've taken a look at how to impersonate access tokens.
Now, as I said within the slides,
if you are ever in a situation, and you will be,
where-- if I list out the tokens available,
you will be in a situation where you will not be able to have--
or you will not find any privileged access
tokens available irregardless of whether they are delegation
tokens or impersonation tokens.
In that case, you will need to use the potato
attack in order for you to--
I'll not get into the nitty-gritty
of this particular attack, but what it will do
is it will essentially get you or generate a NT authority
system access token that you can then impersonate and obtain
the privileges associated with the NT authority system access
token or in the case of the administrator
user, the privileges associated with the administrator user.
Now, given the fact that I've already elevated my privileges,
you can see that I have additional access
tokens available that I can impersonate.
So, for example, I have the NT authority system token right
over here, so if I wanted to impersonate it as well,
I can also do that.
So I can say impersonate token, and I'll paste in the name
there and hit Enter.
And you can see, successfully impersonated
NT authority system.
If I say get user ID, there we are.
And getprivs, there we go.
So we have successfully elevated our privileges.
And as I said, this particular attack
will essentially depend on a few factors.
Number one, what user accounts are currently on the system
and which of these user accounts has admin access or admin
privileges, or what user accounts
are part of the local administrators' group?
And if you can find an access token that is available
that you can impersonate, then you
can essentially impersonate or essentially obtain
the privileges associated with that particular access token.
And as I said, it does not need to belong to a particular user.
It could also belong to NT authority system
or, in this particular case, NT authority local service, which
again, there's not really much sense
in impersonating an account with lower privileges than what
you currently have.
But you can also do that if you want.
All right, so that is going to conclude
the practical demonstration side of this video.
All right, so now that we've explored all of the privilege
escalation techniques that we can utilize on a Windows
system, we can now turn our attention to Windows file
system vulnerabilities, more specifically,
we will be exploring alternate data streams
and how they can be used by attackers to conceal
files, et cetera, et cetera in the next section.
So we are now moving on to a new section, which is Windows file
system vulnerabilities, and I'll be seeing you
in the next video.