Autopilot & The Perceived Tenant Security Risk

Recently there have been concerns raised around Autopilot methods being used to side step security measures, and even leave organisations vulnerable to rogue onboarding of devices with no security sanity check measures in place, once a threat actor had access to stolen credentials.

In this post we will look at how personal devices are typically blocked, where Autopilot comes into place for corporate device tagging, and ultimately ask the question.. Is Autopilot a security risk?

A Brief History of Autopilot

Windows Autopilot has been around since 2017, offering organisations with a streamlined provisioning process for end-users. Since then Intune has matured significantly, and world events in 2020 accelerated the drive for IT departments to make the out of box / onboarding experience more streamlined.

Today it is an integral part of a large number of organisations processes for getting devices to end users, either direct from the factory, or as part of a pre-provisioned stock, joining new devices to your organisations corporate environment has never been simpler.

Hardware Hash

Autopilot like most things has some pre-requisites, and one such pre-requisite has is something called a hardware hash. The hash is collection of elements from your device which are combined to provide a unique identification for that device, a finger print if you will.

Obtaining the hash can be done through PowerShell, and this is process that many will be familiar with, but if you are new to this, then you will need the Get-WindowsAutopilotInfo PS module;

PowerShell Gallery | Get-WindowsAutoPilotInfo 3.8

Are there other methods though? Yes of course there is..

Partner Center

If you are Microsoft partner for instance, you can use the parter center to register devices for your clients without the hash value. Using this method the parter is required to provide three keys pieces of information, these being;

• Make
• Model
• Serial Number

Reseller, distributor, or partner registration of Windows Autopilot devices | Microsoft Learn

Offline JSON

There is another method that some will be familiar with also, this being, the offline Autopilot JSON file, which is essentially an export of the Autopilot profile, allowing the device to connect to the correct tenant and adhere to the settings defined within the profile, BUT, with one key difference… The device can be unknown to Autopilot.

More information on how the JSON can be generated can be found here – Windows Autopilot deployment for existing devices in Intune and Configuration Manager – Step 3 of 10 – Create JSON file for Autopilot profile(s) | Microsoft Learn

Having a copy of the AutopilotConfigurationFile.json for an organisation is something that absolutely should be handled with care, contained within it are information which help the device (any Windows 10/11 device) identify itself as being part of an organisation.

Below is a copy of an offline JSON export, and as you can see it contains the tenant ID;

{
    "CloudAssignedTenantId":  "53707f05-8ca8-4c23-ab74-b876dd85d407",
    "CloudAssignedDeviceName":  "Intune-%RAND:4%",
    "CloudAssignedAutopilotUpdateTimeout":  1800000,
    "CloudAssignedAutopilotUpdateDisabled":  1,
    "CloudAssignedForcedEnrollment":  1,
    "Version":  2049,
    "Comment_File":  "Profile Autopilot AzureAD",
    "CloudAssignedAadServerData":  "{\"ZeroTouchConfig\":{\"CloudAssignedTenantUpn\":\"\",\"ForcedEnrollment\":1,\"CloudAssignedTenantDomain\":\"msendpointmgrlab.com\"}}",
    "CloudAssignedOobeConfig":  286,
    "CloudAssignedDomainJoinMethod":  0,
    "ZtdCorrelationId":  "c894b9ff-9c53-40c2-bf51-b8b2a18d3c8f",
    "CloudAssignedTenantDomain":  "yourdomain.suffix"
}

Taking the tenant ID as a potential piece of information that could be used to onboard a rogue device is of course a concern, however, can we obtain the same information from somewhere else? Why of course we can, there are sites such as ShareGate’s What Is My Tenant ID (Find your Microsoft Azure and Office 365 tenant ID – What is my tenant ID?) which allow you to do just that.

So if the tenant ID can be obtained easily, this means that this field within the file is not truly a risk, but wait, what if I substitute another tenant ID? Could that even work!? That would be terrible, right!?

This is such a question and concern recently shared on Twitter (X). The tweet in question points to this blog post – How to Bypass Intune Device Platform Enrollment Restrictions on Windows (powerstacks.com), in which it talks about how to bypass Intune platform enrolment restrictions. Obviously at this point, many responses started to come back from worried Intune admins.

Now let us then look at this as potential for a security issue.

Faking the JSON

