Hello Splunk Security Team,
There is a logic issue in the Time Provider Persistence Registry detection that causes the scenario to generate excessive noise and false positives.
The current search broadly monitors the W32Time registry path without applying filters specific to the actual persistence mechanism. As a result, legitimate registry modifications are also being captured.
I modified the search and added an additional filter to focus specifically on DLL-related changes associated with this persistence technique.
Please consider applying this change to reduce false positives and improve the overall accuracy of the detection.
| tstats security_content_summarisonly count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where (Registry.registry_path="\CurrentControlSet\Services\W32Time\TimeProviders" AND Registry.registry_value_data=".dll")
Hello Splunk Security Team,
There is a logic issue in the Time Provider Persistence Registry detection that causes the scenario to generate excessive noise and false positives.
The current search broadly monitors the W32Time registry path without applying filters specific to the actual persistence mechanism. As a result, legitimate registry modifications are also being captured.
I modified the search and added an additional filter to focus specifically on DLL-related changes associated with this persistence technique.
Please consider applying this change to reduce false positives and improve the overall accuracy of the detection.
| tstats
security_content_summarisonlycount min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where (Registry.registry_path="\CurrentControlSet\Services\W32Time\TimeProviders" AND Registry.registry_value_data=".dll")