Anyone running AppLocker?

Thanks you but that only work for shortcut and SuRun is easier still. Only reason why I want know is because I think SuRun hook kernel and mean this might be bad. Maybe be I just live with UAC prompt. Not so bad for me. With Shadow Defender I open it mean need password to open with UAC. So no need put password for Shadow Defender it self. Sound okay to me.

 

@MrBrian

What was your source for your exclusions? From where did you get the information to exclude folders like

c:\windows\debug\WIA\*
c:\windows\Tasks\*
c:\windows\Temp\*
c:\windows\tracing\*

and all the other you mentioned?

 

Endorse Cruchot

I find this thread interesting (well excluding the effort discussion that is). It would be even more informative when the poster also explains his consideration for including a path.

Thx

Kees

 

Yeah, that's indeed possible, but there's a but: usually exploit sites don't push the exact same binary for a very long time - often it's just a couple of hours or a small number of successful exploits and the binary changes, to avoid signature-based detection even if it's the same actual malware all the time. If the binary pushed by the exploit site happens to change between the time you accidentally allowed the old binary in AppLocker and when you visit the exploit site again, the hash for the new binary will not be whitelisted, and it won't be allowed to run by AppLocker, and no malware will execute.

But really, one wouldn't have to even consider these things if one just paid attention not to whitelist random LUA-writable stuff while auto-generating rules.

 

Correct, especially when the entire %ProgramFiles% and %Windir% directories are Auto-generate-scanned only once right after a new install of the O/S and initial software profile is set up. After that, it's only specific programs under these directories, most likely only %ProgramFiles%, that might get scanned again, and these are directories that Users can't write to. The user-writable subdirectories are a non-issue with the whitelist approach because anything that may happen to write to them will be stopped dead in its tracks trying to execute, however that may happen, by the default-deny Applocker policy.

 

BTW, to illustrate one of the few "unusual" rules I had to create, Process Explorer x64 version would only work with the Ctrl-Alt-Del hot keys with the rule shown in the screenshot. I had to create this same rule for every individual user of this machine; simply using "Everyone" would not work, because the path is under the user's AppData directory. Autogenerate would not create this necessary rule, either.

Now, without the help of Applocker's "Audit only" feature, figuring this out would have been very difficult

 

Please see posts #27-31 in Maximising Windows 7 security with SRP under LUA (whatever the win7 version).

 

This simple just create user standard account and run accessenum with admin right. Then look at who can write to folders. Any that say "Authenticated Users" or "Users" you must block. Many can write to C:\windows\system32\tasks so if put * you block all in that path! Mean you only need 14 rule! Ok?

 

You are pride man again. Talk on what is annoying and fast and less fast is alway good thing. Never mind I must learn ignore. And need block those 14 path because user limited can write them. Simple.

 

Seem me you always like last word. You admit it possible. End of word. MrBrian right. We talk on low likely any way.

Yes and one no need consider any thing if one dont do anything with computer. Ok? Point is we talk on what easy and safer. MrBrian method very nice. Auto-generate also nice but I like MrBrian better. Other like other method better. End story. Ok?

 

Use caution when using AccessEnum (v1.32 or earlier) on x64 operating systems. See https://www.wilderssecurity.com/showpost.php?p=1680803&postcount=36 for further details. Windows Permission Identifier has the same issue.

For permission auditing, you can also use either AccessChk (v5.0 or later) or Windows Permission Identifier run elevated. If Windows Permission Identifier doesn't work elevated for you, then you may run it unelevated, but be aware that unless you alter some permissions, it may give you incomplete results. The reason that I recommend only v5.0 or later of AccessChk is due to this bug in earlier versions. Example usage of AccessChk: accesschk -ws accountname "c:\windows", where accountname is the name of a standard user account.

 

Another thing to keep in mind with AccessEnum is that by design it doesn't list items that have the same permissions - or more restrictive permissions, depending on which option is being used - relative to its parent. For example, let's suppose that folder A has a subfolder B, which has a subfolder C. Let's suppose that all of these folders have the same permissions. Let's suppose that a limited user can write to any of these folders. AccessEnum by design will list folder A as being writable by limited users, but not folder B or folder C.

 

No problem on 32-bit Win 7 here but thanks you for info!

 

This no problem with our rule since we use \*. Ok?

 

When looking at AccessEnum's Write column, be sure to also look for the given standard account itself, plus any groups the standard account is a part of - there are more than just Authenticated Users and Users. You can use the command line whoami /groups to find out what groups an account is a part of.

AccessEnum tip: sort by the Write column.

 

(from another thread)

If you're using an admin account with UAC enabled, then you should be able to configure AppLocker in much the same way as a standard user would. You can keep rules for the Administrators group, since these rules apply only for elevated programs.

If you're using an admin account with UAC disabled, then you should still be able to use AppLocker, but you'll not want to keep the default rules for the Administrators group.