Hacking admin rights on an Autopilot-installed Windows device (Return of the Shift + F10)

In this post, I will reveal a security flaw in Autopilot, Microsoft's new solution to deploy Windows machines to end users. I will show you how end users easily can get administrator rights during the installation process.
Latest posts by Sami Laiho (see all)

The first thing every hacker needs to get into your network is a compromised endpoint. To install bad things in your network knowingly or unknowingly, hackers need admin rights for the user they have compromised. You need BitLocker to keep people from getting admin rights if they have physical access. And users can't install their own machines because then they would be admins—the first user account created in Windows is always an admin by default.

The most recommended security concept to fight against malware for years has been to remove admin rights from end users. This is why I was so happy when Microsoft introduced their new solution for replacing the old disk imaging: Autopilot! With Autopilot, you can provision your company's computers and, in a way, transform them from consumer devices to enterprise devices. The process is highly automated, and the only thing it requires is:

  1. The company buys a device from a manufacturer.
  2. The device's identification information (given by the manufacturer or retrieved with a script by the company) is registered in a cloud service.
  3. The user receives the device and unboxes it.
  4. The user powers on the machine.
  5. The traditional out-of-the-box experience (OOBE) starts.
  6. The user logs on with an Azure Active Directory (AD) account and password.
  7. The computer is identified as an Autopilot device.
  8. The computer provisions things like changing the SKU to Enterprise, installing apps, configuring security settings like enforcing BitLocker, and joining an Azure AD (and potentially an on-prem) domain.
  9. The user has an operational enterprise device with no intervention from the IT department and the computer never having seen the company premises.

Now back to the admin rights. The good thing for security is that Microsoft markets Autopilot as a solution where you don't have to give the end user admin rights at any point. A configuration setting when the company builds the setup bars Autopilot from granting admin privileges. Great! Now we can deliver machines to end users straight from the manufacturer, have them upgraded and configured correctly, and never give users admin rights!

Or… are you sensing a "but" here? 😉

Here we have a computer started with Windows 10 1909 OOBE, and the first screen looks like this:

First screen of a new computer in Out Of The Box Experience

First screen of a new computer in Out Of The Box Experience

We continue through the screens normally until we can log in with our Azure AD credentials like here:

Choosing to configure the computer for enterprise use

Choosing to configure the computer for enterprise use

Sign in screen for Microsoft or Azure AD accounts

Sign in screen for Microsoft or Azure AD accounts

Now if I continue normally, I will never get admin rights. But if at any point I hit Shift + F10, I get a command prompt with admin rights like here:

Command prompt with full admin rights after pressing Shift + F10

Command prompt with full admin rights after pressing Shift + F10

I can now create an admin account in various ways, for example, like this:

Adding an admin account to the newly unboxed computer

Adding an admin account to the newly unboxed computer

After I've finished the installation, I can use the "hacker" account when I need admin rights or add my Azure AD account to the local administrators group with this command:

😊

From a bad guy's perspective, I would say it's very tempting to find a computer in a box delivered to a company or just resetting the computer if it has already been provisioned!

And yes, I know, this breaks the immutable law of security: "If someone has physical access to your computer, it's not your computer anymore," and all bets are off in that sense. But Microsoft, please, can you make it at least slightly more difficult than just hitting Shift + F10?

Want to write for 4sysops? We are looking for new authors.

Read 4sysops without ads and for free by becoming a member!

