none
AppLocker allow rule exceptions ineffective

    Question

  • I have a rule that says let admins run everything.

    I have another rule that says everyone can run everything under %windir%\* EXCEPT powershell.exe

    any non-admin user can run powershell.exe just fine. AppID service is running. Exe rules are enforced. Why doesn't this work. Client is win 10 edu 1607.


    born to learn!


    • Edited by AJM Admin Monday, April 03, 2017 7:47 PM
    Monday, April 03, 2017 7:47 PM

Answers

  • Ok so it doesn't support path rules of just a name apparently? I swear this was working at some point but I guess not. That really sucks for blocking files that occur in many locations and are also a pretty big threat, such as InstallUtil.exe.

    born to learn!

    • Marked as answer by AJM Admin Tuesday, April 04, 2017 6:00 PM
    Tuesday, April 04, 2017 6:00 PM

All replies

  • Hi,

    Generally, you can use Applocker or Software Restriction Policies (SRPs) to stop PowerShell.exe from running.

    Using Software Restriction Policies to Protect Against Unauthorized Software http://technet.microsoft.com/en-us/library/cc507878.aspx

    In our case, you should put Powershell and the Powershell_ISE for both x86 and x64 into the deny rules. Both locations are as below:

    The 32-bit PowerShell is found at C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe & powershell_ise.exe, and the 64-bit PowerShell is at

    C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe& powershell_ise.exe.

    You should also be able to use the Administrative Template "Don't run specified Windows Applications" and put Powershell and the Powershell_ISE for both x86 and x64 in there. You can then link it in the OUs that you don't want the users to have access to PowerShell.

    Hope the above information is helpful to you.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, April 04, 2017 6:50 AM
    Moderator
  • > I have another rule that says everyone can run everything under %windir%\* EXCEPT powershell.exe
     
    How exactly is this rule designed?
     
    Tuesday, April 04, 2017 8:51 AM
  • So I redesigned the rule a bit, thinking "maybe the issue is there are too many exceptions on the %windir% rule and this is a bug". So I took off all exceptions and made unique deny rules for each, with each deny rule set to affect a specific test user. One deny rule is a path rule for "powershell.exe" which should match that name at ANY path as far as I understand AppLocker. Even having done this, powershell.exe is still allowed for the test user after group policy is refreshed and new applocker policy is applied, but the deny path rule for path = powershell.exe should absolutely be taking precedence over the allow rule for %windir%, but LOOK IT DOES NOT. Below is an excerpt from the AppLocker event log where powershell.exe was ALLOWED to run as the test user, despite the fact that a deny rule is defined to block this user from running 'powershell.exe'.

    ADDENDUM: also I figured "hey maybe this is a sysvol replication issue" - but I have verified it is not; all my sysvol members are getting sync'd up in < 1 second. I've even gone so far as to verify - in the registry on the client that powershell.exe I erroneously allowed to run as the user that should be denied - that the Deny rules ARE PRESENT.

    <RuleAndFileDataxmlns="http://schemas.microsoft.com/schemas/event/Microsoft.Windows/1.0.0.0">

      <PolicyName>EXE</PolicyName>
      <RuleId>{299E2C83-6884-4049-B6FB-8A4CF596FC08}</RuleId>
      <RuleName>%WINDIR%\*</RuleName>
      <RuleSddl>D:(XA;;FX;;;S-1-1-0;(APPID://PATH Contains "%WINDIR%\*"))</RuleSddl>
      <TargetUser>S-1-5-21-1821935976-3447230761-2181848911-26217</TargetUser>
      <TargetProcessId>8868</TargetProcessId>
      <FilePath>%SYSTEM32%\WINDOWSPOWERSHELL\V1.0\POWERSHELL.EXE</FilePath>
      <FileHash>61FF6233DB141BE35A91025614CB7A6504D2E20174CD6298F6E0B02700C3F819</FileHash>
      <Fqbn>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING SYSTEM\POWERSHELL.EXE\10.0.14393.206</Fqbn>
      <TargetLogonId>0x3e18ff</TargetLogonId>

    </RuleAndFileData>


    born to learn!




    • Edited by AJM Admin Tuesday, April 04, 2017 5:09 PM
    Tuesday, April 04, 2017 4:59 PM
  • Ok so it doesn't support path rules of just a name apparently? I swear this was working at some point but I guess not. That really sucks for blocking files that occur in many locations and are also a pretty big threat, such as InstallUtil.exe.

    born to learn!

    • Marked as answer by AJM Admin Tuesday, April 04, 2017 6:00 PM
    Tuesday, April 04, 2017 6:00 PM
  • > Ok so it doesn't support path rules of just a name apparently?
     
    No, it doesn't and it never did. AFAIK SRP supported this scenario :-)
     
    https://technet.microsoft.com/de-de/library/ee460944(v=ws.10).aspx : AppLocker does not enforce rules that specify paths with short names. You should always specify the full path to a file or folder when creating path rules so that the rule will be properly enforced.
     
    To test, it "might" work if you use %OSDRIVE%\*\powershell.exe
     
    Wednesday, April 05, 2017 1:22 PM