Intune Devices invetigation with MDE & Microsoft Sentinel

Are your Intune local users configured as local admin? Do you’ve got additional admin users on Intune devices? In most cases, Intune users could be the Local administrators, and it’s a feature without any disruption, and this is by default.

This blog post described a specific security issue for Intune local admins and how to monitor and defend with MDE and Microsoft Sentinel with several notes and tips.

You know that if you’re not working correctly with the password policy on Intune devices, your local admin account is exposed and received the wrong settings…

Intune Local Admin

In short, it looks like the local administration is significantly more complex with Azure AD joined devices and Intune, especially for larger organizations where different groups of users need administrator access to other groups of machines. For example, when enrolling a device through either the self-service or autopilot, the user who joins the machine to Azure AD will be made a local administrator.

Note: in the case of autopilot, only if enabled in the autopilot profile.

Two additional SIDs will be added to the “Administrators” group on the local Azure AD machine as part of this process:

-The SID that represents the Global Administrator role in Azure AD

-The SID that represents the Azure AD Device Administrator role (referred to as Additional local administrators on Azure AD joined devices in the Azure portal)

TIP: Make Me admin is an open-source application that is freely available that allows standard users to be elevated to administrators in Azure AD devices.

In addition, Microsoft has announced that with the release of 20H2, new functionality will be available for adding and removing users from the local groups on the machine. Unfortunately, there is not much information about the functionality at this stage. However, we expect to see documentation once 20H2 is officially released.

OLD Policy Snippet

A password policy is best for account security, whether for domain scenarios, locally, or wherever passwords are used.

For example, in the Active Directory world, the domain accounts have a default domain password policy or, in other circumstances, an additional policy with a fine-grained password policy. 

Azure AD accounts have the Azure AD password policy for all of their objects, and you can use Intune to set this if you want for any device.

For example, you can deploy the Windows 10 Security baseline in Intune. It will deploy a password policy to your local accounts and your Azure AD account on local machines. Sound promising 🤞

Nevertheless, deploying a password policy via Intune to Windows devices can have an unexpected side effect. The side effect behavior can force a local account to change the password at the next login without reason.

NOTE: if you apply password rotation for the local administrator account using a LAPS solution, this becomes a half workaround because password rotation will fail due to changing the password at the next login.

What is under the hood that you don’t familiar with it? There are so many “little things” when Intune sets a password policy. For example, it uses the DeviceLock policies based on the Policy CSP. 

There are old policies from the Exchange Online world in ancient cases.

For example, it uses the Exchange Active Sync policy engine to set the password policies created back in the Windows 8 days to enforce security policies on devices that sync with Exchange.

When reading the documentation from Microsoft Docs, you will get the password length and complexity policies description and explanation. 👇

If for some reason, you are under this scenario and you must enable a password policy, some default values will set password length and complexity. Once the policy applies, it will require that a local administrator account change its password at the next login. (there’s a but 🤦‍♂️)

But, the EAS is good for old cases, and what if you’re using the new Intune policies? You still have the same password issue because the password policy behaves with the exact mechanism, so the same mechanism is the same issue, no? YEP.

Intune (DeviceLock) Policy

The Device Lock configuration service provider is used by the enterprise management devices to configure device lock-related policies. This configuration service provider is supported by an enterprise management server (the Intune MDM).

Wait, there’s more. Hence the only way it can be sure it complies is to force you to change it, and the new password must meet the policy requirements, and with this behavior, it can accurately report whether the device is compliant with the policy. Again, it seems fitting, but forcing the password changes will break your LAPS solution as you cannot change the password or even remove the requirement with a policy that alters the password at the next login – you’ll get some friendly errors if you try.

Once the password policy is set to your devices, you will view the local configuration via Registry. To view the DeviceLock open the following path via Regedit: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceLock

DeviceLock provides all the information that comes from Intune Device Restriction Policy. If a password policy is required for Intune users, your local admin will probably need to change his password. (from Windows 10 device).

More about Device Lock and Password Settings – Microsoft Docs

If I look at my local users and look at the admin users, I will see that all admin users need to change their passwords. 👇

If you got them or not, you are under some security issue – your local admin account isn’t using the policy you think you’ve got, and probably the password can be changed easily. (The attacker has a halfway local admin password)

