Welcome to the Config Refresh Blog! Today, I’ll be diving into the fascinating world of Config Refresh. Specifically, we’ll explore how Config Refresh identifies which policies have been configured and which ones need to be refreshed. But that’s not all—I’ll also add a humorous twist to the topic by investigating how we might mischievously manipulate the cache for a different kind of refresh. So, buckle up and get ready for an entertaining yet informative journey through the intricacies of Config Refresh and cache manipulation!
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.
If you’re curious about how Config Refresh gets deployed to your device, you’re in the right place. In this blog below, we’ll delve into the deployment process of Config Refresh. But that’s not all! We’ll also explore how Config Refresh operates from the moment the scheduled task kicks off until the policies are fully refreshed. Join me as we uncover the behind-the-scenes workings of Config Refresh, making this technical journey both informative and engaging.
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.