5+
Share
22 Comments
  1. Nigel Brown 7 months ago

    Two things - the experiece you showed is not Autopilot - this is standard OOBE. Second - corporate policy can (should) remove / disable local admin once policy is in affect. This is standard deployment stuff (having a local admin to deploy, and then removing) and I would not consider this any sort of security hole. 

    0

    • Author

      This is the exactly same experience for Autopilot and OOBE. Compared to an attended installation of an end user machine you have no idea how compromised the machine is. If I deliver you a machine with BitLocker on it, prebuilt in your deployment solution, you won't get admin rights - this way you can. Of course if you are doing self-provisioning you need accept certain risk. My point is just that it might not have to A. Be THIS easy. B. That debugging window could run something else that full admin. 

      4+

    • Benjamin 6 months ago

      If you make a local admin like this, then you skip it from even enrolling properly if using intune. I know depending on how it's set up, you still have to sign in with an Azure AD account, but if you shut the computer off after you've finished the prompts and before it can enroll it, then it never enrolls. Therefore, no way to remove this admin account. And speaking for autopilot, Microsoft claims this can be sent directly to the user with no intervention from IT. Except now we have this problem which defeats the whole purpose.

      0

  2. Vasile Jichin 7 months ago

    It s the same thing more or less with task sequence debugging, I doubt that this will be removed.

    0

  3. Lakes 7 months ago

    Autopilot does not conclude until all policies are in effect. The policies should include disabling of all local admin accounts

    0

  4. Jakob Heidelberg 7 months ago

    If you want security - then don't try to get a Windows endpoint on-board that has been controlled by somebody else. Yeah, you can diabled all local admins, I don't care, my stuff runs in a scheduled task, a service, a WMI trigger or some other persistence mechanism. This way of deploying endpoints is bound to fail. You're welcome to accept the risk, but just understand the risk.

    2+

  5. Carter 7 months ago

    The Shift f10 key saved me.  I was board at work messing in the window registry and change a setting to make windows think it was starting for the first time then rebooted my computer.  Well my computer had a pending windows update and when it booted it came up booting for the first time but then it came up updating windows.  That confused the OS and it c awww me back say it can't update when betting for the first time and then rebooted resulting into a forever loop.  

    Luckily it was the end of the day so I went home and researched how to get a command prompt during Post boot and found the shift f10 and was about to get backing the regedit and change the value.  My IT never knew about it.

    0

  6. Wilson King 7 months ago

    This is not a security problem. You can make as many local admin accounts as you want, but as soon as that machine is joined onto the domain, then group policy will remove those accounts. After that, you can't add your domain account to the local administrators group because you no longer have any local admin rights. Others have pointed this out too.

    0

    • The thing is once an attacker obtained admin rights, he can manipulate the system in a way to regain access after his admin account has been removed via Group Policy. As things stand now, every script kiddy can do this. It does not really require a hacker or sophisticated malware. Thus, this is certainly a severe security hole and could be prevented if the entire deployment process was encrypted by default.

      It seems Microsoft either lacks the engineers to get this done, the management doesn't really care about security or both. My guess is the latter applies. I mean the fact that the Shift + F10 thing still exists, speaks a clear language. Everyone who knows how to use a keyboard can exploit this.

      3+

    • Benjamin 6 months ago

      Group policy won't take affect if you're able to create an admin account and also not let the computer enroll. At least for intune autopilot setups. You can do this by shutting down the computer after you go through all of the prompts and before it actually creates the account it's supposed.

      0

  7. Jakob Heidelberg 7 months ago

    Not a security problem that malware can be running silently in system context without enterprise admins know about it? You must be kidding?

    2+
    avatar
    • Wilson King 6 months ago

      No, I wasn't kidding. We are talking about a system that just came from the manufacture and is in the middle of performing OOBE for its first time. You are physically present at the machine and physically pressed Shift + F10 on the keyboard. What malware is running on the machine at this time? None. What malware could be on the machine? Its a brand new fresh install that hasn't even hit the desktop yet. Explain to me at which point the machine is vulnerable to malware? Are you talking about malware you will load from a USB drive after you press Shift + F10? Again, that's you physically at the machine. Are you talking about malware that find's its way in over listening network ports? What malware is on the machine during this OOBE and describe a valid hypothetical situation other than just "but malware, bro".

       

      1+

  8. Jakob Heidelberg 6 months ago

    *You are physically present at the machine and physically pressed...*

    No.  That's the problem right there. The way Autopilot is used, a regular user (not just "you") can go buy a PC and enroll with Autopilot, but it shouldn't be possible for him/her to get privileged access during enrollment process.

    By being admin (e.g. having shell) for just a short amount of time, a malicious user can control the endpoint, potentially forever.

    Let me give you an example: I could setup a scheduled task running every minute as System, executing a script file under "c:\script.file". Now all a "regular" user has to do to install or do whatever as System, is to manipulate that file after OOBE has completed.

    I could give you a lot of methods, some I mentioned above too, but I'll leave it to you imagination.

    1+

  9. Maurice Heine 6 months ago

    I think that one valid point that Sami makes in this post, is that Microsoft gives the illusion that if you use Autopilot, you don't have to worry about admin rights.

    Most people replying here seem to be experienced admins and claim they would not fall for this trick. Then again, most also seem to think that modern desktops are by definition domain joined... Our company is working on getting rid of our dependency on AD and moving to the cloud instead. Intune manages our systems, but stuff like LAPS isn't available out-of-the-box in Intune. We have to rethink the use of admin accounts and so does Microsoft/

    Pointing out flaws like this helps make people aware of these kind of risks and hopefully pushes them (and Microsoft) to to countermeasures.

    2+

  10. rebelemerald 6 months ago

    Yes there is always a way to break things. As an end user you shouldn't be hacking your way to admin rights on you machine by purposely breaking SOP. If you are that user then you are the security risk.

    I would like it if users were required to use a wired network (and connect to power). 

    0

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2020

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account