[solved] HID Backdoor: Start elevated shell if target user is administrator (UAC bypass)

[tomisboy]

Is it even possible the get the shell (wiht the HID wifi Background) with admin right
while having UAC enabled ?

[mame82]

Good question. Not at the moment. The first stage doesn't include an UAC bypass.

Have to wrap my head around a proper solution fo this. Quick and dirty way would be to prepend keystrokes to run the initial powershell with elevated privileges, but this doesn't seem to be a clean solution (based on context menu or dialog).

[PoSHMagiC0de]

Add another fire command or argument to try for admin to run...
powershell -c "start-process powershell -verb runas"

ALT Y to select yes if they are admin to say yes for run as admin.
add another enter after the ALT Y as some systems will not prompt for permission if they are admin so move to a clean line in case you added a Y to powershell console.

Write code to execute shell now.

I actually was going to add an extra payload copying your fire one and adding the extra commands to invoke as admin. Trying to do it silently with exploit usually involves you launching another agent process with the new rights so in beginning better to get it up front if possible. of course if they are not local admin then it will fall apart so user of app will have to know if they are admin already or not.
Maybe add an admin checker payload. It will just try to fire off something as admin and escape out when done, attacker will have to verify visually if they got a prompt for credentials or not.

Just tossing ideas as these are things I was planning on playing with in the project.

[rogafe]

from my test powershell -c "start-process powershell -verb runas" cant be detect by avast don't know for other av

[PoSHMagiC0de]

The above is a common usage for the PS commandline so it will never be detected as malicious. Maybe a warning in the future but to rule a feature as malicious would break too many things.

[mame82]

This payload tests an UAC bypass, I'll implement it as shown in the video. The approach is very similar to the one described here. It doesn't rely on ALT+Y to confirm the UAC dialog and thus doesn't depend on the target language

https://youtu.be/uu15fIb9vbs

[mame82]

The dialog based UAC bypass has been published with this commit:
e23fd4d

Usage FireStage1 uac

Additional remarks:

• No error handling if user isn't administrator. This could be checked from PowerShell with $elevated=(new-object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator), but deploying a check condition makes the keyboard stub even longer
• instead of supplying the -c argument like powershell -c 'start-process -verb runas ...', two powershell sessions are started sequentially. The start... command is typed into the first session, in order to start the elevated second one. I've decided to do it in this way, to avoid logging a suspicious command to GUI r dialog history.
• The window hiding code is only ran for the second PowerShell window, as the first one exits fast (directly after the asynchronous stat-process CmdLet is issued) . The delay given to FireStage1 (default 1000ms) is used for both PowerShell consoles before typing commands starts.
• Instead of using ALT+Y or ALT+J or whatever combination has to be used on the target OS language, I've chosen to use SHIFT TAB to confirm the UAC dialog. This approach doesn't depend on the language, but the "no" option of the dialog has to be preselected (It has been tested on Windows 7 and Windows 10 with German layout and works in both cases).

@ALL
It would be nice if anybody is willing to document that or perhaps write a tutorial on a practical use case (for example dumping SAM from Volume Shadow Copy). Time used on documentation is missing on development (and my time is rare).

@PoSHMagiC0de
An additional note on running PowerShell through the backdoor.
Firstly shell powershell could be used to start a remote powershell session. This feature isn't documented, because of the following issue. Most processes produce output via STDOUT and STDERR which is piped through the HID tunnel to P4wnP1. PowerShell, on the other hand, uses more character streams (for example StandardOutput, ErrorOutput, DebugOutput ...). Windows 10 does a good job on redirecting this output to STDOUT and STDERR (I suppose this is done by the console host of the powershell.exe process). Windows 7 doesn't a good job on this, as output isn't redirected to the STDOUT and STDERR stream of the host process, but to STDOUT and STDERR of the topmost parent console (the one which runs on the target and gets hidden by FireStage1). If this happens, the output of the remote PowerShell processes ends up in an invisible Window (using FireStage1 nohide it could be shown on the target) and couldn't be fetched from the process STDOUT/STDERR streams, in order to tunnel it to the P4wnP1 server.
I wasn't able to solve this so far and there are other ways to interact with PowerShell.

[mame82]

FireStage1 uac does neither use ALT+J, nor ALT+Y as this would depend on target OS Language (not necessarily the same as keyboard layout). There sholdn't be a need to add in something like this, unless the target user is missing Admin privs. This would pop up a password dialog (unhandled error case)

[PoSHMagiC0de]

Hey @mame82

Looks like a lot of what you are doing has been done in my project...kinda except you added some improvements. Check out example payloads in the job folder for the project I built for the BB. The Invoke-Adminjobs does the admin check like you do above, I got it from the Empire Project. I have the sethc backdoor too you have. Been my go to method for customers who locked themselves out of their machine as long as I can access the drive if booted from a bootdisk. There might be other ideas you can snake if you like from it for this project.

https://github.com/PoSHMagiC0de/BBTPS

[mame82]

The Invoke-Adminjobs does the admin check like you do above,

It is a common test, but anyway useless in my case.
I need to know if the process has a split token (tokenElevationType = limited), as this would mean the user is admin, has UAC enabled but the process isn't elevated. If exactly these conditions are met, triggering and confirming the UAC dialog makes sense.
The admincheck from above only tells you if the process is already running elevated. It would fail if a user is in Admin Group, has UAC running, but the process isn't started elevate (this can't ve distinguished from an unprivileged user starting the same process).

I have the sethc backdoor too you have.

Again a common task, but we have different approaches. Flying over your PS code, it seems you're operating on file system (granting permisdions to sethc.exe and replacing it with cmd.exe).
I don't touch these files. Instead a registry based approach is used to preload cmd.exe as debug binary, when sethc.exe is launched.

Your projects seems promising.
Anyway, all payloads in P4wnP1 are meant as PoC or demo on how to build payloads. With exception of the covert HID channel payloads, all payloads replicate common tasks for pentesters and automate these tasks.

The purpose of this project is to provide a framework, which is able to do such tasks ... its purpose is not to provide deployment-ready attacks. But obviously some demos are needed, to allow users to understand how such tasks can be conerted into a short payload fo P4wnP1.

[PoSHMagiC0de]

@mame82
Same. BBTPS is meant as a system to load your own attacks that run asynchronously. I needed to create demos because some people were not getting it. Another reason why I have been trying out your CreateProc with different commands and output types so I can have some feedback for the project on how to use it with existing scripts. May need an easy was to output say a file that has the commandline you want to run to the CreateProc function. Right now I have to use screen's copy and paste. Had to look it up, I was trying to use regular terminal's copy and paste and had issues hehe.
What I found out is with the createproc it is most effective if people have their scripts ready. Since these will be ran from the powershell commandline, it would be best to use Powersploit's out-encodedcommand script to create a compressed encoded command to use. Inside the script the return type depends on what you are returning. If you are sure what you are returning is a single string, not a collection of strings then piping to out-string works fine..on Windows 7 even.
If you are outputting an object, the converting to either csv or json will make it so it shows up in the P4wnP1 terminal. Use Convertto-csv -notype or convertto-json.