So now that we have performed a number of reconnaissance techniques,
let's move to the privilege escalation phase. For this,
I'm going to leverage PowerUp, and within PowerUp,
I'm going to use the module, Invoke‑AllChecks.
This module, we'll go ahead and run a number of different checks
and it'll give me an output of the results.
These results will highlight the different ways that I can leverage
it for either service abuse, adding a new user,
running commands, and so forth.
Now this module is generally pretty noisy, as it outputs a lot
of data, so you can run it natively in PowerShell or you can
also export it to an HTML report.
Now I've gone ahead and run this to export it to an HTML
report, so I'm going to go ahead and open up this HTML
file, and let's see what we have.
So now I've got the report opened up,
let's work through some of these findings and understand what they are.
The first two are pretty obvious, as Invoke‑AllChecks is checking
if the user is part of the local admin group.
In my case, the user is part of the local admin group,
so it gives me an AbuseFunction,
leveraging the Invoke‑WScriptUACBypass. By using this, I can leverage a
command, and that command can be anything that I want, so I can use it
to establish an additional C2 channel,
create additional user accounts, or run an exploit.
The next check that it does is to see if there are any token
privileges that can be abused. So as I scroll down,
there are no unquoted service paths, but there are modifiable service files.
Now these modifiable service files allow me to make use of
the Install‑ServiceBinary module, followed by the name of
that modifiable service file.
So what this module actually does is it replaces the service
binary for a specified service with one that can execute a
specified command as system.
So if you look at the StartName,
we can see that these service binaries are able to run as LocalSystem.
So this gives me the ability to run a command at the highest privilege.
So as I scroll further down,
we come to the Modifiable Services. Now these modifiable
services allow me to abuse a function that the current user
has configuration rights to.
So for example, looking at the output that we have here,
the AbuseFunction would allow me to invoke a ServiceAbuse. So for example,
if I have to copy this Invoke‑ServiceAbuse command as it is and run it in
PowerShell, this will go ahead and create a new user account.
It'll then go and add this user to the local administrators' group.
So if I wanted to change that default command,
I could go ahead and do that by using the same invoke‑serviceabuse function,
but this time adding the command that I would like to use.
So if I wanted to add a different user or run a different
command, this is possible with the invoke‑serviceabuse
function. Now Scrolling further down the list,
we've got the path to .dll Hijacks. Using the AbuseFunction of
Write‑HijackDll, followed by the DllPath, and this will give us the
ability to patch a specified batch file,
which can contain a specified command into a precompiled hijackable DLL.
So let's take a look at an example of this.
I will use this example, and within PowerShell, I'm going
to go ahead and run this, and now you'll see that it has
created the batch file for us.
Let's take a look at what that batch file contains.
We can see that this batch file is a self‑deleting batch
file and it contains a simple command to add a user to the
local administrators' group.
Now of course, you can modify this batch file to run
different commands as you please.
The next batch of checks that we have relates to
Modifiable Registry Autorun keys.
Now this is great because we can leverage this autorun key, for example,
if we wanted to establish a backup C2 session that would run automatically.
We then come to the Modifiable Scheduled Task Files.
This returns any scheduled tasks where the current user can modify
any file in the associated task action string.
Now again,
this leads to additional privilege escalation opportunities
because since these tasks are scheduled, right, and you can
modify the task string, well, you can inject any command into that task string.
We then come to the Unattended Install Files.
This is a good place to look because you might be lucky and find some
deployment credentials that exists in that unattended install file.
And the last check that is done is looking at the
Cached Group Policy Preference Files.
And this check will go and retrieve any plaintext passwords that exist, along
with other information for accounts that are pushed through the group policy
preferences and left in the cached files on the host.
So what did we learn from this output of the PowerUp module? Well, using one
simple Invoke‑AllChecks, we have the ability to gain a lot of insight for
additional ways that we can perform privilege escalation,
create additional accounts, run additional commands, and so forth.