Guide Windows Home/Pro owner? Use Software Restriction Policies!

Guides - Privacy & Security Tips
123 Replies 59,235 Views
This guide may include member-written or external content. Check the steps before applying them.
@Av Gurus

Yes then you make a hole in your SRP, since most software installs from Temp folder.

Because the Software Restriction Policies default is set to basic user AND SRP does not apply to Administrator AND you can elevate MSI (installers) with Symantec registry tweak, you should not run into update/install problems, because:
  • All software in Windows and Program Files folders have to run elevated to get update access to these UAC protected folders. Since SRP does not apply to Admin, all already installed programs are not restricted by SRP (basic user). So the SRP is set and forget
  • When you want to install new software, just right click and choose "Run as Administrator" and new software will install fine. So the SRP only blocks executions from user space which are not initiated by the user.
 
Somewhat unusual TIP: add VoodooShield in AUTO-PILOT to these SRP basic user.

Although two anti-executables (VS and SRP) seem like a redundant set up, they complement each other nicely, because
  1. VS and SRP both allow already installed software to run & update (so it is Set and Forget).

  2. VS also blocks suspicious command line executions which hardens SRP against poisened documents (e.g. SRP/AppLocker bypas through Macro execution as discovered by Didier Stevens in the past)

  3. SRP complements VS because blocks all unelevated executable file formats in user folders (VS does not block DLL's for example).

  4. When you knowingly bypass SRP with "Run as Admin", then VS running in AUTO-PILOT mode closes any "shoot in the foot" errors made by the user because it:
    • Blocks all known malware using 55 engines of Virus Total
    • Blocks 99% of all zero days with its own Artificial Intelligence engine
 
Last edited:
In Windows 8+, You can also consider forcing SmartScreen (App on the Run) to check all executable files in the User Space on NTFS hard disk. It can be done by the Reg tweak and simple vbs script.
The Reg tweak adds the new element in Explorer context menu (right mouse click) due to:
[HKEY_CLASSES_ROOT\*\shell\Run with SmartScreen\command]
@="C:\\Windows\\RunAsSmartscreen.vbs \"%1\" %*"
The RunAsSmartscreen.vbs script adds the proper alternate data stream to the file that is going to be run and triggers SmartScreen check. I think that SmartScreen Filter gives less false positives than Voodoo Shield in AUTO-PILOT. In the real world, both solutions give similar protection.
If You want to disable Windows Script Host, the SmartScreen solution is still possible by wrapping RunAsSmartscreen.vbs to RunAsSmartscreen.exe with Sordum "Exe From Vbs" (Exe From Vbs v1.3 ~ Sordum software Blog). This wrapper adds script interpreter to the exe file, so WSH is not needed when using RunAsSmartscreen.exe .
The RunAsSmartscreen.exe starts with Administrator rights, so automatically can bypass SRP protection.
By the way, thanks for all Your posts about Windows built in security solutions.
 
Windows_Security said:
When you knowingly bypass SRP with "Run as Admin", then VS running in AUTO-PILOT mode closes any "shoot in the foot" errors made by the user because it:
Click to expand...
Also if you have applied a password to VS, then when you try to elevate using "Run As Admin" VS will require a password before allowing ;)
 
