Situational Awareness
Now that we have a basic understanding of Windows privileges,
we’ll cover various methods to get situational awareness on a system.
Let’s assume we used a client-side attack or exploited a vulnerability
to access a Windows system as an unprivileged user.
Before we attempt to elevate our privileges,
we must obtain information about the system we are on.
This is a crucial step to better understand the nature of the
compromised machine and discover possible vectors for privilege escalation.
However, it is often skipped or minimized by inexperienced penetration testers
since sifting through and interpreting a lot of information is not as exciting
as attacking services or machines.
Experienced penetration testers know that by gathering as much information
as possible, they obtain valuable information about the target system
they can use to create various actionable vectors to elevate their privileges.
There are several key pieces of information we should always obtain:
Username and hostname
Group memberships of the current user
Existing users and groups
Operating system, version and architecture
Network information
Installed applications
Running processes
After we perform the enumeration steps to obtain this information,
we will have a solid understanding of our target system.
Let’s start gathering the information on the CLIENTWK220 system.
In this example, we’ll assume that we previously started a bind shell
on port 4444 through a clientside attack.
Let’s demonstrate how to obtain the information.
We’ll connect to the target system with netcat and enter whoami to obtain
the first pieces of information: the username and hostname.
The output shows that we have command execution as user dave.
Additionally, the output contains the hostname of the system, clientwk220.
This hostname implies that our bind shell runs on a client system
rather than on a server.
The hostname often can be used to infer the purpose and type of a machine.
For example, if it is WEB01 for a web server or MSSQL01 for a MSSQL server.
Next, we want to check which groups dave is in.
To display all groups our current user is a member of, we can use whoami /groups.
The output shows that dave is a member of the helpdesk group.
Helpdesk staff often have additional permissions and access
compared to standard users.
Additionally, the user is a member of BUILTIN\Remote Desktop Users.
Membership of this group offers the possibility to connect to the system
via RDP.
The other groups dave is a member of are standard for non-privileged users
such as Everyone and BUILTIN\Users.
The next piece of information we are interested in are other users and groups
on the system.
We can use the net user command or the Get-LocalUser Cmdlet to obtain a list
of all local users.
Let’s use the latter by starting PowerShell and running Get-LocalUser.
The output shows several interesting items that can help us get an overview
of the system.
The first one is that the built-in Administrator account is disabled.
Next, two presumed regular users called steve and dave exist.
In addition, we have identified two other users named daveadmin and BackupAdmin.
Both usernames contain “admin”,
which implies that they are potentially administrative users,
making them valuable targets.
We can also assume that daveadmin is the privileged account of dave.
Administrators often have both a non-privileged and a privileged account.
They use the non-privileged account for day-to-day work and the privileged account
for administrative tasks.
For security reasons, they don’t use the privileged account for performing
potentially unsafe tasks such as browsing the internet.
Before we make further assumptions,
let’s enumerate the existing groups on CLIENTWK220.
We can choose between the command net localgroup
or Get-LocalGroup in PowerShell.
The output shows the non-standard groups adminteam, BackupUsers, and helpdesk.
The adminteam group may be of interest to us since it contains the string “admin”
and has a custom description text,
indicating the members are admins to all workstations on the second floor.
However, we don’t currently have any further information regarding
which floors exist or which departments are on which floors.
Another interesting finding is the group name BackupUsers
as with the user BackupAdmin before.
Backup solutions often have extensive permissions to perform their operations
on the file system, making both potentially valuable targets.
Apart from the non-standard groups,
there are several built-in groups we should analyze, such as Administrators,
Backup Operators, Remote Desktop Users, and Remote Management Users.
Members of Backup Operators can backup and restore all files on a computer,
even those files they don’t have permissions for.
We must not confuse this group with non-standard groups such as BackupUsers
in our example.
Members of Remote Desktop Users can access the system with RDP,
while members of Remote Management Users can access it with WinRM.
For this example, let’s review the members of adminteam and Administrators.
We can do this with Get-LocalGroupMember, passing the group name as an argument.
The output shows that only daveadmin is a member of adminteam.
However, adminteam is not listed in the local Administrators group.
We only know that members of the group are administrators to workstations
on the second floor.
The information we have gathered thus far is not directly actionable,
but it may become so when we move deeper into the network
and identify which systems reside on the second floor.
The output also shows that apart from the disabled local Administrator account,
the users daveadmin and BackupAdmin are members of the local Administrators group.
Therefore, we’ve now identified two highly valuable targets.
While it is crucial to know which users are privileged,
it is also vital for us to understand which users can use RDP.
Obtaining the credentials for one of these users may lead us to a GUI access,
which often tremendously improves our means of interacting with the system.
We’ve collected quite some information about the users and groups
on the target system.
Let’s briefly summarize what we know so far.
Our bind shell runs as the user dave on a machine with the hostname CLIENTWK220.
This user is in a group named helpdesk.
Additionally, there is another user named daveadmin which is probably the person’s
privileged account, while dave may be used for day to day work.
The user daveadmin is also in a group named adminteam,
whose description indicates it has administrative privileges
on all workstations on the second floor.
Furthermore, daveadmin and BackupAdmin are local Administrators on CLIENTWK220.
Next, we’ll gather information about the actual target machine,
its configuration, and applications running on it.
Let’s check the operating system, version, and architecture first.
We can use systeminfo to gather this information.
The output shows that our bind shell runs on a Windows 11 Pro system.
To get the exact version,
we can use the build number and review the existing versions
of the identified operating system.
In our case, this build is version 21H2 of Windows 11.
Additionally, the output contains the information that our bind shell runs
on a 64-bit system.
This information becomes relevant when we want to run binary files on the system,
since we cannot run a 64-bit application on a 32-bit system.
Next, let’s move down the list and review the network information we can obtain
as dave.
Our goal in this step is to identify all network interfaces, routes,
and active network connections.
Based on this information,
we may identify new services or even access to other networks.
This information may not directly lead us to elevated privileges,
but it is vital to understanding the machine’s purpose and to obtain vectors
to other systems and networks.
To list all network interfaces, we can use ipconfig with the argument /all.
The output shows some interesting information.
For example, the system is not configured to get an IP address via DHCP,
but it was set manually.
Furthermore, it contains the DNS server, gateway, subnet mask, and MAC address.
These pieces of information will be useful when we attempt to move to other systems
or networks.
To display the routing table, which contains all routes of the system,
we can use route print.
The output of this command is useful to determine possible attack vectors
to other systems or networks.
The output shows no routes to any previously unknown networks.
However, we should always check the routing table on a target system
to ensure we don’t miss any information.
To list all active network connections we can use the netstat command
with -a as the argument to display all active TCP connections
as well as TCP and UDP ports,
-n to disable name resolution,
and -o to show the process ID for each connection.
The output shows that ports 80 and 443 are listening,
usually indicating that a web server is running on the system.
Additionally, an open port of 3306 is indicative of a running MySQL server.
The output also shows our Netcat connection on port 4444
as well as an RDP connection on port 3389.
This means we are not the only user currently connected to the system.
Once we manage to elevate our privileges,
we could use Mimikatz and attempt to extract credentials of the user.
Next, we’ll check all installed applications.
We can query two registry keys to list both 32-bit and 64-bit applications
in the Windows Registry with the Get-ItemProperty Cmdlet.
We’ll pipe the output to select with the argument displayname
to only display the application’s names.
We’ll begin with the 32-bit applications and then display the 64-bit applications.
We’ll notice that apart from standard Windows applications,
the KeePass password manager, 7-Zip, and XAMPP are all installed on CLIENTWK220.
As discussed in the “Locating Public Exploits” Topic,
we could search for public exploits for the identified applications
after we finish the situational awareness process.
We could also leverage password attacks to retrieve the master password
of the password manager to potentially obtain other passwords,
enabling us to log on as a privileged user.
However, the listed applications in the output may not be complete.
For example, this could be due to an incomplete or flawed installation process.
Therefore, we should always check 32-bit and 64-bit Program Files directories
located in the C drive.
Additionally, we should review the contents of the Downloads directory
of our user to find more potential programs.
While it is important to create a list of installed applications
on the target system, it is equally important to identify which of them
are currently running.
Let’s review the running processes of the system with Get-Process.
The output shows a shortened list of all running processes on CLIENTWK220.
It contains our bind shell with ID 1320,
and the PowerShell session we started for the enumeration process with ID 1332.
When we review the netstat output again, we can confirm that the process ID 3116
belongs to mysqld and ID 2996 to Apache displayed as httpd.
Due to the active process named xampp-control,
we can infer that both Apache and MySQL were started through XAMPP.
We gathered quite a lot of information with the previous commands.
Let’s briefly summarize what we found out about the target system:
The system is a 64-bit Windows 11 Pro Build 22000 with an active web server
on ports 80 and 443, MySQL server on port 3306, our bind shell on port 4444,
and an active RDP connection on port 3389.
Additionally, we found out that KeePass Password Manager, 7Zip, and XAMPP
are installed on the target system.
The information we gathered on users and groups as well as the target system
provide a good overview of the machine.
In the next section, we’ll search for sensitive information on the target system
and interpret it based on the information gathered in the
situational awareness process.