Inspecting User Trails
As penetration testers, we are often time-constrained during our engagements.
For this reason, we should focus our efforts first on low-hanging fruit.
One such target is users’ history files.
These files often hold clear-text user activity that might include sensitive
information such as passwords or other authentication material.
On Linux systems, applications frequently store user-specific configuration files
and subdirectories within a user’s home directory.
These files are often called dotfiles because they are prepended with a period.
The prepended dot character instructs the system not to display these files
when inspecting by basic listing commands.
One example of a dotfile is .bashrc.
The .bashrc bash script is executed when a new terminal window is opened
from an existing login session or when a new shell instance is started
from an existing login session.
From inside this script, additional environment variables can be specified
to be automatically set whenever a new user’s shell is spawned.
Sometimes system administrators store credentials inside environment variables
as a way to interact with custom scripts that require authentication.
Reviewing our target Debian machine,
we’ll notice an unusual environment variable entry:
Interestingly, the SCRIPT_CREDENTIALS variable
holds a value that resembles a password.
To confirm that we are dealing with a permanent variable,
we need to inspect the .bashrc configuration file.
From the output, we can confirm that the variable holding the password is exported
when a user’s shell is launched.
Let’s first try to escalate our privileges
by directly typing the newly-discovered password.
Since we’ve successfully obtained root privileges,
let’s now try another privilege escalation route
that is instead based on the environment variable credential finding.
Instead of aiming directly for the root account,
we could try gaining access to the eve user
we discovered during a previous section.
With our knowledge of script credentials, we could try building a custom dictionary
derived from the known password to attempt brute forcing eve’s account.
We can do this by using the crunch command line tool to generate a custom wordlist.
We’ll set the minimum and maximum length to 6 characters,
specify the pattern using the -t parameter
then hard-code the first three characters to Lab followed by three numeric digits.
We can then verify the content of the generated wordlist:
Since an SSH server is available on our target machine,
we can try to attempt a remote brute force attack via Hydra.
We’ll supply the target username with the -l parameter,
our wordlist with -P,
the target IP address,
limit the number of parallel connections to 4 with -t,
and finally ssh as the target protocol.
We will also include -V to increase verbosity.
Our hydra brute forcing attack succeeded
and we can now directly log in to the target machine
with eve’s credentials via SSH:
Once logged in as eve,
we can verify if we are running as a privileged user
by listing the sudo capabilities using the sudo -l command.
Since eve seems to be an administrative account,
we discover it can run any command as an elevated user.
This means we can elevate directly to root
by running i with sudo and supplying eve’s credentials
(if they haven’t already been entered within the last 15 minutes).
Great!
We managed to elevate our privileges
and gain administrative access via another route.
In the next section, we will learn how to escalate privileges
by harvesting system services credentials.