Today’s blog post concerns a security risk often overlooked by IT admins and organizations. It involves creating a local admin account using OOBE during or before deploying a device—a critical aspect that, in my opinion, needs to be addressed. Read the blog post to prevent privileged escalation during OOBE or unauthorized access and enhance security.
Earlier, a security testing company contacted Microsoft about the security risk/potential bug; they stated the following: We have completed our investigation and found the issue submitted to us is not a security issue and is by design; this issue doesn’t meet the security servicing bug bar.
Chapters
Some example scenarios
In this scenario, the hardware supplier prepares the device or IT Servicedesk then ships it to the user. The user only needs to log in to complete the final phase of ESP, which is the Account Setup phase. The Device Preparation and Device Setup ESP phases have already been completed.
The device already has the company image, and the user is expected to proceed through the enrollment steps, completing the three ESP phases: Device Preparation, Device Setup, and Account Setup.
As you may know, during the pre-ESP or ESP phases, when using Autopilot, it’s possible to use the SHIFT + F10 keyboard shortcut to initiate a command shell, mainly for troubleshooting by an IT admin. However, this capability can be exploited by a malicious actor. While blocking SHIFT + F10 for IT admins is an option, it can make fixing problems on the device more challenging.
With this command shell, a malicious actor can execute various commands. In this blog post, we specifically address the creation of a new account and adding it to the local Administrators group. This allows the malicious actor to perform tasks with administrator rights after enrollment, which we want to prevent.
Key to Success
- Creation of a configuration profile using Settings Catalog
- Windows LAPS (Account protection)
- Local user group membership (Account protection)
Technical Requirements
- An account with at least Intune Administrator permissions
- Intune subscription with at least Microsoft Intune Plan 1
(This license is required to apply the Windows LAPS policy to a device) - Windows 10 20H2 (19042.2846) and later for LAPS to work
- Intune subscription with at least Microsoft Intune Plan 1
Demonstration
So, what exactly do we mean by “prevent privileged escalation during OOBE”? The example below shows a prepared Windows 10/11 image that has not yet been further deployed. In this scenario, the laptop is booted, and the user is expected to start the rollout. In both pre-provisioning and user-driven enrollment, the screen below will appear.
As shown in the video, a Test account was created by launching the command shell by pressing SHIFT + F10 and making it a member of the (local) Administrators group. We weren’t prompted with a UAC window. So the user can create an account in advance that can be abused later after enrollment. When users don’t automatically have local admin rights, this is not ideal and can be considered a security risk; therefore, we want to prevent privileged escalation during OOBE.
Having successfully enrolled the device, the user can sign in and perform administrative tasks without requiring local admin rights. This is what we mean by preventing privileged escalation during OOBE.
Mitigate
First, remember that there are several ways to address this issue. In my demonstration, I chose a straightforward solution without using scripts and applications, which should make it more accessible to configure.
1. Configuration profile (Settings catalog)
Configuration profile is used to rename and enable the built-in Administrator account. It is strongly recommended that the built-in administrator account be renamed. This will make it more difficult for a malicious person to abuse the account.
1. Browse to the Intune portal
2. Click on the Devices | Windows Configuration profiles section, choose Create a new policy, and give it a name and description.
3. Click on +Add settings and search for the following two settings:
4. Configure the following two Local Policies Security Options:
– Accounts Enable Administrator Account Status: Enabled
– Accounts Rename Administrator Account: “youradminnamehere”
Please remember to set the first setting to Enable; otherwise, the Administrator account will be disabled by default, and you won’t be able to use the admin account.
Assign this policy to a device group and save the policy.
We choose a device group instead of a user group assignment because, first, we want the policy to be applied at the machine level, and second, during pre-provisioning, the policy lands on the device as quickly as possible.
2. Windows LAPS
(Account protection)
We use Windows LAPS to rotate the local administrator password. This way, you are not bound to a default password. This is a paid feature. Using Windows LAPS will not create the local administrator account. We use the Local user group membership configuration to create the local administrator account (see below). This step is crucial; without a created local administrator account, Windows LAPS won’t work if you change the default built-in Administrator account. It will fail with the error that the configured account cannot be found.
Please note that some additional steps must be followed to use LAPS. Other community members have described step-by-step instructions on how to activate LAPS in your tenant. The following will not directly cause Windows LAPS to be active in your environment.
1. Browse the Endpoint Security blade and search for Account Protection under the Manage section.
2. Create Policy and choose Windows 10 and later as a Platform and Local admin password solution (Windows LAPS) as a profile.
3. Now, configure a Name and Description for the policy and click Next.
4. Now configure the settings based on the organizational need; remember to change the Administrator Account Name settings to the name you have configured in the previous step.
5. Assign this policy to a device group. This will ensure that the policy has been pushed on the client when a device has been pre-provisioned by the hardware supplier or the IT Service Desk.
3. Local user group membership (Account protection)
Even when the user has created the account before and made it a member of the Administrators group, it will be removed as soon as the policy lands on the device.
As a precautionary measure, a new Administrator account will be created. By following this step, we ensure that previously created accounts are removed and will be replaced from the Administrators group. To do this, we use the Add (Replace) function.
1. Browse to the Endpoint Security blade and search for Account Protection under the Manage section.
2. Create a Policy, select Windows 10 and later as Platform and Local user group membership for the Profile, and click Create.
3. From there, we configure a Name and Description for this policy.
Now that we have completed the mentioned steps, we will create a Local Admin account to be added to the device. This step is crucial for LAPS to recognize the Administrator Account Name.
4. Choose as the Local Group -> Administrators;
5. for the Group and user action, Add (Replace);
6. for the User selection type, select Manual;
7. Selected users/groups type in the admin account name that needs to be created.
8. Now, click Next and assign this policy to the device group.
Verify
Once the above steps have been followed, the next step is to verify that the policies and configurations land on the device. The difference between a pre-provisioned device and a user-driven enrollment is that with pre-provisioning, the policy has already landed on the device. For a pre-provisioned device, you can try invoking SHIFT + F10. The device will immediately create a UAC prompt and ask for the Administrator credentials. If so, the policies have successfully landed on the device. You can try to check the locations below to verify. The user can still run a command prompt but without administrative permissions. So, creating a new user will result in access denied.
Configuration profile
To verify that the device’s configuration profile has been applied, open the Computer Management settings to verify that the built-in Administrator account has been renamed and enabled.
The previous created Test account has also been removed from the Administrators group as you can see in the screenshot below.
You can verify if the account rename was successful by searching the event viewer for security event id: 4781
Windows LAPS
Verify that the LAPS policy has landed on the device by browsing for the following registry value: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\LAPS.
If there are any errors or the policy didn’t apply/change, try to open the event viewer and browse to the following section:
Applications and Services Logs – Microsoft – Windows – LAPS
Wrap-up
Microsoft knows invoking a command prompt with the SHIFT + F10 hotkey is possible. They made this available now because they feel allowing admins to troubleshoot a device may be more burdensome. I think this is a missed opportunity from a security perspective and would ask Microsoft to reconsider.
I hope this blog has inspired you to choose this solution in future and existing deployments.
I close this blog with a word of advice: prevention is better than cure!
How does this help? When you Shift-F10 you are running as the defaultuser0 account, which is in the local admin group. I don’t need the local administrator account for anything. what am I missing?
You’re right that when using Shift-F10 during OOBE, the defaultuser0 account is active, and it does have local admin privileges. However, the concern here isn’t just the existence of defaultuser0. The real risk is that a malicious user or attacker could create an additional local admin account during the setup process and use it later to gain access, even after the device has been fully enrolled and in use.
The measures I’ve outlined, such as using Windows LAPS and a local user group membership policy, are designed to ensure that no unwanted local admin accounts remain on the device after deployment. This prevents anyone from retaining admin rights post-enrollment, except for the accounts you’ve explicitly configured and managed through LAPS. Without these steps, the risk of privilege escalation remains, which is what we want to avoid.