Andy Ful
From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
- Dec 23, 2014
- 8,484
In the part 1 - Secure Windows - How do Software Restriction Policies work (part 1) ? - the first layer of SRP protection was introduced.
It is related to 'Designated File Types' list (DFT) and ShellExecute() API function. If the file extension is on DFT list, then ShellExecute() can prevent that file from opening.
Blocking files by ShellExecute() prevents users from unknowingly or accidentally executing malicious code, but files still can be opened by the system when using commands. If you choose to open HTA file directly, using the command:
'mshta.exe %Userprofile%\Desktop\How2BeReach.hta',
then ShellExecute() will be skipped, and SRP will not know that something is going to be executed.
Now, Windows has two possibilities:
1. Allow to open the file.
2. Use another mechanism to call into SRP.
In most cases Windows will follow the 'point 1'. So, users cannot open the files from DFT list by clicking the file icon on the Desktop, pressing Enter, choosing 'Open' or 'Open with ...' from Explorer context menu. This prevents fooling users to open double extension malware files like IamInnocentFile.pdf.exe (with PDF icon). The user can still try to open the file using the application that support opening it (sponsor). In the case of the above malware, the PDF viewer will run (with file opening error), and IamInnocentFile.pdf.exe will not be executed, at all. Yet, the files can be opened, when using commands.
In some special cases Windows will use the 'point 2' solution, anyway. There are some Privileged Objects: 'CMD Host', 'Windows Script Host', and 'Windows Installer'. They are prepared to call into SRP about supported files. So, in the case of the 'How2BeReach.vbs' file, it can be blocked, because 'Windows Script Host' can call into SRP about VBS files (even when VBS is not on DFT list).
It is worth mentioning, that above privileged objects can control file execution independely of ShellExecute() and DFT list. File blocking by 'Script Hosts' or 'Windows Installer' is also more comprehensive as compared to ShellExecute().
For example, the How2BeReach.vbs can be run by (A) double click from the Desktop or by (B) executing the command: 'wscript.exe %Userprofile%\How2BeReach.vbs'. If we add VBS extension to DFT list, then:
ShellExecute() can block the (A) but cannot block (B).
Privileged Objects can block both (A) and (B).
Finally, Privileged Objects can block supported files even when those files have changed extensions.
One can ask a question: what is the (B) protection for? Users, mostly run files by clicking, not by executing commands. That is true, but the autorun.inf on the pen drive or DVD disk, can execute commands. The same is true when the system or application is exploited, etc. So, the (B) protection is essential against many 'Drive By' attacks.
From the above considerations, we can conclude, that scripts: BAT, CMD, JS, JSE, VBS, VBS, WSF, WSH, and MSI files can be blocked in two independent ways:
* by extension (DFT list, ShellExecute());
* by Privileged Objects ('CMD Host', 'Windows Script Host', and 'Windows Installer').
The same applies to SCR files that use ShellExecute() to find out, that they are just a special kind of EXE files.
The native Windows executables: COM and EXE files, are always executed without invoking ShellExecute(). Instead of this, the API function CreateProcess() is used, and it can also call into SRP to block COM, EXE (and SCR) files.
There's another API function, that can call into SRP. The LoadLibrary() is invoked when EXE file is executed, and tries to load binary libraries (DLL and OCX files). SRP can be configured, either to allow or block loading libraries from specified locations. This layer of protection can stop many DLL attacks, when system files are used to load malicious libraries from the User Space (paths ommittet for simplicity):
InstallUtil.exe /logfile= /LogToConsole=false /U malicious.dll
regsvcs.exe malicious.dll
regasm.exe /U malicious.dll
regsvr32 /s /u malicious.dll
regsvr32 /s malicious.dll
rundll32 malicious.dll,EntryPoint
SRP have three enforcement settings:
* No Enforcement - ignores 'DFT list + ShellExecute() + CreateProcess() + LoadLibrary()' calls. SRP will only answer the calls from 'CMD Host', 'Windows Script Host' and 'Windows Installer'.
* Skip DLLs - ignores only LoadLibrary() calls - other security layers: 'DFT list + ShellExecute() + CreateProcess() + LoadLibrary()' + 'CMD Host' + 'Windows Script Host' + 'Windows Installer' calls are not ignored.
* All files - activates all SRP security layers.
The protection applied by: CreateProcess(), LoadLibrary(), CMD Host, Windows Script Host, and Windows Installer, can work even when files have changed extensions.
We see that 'All files' enforcement setting is the most powerful, but one should remember, that programs which use binary libraries located in the User Space, will not run properly. So, all those libraries have to be whitelisted.
End of part 2.
It is related to 'Designated File Types' list (DFT) and ShellExecute() API function. If the file extension is on DFT list, then ShellExecute() can prevent that file from opening.
Blocking files by ShellExecute() prevents users from unknowingly or accidentally executing malicious code, but files still can be opened by the system when using commands. If you choose to open HTA file directly, using the command:
'mshta.exe %Userprofile%\Desktop\How2BeReach.hta',
then ShellExecute() will be skipped, and SRP will not know that something is going to be executed.
Now, Windows has two possibilities:
1. Allow to open the file.
2. Use another mechanism to call into SRP.
In most cases Windows will follow the 'point 1'. So, users cannot open the files from DFT list by clicking the file icon on the Desktop, pressing Enter, choosing 'Open' or 'Open with ...' from Explorer context menu. This prevents fooling users to open double extension malware files like IamInnocentFile.pdf.exe (with PDF icon). The user can still try to open the file using the application that support opening it (sponsor). In the case of the above malware, the PDF viewer will run (with file opening error), and IamInnocentFile.pdf.exe will not be executed, at all. Yet, the files can be opened, when using commands.
In some special cases Windows will use the 'point 2' solution, anyway. There are some Privileged Objects: 'CMD Host', 'Windows Script Host', and 'Windows Installer'. They are prepared to call into SRP about supported files. So, in the case of the 'How2BeReach.vbs' file, it can be blocked, because 'Windows Script Host' can call into SRP about VBS files (even when VBS is not on DFT list).
It is worth mentioning, that above privileged objects can control file execution independely of ShellExecute() and DFT list. File blocking by 'Script Hosts' or 'Windows Installer' is also more comprehensive as compared to ShellExecute().
For example, the How2BeReach.vbs can be run by (A) double click from the Desktop or by (B) executing the command: 'wscript.exe %Userprofile%\How2BeReach.vbs'. If we add VBS extension to DFT list, then:
ShellExecute() can block the (A) but cannot block (B).
Privileged Objects can block both (A) and (B).
Finally, Privileged Objects can block supported files even when those files have changed extensions.
One can ask a question: what is the (B) protection for? Users, mostly run files by clicking, not by executing commands. That is true, but the autorun.inf on the pen drive or DVD disk, can execute commands. The same is true when the system or application is exploited, etc. So, the (B) protection is essential against many 'Drive By' attacks.
From the above considerations, we can conclude, that scripts: BAT, CMD, JS, JSE, VBS, VBS, WSF, WSH, and MSI files can be blocked in two independent ways:
* by extension (DFT list, ShellExecute());
* by Privileged Objects ('CMD Host', 'Windows Script Host', and 'Windows Installer').
The same applies to SCR files that use ShellExecute() to find out, that they are just a special kind of EXE files.
The native Windows executables: COM and EXE files, are always executed without invoking ShellExecute(). Instead of this, the API function CreateProcess() is used, and it can also call into SRP to block COM, EXE (and SCR) files.
There's another API function, that can call into SRP. The LoadLibrary() is invoked when EXE file is executed, and tries to load binary libraries (DLL and OCX files). SRP can be configured, either to allow or block loading libraries from specified locations. This layer of protection can stop many DLL attacks, when system files are used to load malicious libraries from the User Space (paths ommittet for simplicity):
InstallUtil.exe /logfile= /LogToConsole=false /U malicious.dll
regsvcs.exe malicious.dll
regasm.exe /U malicious.dll
regsvr32 /s /u malicious.dll
regsvr32 /s malicious.dll
rundll32 malicious.dll,EntryPoint
SRP have three enforcement settings:
* No Enforcement - ignores 'DFT list + ShellExecute() + CreateProcess() + LoadLibrary()' calls. SRP will only answer the calls from 'CMD Host', 'Windows Script Host' and 'Windows Installer'.
* Skip DLLs - ignores only LoadLibrary() calls - other security layers: 'DFT list + ShellExecute() + CreateProcess() + LoadLibrary()' + 'CMD Host' + 'Windows Script Host' + 'Windows Installer' calls are not ignored.
* All files - activates all SRP security layers.
The protection applied by: CreateProcess(), LoadLibrary(), CMD Host, Windows Script Host, and Windows Installer, can work even when files have changed extensions.
We see that 'All files' enforcement setting is the most powerful, but one should remember, that programs which use binary libraries located in the User Space, will not run properly. So, all those libraries have to be whitelisted.
End of part 2.
Last edited:
