Method found that bypasses UAC even at maximum level for all versions of Windows

Topic

New Reply

(Edit: Good introduction to UAC: Windows 7 User Account Control Guide)

A method has been found that bypasses UAC (User Account Control), even at its maximum level (“Always notify”), purportedly for all versions of Windows. I verified that the code (which is also linked to in the first link) bypasses Windows 7 with UAC set to “Always notify.” The author (Google security vulnerability researcher James Forshaw) claims that this UAC bypass method works even on Windows 10. Note for testers: Purportedly the minimum version of PowerShell required for this code to run is 3.0.

I also tested whether this method allows admin privileges to be obtained in a standard account; without any modification, the code failed to gain admin privileges, giving an error in CreateProcessWithLogin. However, note the author’s admonition about over-the-shoulder elevation in the first link.

UACMe method 35 also implements this UAC bypass method.

2 users thanked author for this post.

ch100, AlexEiffel

Reply | Quote

Replies

From the first link in the first post:

‘DON’T USE SPLIT-TOKEN ADMINISTRATOR ACCOUNTS FOR ANYTHING YOU CARE ABOUT.

Or just don’t get malware on your machine in the first place About the safest way of using Windows is to run as a normal user and use Fast User Switching to login to a new session with a separate administrator account. The price of Fast User Switching is the friction of hitting CTRL+ALT-DEL, then selecting Switch User, then typing in a password. Perhaps though that friction has additional benefits.

What about Over-The-Shoulder elevation, where you need to supply a username and password of a different user, does that suffer from the same problem? Due to the design of UAC those “Other User” processes also have the same Logon Session SID access rights so a normal, non-admin user can access the elevated token in the same way. Admittedly just having the token isn’t necessarily exploitable, but attacks only get better, would you be willing to take the bet that it’s not exploitable?

[…]

Anyway, unless Microsoft change things substantially you should consider UAC to be entirely broken by design, in more fundamental ways than people perhaps realized (except perhaps the CIA). You don’t need to worry about shared resources, bad environment variables, auto-elevating applications and the like. If malware is running in your split-token account you’ve given it Administrator access. In the worst case all it takes is patience, waiting for you to elevate once for any reason. Once you’ve done that you’re screwed.’

2 users thanked author for this post.

Noel Carboni, ch100

Reply | Quote

This is interesting to know, but those unsuspecting users may believe it is a big deal, which is not.
Please note, that some user action is required and malware already present on the computer.
This is the big deal.
Why is malware present on the computer in the first place?!

1 user thanked author for this post.

Noel Carboni

Reply | Quote

There are a lot of security-conscious people who use an admin account with UAC at max as their everyday account. Bypasses such as this are important news to those folks, in my opinion.

Reply | Quote

Note: this code requires the presence of an elevated process running in the same desktop. UACMe method 35 instead runs an elevated Microsoft process (possibly triggering a UAC prompt), after which the code is able to obtain elevated privileges.

Reply | Quote

Wiki: UAC Bypasses and UAC bypass research

1 user thanked author for this post.

Reply | Quote

Ok, just to be clear because it is not to me,

There is a way that if you run admin with UAC, some code can run without triggering UAC and obtain admin rights as if you allowed it? Is it only if you run admin with UAC or does it work if you run standard user while being able to respond to a UAC prompt to provide the password of another admin user? When you say it needs an elevated process, does it mean that you need to first have allowed any process through UAC, like you allow an updater to run, then the rogue process that was actively listening for elevated process finds it and injects code in it? It is easily exploitable, can it be mitigated or is the UAC that broken by design that it is completely useless because of this? Lots of questions.

Does any of this work if you activate secure attention sequence on OTS elevation?

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\CredUI]
“EnableSecureCredentialPrompting”=dword:00000001            ;

 

 

1 user thanked author for this post.

ch100

Reply | Quote

This particular UAC bypass method requires an existing (either preexisting or newly launched by malware) elevated process to work, but it doesn’t involve injecting code into the existing elevated process. The existing elevated process might have triggered a UAC prompt when it was elevated, depending on your UAC settings. It appears that any elevated process works for the sake of this method. Here is a summary of the method from https://www.peerlyst.com/posts/wiki-uac-bypasses-and-uac-bypass-research-nic-cancellari:

“Via Tiraniddo (requires an existing elevated process):

