SRP: Protecting Windows Folder in Win 10

[DeepWeb]

Don't see the point in all of this when all it takes is one admin or system token to override it all.

 

[softie15]

Don't see the point in all of this when all it takes is one admin or system token to override it all.

If 99 % of time you run your system as standard account, how would downloaded malware you encounter get a chance to grab admin privs / system token? This topic, and more generally SRPs, is one of many prevention strategies for this.

 

[Andy Ful]

I tried the following: Default-Deny SRP without Windows Subdirectories rules (actually they are there Unrestricted), removed BAT from DFT.

As standard user, from command prompt, I was able to copy and execute a simple .bat script into each of the directories I identified in the OP. But I could not write to C:\Windows itself for example (as expected). Specifically, I could write and run in all these directories:
C:\Windows\tracing
C:\Windows\Registration\CRMLog
C:\Windows\System32\FxsTmp
C:\Windows\System32\com\dmp
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\drivers\color
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\FxsTmp
C:\Windows\SysWOW64\com\dmp
C:\Windows\SysWOW64\Tasks
C:\Windows\Tasks
C:\Windows\Temp

Now, I readded back BAT to DFT and tried same experiment with copying notepad.exe. In this case, I could copy it to all locations but not execute from most (again, from standard user command prompt). Following dirs are the only ones that executed it:

C:\Windows\System32\drivers\color
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\Tasks
C:\Windows\Tasks
C:\Windows\Temp

(Minor note: for some reason notepad.exe did not pop up a window from these directories. It seems to have ran but did not do much. I think it might relate to some other protection I have perhaps - it just paused for a while and quit without any logs in Event Viewer. Only when I call notepad.exe from C:\Windows it actually pops up a window.)

So options appear to be:

- blacklist explicitly all 13 dirs from the OP (and implicitly all their subdirs) - this will make sure that if some file extension is missing from DFT, malware still cannot write it under Windows dir. I guess SRP would be useless against such extension anyway though - they could just write it to some User-Space directory and run it then. So, perhaps this option is uselesst then...?

- blacklist (i.e. SRP disallow rules) explicitly just the 5 directories from the second experiment, not all 13 - that's what you recommend, right? This one will protect DFT extensions (only)

- maybe even blacklist less locations by only blacklisting DIRECT members in the 5 locations (possible in gpedit?) and then figure out other subdirectories of them where direct files but not subdir need to be blacklisted. Your original post for example examined subdirectories even if their higher-up directories were already listed as not-protected. For example, only DIRECT members of
C:\Windows\SysWOW64\Tasks
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
need to be blacklisted, but not other subdirs of SysWOW64\Tasks.

I am afraid that your test is invalid, because the below fact:

• Notepad cannot be copied to another folder and run (it will fail).

You have to repeat the test with the normal executable like C:\Windows\System32\control.exe .
It can be copied to any folder and run.
You can also try my batch (see attachment, change the file extension txt --> bat). Copy this batch to the whitelisted location and run. Close every instance of control.exe . Press space to continue the batch.
It copies notepad.exe and control.exe to the below folders:
C:\Windows\System32\drivers\color
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\Tasks
C:\Windows\Tasks
C:\Windows\Temp
Next, it tries to execute notepad.exe and control.exe from the above folders.
Finally, it tries to delete notepad.exe and control.exe from those folders.
.
The results:
The first folder is copy protected.
The executable control.exe can be copied and run from all the above folders, except the first.
The executable notepad.exe cannot be executed from the above folders (it cannot run when copied).
The above folders have also different RWD permissions. For example, the files can be copied to c:\Windows\SysWOW64\Tasks\ but cannot be deleted.
.
Post edited. The execution permission can work also for BAT files. But, does not work for CHM, Windows Script Host, PowerShell scripts.

 

[softie15]

