Last Updated on May 23, 2024 by rudyooms
In this blog, I am going to take a closer look at how Config Refresh knows which policies were configured and which ones need to be refreshed. To make it more funnier, I am going to take a look at how we could manipulate that cache to get a different kind of refresh
I will divide this blog into multiple parts
1. Introduction
Last week, Config Refresh was mentioned in this Microsoft article below. This article showed us the latest Windows 11 features that would strengthen security.
With this new Microsoft article posted, I felt I needed to post this blog.
2. Config Refresh
As also mentioned in the Microsoft article, the power of config refresh allows us to bring our device back to a desired state (policies) even when it is offline. We can configure a cadence to let Windows reapply the Intune-configured policies to the device.
I wrote about how this process happens under the Windows hood in the blog below.
Config Refresh | Intune | Offline Refresh Intune Policies (call4cloud.nl)
In my summary, I mentioned that Config Refresh will query the policymanager\providers for all Intune configured policies. Once it knows which policies were configured and how, it will tag them, delete them, and set them once again. With it, the policies are refreshed. Sounds like the configuration was just refreshed!
Great, right? With this flow, I became interested in the cached providers registry key from which Config Refresh fetches the previously configured Intune Policies.
3. The Provider Key
All of the configured Intune policies and their corresponding settings also exist in policymanager\providers registry key.. the moment Config Refresh kicks off, it will check this specific providers registry node.
So, let’s play dodgeball with this policy manager registry key to see how it works!
If the Config Refresh feature is enabled, it will check all provider registry subkeys.
These subkeys contain all of the policies you configured in Intune.
Good to know is that when you mess around with (aka delete) the policy that lives in the policymanager\providers registry key, it won’t refresh the software\policies that may have been deleted.
No policy cache? No refreshed policies!
4. What if we change it?
Deleting the Config Refresh cache will not refresh the policy, as it doesn’t know how it was configured, right? But what if we change one specific value from 1 to zero? Let’s say the AllowRealtimeMonitoring Defender registry key?
If we change that value to 0 and wait a bit to let config refresh kick in (or manually launch the scheduled task to refresh the settings)
Guess what will happen with the configured policy in the corresponding policymanager and software\policies
As shown above, when we change the cache, the config refresh scheduled task will update this AllowRealTimeMonitoring defender policy to 0. You can re-watch the behavior in the video below.
Conclusion
Of course, this is not UNexpected behavior—it is just how Config Refresh was designed to work. It is good to know that all those registry keys you could have manipulated will be restored to their original state when your device syncs. Besides how it was intended, it is evident that you can do everything if you are an Admin on the device. So don’t be an admin on your device!
The only thing I am hoping for is that malware isn’t aware of this behavior.
Basically, this means that if your malware is smart enough, it might be able use the policy refresh to circumvent the hardening features to prevent Defender from unloading. Tamper protection disabled, settings adjusted, and away we go.
Maybe I’m being paranoid, but after the stories about the (initially) unprotected Recall database and other similar questionable moves, I’m having trouble believing in the proclaimed “Secure first” strategy at Microsoft.