Securing AppLocker Path Rules Against User-Writable Locations

Question

Hi guys,

Our security auditor found that our current AppLocker policy allows users to run executables from the C:\Windows\Tasks folder because it's part of a default path rule. Why is allowing standard users write-access to a permitted AppLocker path a major security risk, and how do we tighten that rule?

Answer 1

Hi Malee Wongsa

The core issue is that AppLocker path rules are only secure when users do not have write permissions to those locations. If a standard user can copy or create an executable in a trusted path such as C:\Windows\Tasks, AppLocker will treat that file as trusted and allow it to run, effectively bypassing your application control strategy. An attacker who gains access to a standard user account could abuse this behavior to execute unauthorized code, establish persistence, or potentially move further into the environment.

I think you should review all default AppLocker path rules and removing any that point to locations where non-administrative users have write access. In this specific case, verify the NTFS permissions on C:\Windows\Tasks and either restrict write access appropriately or create a more granular AppLocker rule that only permits trusted executables from secured system directories. As a best practice, supplement path rules with Publisher rules whenever possible, since they validate the digital signature of the application rather than relying solely on file location.

If everything is okay, don't forget to share your experience with the issue by "Accept answer". If you need more information, feel free to leave a message. We are happy to help!