1. Capture the admin token and create a restricted version which is no longer elevated.
2. Impersonate the token and get a system service to create a new process using that token. This results in a low-privilege new process which happens to be in the non-limited logon session.
3. Capture the original full privileged admin token in the new process and impersonate, as our logon session doesn’t have the LIMITED_LOGON_SESSION flag the impersonation check passes and we’ve got full privilege again.
4. Works on anything Vista+ it seems. For now.”

When/if an existing elevated process exists within the same desktop, malicious code can use it to get admin privileges without a UAC prompt.

When I tried this code in a standard account, in conjunction with an existing over-the-shoulder-elevated process, it failed to gain admin privileges. But do read paragraph 4 of post #119641.

This seems to be easily exploitable. Perhaps antivirus would flag either the code or behavior. I don’t know of any other mitigations.

1 user thanked author for this post.

AlexEiffel

Reply | Quote

Mr. Brian said – “This particular UAC bypass method requires an existing (either preexisting or newly launched by malware) elevated process to work..”

So as they say, you’re already on the other side of the airtight hatchway!

Reply | Quote

My recommendation is to use a standard account as your everyday account, and set UAC to max level.

Reply | Quote

MrBrian wrote:

My recommendation is to use a standard account as your everyday account, and set UAC to max level.

I consider this being excessive. The default level is just the right balance between security and functionality and this has been tested and proved for the last 8 years.
On the other hand, the Vista original settings were broken, which was corrected later in Windows 7 and possible in the Vista Service Packs.

Reply | Quote

ch100 wrote:

MrBrian wrote: My recommendation is to use a standard account as your everyday account, and set UAC to max level. I consider this being excessive. The default level is just the right balance between security and functionality and this has been tested and proved for the last 8 years.

On my Windows 7 Pro machine the default level IS the max level.

1 user thanked author for this post.

Alice

Reply | Quote

Not everyone believes that the Vista implementation of UAC was broken.  For another well informed view, I suggest you take a look at There are really only two effectively distinct settings for the UAC slider

3 users thanked author for this post.

MrBrian, windows7wasthebest, ch100

Reply | Quote

There are many UAC bypass methods that work (or worked) with below-max settings.

Reply | Quote

It might acceptable to keep UAC at the default level for those using an admin account for only admin purposes.

Reply | Quote

As a first check, would this new session created be immediately apparent by checking with Task Manager? Or, is it hidden from that process?

Would that check work as a positive indication of negative presence in the current instance?

Sorry, that’s kind of dense. If I see something, bad; if everything I see is familiar, no worries? Bad of course would require additional action.

Edit to add: I do not believe I am a target. I am proposing a hypothetical in your scenario, for your advice to others on a first step.

1 user thanked author for this post.

Reply | Quote

If you’re asking about detection of this UAC bypass method, the first link in the first post covers that.

1 user thanked author for this post.

Cascadian

Reply | Quote

Yes, I had read where tiraniddo devoted a section to DETECTION AND MITIGATION where he¹ writes:
— Is there a good way of detecting this UAC bypass in use? Prior to Windows 10 it can be done pretty silently, a thread will magically become more privileged. So I suppose you might be able to detect that taking place, namely a elevated token being impersonated by a non-elevated process. For Windows 10 is should be easier as you need to do one or more dances with processes, at least as I’ve implemented it. I’m not much into the latest and greatest in DFIR, so perhaps someone else is better placed to look at this —

I thought I read you as having performed testing live on your own system; so thought you may have been “better placed to look at this” and determine if my simplified test was satisfactory. The way I read that paragraph says my test fails as a trusted positive test. I was hoping you could pass or eliminate same. Thanks.

¹Note: I am not familiar with tiraniddo, so chose to use the old form of gender neutral ‘he’. No assumption intended, ‘she’ might have been more appropriate.

Reply | Quote

I did test on Windows 7 indeed. I’m not sure what you meant by “new session” in this context though.

1 user thanked author for this post.

Cascadian

Reply | Quote

Yes MrBrian, my syntax error is obvious when you point it out. I apologize for the confusion I caused. Let me retry.

“2. Impersonate the token and get a system service to create a new process using that token. This results in a low-privilege new process which happens to be in the non-limited logon session.” — from tiraniddo quote in your post

Session, is indeed the wrong word for what I wanted: A new instance of a duplicate process, running with impersonated credentials, in the non-limited logon session.