If I look for a quick and dirty solution, so, actually, I can log in as the local administrator, change the password when prompted, or log in as another administrator account and use Local Users and Groups to change the password. But I’ve got a thousand devices.

TIP: I must emphasize that this only affects local accounts, not a domain. Furthermore, if you’re working with managed groups for Intune device you probabaly minimize this security issue  

Since manually and interactively changing a local admin password is not feasible at scale, I cannot recommend using Intune to set a password policy if you use a password rotation solution.

However, remember that a password policy can be put in different places in Intune – as part of a Windows 10 security baseline, as a configuration profile, using OMA-URIs directly or via the new LAPS policy.

At the bottom line, the password policy has side effects, and it seems the local admin users must change the password in any policy: the old EAS and the Device Lock policy.

What about LAPS? The new LPAS can fix this password issue? Later on, this post.

Monitor Local Admin with MDE & Microsoft Sentinel

The biggest issue with Intune is that we cannot monitor local user and their actions, including if the local admin has changed, modified, password set to expire, and even if the LAPS is working or not.

So, we don’t have any eyes on the machine in this kind of situation, and we probably do not know if the attack is trying to compromise the local account.

Hence, what can we do in the account compromise game? in this scenario, we must use specific security products and tools: The Microsoft Defender for Endpoint. If we’ve got the Microsoft Sentinel, it can take to the highest level when investigating issues.

TIP: In this scenario, I’ve got Microsoft Sentinel, MDE, and Intune for all devices. 

There are many queries under my GitHub profile, but check specific values and a few lines from the Microsoft Sentinel.

First thing first, I will check the MDE for DeviceLogonEvents and extract the locallogon value from IsLocalAdmin with the following query:

DeviceLogonEvents
| where Timestamp > ago(90d)
| where IsLocalAdmin == 1
| extend locallogon = extractjson(“$.IsLocalLogon”,AdditionalFields, typeof(string))
| project Timestamp, DeviceName, AccountDomain, AccountName, LogonType, ActionType, locallogon
| distinct AccountDomain, AccountName, DeviceName

Let’s continue and run a specific query to extend several values with the following example:

DeviceEvents
| where Timestamp > ago(14d)
| extend AddedAccountSID = tostring(parse_json(AdditionalFields).MemberSid)
| extend LocalGroup = AccountName
| extend LocalGroupSID = AccountSid
| extend Actor = trim(@”[^\w]+”,InitiatingProcessAccountName)
| project Timestamp , DeviceName, AddedAccountSID , LocalGroup , LocalGroupSID , Actor

Still, a lot of information, but let’s run the query from Microsoft Sentinel with the following query to check which user configured with Password must be changed at the next logon:

union DeviceLogonEvents, DeviceEvents
| where TimeGenerated> ago(1d)
| where AdditionalFields contains “PasswordLastSet”
| extend AccountDomain
| extend PasswordLastSet_ = tostring(AdditionalFields.PasswordLastSet)
| sort by TimeGenerated desc

From the AddtionalField value, we can grab the Password Last Set, and from the ActionType value, we can show if the user was added recently.

As we can see on the Microsoft Sentinel result, we’ve got a few indicators about admins that need to change their local password at the next login. Instead, all the values come from an additional field with password last set, new UAC, and the InitiatingProcessLogonId.

More information about 4738(S) A user account was changed in Windows 10 | Microsoft Docs

TIP: the IsLocalAdmin == 1 parameter is a good value to indicate if someone touches the local admin, but, if the local admin never logged on so the is local admin value not bring back the correct rsult.

Now that we’ve got some information, we can but an Analytics tule and Hintubg query.

Mitigate this issue

To mitigate this security issue and avoid local admin take over, you can use the following actions on Intune devices: (recommended by this order)

• Manage local admin membership with Policy CSP
• Appy password policy with Windows 10 Security Baseline via Intune
• Deploy Intune LAPS with all switches and parameters
• Make sure MDE is part of Intune devices
• Monitor Intune devices with MDE and Microsoft Sentinel

TIP: to mitigate this issue, you must enforce at least to deploy Intune LAPS and make sure that you’re managing local admin membership – until you achieve it, your device is exposed on the local admin accounts.

Microsoft Sentinel & MDE queries on Microsoft Sentinel 4 SecOps

Microsoft Sentinel blog post on MISCONFIG

Microsoft Sentinel blog post on Microsoft Sentinel Archives – Elli Shlomo (eshlomo.us)