Now, this blog post is mostly something I do not expect to share publicly, and thus I will state:
_"I have not done particularly deep research into this. Beware, 🤓👆 material ahead."_
# 1. The facepalm bypass: UAC Bombing
Picture this: you're _legitimately_ inside a personal Windows machine through basically any access vector: a beacon, remote session, shell, or _whatever_.
The compromised user is a member of the local Administrators group, but your current process is running in a non-elevated context.
You could now attempt one of the many known UAC bypass techniques.
But perhaps you don't want to mess with registry hijacking, auto-elevated binaries, or any other technique that might introduce additional detection opportunities.
No worries.
A significantly stupider alternative exists: **UAC Bombing.**
> UAC bombing consists of repeatedly triggering UAC elevation prompts, relying on user fatigue, annoyance, or confusion until the user eventually approves one.
**Briefly**, imagine the user suddenly receives a UAC prompt requesting elevation.
Some users might immediately click `Yes`.
Great.
Others will click `No`.
The prompt appears again.
They click `No` again.
The prompt appears again.
And again.
Eventually, the user is probably wondering what the hell is happening.
At this point, a few things might happen:
- The user continues denying the requests.
- The machine gets restarted.
- The user eventually clicks `Yes`.
If the user approves the request, the process receives the elevated context it originally requested.
Congratulations.
You have successfully replaced sophisticated privilege escalation research with annoying someone.
## The incredibly advanced PoC
The basic concept is extremely simple.
On Windows, a process can request elevation through ShellExecute by specifying the `runas` verb. If the user rejects the UAC prompt, the request fails.
A PoC can simply request elevation again after a rejection:
```csharp
using System;
using System.ComponentModel;
using System.Diagnostics;
class Program
{
static void Main()
{
for (int i = 0; i < 5; i++)
{
try
{
Process.Start(new ProcessStartInfo
{
FileName = "cmd.exe",
UseShellExecute = true,
Verb = "runas"
});
// User clicked Yes.
Console.WriteLine("You are elevated! CMD started.");
break;
}
catch (Win32Exception)
{
// User clicked No. Ask again.
}
}
}
}
````
In this example, accepting the UAC prompt launches an elevated `cmd.exe`.
The loop is intentionally bounded to five attempts for demonstration purposes. An actual implementation of the concept could obviously behave differently.
The PoC is available here:
https://github.com/lypd0/UACBombing
## Important clarification
Despite the intentionally stupid name of this section, **UAC bombing is not technically a UAC bypass**.
Nothing is being bypassed.
Windows displays the elevation prompt exactly as intended, and elevation only occurs if an authorized user explicitly approves it.
What is being attacked is effectively the **human interaction with UAC**, rather than the UAC mechanism itself.
## Disclaimer
Before I experience DM bombing myself, yes, there are several obvious limitations:
* An interactive user must actually be present to approve the UAC request.
* The user must be capable of approving the requested elevation, either through administrative consent or appropriate credentials.
* It therefore does not magically turn an unprivileged account into an administrator.
* In many enterprise environments, standard users cannot simply approve elevation themselves.
* The technique is extremely noisy and very likely to make the user realize that something is wrong.
* Repeated UAC prompts may also create useful telemetry for defenders.
* Restarting the machine does **not** magically make the prompts return unless some separate persistence mechanism causes the program to execute again.
* There are obviously additional environmental and operational considerations that I do not feel like turning this small post into a thesis about.
Peace.