Anyone running AppLocker?

[acr1965]

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

[Cudni]

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

[MrBrian]

See my post http://www.wilderssecurity.com/showp...1&postcount=31.

I've kept on UAC also.

[acr1965]

Originally Posted by MrBrian

See my post http://www.wilderssecurity.com/showp...1&postcount=31.

I've kept on UAC also.

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?

[MrBrian]

Originally Posted by acr1965

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?

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.

Originally Posted by acr1965

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?

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/l...8WS.10%29.aspx

[MrBrian]

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.

[MrBrian]

Originally Posted by wat0114

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.

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.

[MrBrian]

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.

Originally Posted by MrBrian

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?

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?

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.

Agreed, but I guess no Applocker policy approach will work effectively if the machine is already compromised

[MrBrian]

Originally Posted by wat0114

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?

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

Originally Posted by wat0114

Agreed, but I guess no Applocker policy approach will work effectively if the machine is already compromised

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?

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

I don't like answering Credentials prompts as an admin

Originally Posted by MrBrian

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

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??

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?

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.

[MrBrian]

Originally Posted by wat0114

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??

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 .

Originally Posted by wat0114

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.

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?

[s23]

Originally Posted by MrBrian

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?

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.

[Noob]

Too complex

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

Originally Posted by Noob

Too complex

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

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.

[timestand]

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

[timestand]

Originally Posted by MrBrian

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 Windows 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.

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!

[Windchild]

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

Originally Posted by MrBrian

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?

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.

[timestand]

Originally Posted by Windchild

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.

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.

[TheKid7]

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.

[doktornotor]

Nope, they are not the same.

http://www.microsoft.com/windows/ent.../features.aspx

[Windchild]

Originally Posted by timestand

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.

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.

[s23]

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

Originally Posted by s23

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

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.