Hidden in Plain View
Based on the information found in the previous section,
we can assume that the users on CLIENTWK220 use a password manager.
However, we should never underestimate the laziness of users
when it comes to passwords and sensitive information.
What was traditionally the Post-it note with the password under the keyboard
is now quite often a text file on the desktop.
While browsing the home directory of our user or publicly accessible folders,
we can retrieve various pieces of sensitive information,
which may provide us a vector for privilege escalation.
For example, sensitive information may be stored in meeting notes,
configuration files, or onboarding documents.
With the information we gathered in the situational awareness process,
we can make educated guesses on where to find such files.
Let’s search CLIENTWK220 for sensitive information.
We have identified that KeePass and XAMPP are installed on the system and therefore,
we should search for password manager databases
and configuration files for these applications.
Let’s begin our search by entering C:\ for -Path,
and *.kdbx as an argument for -Include
to search for all password manager databases on the system
with Get-ChildItem in PowerShell.
The output shows that no password manager databases could be found in our search.
Next, let’s search for sensitive inform- ation in configuration files for XAMPP.
After reviewing the documentation,
we’ll enter *.txt,*.ini for -Include
because these file types are used by the application for configuration files.
Additionally, we’ll enter C:\xampp as the argument for -Path.
The output shows us that our search returned two files
that may contain sensitive information.
The file my.ini is the configuration file for MySQL,
and passwords.txt contains the default passwords
for the different XAMPP components.
Let’s review them.
Unfortunately, the file C:\xampp\passwords.txt
only contains the unmodified default passwords of XAMPP.
Furthermore, we don’t have permissions to view the contents of
C:\xampp\mysql\bin\my.ini.
Next, let’s search for documents and text files
in the home directory for the user dave.
We”ll enter the file extensions to search for,
and set -Path to the home directory.
The output shows that we found a text file on dave’s desktop named asdf.txt.
Let’s check the contents of this file.
This output shows the file was used for meeting notes.
The note states that the web application uses local users’ credentials
and that for testing “Steve’s” password can be used.
Very nice!
The information gathered in the situational awareness process
comes in handy now,
since we already know that a user named steve exists on the target system.
Before we attempt to leverage the password,
let’s check what groups steve is a member of.
This time, we’ll use the net user command with steve as the username
to obtain this information.
While the output shows that steve is not a member of the Administrators group,
the user is a member of the Remote Desktop Users group.
Let’s connect to CLIENTWK220 with RDP as steve and open PowerShell.
Due to access as new user,
and therefore different permissions on files on the system,
the process of searching for sensitive information begins again.
This is a great opportunity to zoom out here for a moment.
With access to a new user,
the process of searching for sensitive information starts again.
This is not only true for this specific case,
but also for nearly all areas of a penetration test.
The cyclical nature of a penetration test is an important concept for us to grasp,
because it provides a mindset of continuously reevaluating
and including new information and access in order to follow previously
inapproachable or newly identified attack vectors.
In our search as dave we received a permission error on the my.ini file.
Let’s begin by checking if we have access to it as steve.
The output shows that we could access the my.ini file and display its contents.
The file contains the manually set password.
Additionally, a comment states that this is also
the Windows password for backupadmin.
Let’s review the groups that backupadmin is a member of to find out if we can use
services such as RDP or WinRM to connect to the system as this user.
Unfortunately, backupadmin is not a member of the groups Remote Desktop Users
or Remote Management Users.
This means we need to find another way to access the system
or execute commands as backupadmin.
Since we have access to a GUI we can use Runas,
which allows us to run a program as a different user.
Run-as can be used with local or domain accounts
as long as the user has the ability to log on to the system.
Without access to a GUI we cannot use Run-as since the password prompt doesn’t
accept our input in commonly used shells, such as our bind shell or WinRM.
However, we can use a few other methods to access the system as another user
when certain requirements are met.
We can use WinRM or RDP to access the system
if the user is a member of the corresponding groups.
Alternatively, if the target user has the Log on as a batch job access right,
we can schedule a task to execute a program of our choice as this user.
Furthermore, if the target user has an active session,
we can use PsExec from Sysinternals.
Since we have access to a GUI,
let’s use Run-as in PowerShell to start cmd as the backupadmin user.
We’ll enter the username as the argument for /user:
and the command we want to execute.
Once we execute the command,
a password prompt appears in which we’ll enter the previously found password.
Once the password is entered,
a new command line window appears.
The title of the new window states
*running as CLIENTWK220\backupadmin
Let’s use whoami to confirm the command line is working
and we are indeed backupadmin.
The output shows that we are executing commands as user backupadmin.
Very nice!
In this section, we searched for and leveraged sensitive information
on CLIENTWK220
to successfully obtain access from dave to steve,
and then from steve to the privileged user backupadmin.
We did all of this without using any exploits.
As we learned in the “Password Attacks” Topic,
when we find passwords in configuration or text files,
we should always try them for all possible users or services
as passwords are often reused.