- Hardening AppLocker - Thu, Jun 25 2020
- AppLocker Audit vs. Enforced mode - Tue, Jun 23 2020
- Creating AppLocker rules from the Windows event log - Wed, Jun 17 2020
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:
- The company buys a device from a manufacturer.
- The device's identification information (given by the manufacturer or retrieved with a script by the company) is registered in a cloud service.
- The user receives the device and unboxes it.
- The user powers on the machine.
- The traditional out-of-the-box experience (OOBE) starts.
- The user logs on with an Azure Active Directory (AD) account and password.
- The computer is identified as an Autopilot device.
- 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.
- 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
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
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
I can now create an admin account in various ways, for example, like this:
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:
NET LOCALGROUP ADMINISTRATORS AzureAD\Sami.Laiho /add
😊
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!
Subscribe to 4sysops newsletter!
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?
IT Administration News
- Google unveils Veo, a high-definition AI video generator that may rival Sora | Ars Technica
- OpenAI created a team to control ‘superintelligent’ AI then let it wither, source says | TechCrunch
- Microsoft to start enforcing Azure multi-factor authentication in July
- Linux maintainers were infected for 2 years by SSH-dwelling backdoor with huge reach | Ars Technica
- Microsoft aware of Windows Server KB5037765 0x800f0982 error
Join our IT community and read articles without ads!
Do you want to write for 4sysops? We are looking for new authors.
-vulnerability-480x270.png)
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.
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.
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.
It s the same thing more or less with task sequence debugging, I doubt that this will be removed.
Autopilot does not conclude until all policies are in effect. The policies should include disabling of all local admin accounts
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.
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.
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.
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.
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.
If you don't let the computer enrol then you don't get access to the corporate resources. What is the use of gaining admin on a blank machine?
Not a security problem that malware can be running silently in system context without enterprise admins know about it? You must be kidding?
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".
Old post, I know, but I see several people don’t get the security flaw.
The idea behind autopilot is that the device is sent from OEM/hardware supplier towards the end user directly, who then configures their device with OOBE and receives all policies. No complete supervision of this process is done.
An attacker (could be end user, could be someone intercepting the package between OEM/hardware supplier and end-user) is able to insert malware onto the device as during the process admin permissions are available to the attacker. Just removing a created admin account is not enough: other persistence methods could have been used by the attacker to reobtain this account (for example by creating a scheduled task, but that’s just one of the options).
A control should thus be added to mitigate this risk:
– Make the OEM use a provisioning package to disable shift+F10. You create a risk of not being able to (fully) support the device when having autopilot issues though.
– Use WhiteGlove in a supervised environment (this wasn’t available back when the whole conversation was ongoing).
*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.
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.
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).
Just use a provision package with your OEM and turn off shift-f10 capability
Well, the bad actor would need access to the device _and_ credentials, and they would only get local adminastrator rights at the end. No guarantee for lateral movement, privilege escalation in a domain, etc. The same thing can be achieved on a new (not reset) device simply by not connecting it to the network at OOBE, create a local account, join with credentials to azure AD once inside windows. An added bonus is that installation of malware would be through the regular gui. Local admin guarantee, autopilot circumvented.
Long story short, you can’t really trust that all your devices are without local admin without additional verification.You can create a proactive remediation to uncover local administrators and subsequently remove them.