Sheridan Posted January 18, 2016 Posted January 18, 2016 I've got an Applocker policy to replace SRP, which specifically Denys users from running Powershell (powershell.exe) However, if they search for it, they can run it ok. Other Applocker restrictions seem to be applying but powershell is still allowed to run. I've checked that the executable name running under the restricted account is still showing as powershell.exe. Odd behaviour this, anyone else blocking powershell with Applocker had any issues?
Arthur Posted January 18, 2016 Posted January 18, 2016 (edited) Have you blocked all four of them? C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell_ise.exe Edited January 18, 2016 by Arthur
Sheridan Posted January 18, 2016 Author Posted January 18, 2016 I'd just blocked the powershell.exe so it wouldn't be allowed to run from anywhere, which is how it worked in SRP?
Arthur Posted January 18, 2016 Posted January 18, 2016 What type of rule did you create? Hash, Publisher?
Sheridan Posted January 18, 2016 Author Posted January 18, 2016 I just used a simple Path rule - and it seems like the default rule to Allow C:\Windows\System32 allows Powershell to run, even if there is a specific Deny for that path. I put Powershell.exe as an exception to that default rule and it now stops it running - I always thought the Deny rules tool precedence over the Allow, as they did in SRP?
Garacesh Posted January 18, 2016 Posted January 18, 2016 Derp. Wrong thread. That'll teach me to have multiple tabs of similar topics open at once.
xlandhenry Posted January 19, 2016 Posted January 19, 2016 Path rule works only for the executable specified in that path.
Sheridan Posted January 19, 2016 Author Posted January 19, 2016 I've tried with the exact path specified and it still allows it to run - the only way it works as expected is if I add the path as an exception in the default Allow rule for C:\windows. Not the behaviour I was expecting.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now