Most environments block the ability to enroll personal Windows devices into Intune. Doing so also prevents them from joining Entra ID if Intune auto-enrollment is enabled. This is because we don’t normally want users’ personal computers managed by Intune. However, if you are blocking personal Windows computers from enrolling into Intune as a security measure, you might be surprised how easily this can be bypassed.
The purpose of this blog is purely educational, I am not going to discuss how a bad actor might gain access to a password or bypass MFA. I will leave that up to your imagination but it’s fair to say that both can be accomplished without a lot of skill or effort in most environments. Let’s assume you are using this blog with legally obtained credentials, and you can MFA, if your environment requires such.
Understanding Windows Autopilot Profile JSON Properties
From the Microsoft documentation we know that, when the Windows Autopilot profile JSON file is pre-installed on the device, the Windows Autopilot deployment can run on the device without having to first perform the following actions:
- Import the device into Intune as an Autopilot device.
- Assign an Autopilot profile to the device.
So, what is the Windows Autopilot profile JSON? Surely it must contain some super-secret values that cannot be discovered by a bad actor, right? Well, no, it does not. Again referring the official Microsoft docs we can see exactly what is required in the file.
To initiate the bypass, it’s crucial to understand the required properties of the Windows Autopilot profile JSON file:
- CloudAssignedTenantId can be discovered by visiting Find your Microsoft Azure and Office 365 tenant ID – What is my tenant ID? and entering the email domain name of the tenant you’d like to join a device to.
- CloudAssignedTenantDomain is the email domain name that you’d like to join a device to.
- CloudAssignedOobeConfig is documented on the page above and some of you guys that are much smarter than I will surely be able to do the math to determine what the possible values are, but I just used my favorite search engine and found examples online where people were using 1310 so that’s what I used.
- CloudAssignedDomainJoinMethod will most likely need to be “0” which means Entra ID join the device.
- CloudAssignedForcedEnrollment I just used 1 but it would be interesting to see if 0 were used whether automatic enrollment into Intune would be skipped altogether.
- ZtdCorrelationId can literally be any GUID. I used an online GUID generator to create one. This will end up in the as part of the EnrollmentProfileName. (More about this later)
- CloudAssignedAadServerData contains a string of information that again is easy to find examples of online. It will be this basically: “{\”ZeroTouchConfig\”:{\”CloudAssignedTenantUpn\”:\”\”,\”ForcedEnrollment\”:1,\”CloudAssignedTenantDomain\”:\”TargetDomainName.com\”}}”
Note: Just for fun I added “CloudAssignedDeviceName”: “BADGUY-%SERIAL%”, to my json.
Executing the Bypass
To test this, I created a brand-new Hyper-V virtual machine, booted from a Windows .iso and once I was in OOBE at the “Let’s start with region” prompt I pressed Shift+F10 to get to a cmd prompt, enter notepad.exe to open notepad, paste in the content of the JSON file, save the file as C:\Windows\Provisioning\Autopilot\AutopilotConfigurationFile.json, and reboot.
Upon starting the computer again prompted “Let’s start with region”, followed by the “Welcome to COMPANY NAME” screen where I entered company credentials. Upon completion I confirmed that the device was successfully joined to Entra ID, the device name was indeed BADGUY-123456, the device is marked to company owned, and is complaint.
VOILA! I have just joined a computer to Entra ID without it being “approved” by my administrator. Without it being “known” by the tenant. Without it being “company” owned. (My boss said I ruined his Wednesday when I showed him).
Take this for what it’s worth and do with it as you please. My hope is that you defend against it. And how might we defend against it you might ask?
Addressing Security Implications
Remember I said, “more about this later” earlier? The EnrollmentProfileName of all devices deployed using this method will be “OffilineAutoPilotProfile-xxxxxxxxx” where xxxxxxxxx is whatever GUID was used as the ZtdCorrelationId. One might create a dynamic group using (device.enrollmentProfileName -startsWith “OfflineAutopilotprofile-“) and deploy a compliance policy to that group. In the compliance policy set something that is impossible to become complaint with. Require compliant devices in your conditional access policies and these devices can get to nothing.
It would be fantastic is Microsoft would give us the ability to disable Offline Autopilot deployments in Intune but until then this is something that is easily exploited.
