How to detect the source of registry key modifications on windows devices – Intune

In this blog post, we'll explore how to detect the source of registry key modifications on a Windows device. In other words, we'll look into identifying who is adding, deleting, or changing registry keys, whether through Group Policy (GPO), Intune, SCCM, scripting, or other methods.

Scenario: BitLocker Recovery Mode

While investigating an event related to exceeding the maximum failed sign-in attempts that caused a device to enter BitLocker recovery mode, I have come across an interesting finding. For a full list of BitLocker recovery scenarios, you can refer to the official Microsoft documentation.

Here’s how the situation cracked: I selected a device enabled with BitLocker and deliberately attempted several incorrect passwords. After few failed attempts (with no domain controller access, so user lockout wasn’t applicable), the device prompted the message:

"That password isn't correct. Be careful – if you keep entering the wrong password, you'll be locked out. To unlock, you'll need a BitLocker recovery key."

On the next incorrect attempt, the device rebooted into BitLocker recovery mode.

This behavior happens only if the registry key for the machine lockout threshold is set to MaxDevicePasswordFailedAttempts, located at registry:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Upon reviewing the registry key configuration, I considered increasing the value of MaxDevicePasswordFailedAttempts to 10 or so. However, before making any changes, I needed to first determine where this setting was coming from.

Possible Sources of the Setting:

Multiple device management tools could be influencing this registry key, including:

• Group Policy (GPO)
• SCCM/ConfigMgr
• Intune
• Scripting

Step 1: Check GPO

First, I checked if a policy was configured and deployed via Group Policy. After exporting the gpresult and reviewing the lockout settings on the device, I found no relevant entries.

Step 2: Check Intune

Next, I looked at Intune by running MDM device diagnostics logs from the Windows Settings > Account page. After exporting the output and searching for "password failed," I found the setting for MaxDevicePasswordFailedAttempts was configured to 10.

Here's the confusion: Intune reported the value as 10, but the effective value was 7.

Step 3: Investigating the Discrepancy

I confirmed that the MaxDevicePasswordFailedAttempts registry value was correctly set to 10 in the Intune registry location:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceLock

Using my script that helps to identify the setting coming from which configuration profile, I am able to find the device configuration policy and see the reporting status as well.

However, Intune's reporting showed no conflicts, and the registry seemed to reflect the correct settings. But where did the 7 value originate from?

Step 4: Testing with Registry Key Deletion

To investigate further, I deleted the MaxDevicePasswordFailedAttempts registry key from:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Then I ran gpupdate /force and performed a full intune sync (using schedule task). After waiting for a few hours, the registry key reappeared.

At this point, I decided to enable registry auditing to capture any changes to this registry key.

Enabling Audit Logs for Registry Changes

Follow these steps to enable auditing for registry key modifications:

1. Enable Registry Auditing

• Open Command Prompt as Administrator and type gpedit.msc to open the Group Policy Editor.
• Navigate to Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Object Access.
• Double-click Audit Registry and enable the policy for Success.

1. Grant Auditing Permissions to the Registry Key

• Open Registry Editor and navigate to the registry key you want to monitor (e.g., Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System).
• Right-click the registry key and select Permissions.
• Click Advanced and then go to the Auditing tab.
• Click Add, select Everyone for principal, and choose Show advanced permissions to configure the settings. Select set value, create subkey and read control.

3. Wait for Changes

After performing the above steps, wait for the registry key to be modified (this may take a few hours or a day).

1. Review the Event Viewer

• Open Event Viewer and navigate to Windows Logs > Security.
• Search for MaxDevicePasswordFailedAttempts in the logs.
• You will find an event indicating that a Powershell.exe process modified the registry key.

The Source of the Modification

The presence of Powershell.exe in the event logs suggests that a PowerShell script is responsible for modifying the registry. In this case, it was most likely an Intune remediation script running at regular intervals or scripts feature too!.

Step 5: Revert Audit Changes

After identifying the source of the registry changes, don't forget to disable auditing for the registry to avoid unnecessary overhead.

• Open Command Prompt as Administrator and type gpedit.msc to return to the Group Policy Editor.
• Under Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Object Access, double-click Audit Registry and disable it.

---

Conclusion

I hope this guide helps you in troubleshooting and detecting the source of registry modifications on Windows devices. Enabling registry auditing and reviewing the Event Viewer can be powerful tools for tracking changes, especially when using device management tools like Intune or SCCM.