Thanks @Andy Ful for explaining the notepad / .bat behavior and apologies for messing up my OP: C:\Windows\System32\drivers\color should have been C:\Windows\System32\spool\drivers\color. I wish I could still edit it :-(

With that fix, I think you will find that control.exe can also be copied to and executed from C:\Windows\System32\spool\drivers\color. That's what I see on my system too.

So, I think we agree on observed behavior - even with notepad.exe not fully working, I could see the exe was trying to run (due to Comodo showing me that cmd.exe is trying to run it).

I am unclear on what you'd recommend in terms of the option to choose from my earlier post. I listed 3 potential approaches at the end of that post. I am guessing all 3 work but curious which one you think is the safest while still stable for running the system...?

 

[MITKH]

In my opinion, the only way to deal with bundles is to do it. Import important files in a

 

[Andy Ful]

I repeated the test for all not protected folders from the thread Windows 10 UAC File Protection Loopholes
Three folders are now copy protected in Windows 10 v1709:
C:\Windows\servicing\Packages
C:\WINDOWS\servicing\Sessions
C:\Windows\System32\Tasks\Microsoft\Windows\PLA\System
.
the rest are still unprotected (see below):
C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
C:\Windows\System32\spool\drivers\color
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\Tasks
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
C:\Windows\Tasks
C:\Windows\Temp
.
See attachment for the testing batch (change the extension txt --> bat).

 

[Andy Ful]

Thanks @Andy Ful for explaining the notepad / .bat behavior and apologies for messing up my OP: C:\Windows\System32\drivers\color should have been C:\Windows\System32\spool\drivers\color. I wish I could still edit it :-(

I edited my previous post. I retested the behavior of BAT and CMD files and it is similar to the behavior of EXE files. So, the ACL execution permission can work also for BAT and CMD files (I was wrong thinking otherwise). But, does not work for CHM, Windows Script Host, PowerShell scripts, etc. That is interesting.
SRP in Default Security Level = Disallowed can additionally protect Windows Script Host (also command lines with WSH sponsors wscript.exe and cscript.exe) in blacklisted Windows subfolders.
So, all writable Windows subfolders should be blacklisted for maximum security, even "writable and not executable":
C:\Windows\System32\Com\dmp
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\Tasks
C:\Windows\Tasks
C:\Windows\Temp
C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
C:\Windows\System32\spool\drivers\color
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
.
If the user blocks WSH via policy (like in Hard_Configurator) or via blocked sponsors, then only "writable and executable" Windows subfolders may be blacklisted (skipped first three entries, from the above list).

 

[softie15]

I edited my previous post. I retested the behavior of BAT and CMD files and it is similar to the behavior of EXE files. So, the ACL execution permission can work also for BAT and CMD files (I was wrong thinking otherwise). But, does not work for CHM, Windows Script Host, PowerShell scripts, etc. That is interesting.
SRP in Default Security Level = Disallowed can additionally protect Windows Script Host (also command lines with WSH sponsors wscript.exe and cscript.exe) in blacklisted Windows subfolders.
So, all writable Windows subfolders should be blacklisted for maximum security, even "writable and not executable":
C:\Windows\System32\Com\dmp
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\Tasks
C:\Windows\Tasks
C:\Windows\Temp
C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
C:\Windows\System32\spool\drivers\color
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
.
If the user blocks WSH via policy (like in Hard_Configurator) or via blocked sponsors, then only "writable and executable" Windows subfolders may be blacklisted (skipped first three entries, from the above list).

Thanks for detailed reply! One thing though - some folders don't need protection because when you protect higher level folders then also include all the lower level ones, right? E.g. when I create disallow rule for

C:\Windows\System32\Tasks

there is no need to also then disallow

C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update

Or do you specify for your paths above to NOT be recursive? Something like C:\Windows\System32\Tasks\* ?

P.S. Win Pro 1709 (or at least my box) does not have C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys dir.

 

[Andy Ful]

Thanks for detailed reply! One thing though - some folders don't need protection because when you protect higher level folders then also include all the lower level ones, right? E.g. when I create disallow rule for

C:\Windows\System32\Tasks

there is no need to also then disallow

C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update

Or do you specify for your paths above to NOT be recursive? Something like C:\Windows\System32\Tasks\* ?

P.S. Win Pro 1709 (or at least my box) does not have C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys dir.

Your method would be unnecessary restrictive.

 

[softie15]

Your method would be unnecessary restrictive.

Uh oh! So it may cause system instability then?

I thought that was YOUR method... I am glad I asked! So, to properly do this the way you would, should all those paths end in /* in SRP? E.g. path rule for

C:\Windows\System32\Tasks\*
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update\*
etc.

?

 

[Andy Ful]

Uh oh! So it may cause system instability then?

I thought that was YOUR method... I am glad I asked! So, to properly do this the way you would, should all those paths end in /* in SRP? E.g. path rule for

C:\Windows\System32\Tasks\*
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update\*
etc.

?

Ha, ha - you caught me.
When you have both Disallowed rules:
C:\Windows\System32\Tasks
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
then the second is only for convenience and for avoiding mistakes. For example, if you would allow temporarily something only in 'C:\Windows\System32\Tasks' , then you can simply edit the rule to 'X:\Windows\System32\Tasks' and the second rule 'C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update', will be still valid. So, you are right, Using Disallowed rules as the above, can be more restrictive.
I would recommend using several Disallowed rules with common left side, because if you remove C:\Windows\System32\Tasks, you are in fact removing several rules, not one.
The less restrictive rules would be, those with *.* :
C:\Windows\System32\Tasks\*.*
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update\*.*

 

[softie15]

The less restrictive rules would be, those with *.* :
C:\Windows\System32\Tasks\*.*
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update\*.*

Thanks for a good discussion... I know what you mean above when you say "less restrictive" but it made me think of something... it's a little subtle, so please bear with me...

If we step back for a second, we are trying to build most secure and most stable system. The point of protecting Windows folders to avoid allowing any executions from non-admin-writable folders. Does protecting
C:\Windows\System32\Tasks\* (same as *.*?)
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update\*
achieve that, security-wise or does it leave any writable holes?

In other words, if we believe we identified that "...\Microsoft\Windows\RemoteApp and Desktop Connections Update\*" is the ONLY path that's writable under Tasks dir (and none of its subpaths are writable as well), then it seems like above two rules are the SAME as if we just had

C:\Windows\System32\Tasks

rule (for ALL subdirs of Tasks), right?

If the two approaches are the same security-wise, then the 2-rule approach is actually NOT less restrictive but JUST-AS-RESTRICTIVE as far as security goes.

But then, it seems like stability-wise, it's better to have the 2 path rules rather than the whole Tasks directory because some Admin software MAY want to write something into a subdir of Tasks and execute it, right?

Am I thinking about this right?

Then again... one potential hole I just thought of but have not tried: if we go with two rules, could some malware with user-privs create a directory under Tasks, then drop something into that dir, and then execute it, since now the subdirectory would not be covered by the 2 rules...

 

[Andy Ful]

...
Does protecting
C:\Windows\System32\Tasks\* (same as *.*?)

No. You would have to use : C:\Windows\System32\Tasks\*.*
...

... if we go with two rules, could some malware with user-privs create a directory under Tasks, then drop something into that dir, and then execute it, since now the subdirectory would not be covered by the 2 rules...

The number of folder path rules is not important for security if the rules have the common left side, but using *.* (file path with wildcards) is important, and less secure.
The folder path rule 'C:\Windows\System32\Tasks' covers also subfolders.
.
1. Convenient, restrictive and secure folder path rules (bolded common left side):
C:\Windows\System32\Tasks
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
.
2. Restrictive and secure as the above, but one must be careful when removing Disallowed rules:
C:\Windows\System32\Tasks
.
3. Convenient, less restrictive and less secure Disallowed file path rules:
C:\Windows\System32\Tasks\*.*
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update\*.*
.
Disallowed file path rules do not include subfolders, but one can make them more secure (one or more subfolders deeper):
C:\Windows\System32\Tasks\*.*
C:\Windows\System32\Tasks\*\*.*
C:\Windows\System32\Tasks\*\*\*.*
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update\*.*
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update\*\*.*
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update\*\*\*.*
.
From my experience, it follows that the standard Disallowed folder path rules (from point 1.), for unprotected Windows folders, have no impact on the system stability. I use them in Hard_Configurator.

 

[softie15]

Why exactly is #3 less secure than say #2? Where can malware write / execute under #3 that it could not do under #2?

I was thinking any other subfolder under Tasks, except for the 1 identified are already NON-writable by users? Or is it less secure because of that last-paragraph-scenario in my previous post?

 

[Andy Ful]

Why exactly is #3 less secure than say #2? Where can malware write / execute under #3 that it could not do under #2?

I was thinking any other subfolder under Tasks, except for the 1 identified are already NON-writable by users? Or is it less secure because of that last-paragraph-scenario in my previous post?

Generally, #3 type rules are more secure for folders that allow making subfolders, then the exploit can make a subfolder, copy the payload to it and execute. This is not the case with the concrete folder
C:\Windows\System32\Tasks, but is true for the folder:
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
In #1 or #2 the payload will be blocked by SRP, in #3 not.

 

[softie15]

Generally, #3 type rules are more secure for folders that allow making subfolders, then the exploit can make a subfolder, copy the payload to it and execute. This is not the case with the concrete folder
C:\Windows\System32\Tasks, but is true for the folder:
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
In #1 or #2 the payload will be blocked by SRP, in #3 not.

Great, thanks for confirming!
So you are talking about the last-paragraph-scenario in my prior post, i.e. "Then again... one potential hole I just thought of but have not tried: if we go with two rules, could some malware with user-privs create a directory under Tasks, then drop something into that dir, and then execute it, since now the subdirectory would not be covered by the 2 rules..."

Now, I noticed in your earlier post here you said: "all writable Windows subfolders should be blacklisted for maximum security, even "writable and not executable""; however your re-tests were only based on what you had considered as Protected folders before. In other words, I think you will find other writable folders as well. My OP is effectively listing all such writable dirs (after I had disregarded all writable subdirs of such dirs, but I understand based on your explanation why those might also be good to include if we plan to sometimes remove ancestor folders).

On my system these are the writable dirs (bolded items are NOT included in your latest list from this post):

C:\Windows\tracing
C:\Windows\Registration\CRMLog
C:\Windows\System32\FxsTmp
C:\Windows\System32\com\dmp
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\drivers\color
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\FxsTmp
C:\Windows\SysWOW64\com\dmp
C:\Windows\SysWOW64\Tasks
C:\Windows\Tasks
C:\Windows\Temp

Thank you for a great discussion, Andy. I think I have a much better appreciation of this topic now and feel safer blocking above dirs after learning of your experiences!

 

[Andy Ful]

Great, thanks for confirming!
So you are talking about the last-paragraph-scenario in my prior post, i.e. "Then again... one potential hole I just thought of but have not tried: if we go with two rules, could some malware with user-privs create a directory under Tasks, then drop something into that dir, and then execute it, since now the subdirectory would not be covered by the 2 rules..."

Now, I noticed in your earlier post here you said: "all writable Windows subfolders should be blacklisted for maximum security, even "writable and not executable""; however your re-tests were only based on what you had considered as Protected folders before. In other words, I think you will find other writable folders as well. My OP is effectively listing all such writable dirs (after I had disregarded all writable subdirs of such dirs, but I understand based on your explanation why those might also be good to include if we plan to sometimes remove ancestor folders).

On my system these are the writable dirs (bolded items are NOT included in your latest list from this post):

C:\Windows\tracing
C:\Windows\Registration\CRMLog
C:\Windows\System32\FxsTmp
C:\Windows\System32\com\dmp
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\drivers\color
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\FxsTmp
C:\Windows\SysWOW64\com\dmp
C:\Windows\SysWOW64\Tasks
C:\Windows\Tasks
C:\Windows\Temp

Thank you for a great discussion, Andy. I think I have a much better appreciation of this topic now and feel safer blocking above dirs after learning of your experiences!

.
Here is the complete list for Windows 10 v.1709:
Unprotected (writable and executable)
C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
C:\Windows\System32\spool\drivers\color
C:\Windows\System32\Tasks
C:\Windows\SysWOW64\Tasks
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
C:\Windows\Tasks
C:\Windows\Temp
Protected (writable and not executable) but Windows Script Host and MSI scripts can be copied there and run via command line using sponsors (wscript.exe, cscript.exe and msiexec.exe):
C:\Windows\Registration\CRMLog
C:\Windows\System32\Com\dmp
C:\Windows\SysWOW64\Com\dmp
C:\Windows\System32\FxsTmp
C:\Windows\SysWOW64\FxsTmp
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\tracing
.
When SRP Default Protection Level = Disallowed, then the above blacklisted entries protect also Windows Script Host and MSI.
When SRP Default Protection Level = Basic User, then the above blacklisted entries do not protect WSH, so it should be protected via policy or by blocking wscript.exe and cscript.exe.
One should realize that protecting Windows subfolders via SRP folder blacklist, can only protect native executables (EXE, COM, SCR files), BAT, CMD, Windows Script Host and MSI scripts. The other commonly abused files like HTA, CHM, etc. can be protected against command line execution by blocking sponsors (mshta.exe, hh.exe, etc.).

 

[Andy Ful]

Sometimes, when I post answers late in the night, I can make mistakes. That happened in my previous post, where are concluded that Windows Script Host scripts are not protected in blacklisted Windows subfolders. It is funny, because I know much about SRP, and even wrote some tutorials about SRP. That is true that those scripts are not protected by Default Security Level set to Basic User, but they are protected by SRP Disallowed rules used to blacklist subfolders.
So it is time to sum up, all interesting facts about protecting Windows writable subfolders.
.
In Windows, there are several techniques to block the possibility of running files in the folder.
The best known (available on Windows Home) are the below:
ACL permissions > SRP Disallowed Rules > SRP Default Security Level set to Disallowed or Basic User
The technique on the left can override that on the right.
.
Most C:\Windows subfolders has ACL permission that does not allow to write files, by programs running as standard user. But there are a few subfolders that are writable, anyway:
C:\Windows\debug\WIA
C:\Windows\Registration\CRMLog
C:\Windows\servicing\Packages
C:\Windows\servicing\Sessions
C:\Windows\System32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}
C:\Windows\System32\Com\dmp
C:\Windows\System32\FxsTmp
C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
C:\Windows\System32\spool\drivers\color
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\Tasks
C:\Windows\System32\Tasks_Migrated
C:\Windows\System32\Tasks\Microsoft\Windows\PLA\System
C:\Windows\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
C:\Windows\SysWOW64\Com\dmp
C:\Windows\SysWOW64\FxsTmp
C:\Windows\SysWOW64\Tasks
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update
C:\Windows\Tasks
C:\Windows\Temp
C:\Windows\tracing
.
Some of them are not writable in Windows 10, and a few do not have executable ACL permissions.
Blacklisting those subfolders has no impact on Windows functionality and Windows Updates in the standard computer with Windows Home (Vista and higher versions):
Hard_Configurator - Windows Hardening Configurator
Hard_Configurator - Windows Hardening Configurator
Hard_Configurator - Windows Hardening Configurator
ACL executable permission apply to Windows native executables (EXE, COM, SCR) and BAT, CMD scripts hosted by cmd.exe . Those files won't execute in Windows subfolders which are not executable, but sadly, some of the folders listed above are executable. Furthermore, without additional protection other scripts like those hosted by Windows Script Host, PowerShell or MSI Installer can be copied to writable Windows subfolder and run as standard user. Also, there are more such files commonly used by malc0ders: CHM, HTA, REG, etc.
Using SRP can be a kind of solution. When the user applies SRP with Default Security Level set to Disallowed or Basic User, often the C:\Windows folder is whitelisted, because almost all Windows subfolders are not writable. But, for the enhanced security the writable exceptions should be better protected. This can be done by applying SRP Disallowed folder path rules for the listed above, writable Windows subfolders. Disallowed rules automatically activate extended protection for CMD host, Windows Script Host, and Windows Installer, so scripts: BAT, CMD, JS, JSE, VBS, VBE, WSF, WSH, MSI are blocked also via command line when using the sponsors cmd.exe, wscript.exe, cscript.exe, msiexec.exe.
One can enhance the protection also for PowerShell scripts and other abused files (CHM, HTA, REG, etc.) by adding Disallowed rules for sponsors (powershell.exe, powershell_ise.exe, hh.exe, mshta.exe, regedit.exe, reg.exe, regedt32.exe, etc.).
.
Protecting Windows subfolders is important in default-deny SRP, when something is abused, like Office documents with malicious macros, PDF documents with embedded scripts or the shortcuts with malicious commands. The users who use sandboxed applications for opening potentially vulnerable files (documents, media, etc.) and are careful with shortcuts, are not obliged to bother with blacklisting Windows writable subfolders.

 

[softie15]

Thank you for a nice summary, Andy!

One can enhance the protection also for PowerShell scripts and other abused files (CHM, HTA, REG, etc.) by adding Disallowed rules for sponsors (powershell.exe, powershell_ise.exe, hh.exe, mshta.exe, regedit.exe, reg.exe, regedt32.exe, etc.)

I know you later said careful users don't have to bother, but for the paranoid of us, would you say hh.exe, mshta.exe, regedit.exe, reg.exe, regedt32.exe are fine to block and will not cause instability (since they are only blocked for NON-admins), right? Any others that come to mind?

 

[Andy Ful]

Thank you for a nice summary, Andy!
I know you later said careful users don't have to bother, but for the paranoid of us, would you say hh.exe, mshta.exe, regedit.exe, reg.exe, regedt32.exe are fine to block and will not cause instability (since they are only blocked for NON-admins), right? Any others that come to mind?

Paranoid users should block all sponsors, and delay Windows Updates. Then updating may be done with unblocked sponsors. The blocked sponsors can interfere with updates very rarely. I installed Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10, several times with upgrades and hundreds of updates. Only one update in Windows 10 FCU failed (one month ago). I simply unblocked the sponsors, and the update finished successfully.
But the most effective protection is not using MS Office, not allowing macros, and using the protected PDF viewer.