Here is the vbs script that works on my Windows 10 Home. It is in the alpha stage (not tested on other machines).
Anybody can optimize and modify it.
If You want to bypass SRP the script must be wrapped to exe file for asking admin rights.
Some executable extensions have to be removed from SRP ( BAT, CMD, JS, JSE, MSI, VBE, VBS, WSF), if You want to run them with "Run As Smartscreen". I noticed that they are still protected by SRP. The difference is that they are blocked when sponsors (cmd.exe, wscript.exe, msiexex.exe) try to get files in the User Space.
.
.
RunAsSmartScreen.vbs
****************************************************************************************************************************************
Set WshShell = CreateObject("WScript.Shell")
'****** Put the path of the file to fsoFile variable ******
Set fso = CreateObject("Scripting.FileSystemObject")
Set fsoFile = fso.GetFile(WScript.Arguments.Item(0))
'****** Check if the file is in the System Space ******
If InStr(chr(34)&fsoFile&chr(34), "C:\Windows\") = 2 Then
WshShell.Run(chr(34)&fsoFile&chr(34))
WScript.Quit
Else
If InStr(chr(34)&fsoFile&chr(34),"C:\Program Files\") = 2 Then
WshShell.Run(chr(34)&fsoFile&chr(34))
WScript.Quit
Else
If InStr(chr(34)&fsoFile&chr(34),"C:\Program Files (x86)\") = 2 Then
WshShell.Run(chr(34)&fsoFile&chr(34))
WScript.Quit
Else
'****** Clear all file attributes
fsoFile.Attributes = fsoFile.Attributes AND 0
'****** Create, run and delete another script AddZoneIdentifierToFile.vbs , that adds the proper ADS ******
Set f = fso.CreateTextFile("C:\Windows\temp\AddZoneIdentifierToFile.vbs")
f.WriteLine ("Set WshShell = CreateObject(" & chr(34) & "WScript.Shell" & chr(34)&")")
f.WriteLine ("Set fso = CreateObject(" & chr(34) & "Scripting.FileSystemObject" & chr(34)&")")
f.WriteLine ("Set f = fso.CreateTextFile(" & chr(34) & fsoFile & ":Zone.Identifier" & chr(34)&")")
f.WriteLine ("f.WriteLine " & chr(34) & "[ZoneTransfer]" & chr(34))
f.WriteLine ("f.WriteLine " & chr(34) & "ZoneId=3" & chr(34))
f.WriteLine ("f.close")
WshShell.Run ("C:\Windows\Temp\AddZoneIdentifierToFile.vbs")
Set f = fso_OpenTextFile("C:\Windows\Temp\AddZoneIdentifierToFile.vbs", 1)
f.Close
WScript.Sleep 1000
fso.DeleteFile("C:\Windows\Temp\AddZoneIdentifierToFile.vbs")
'****** Run the file ******
WshShell.Run(chr(34)&fsoFile&chr(34))
End If
End If
End If
Set WshShell = Nothing
WScript.Quit

****************************************************************************************************************************************
I do not know why there is the yellow face in the vbs code. You must replace it by dotOdot, similarly to the fso.DeleteFile command.
.
.
Run_As_SmartScreen.reg
***************************************************************************************
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell\Run As SmartScreen]
"Icon"="%windir%\\system32\\SmartScreenSettings.exe"
[HKEY_CLASSES_ROOT\*\shell\Run As SmartScreen\command]
@="C:\\Windows\\RunAsSmartscreen.exe \"%1\" %*"
***************************************************************************************
.
.
Installation:
Wrap RunAsSmartscreen.vbs to RunAsSmartscreen.exe
Copy RunAsSmartscreen.exe to the "C:\Windows\" folder.
Import Run_As_SmartScreen.reg to the Windows Registry.
.
.
Deinstallation:
Remove RunAsSmartscreen.exe from "C:\Windows\" folder.
Delete the registry key: [HKEY_CLASSES_ROOT\*\shell\Run with SmartScreen]
.
.
This is the more convenient "Run As SmartScreen" solution. I also tried solutions with RunAsSmartscreen.bat or RunAsSmartscreen.vbs without wrapping, but then the launcher is needed, to run the file from the script with admin rights, to bypass SRP. On my machine, the Nirsoft program "nircmd.exe" worked well.
 
Last edited:
I updated my poor knowledge of vbs scripting. There's no need to use wrappers or launchers to elevate (but still this is the convenient way). I created an example of "Run As SmartScreen" solution using only vbs scripts (see below for attached files).
I've also noticed recently that "Run As Admin" works well with default deny SRP when value of SRP DefaultLevel=0.
If DefaultLevel=20000 then SRP cannot protect removed script extensions (see post #14 in Secure Windows - Software restriction Policies to Windows Home )

If the "Run As SmartScreen" setup was made for the inexperienced user, some system hardening is needed:
1. Restrict access to removable disks (default -> "Deny_Execute"=dword:00000000)
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}]
"Deny_Execute"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Storage]
"Deny_Execute"=dword:00000001

2. Hide "Run As Admin":
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"HideRunAsVerb"=dword:00000001

Removable disks may have non NTFS format, so files lose alternate data streams there and cannot be checked by the SmartScreen.
The user may accidentally choose "Run As Admin" instead of "Run As SmartScreen".
 

Attachments

Last edited:
From last Windows Update (Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB3194496)) Windows Defender have problem with update (mpam) and something from Chrome (software_reporter_tool.exe).
Any solution accept temporary set to Unrestricted, apply update and then set back to Basic?

Clipboard01.jpg Clipboard02.jpg Clipboard03.jpg
 
Blocking User Space execution and using portable programs don't work well together.

Yyou can only run them as Admin, while you want to run programs with the lowest rights possible.

By adding a folder in user space with execution rights you are putting a hole in your defense.

I installed Portable Firefox in User folder and Ran it as Admin, it works.
 
Last edited:
Windows_Security said:
Blocking User Space execution and using portable programs don't work well together.

Yyou can only run them as Admin, while you want to run programs with the lowest rights possible.

By adding a folder in user space with execution rights you are putting a hole in your defense.

I installed Portable Firefox in User folder and Ran it as Admin, it works.
Click to expand...
So in my case I have portable apps in C directory, should I move them to documents or downloads?

Here some additional rules i've added, can you guys let me know if I should add others?

2016-10-12_134557.png
 
Last edited:
Av Gurus said:
I put all my portable app in one folder and then set that folder to Unrestricted in SRP.
Click to expand...

If Your portable programs do not update frequently the best way is to whitelist them by hash. Also, many portable applications work well in "Program Files" or "Program Files (x86)" - sometimes You need to change the folder where the application saves its settings etc. , because in above folders the Administrative Rights are needed.
Some programs are wrapped and have to use TEMP folder in the User Space to execute (most frequently it is ...\AppData\Local\Temp). Execution in the TEMP folder will be blocked by SRP, so the unwrapped file should be whitelisted by hash too. Usually, such files are quickly deleted, so utilities similar to "Moo0 FileMonitor" or Excubits MZWriteScanner may be needed to detect which files were temporary dropped to TEMP folder.
 
I keep my portable app on a separate disk (not on C:) so I can have it when I reinstall Windows.
I know about that TEMP problem (Process Explorer, Zemana AM update...).
Whitelist by Hash don't know how to do that...???

I just try now (see picture) is like this OK?

1.jpg
 
Av Gurus said:
I keep my portable app on a separate disk (not on C:) so I can have it when I reinstall Windows.
I know about that TEMP problem (Process Explorer, Zemana AM update...).
Whitelist by Hash don't know how to do that...???

I just try now (see picture) is like this OK?

View attachment 118032
Click to expand...

It looks good.:)
 

Recently browsing

Members who viewed this thread in the last 5 minutes

You may also like...

Back
Top