blog.kanbach.org

This is a short story that describes an alternative way of breaking out of the Windows Out-of-Box-Experience (OOBE) and gaining access to the command line of Windows with the privileges of the user defaultuser0 who is part of the local Administrators group.

What is OOBE?

To get everyone on board, I would like to briefly describe what OOBE is, and when these screens appear to the user.

The Windows Out-of-Box-Experience is a series of screens that the user is presented when Windows is initially started after its installation. Alternatively, OOBE can also be enforced, if the Windows tool Sysprep is executed, that could be used to place Windows into the OOBE state after a reboot.

OOBE is typically used for initial configuration of the operating system that covers language selection, keyboard layout, adding initial user accounts and configuring the privacy settings.

Blast from the past: Shift + F10 for elevated command prompt

In the history of OOBE, the keyboard shortcut Shift + F10 is a well-known, yet dangerous feature within OOBE that could be leveraged by regular domain users who first perform a push-button reset via the Intune Company Portal to reset their PC and then utilize Shift + F10 in OOBE to spawn an elevated command shell.

OOBE is executed in the context of the local user account “defaultuser0” that is a temporary user during OOBE and is a member of the local Administrator group. A command shell running as this user could be used to create further local administrator accounts, change the password of the built-in administrator, or place a backdoor on the operating system.

Luckily there is a possibility to disable the shortcut, by placing an empty file called DisableCMDRequest.tag into the folder C:\Windows\Setup\Scripts\. The file must be present after each wipe, and how this could be achieved is well described in https://call4cloud.nl/the-oobe-massacre-the-beginning-of-shift-f10/.

So now it would be safe to assume, that by creating this file no breakout would be possible anymore, right? Well, not exactly, and the new way of spawning an elevated shell is described in the following section.

Alternative way of launching a shell: Win + R to the rescue

Within OOBE it is possible to spawn a hidden command shell, or execute arbitrary other commands via the Run dialogue. This technique is not affiliated to the Shift + F10 keyboard shortcut.

To launch the Run dialogue, it is possible to use the keyboard shortcut Win + R like you would do in a normal Windows session. Wait… is it really that simple? Well, almost - For this keyboard shortcut to work, the focus needs to be on a different window first. As an example, the tool Magnify.exe can be opened via the accessibility tools. When the Magnify window is clicked and Win + R is entered, the Run dialogue is spawned.

This dialogue however resides in the background and can't be seen directly. However, its existence can be revealed by entering Alt+Tab to switch between windows.

As mentioned before, the user associated with the dialogue and all subsequent actions is defaultuser0. Since this user is an administrator, it is possible to launch an elevated command shell via the Run dialogue.

To make Run launch an elevated shell, first the focus has to be on the Run dialogue window. Then by typing in cmd.exe and pressing Ctrl + Shift + Enter afterwards, an elevation prompt is executed (Consent). When this UAC prompt is accepted by clicking “Yes”, an elevated command prompt is opened, which however still resides in the background. Nevertheless, by typing in commands, it is possible to interact with this shell.

Local users could exploit this behaviour to create backdoor accounts or modify the system in an arbitrary manner. This even works, if the file C:\Windows\Setup\Scripts\DisableCMDRequest.tag is present, a file intended to block the well-known Shift + F10 keyboard shortcut from spawning a visible elevated shell.

At this moment no remediation is known and Microsoft does not consider this keyboard shortcut as a security issue ("[…] due to that fact that OOBE runs in an admin session and leaving new device unattended during OOBE is like leaving the machine unlocked.").

For this reason, the best way to prevent domain users from resetting their PC via the company portal and then act as a local admin in OOBE is to hide the reset button from users in the Company Portal. To do this, first navigate to the Microsoft Intune admin center then in the left pane, select Tenant administration and then Customization. Afterwards, either modify the default policy or a custom one if you created one in the past. In the policy, make sure that Hide reset button on corporate Windows devices is checked.

Conclusion

Windows OOBE presents the user an open by default interface that runs with high user privileges. Allowing corporate, low-privileged users this level of access poses an inherent security risk. However sometimes entering the OOBE screen is possible for users as well via the push-button reset function in Microsoft Intune. Therefore Microsoft implemented measures to lock down OOBE in order to prevent gaining a shell via simple means. As this measure however is incomplete, since it doesn't take all possible keyboard shortcuts into account, it is still possible for arbitrary users within OOBE to spawn a shell. Microsoft treats it as a “won't-fix”, so be careful about whom to grant the push-button reset privileges.

References

[1]: https://call4cloud.nl/the-oobe-massacre-the-beginning-of-shift-f10/