So let us say that we had a organisation we want to target, at this point it might make you believe that you can simply take any tenant ID, which we can easily find out by just the domain name, and then use that information to create a file that would act as a front door key for access into another environment, with a “corporate” device.

This seems to much of a security risk not be have been considered.

Let us try such a method. In the below the JSON has been updated with a different tenant ID, and the theory states that if I take that file and add the updated tenant ID, I can then onboard my device into the target tenant with malicious intent.

{
    "CloudAssignedTenantId":  "53707f05-8ca8-4c23-ab74-b876dd85d407",
    "CloudAssignedDeviceName":  "FAKE-%RAND:4%",
    "CloudAssignedAutopilotUpdateTimeout":  1800000,
    "CloudAssignedAutopilotUpdateDisabled":  1,
    "CloudAssignedForcedEnrollment":  1,
    "Version":  2049,
    "Comment_File":  "Profile Autopilot AzureAD",
    "CloudAssignedAadServerData":  "{\"ZeroTouchConfig\":{\"CloudAssignedTenantUpn\":\"\",\"ForcedEnrollment\":1,\"CloudAssignedTenantDomain\":\"msendpointmgrlab.com\"}}",
    "CloudAssignedOobeConfig":  286,
    "CloudAssignedDomainJoinMethod":  0,
    "ZtdCorrelationId":  "a362cd31-1094-4388-8910-2e2798f9b09a",
    "CloudAssignedTenantDomain":  "yourdomain.suffix"
}

In the above we have used the New-Guid PowerShell command to generate a ZtdCorrelationId, and also updated the device naming convention.

With the JSON dropped into the C:\Windows\Provisioning\Autopilot folder, we can start our device and see what happens;

OK, so we can see the target organisation branding, therefore I must be able to onboard the device with “stolen credentials”.

End User Device

Intune Admin Center

Voila, just like that we now have a corporate device which is compliant and can now act as a jump point to other corporate resources and data. This is truly a case of fake it until you make it!

This is bad, very bad, right?

Well it could be considered to be a security risk, except for the next fact…

Autopilot is NOT a security measure

At this point we are going to point out something that might not be obvious to everyone.

Many admins consider that blocking personal devices in Microsoft Intune to be a security measure that protects them from rogue devices. Personal enrolment can be blocked, and typically should be for non mobile OS platforms (assuming you allow BYOD for mobiles), and this is done from the Device Platform Restrictions section underneath Devices / Device Onboarding / Enrollment;

Policies are configured on a per OS basis, with the exception of the default policy that contains all OS options, and typically we would recommend against editing that policy.

The idea here is that blocking personal enrolment provides bullet proof protection against rogue users, as the device needs to be “corporate”, but how is that state obtained?

For the Windows device to be considered corporate, it needs to be either;

• Hybrid Entra Joined
• Entra Joined
• Autopilot Enabled Devices

Taking this approach, an admin would typically configure a policy similar to the one below;

At this point we already know that having the Autopilot JSON will mark the device as corporate, so then this method is not fool proof, BUT, it is important to have to prevent users onboarding personal devices (outside of Autopilot) when they are within MDM scope.

The next thing that admins tend to gravitate towards is the Microsoft Entra join and registration settings, changing this from the default “All Users” to a subset group:

The issue is that in the scenario of a user who is licensed, but whose credentials were stolen, the user most likely was part of a group that allowed onboarding in the first instance. The thing to understand at this point is neither Windows Autopilot, enrolment restrictions, or registration settings are security measures that protect your organisation against rogue devices.

We are not saying that they are pointless, they absolutely should be part of your overall security protection, but we need to address the actual issue here. In fact we recommend that this is set to “All” to avoid potential device onboarding / registration issues.

The issue of course is the most important thing, the users identity, and how this identity is handled in different situations..

Yes, we are of course talking about good old Conditional Access…

Security Through Conditional Access

Conditional Access (CA) in Microsoft Entra ID Premium 1 & 2 is a powerful rule based solution which takes information from a users’ sign in, to guide them through a set of checks and balances when providing access to Microsoft Entra authenticated apps and services. What is Conditional Access in Microsoft Entra ID? – Microsoft Entra ID | Microsoft Learn

By default new tenants utilise something called “Security Defaults” (Providing a default level of security in Microsoft Entra ID – Microsoft Entra | Microsoft Learn), however, where as the defaults are a good starting point, many opt out of this for granular conditional access to facilitate access control for specific users / apps / device OS types etc.

