Overview
When a threat actor gains execution on a target’s device, one of their next objectives is often to escalate privileges. While there are numerous methods to achieve this, one particularly intriguing approach involves having the user perform the escalation themselves. If successful, this method could be significantly easier than searching for obscure vulnerabilities, or risking detection through other invasive techniques. UAC bypasses notwithstanding, on modern Windows systems, this typically involves triggering a UAC prompt. However, based on my experience, users have become desensitized to prompts, alerts, and confirmation dialogs. If I were to wager, I’d bet that if 100 users with the necessary privileges were unexpectedly presented with a UAC prompt, more than a few would likely approve it.
Of course, triggering UAC may not always be appropriate or feasible in every situation. However, this idea focuses on scenarios where activating a UAC prompt could be a viable and acceptable trade-off.
Possible situations
One scenario where this approach might make sense, while also increasing the likelihood of user compliance and reducing the risk of raising suspicion, would be if you managed to drop a DLL hijacker or proxy into an application located in the user’s AppData folder. Under normal circumstances, unless the application is executed with elevated or administrative rights, your malicious code will be restricted to the rights of the user (or the process that launched it), likely not ideal.
With code execution established, what if the malicious DLL drops and executes a payload? This payload could then check whether elevation is needed and, if so, attempt to elevate privileges, triggering a UAC prompt.
For instance, imagine the AppData program infected with the malicious node (DLL) file, is Slack. From the user’s perspective, the sequence of events might look like this: they launch Slack, the application begins to load, and then, BOOM! A UAC prompt appears. In reality, it’s not Slack triggering the prompt but rather the malicious payload. However, if I were to place a bet, I’d wager that more than zero users would correlate the launch of Slack with the UAC prompt. Assuming a general desensitization to prompts, it’s likely that more than a few would simply click “Yes” and continue without much thought.
To be clear, I’m using Slack purely as an example; this approach could work with any number of programs. The key point I am trying to make, is that many users are likely to associate the launch of a program they initiated and “trust” with the UAC prompt. Yes, more than a few vigilant users might question the situation, but my theory is that at least some users, perhaps those who aren’t paying attention, will simply click “Yes” without further scrutiny.
The Challenge
Unless you have managed to do some work, or are lucky enough to have gotten a hold of a valid code signing cert, the user will likely be shown something like this:
Yuck! Okay, this looks shady as hell. Even someone who is not paying much attention and/or is pretty desensitized, would likely have questions. Though I still think even with this, over enough time and iterations there would be users who click “Yes,” but I grant this would be a big risk and less likely.
An Idea
So what if we could present the user with a more “comforting” UAC. Maybe something that says “Verified Publisher,” and without the need to obtain a code signing cert? What if the user saw this instead?
Hmmm? Maybe.
The idea is to use PowerShell to launch an elevated cmd.exe process along with arguments so the spawned cmd.exe process then executes our malicious payload. We hide the spawned window to keep questions to a minimum.
The command to achieve this looks like:
powershell -Command "Start-Process cmd.exe -ArgumentList '/c [Path to Evil]' -Verb RunAs -WindowStyle Hidden"
Again using Slack as example, the execution chain/process would look like:
Slack > Malicious DLL > Payload Dropped > PowerShell > UAC > cmd.exe > Malicious Payload = Profit?
This video shows the process in action, starting with the PowerShell execution.
But Wait, that user obviously was already a member of the Local Admin’s Group…
So the above may “work” if your impacted user also happens to be part of the Local Admin Group. Sadly, in many places this is still a thing. Ideally, an organization would have separation of privileges, where users who may have a need for Local Admin rights, are provisioned a separate account which (again ideally) is only used for those times they need to elevate.
In such a scenario the overall method described above still works, with a couple non-trivial caveats; 1) Obviously there is now going to be a bit more friction thrown in because now a targeted user would need to enter their Local Admin user name and password, and 2) For this to work, the targeted user would need to have access to a Local Admin account.
Depending on the target organization, finding a users who has access to a Local Admin account may not be that improbable. Also, again my thesis rests upon the presumption that a UAC prompt appearing in conjunction with an user initiated task (like launching Slack), and with the prompt appearing “generic” with reassuring words like “Verified Publisher,” may have a probability of success higher than what some might assume. If successful the threat actor would gain escalation rather “cheaply,” and “quickly.”
In addition as the malicious DLL is generating (via the above command) the UAC prompt there is nothing which prevents the DLL from somehow checking if the malicious payload process was spawned, and if not, just launching it directly. Thus, even if the user is suspicious, or lacks a Local Admin account, or for whatever reason the elevation fails, remote access is still possible.
Putting this all together…
In this video I show how this may look in a more “traditional” enterprise set up. I also show, Microsoft Defender’s Real-time Protection is enabled. I am working on another post where I will describe how in 2025 it is still possible to execute a Meterpreter session on a fully updated Windows machine running Microsoft Defender; stay tuned…