Getting an Overview - Permissions and Logged on Users
Now that we have a clear list of computers, users,
and groups in the domain,
we will continue our enumeration
and focus on the relationships between as many objects as possible.
These relationships often play a key role during an attack,
and our goal is to build a map of the domain to find potential attack vectors.
In order to find possible attack paths,
we’ll need to learn more about our initial user
and see what else we have access to in the domain.
We also need to find out where other users are logged in.
Let’s dig into that now.
PowerView’s Find-LocalAdminAccess command
scans the network in an attempt to determine if our current user
user has administrative permissions on any computers in the domain.
The command relies on the OpenServiceW function,
which will connect to the Service Control Manager (SCM)
on the target machines.
The SCM essentially maintains a database of installed services
and drivers on Windows computers.
PowerView will attempt to open this database
with the SC_MANAGER_ALL_ACCESS access right,
which require administrative privileges,
and if the connection is successful,
PowerView will deem that our current user
has administrative privileges on the target machine.
Let’s run Find-LocalAdminAccess against corp.com.
While the command supports parameters such as Computername and Credentials,
we will run it without parameters in this case
since we are interested in enumerating all computers,
and we are already logged in as stephanie.
In other words,
we are spraying the environment to find possible local administrative access
on computers under the current user context.
The output reveals that stephanie has administrative privileges on CLIENT74.
While it may be tempting to log in to CLIENT74
and check permissions right away,
this is a good opportunity to zoom out and generalize.
Penetration testing can lead us in many different directions
and while we should definitely follow up on the many different paths
based on our interactions,
we should stick to our schedule or plan
most of the time to keep a disciplined approach.
Let’s continue by trying to visualize
how computers and users are connected together.
The first step in this process will be to obtain information
such as which user is logged in to which computer.
Historically, the two most reliable Windows APIs that could,
and still may, help us achieve these goals
are NetWkstaUserEnum and NetSessionEnum.
The former requires administrative privileges, while the latter does not.
However, Windows has undergone changes over the last couple of years,
possibly making the discovery of logged in user enumeration more difficult for us.
PowerView’s Get-NetSession command
uses the NetWkstaUserEnum and NetSessionEnum APIs under the hood.
Let’s try running it against some of the machines in the domain
and see if we can find any logged in users:
We are not receiving any output.
A simple explanation would be that there are no users logged in on the machines.
However, to make sure we aren’t receiving any error messages,
let’s add the -Verbose flag:
Unfortunately, it appears that NetSessionEnum does not work in this case
and returns an “Access is denied” error message.
This most likely means that we are not allowed to run the query,
and based on the error message, it may have something to do with privileges.
Since we may have administrative privileges on CLIENT74 with stephanie,
let’s run Get-NetSession against that machine
and inspect the output there as well:
We did receive some more information this time.
However, looking closer at the output,
the IP address in CName ending in .75
does not match the IP address for CLIENT74.
In fact, it matches the IP address for our current machine, which is CLIENT75.
Since we haven’t spawned any sessions to CLIENT74,
something appears to be off in this case as well.
In a real world engagement, or even in the Challenge Labs,
we might accept that enumerating sessions with PowerView does not work
and try to use a different tool.
However,
let’s use this as a learning opportunity a deeper dive into the NetSessionEnum API
and try to figure out exactly why it does not work in our case.
According to the documentation for NetSessionEnum,
there are five possible query levels:
0,
1,
2,
10,
and 502.
Level 0 only returns the name of the computer establishing the session.
Levels 1 and 2 return more information but require administrative privileges.
This leaves us with Levels 10 and 502.
Both should return information such as the name of the computer
and name of the user establishing the connection.
By default, PowerView uses query level 10 with NetSessionEnum,
which should give us the information we are interested in.
The permissions required to enumerate sessions with NetSessionEnum
are defined in the SrvsvcSessionInfo registry key,
which is located in the hive displayed.
We’ll use the Windows 11 machine we are currently logged in on
to check the permissions.
Although it may have different permissions
than the other machines in the environment,
it may give us an idea of what is going on.
In order to view the permissions,
we’ll use the PowerShell Get-Acl[^getacl] cmdlet.
This command will essentially retrieve the permissions
for the object we define with the -Path flag
and print them in our PowerShell prompt.
The output reveals the groups and users that have either FullControl or ReadKey,
meaning they can all read the SrvsvcSessionInfo key itself.
However, the BUILTIN group,
NT AUTHORITY group,
CREATOR OWNER and APPLICATION PACKAGE AUTHORITY are defined by the system,
and do not allow NetSessionEnum
to enumerate this registry key from a remote standpoint.
The long string in the end of the output i
according to Microsoft’s documentation, a capability SID.
In fact, the documentation refers to the exact SID in our output.
A capability SID is an unforgeable token of authority
that grants a Windows component or a Universal Windows Application
access to various resources.
However, it will not give us remote access to the registry key of interest.
Now let’s get a better sense of the operating system versions in use.
We can do this with Net-GetComputer,
this time including the operatingsystemversion attribute:
As we discovered earlier,
Windows 10 is the oldest operating system in the environment,
and based on the output,
it runs version 16299,
otherwise known as build 1709.
While the documentation from Microsoft
is not clear when they made a change to the registry hive,
it appears to be around the release of this exact build.
It also seems to affect all Windows Server operating systems
since Windows Server 2019 build 1809.
This creates an issue for us since we won’t be able to use PowerView
to build the domain map we had in mind.
Even though NetSessionEnum does not work in this case,
we should still keep it in our toolkit
since it’s not uncommon to find older systems in real-world environments.
Fortunately there are other tools we can use,
such as the PsLoggedOn application from the SysInternals Suite.
The documentation states that PsLoggedOn will enumerate the registry keys
under HKEY_USERS
to retrieve the security identifiers (SID)
of logged-in users and convert the SIDs to usernames.
PsLoggedOn will also use the NetSessionEnum API
to see who is logged on to the computer via resource shares.
One limitation, however,
is that PsLoggedOn relies on the Remote Registry service
in order to scan the associated key.
The Remote Registry service has not been enabled by default
on Windows workstations since Windows 8,
but system administrators may enable it for various administrative tasks,
for backwards compatibility,
or for installing monitoring or deployment tools, scripts, agents, etc.
It is also enabled by default on later Windows Server Operating Systems
such as Server 2012 R2,
2016 (1607),
2019 (1809), and Server 2022 (21H2).
If it is enabled, the service will stop after ten minutes of inactivity
to save resources,
but it will reenable with an automatic trigger once we connect with PsLoggedOn.
Let’s try to run PsLoggedOn
against the computers we attempted to enumerate earlier,
starting with FILES04 and WEB04.
PsLoggedOn is located in C:\Tools\PSTools on CLIENT75.
To use it, we’ll simply run it with the target hostname:
In this case, we discover that jeff is logged in
on FILES04 with his domain user account.
This is great information, which suggests another potential attack vector.
We’ll make a note in our documentation.
Let’s go ahead and enumerate WEB04 as well:
According to the output, there are no users logged in on WEB04.
This may be a false positive since we cannot know for sure
that the Remote Registry service is running,
but we didn’t receive any error messages, which suggests the output is accurate.
For now, we will simply have to trust our enumeration
and accept that no users are logged in on the specific server.
As we discovered earlier in this section,
it appears that we have administrative privileges on CLIENT74 via stephanie,
so this is a machine of high interest,
and we should enumerate possible sessions there as well.
Let’s do that now.
For educational purposes, we have enabled the Remote Registry service on CLIENT74.
It appears jeffadmin has an open session on CLIENT74,
and the output reveals some very interesting pieces of information.
If our enumeration is accurate
and we in fact have administrative privileges on CLIENT74,
we should be able to log in there and possibly steal jeffadmin’s credentials!
It would be very tempting to try this immediately,
but it’s best practice to stay the course and continue our enumeration.
After all, our goal is not to get a quick win,
but rather to provide a thorough analysis.
Another interesting thing to note in the output
is that stephanie is logged on via resource shares.
This is shown because PsLoggedOn also uses the NetSessionEnum API,
which in this case requires a logon in order to work.
This may also explain why we saw a logon earlier
for stephanie while using PowerView.
This concludes the enumeration of our compromised user,
including the enumeration of active sessions within the domain.
Based on the information we have gathered,
we have a very interesting attack path
that may lead us all the way to domain administrator if pursued.