So, looking to WindowsTaskManager\ProcessesTab\UserNameColumn(sorted), SYSTEM would have the new instance imposter running among other authentic processes. Is there a tell-tale detail among the possible columns of information to display that would yield a positive indication that one process among many is the imposter? Or do you only know, because you set the test parameters? That is would you recognize it in the wild without test conditions?

Again, I believe the process would not be distinguishable; but hoped for a simple indicator.

Thank you, for considering my question. Task Manager, used with knowledge, has helped me understand much of Win7. I’m not sure that it helps here.

If I have confused the issue beyond repair; then would you explain for me “If you’re asking about detection of this UAC bypass method, the first link in the first post covers that.”

Reply | Quote

@Paul: I just ran UACMe method 35. The newly created elevated process had nothing in the process user name column, and nothing in Process Explorer’s Integrity column.

Reply | Quote

MrBrian, thanks for the attention you gave to my question.

1 user thanked author for this post.

MrBrian

Reply | Quote

I stumbled across a UAC Bypass blog recently, by a German Masters student:
https://winscripting.blog/2017/05/12/first-entry-welcome-and-uac-bypass/

Reply | Quote

MrBrian wrote:

Anyway, unless Microsoft change things substantially you should consider UAC to be entirely broken by design

Some of us have been at this realization for years.

And to top it off, it’s a poor implementation of that bad design, achieving the worst possible outcomes: A false sense of security coupled with a reduction in usability, not to mention the computer lying to the user (and itself) about where it is storing some data.

All UAC actually achieves, at a cost to all users in general, is a possible reduction in the risk that some users – presumed to be running malware blindly and regularly – will have an immediate and devastating outcome from doing so.

The entire “the computer system is presumed to have malware and must be protected from within” concept needs to be questioned. It’s possible to keep it out.

-Noel

Reply | Quote

From How to turn off User Account Control prompts safely:

“First of all, you should know that besides displaying the elevation prompts, UAC is responsible for a couple of other security-related settings:

File system and registry virtualization;
Protected Mode in Internet Explorer.

[…]

The recommended way of getting rid of the [UAC] prompts is to disable them while keeping other UAC features on.”

Reply | Quote

Please note that James Forshaw also wrote:

“About the safest way of using Windows is to run as a normal user and use Fast User Switching to login to a new session with a separate administrator account.”

I use a standard account for everyday activities in Windows 7. Within the standard account, I usually have an elevated program launcher (I use Folder Menu) running, which allows me to launch other elevated programs from the standard account using Folder Menu without UAC prompts. I also use RunAsRob to start Folder Menu elevated from my standard account without having to supply an admin password. There is a risk that malware running in the standard account could use either of these two programs to get admin privileges.

1 user thanked author for this post.

Elly

Reply | Quote

According to a WikiLeaks document, the CIA has a UAC bypass method named Stinger that might be the same as the UAC bypass method of this topic. I won’t link to the WikiLeaks document; if interested, do a web search for “UAC bypass that obtains the token from an auto-elevated process, modifies it, and reuses it to execute as administrator.”

Reply | Quote

There is some interesting old Microsoft data at User Account Control (2008). See “Figure 2. Number of unique applications and tasks creating UAC prompts.” and “Figure 6. Percentage of UAC prompts allowed over time.”

Reply | Quote

Why UAC is important and how it can protect you (standard account has same protections)

Why you shouldn’t run as admin

 

Reply | Quote

A few examples of why malware might want admin privileges:

Spotlight on Ransomware: How ransomware works Part 1 (reason: ransomware removes file backups)

Intel AMT Lets Hackers Bypass Windows Firewall (reason: turning on a feature to allow stealthy bypass of host-based firewalls)

Reply | Quote

I edited the first post to add a good introduction to UAC.

Reply | Quote

Noel Carboni wrote:

A false sense of security coupled with a reduction in usability, not to mention the computer lying to the user (and itself) about where it is storing some data.

Is this about the UAC virtualization of files and registry?
If it is so, then this implementation is highly annoying to me as well, as it completely misleads a user with a non-priviledged account into believing that they correctly installed or used something.

Reply | Quote

Yes, file and registry virtualization are what I was on about. And yes, I’m aware they can be individually disabled.

Personally to me it feels like knowing my systems are fully capable of doing everything possible keeps me thinking clearly more than getting lulled into a false sense of security by continually being reminded that the computer is protecting itself from my being able to do the things I want to do with it.

-Noel

Reply | Quote