Awesome.
Now that we know how to escalate privileges by exploiting vulnerabilities,
let's take a look on how to escalate privileges by exploiting misconfigurations.
One thing to remember is that there are a lot of ways of
escalating privileges via misconfigurations,
and the reality is what works today might not work tomorrow.
So as a security specialist,
your job is to always research new attacks that can
be used during your pen test.
However, there are a few really common misconfigurations that almost always work,
even if the computer has the latest patches and updates.
For example,
one of the most common misconfigurations that can lead to privilege
escalation is when you have a service running as admin,
but with the configuration files that can be changed by anyone.
In this way, anyone can replace the services files and execute code as admin.
And similar to that,
we can try to find scheduled tasks that have the wrong file permissions.
For example, if the admin set up a script that runs every hour,
but anyone can edit the script,
then we can easily add malicious code to the script.
Also,
another really common way of escalating privileges is finding
scripts that contain plaintext credentials.
And believe it or not, this is more common than anything.
All right, demo time.
Let's take a look on how to escalate privileges by exploiting misconfigurations.
In here, we'll cover how to find misconfigurations,
how to create a malicious payload, and, the best part,
how to get an admin‑level Meterpreter shell.
So if you're ready, let's go to our virtual machine.
We're back to the lab environment. To save us some time, I already have
here a Meterpreter shell open to the victim computer.
I got the shell using the executable Meterpreter payload.
And in here, I have a shell with low‑level privileges as mjackson. Okay,
so let's see how we can get admin privileges using a misconfiguration.
One of the most common misconfigurations that could lead to privilege
escalation is scheduled tasks with the wrong permissions configured.
So let's start by taking a look at which scheduled task we
currently have in the victim computer.
For that,
I will open an operational system shell and then use this command schtasks,
and this will list all the scheduled tasks in this computer.
Take a look.
We got a huge list of scheduled tasks.
I can even see the next runtime for some of those. However,
as we are a low‑privilege user,
we might not be able to see all the scheduled tasks in there.
For example,
the administrator might have created some scheduled
tasks that we cannot see here.
So one thing that we can do is start to look around the computer for
custom scripts that might be related to a scheduled task.
So earlier today, I was analyzing the server and I found on the C
drive this directory called AdminScripts, and this sounds
promising. So let's take a look inside of it.
Cool.
Check it out.
We have here the script called scheduled‑onlogin‑clean‑old‑files.
It seems to be a script that runs every time an administrator logs
into the computer. In a real pen test, the file name might not be that
detailed. But the biggest red flag here is that we have an admin
script, but that anyone can edit it.
Here, take a look at the file permissions.
If you're not familiar with the Linux file permissions, when we
have this rwx repeated three times, it means that any user in
the machine can edit the script.
So again, it is an admin script that anyone can edit.
And that's awesome because we can inject anything we want into this file.
And according to the file name,
it seems that it will run every time an admin logs into the computer.
So what we can do here is edit this script and add one line that
will execute a malicious Meterpreter payload.
So then, when the admin logs into the machine, they will get a shell.
So let's first take a look on what is inside of this file.
Cool.
Take a look.
It's just one line of code that deletes any old files in the AdminFiles folder.
So what I will do here is create a Meterpreter executable
payload and then add one line to this file that will execute my
payload every time the script is run.
So let's create our payload.
For that, I'll use the exact same msfvenom command that I used before.
The only thing that will change is the LPORT because we cannot
have two sessions using the same port. In here,
I will change the LPORT to 8080.
Also, just to keep things organized, I'll change the file name to something else.
Perfect.
Take a look.
We have a new payload for the admin user.
Now let me upload the shell to the server using that upload command
that we saw in the previous module. As a heads up, as we're
uploading a malicious shell into the server,
the antivirus might detect it. In here, to make this demo simpler,
I disabled the Windows Defender. In your case,
you might have to find a way to obfuscate your code or any
other way of bypassing the detection.
Perfect. The file now is uploaded.
All we have to do now is add one more line to that
script so then our payload is executed.
For that,
I will open the operation system shell and then use the command
echo, which writes a sentence into a file.
And in here, I will write the path to the malicious
Meterpreter executable that we created.
And then to put this line in the end of the file,
I'll put the greater sign twice and then the file that I want to save. Perfect.
That's it.
Now I can exit the shell and then double check to
make sure the code is in there.
Perfect.
It is.
Now next time this script is run, it will execute our Meterpreter shell,
and we will receive a call back.
So then we need a listener for that.
And we know really well how to do that.
So let me quickly open one. I'll background the session here and
then use the same exploit multi/handler with the same Windows
payload, but now with the right port, which is 8080. Then, let's run this.
And there we go.
We have a listener ready.
So now, in theory, when the admin script is executed, we'll get a shell.
And by the name of the file,
it seems that this script is scheduled to run every time
that the admin logs on. In a real pen test,
you'd have to wait until that happens.
But as we are in the lab environment,
I'll simply go to the victim machine and log into
the server to trigger the script.
Perfect. Note that nothing appears here on the victim
machine. It's like nothing happened.
But let's check our attacker machine. Awesome.
Take a look.
We get an Meterpreter session, and the best part is this
session is running as administrator.
It doesn't get better than that.