For many understanding how conditional access works and how it should be optimally configured from a security perspective is a real challenge. The issue though is that unless you take conditional access seriously, it will leave holes that can be exploited.

Now let us explore how CA should be leveraged to help prevent rogue devices.

Require Multi-Factor Authentication

Requiring users to validate their identity through MFA is something that should be seriously considered, as this by itself could provide enough protection to ensure that stolen credentials cannot be used to onboard a device.

Eagle eyed readers would have also spotted that in the Entra ID device settings page, Microsoft clearly also recommend the use of Multifactor Authentication as part of your device registration process;

This setting should however be configured as part of your CA policy design, like in the example below;

With either of the above in place, you can see the where onboarding a device would prove difficult (and we are not getting involved in MFA phished credentials in this post);

As you can see this is the first thing that can be used to prevent successful rogue device onboarding.

But what what else could we do?

Offline JSON Device Block

When a device goes through Autopilot provisioning without being known to Autopilot (.i.e in the Autopilot devices list), there is a key piece of information that we can leverage to identify that device is using an offline profile.

In the properties of the device we can clearly see the name of the offline profile ID used to onboard, and due to the fact that normal corporate devices shouldn’t be using this method, this is something we can leverage in a conditional access policy.

• Create a new Conditional Access policy
• Target a persona group or all users

• Exclude your emergency accounts
  
  Note: Please ensure that you have a working emergency account excluded from policies prior to making CA changes in order to ensure you do not lock yourself out of your tenant.
  Manage emergency access admin accounts – Microsoft Entra ID | Microsoft Learn
  
• Select All Cloud Apps in the Target Resource section

• Under Conditions, first of all select Windows in the Device Platform list

• Scrolling down to Filters, now add a filter that includes devices where the “enrollmentProfileName” starts with “OfflineAutopilotprofile-“

• Enable the policy

With this in place, even if the device has been onboarded into the tenant, the user will be blocked from accessing all corporate applications authenticated through Microsoft Entra ID;

Note: One thing to keep in mind at this point is if you are deploying certificates and VPN apps which DO NOT integrate with Microsoft Entra ID authentication, there still is a potential risk from this device. Again, this is where an overall security design comes into play.

Should you have a scenario where offline profiles are required, the CA rule will need to be adjusted to exclude the offline profile is not matched. For example;

In this exclusion scenario, it is also recommended to use additional control methods to limit where devices can be onboarded from. For example, a particular user group, in a defined location, such as a provisioning VLAN with a different outbound NAT to general internet access.

Should you wish to monitor the extent of devices using the offline method, you can also create a Dynamic Group based on the same logic;

You can also use this logic as a basis for targeting of your autopilot profiles so that devices onboarding with an offline profile are then not assigned a different profile when the “convert all devices to Autopilot devices” option is set.

Ignorance Isn’t Bliss – Notifications

Another feature within Microsoft Intune that can be used to notify end users that devices have been added using their credentials is the “Enrollment Notifications” feature (Set up enrollment notifications in Intune – Microsoft Intune | Microsoft Learn).

Configuring this feature is simple and then for each device that is onboarded, the user will receive a notification in their inbox with the full detail of the device added using their credential. Hopefully this notification might then be observed by the user and flagged to IT in the instance of the device not being known to that user.

Intune Admin Center

End User Notification

Conclusion – Autopilot JSON’s are not evil

The AutopilotConfiguratiionFile.json is something that can of course be used to side step some of the perceived control measures, but in the same breath, these can be tightly controlled with conditional access. Furthermore, the JSON it is also a very powerful tool in your arsenal when undertaking tenant to tenant migrations for instance. Therefore calling for it to be removed as the root cause of all evil is not something we would sign up for.

In fact a rogue threat actor with partner portal access is more of a concern, as they would be able to add a device to the Autopilot device list and avoid the entire offline JSON path.

We understand that security is a hard topic for many, and organisations often have much internal infighting trying to apply rules that “might impact on end user productivity”, but done correctly, conditional access is something that will not only protect against rogue devices, but protect against so much more.

So please invest time in CA, and our recommendation is to use a persona based approach. Further information on this can be found here – Conditional Access architecture and personas – Azure Architecture Center | Microsoft Learn. As always please ensure you limit the scope of your CA policies during testing, screenshots and walk throughs are provided as a guide, without liability.

Thanks for reading!