Anyone running AppLocker?

Discussion in 'other security issues & news' started by acr1965, May 16, 2010.

Thread Status:
Not open for further replies.
  1. acr1965
    Offline

    acr1965 Registered Member

    I have Windows 7 Ultimate and see it has the AppLocker configuration option. There are some helpful links on MS technet and AppLocker does not appear overly complicated to set up. I am wondering what others have experienced using AppLocker. Any info to pass along would be appreciated.

    Also, with AppLocker enabled do I still need UAC enabled?

    thanks
  2. Cudni
    Offline

    Cudni Global Moderator

    made sure I had default rules set; used the auto wizard then run it for awhile with audit only to make sure I didn't muck it up after I made few tweaks to the rules. I keep UAC on. Good fun all in all
  3. MrBrian
    Offline

    MrBrian Registered Member

  4. acr1965
    Offline

    acr1965 Registered Member

    I read you link and saw the first post about "allow admin to execute anything"

    If I am the only user of my computer and always run as admin is there any significant benefit to running applocker under that rule set?
  5. MrBrian
    Offline

    MrBrian Registered Member

    That depends if you're running with UAC disabled. That particular rule will fire only when running with a full admin token. If you're using UAC, then you're not considered a member of the Administrators group when running with a limited token (i.e. not elevated). If you disabled UAC, then that rule will allow anything to run.

    I'm using that ruleset running normally as a standard user, but I think it could work for you if you're running as admin with UAC on.
    Last edited: May 16, 2010
  6. wat0114
    Online

    wat0114 Guest

    Maybe if you delete the: <Allow BUILTIN\Administrators (Default Rule) All Files> rule. IMO, it's easier and maybe even more secure to Auto-generate your Executable rules with Publisher->Hash->Path in this order of priority, and use the defaults for your Windows installer and Script rules. You won't need to create exceptions using this approach, but you will have to Auto-generate new rules for newly installed programs or when a file with a hash-only rule is updated/changed. Publisher rules are nice because you can set them up to allow on, for example, the current file version or above. So, this approach does require some routine maintenance as opposed to MrBrian's approach. I just feel it offers better security because of the benefit of Publisher and Hash rules, so malicious changing of the file's digital signature will not elude the Executable policy. You would also need to delete the rule I posted at the beginning if you want to always run as administrator. Keep in mind doing so will prevent you from running any executable outside of what's listed in the ruleset. You may need to create a a couple customized rules to avoid problems (see note below about using "Audit only" enforcement). Keeping UAC on default level is recommended as MrBrian does.

    Finally, before enforcing your Applocker policy, you can change enforcement to "Audit Only", run all your different applications for a while, then check the Event Viewer for any potential issues, as described here:

    http://technet.microsoft.com/en-us/library/ee791749(WS.10).aspx
  7. MrBrian
    Offline

    MrBrian Registered Member

    Note to early readers of my last post: I edited it extensively.

    Here is my full AppLocker ruleset for Windows 7 x64:

    1. Executable Rules
    -Allow Everyone to run all files in Windows folder, with these exceptions:
    c:\windows\debug\WIA\*
    c:\windows\Registration\CRMLog\*
    c:\windows\System32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\*
    c:\windows\System32\com\dmp\*
    c:\windows\System32\FxsTmp\*
    c:\windows\System32\spool\PRINTERS\*
    c:\windows\System32\spool\drivers\color\*
    c:\windows\System32\Tasks\*
    c:\windows\SysWOW64\com\dmp\*
    c:\windows\SysWOW64\FxsTmp\*
    c:\windows\SysWOW64\Tasks\*
    c:\windows\Tasks\*
    c:\windows\Temp\*
    c:\windows\tracing\*
    -Allow Everyone to run all files in Program Files folder
    -Allow Administrators to run all files

    2. Windows Installer Rules
    -Allow Everyone to run all Windows Installer files in %systemdrive%\Windows\Installer folder
    -Allow Administrators to run all Windows Installer files

    3. Script Rules
    -Allow Everyone to run all scripts in Windows folder, with same exception list as in Executable Rules (above)
    -Allow Everyone to run all scripts in Program Files folder
    -Allow Administrators to run all scripts

    4. DLL Rules
    -Allow Everyone to run all DLLs in Windows folder, with same exception list as in Executable Rules (above)
    -Allow Everyone to run all DLLs in Program Files folder
    -Allow Administrators to run all DLLs

    I also added a rule to each of the above to allow Everyone to execute any files in a specific temp folder that I created, for occasions in which I wish to run something non-elevated that isn't already in the Program Files or Windows folders.

    Since I'm using UAC, the Administrators rules fire only when elevated, even if using an admin account.

    The exceptions are there to prevent execution in folders within Windows folder in which execution would otherwise be permitted by default.
    Last edited: May 17, 2010
  8. MrBrian
    Offline

    MrBrian Registered Member

    Keep in mind though that in order for such a malicious change to happen to files within Program Files or Windows folders, malware had to have run elevated (assuming the relevant file/folder permissions are sound) to make such a change. Correct?

    Another thing to keep in mind if automatically generating AppLocker rules is that you should review the resulting ruleset to make sure that you didn't whitelist anything suspicious.

    By the way, I use UAC at the highest setting, not the default.
  9. MrBrian
    Offline

    MrBrian Registered Member

    A nice consequence of my ruleset is that attempts to run anything in my download folder (or anywhere else outside of Program Files or Windows folders, except for the special folder that I created in which I allow non-elevated execution) will be denied, unless I've OK'd a UAC prompt. And when running an installer (which had to have been OK'd by me due to UAC), installation will not fail due to AppLocker rules, because Administrators can run anything anywhere in my ruleset.
  10. wat0114
    Online

    wat0114 Guest

    Of course, but the OP is running full-time admin, which I don't agree with but to mitigate the potential concern it seems reasonable to remove the all-liberal administrator rule from the set. Doesn't keeping that rule as a full-time administrator render the others superfluous, with UAC the only safeguard against malicious attempts, unless I'm missing something?

    Agreed, but I guess no Applocker policy approach will work effectively if the machine is already compromised :)
  11. MrBrian
    Offline

    MrBrian Registered Member

    True, if one dismisses UAC prompts without consideration or skill ;). (Same holds true for any HIPS, right?)

    What would happen in this scenario: you're running as a standard user. Malware puts an executable file in some location writable to a standard user, but AppLocker prevents execution. However, the next time you autogenerate AppLocker rules, your whitelist will include this executable if you're not vigilant, correct?
  12. wat0114
    Online

    wat0114 Guest

    I don't like answering Credentials prompts as an admin ;)


    In the OP's case who runs full-time admin, I just don't see how the Allow everything for administrators path rule does anything helpful but render the Applocker policy useless??

    Point well made, but how does the malware run in the first place as a standard user with the Applocker policy I use, unless I've installed it willingly as an administator? I don't see this as possible, but again, please elaborate because I don't want to misunderstand anything.
    Last edited by a moderator: May 16, 2010
  13. MrBrian
    Offline

    MrBrian Registered Member

    AppLocker considers a user running as admin but not with a full token to not be part of the Administrators group. Only when running elevated does the Administrators rule fire. And to run elevated, you first have to pass UAC :).

    This could happen in a buffer overflow exploit. The shellcode will run, then typically attempt to download a trojan and execute it. With your AppLocker rules, the execution would be blocked, but what happens during your next auto rules generation? The downloaded trojan is still there, right?

    Also, if malware has managed to change executables, won't a subsequent auto rules generation whitelist those malicious changes also?
  14. s23
    Offline

    s23 Registered Member

    A backup/virtualization software is the best thing to evade this I think. If you have a clean image of you system, before use the auto-generate rules again, you restore it. Is not that easy, but if you use different partitions to system and data, can be done. You can use CTM or Shadow Defender/Returnil/Wondershare time freeze (or anything like this) to do this too. If you virtualize the system partition, even if the malware was written at one of the folders mentioned by MrBrian, it will not execute with publisher/hash rules and after restart will be gone. Is a option.
    Last edited: May 16, 2010
  15. Noob
    Offline

    Noob Registered Member

    Too complex :D

    I tried using it, but according to what i read you have to create a rule for every .exe or process?
    That's too much work for it :)
  16. wat0114
    Online

    wat0114 Guest

    No it's not. You could employ MrBrian's method or similar Path rule approach, or use the Auto-Generate feature, which takes about 5 minutes tops.
  17. timestand
    Offline

    timestand Former Poster

    I agree MrBrian method. Why MrBrian dont talk in thread where doktornotor attack me. doktornotor method maybe less secure now you see.
  18. timestand
    Offline

    timestand Former Poster

    I agree all except one thing. I also use exception rules on Window Installer Rules. Why you no use? And good see you use DLL rule!
  19. Windchild
    Offline

    Windchild Registered Member

    Ah, seeing threads like this warms my heart. :) Yeah, running AppLocker on a couple of systems currently. And it's really quite nice.

    Two things come to mind here:

    1) Auto-generating rules to allow files created and/or writable by limited users is unwise, unless we're actually trying to give limited users the ability to run random programs. And if we are, why are we even using AppLocker? One does need to be careful when auto-generating anything, whether AppLocker rules or something completely different.

    2) Even if you did at some point accidentally auto-generate rules to allow some trojan dropper sitting in a download folder to execute, there is the question: what is going to execute it? It won't execute by itself, even if AppLocker has whitelisted it. So either you have to manually execute it, or there has to be the typical registry autorun to do it. And seriously, that autorun would have been sitting there all the time (if it ever managed to get there in the first place, seeing how the dropper didn't actually run, just some piece of short shellcode that's most often just a download-&-execute affair, leaving all the actual work to the dropper, and it's the dropper that typically creates the autoruns for the actual malware and/or itself). That should have been noticed... But let's say we don't notice it, and the dropper runs. At which point it most likely downloads the actual malware, saves it in some folder, and tries to execute it - but can't, since AppLocker hasn't allowed those files... So there's yet another chance to notice something is really not right. If one is going to auto-generate rules to include files writable by limited users, one should at least keep a very sharp eye on stuff like this.
  20. timestand
    Offline

    timestand Former Poster

    Or maybe it dont download actual malware and is actual malware it self. And it execute and it kill you system with same as killdisk. Yes rare but why risk auto generate way. Use MrBrian way safer I think.
  21. TheKid7
    Offline

    TheKid7 Registered Member

    Is Windows 7 Professional and Windows 7 Enterprise the same? I don't need many of the features of Ultimate.

    I see that Applocker is listed as available only on the Ultimate and Enterprise versions of Windows 7.

    Thanks in Advance.
  22. doktornotor
    Offline

    doktornotor Registered Member

  23. Windchild
    Offline

    Windchild Registered Member

    If you're running without admin privileges, then it won't kill your system even if it executes - without privilege escalation, the worst such a killdisk malware could do is wipe out the files your user profile has write access to, and you ought to have backups of that stuff anyway.

    But personally, I prefer to make my own rules rather than let AppLocker auto-generate them. Auto-generate can be very handy in some environments, but I'm a creature of habit and find it more comfortable and safer to just make the rules myself. :)
  24. s23
    Offline

    s23 Registered Member

    How you guys are using the auto-generate rules wizard?
    To create publisher/hash rules to all content in Program Files/Windows folders?
  25. wat0114
    Online

    wat0114 Guest

    Correct, the %ProgramFiles% directory (so also Program Files (x86) in 64 bit).

    @Windchild: why on earth would I Auto-genrate rules for some random programs?? I Auto-generate them for safe programs only that limited users can also use, and create exceptions for any I don't want them using such as nVidia control panel.

    Other than the initial auto-generate for all SAFE files under the %ProgramFiles% directories, all subsequent auto-generates are done only for new installed executables or updated Hash-only executables, so I select only that individual programs directory to auto-generate on. Anyway, more later.

    *EDIT*

    going further, I believe MrBrian's concern about malware somehow placing a malicious executable into one or more of the user-writable directories becomes a non-factor because of what I've stated above. The Auto-generate feature is used for the entire %ProgramFiles% directory after one has installed all their desired programs, then it is used only on specific directories for new installed programs later or updated Hash-only programs. The user can easily select the exact location for the Auto-generate feature to scan.
    Last edited by a moderator: May 17, 2010
Thread Status:
Not open for further replies.