Windows Home/Pro owner? Use Software Restriction Policies!
- Thread starter Windows_Security
- Start date
The associated guide may contain user-generated or external content.
- Sep 22, 2014
- 1,767
It should start on login.
Did you add Program Files/Program Files (x86) to unristricted?
Did you add Program Files/Program Files (x86) to unristricted?
- Feb 15, 2012
- 2,128
- Feb 15, 2012
- 2,128
- Dec 23, 2014
- 8,591
Here is a good explanation:
"A hash is a series of bytes with a fixed length that uniquely identifies a program or file. A hash value is generated by an algorithm that essentially creates a fingerprint of the file, making it nearly impossible for another program to have the same hash. If you create a hash rule and a user attempts to run a program affected by the rule, the system checks the hash value of the executable file and compares it with the hash value stored in the software restriction policy. If the two match, the policy settings will apply. Therefore, creating a hash rule for an application executable prevents the application from running if the hash value is not correct. Because the hash value is based on the file itself, the file will continue to function if you move it from one location to another. If the executable file is altered in any way, for example, if it is modified or replaced by a worm or virus, the hash rule in the software restriction policy prevents the file from running."
http://prep-for-70-410.blogspot.com/2015/12/configure-application-restriction.html
File hashes are widely used to uniquely identify files, for example Virus Total shows file hashes in "Additional Information" bookmark.
In Windows 10, SRP uses MD5 and SHA-256 cryptographic algorithms to fingerprint the files whitelisted by hash. The second algorithm is pretty good.
The main difference (for whitelisting) between Hash and Path checking is simple. The first can recognize if the file has been changed by malware, the second unfortunately cannot.
Also, UTC/GMT times also affects hash generated by the software to harden the security. One time Password and Authenticator apps on phones is a good example.
Does EMET require additional setups such as whitelisting apps etc. I simply set max security settings and recently EMET protected me, from installing Java on IE11, BTW Its long time since I used IE so EMET helped me to block it because it was insecure.
EMET require manual whitelisting, if not some of your softs may be blocked depending the security setting you chose.
I just tested latest EMET version. It is still a bit buggy - and Microsoft set the EMET service start to Automatic (Delayed) ? It seems to be a little bit of a resource hog too...
I observed delays by over 20 sec if EMET was running on Auto startup on HDD. On SSD, it doesn't matter.
Any examples, Mr. Umbra? So far, I've seen Java, IE, FF, Chrome, FB, Twitter apps in EMET list.
- Dec 23, 2014
- 8,591
After a few months of using SRP, I realized that 'Basic User' security level is vulnerable to simple drive by attack in my computer. It is sufficient to drop malware EXE file and the shortcut to it, and then execute this shortcut. Other extensions are still protected.
Am I stupid or Microsoft is so clever?
Am I stupid or Microsoft is so clever?
- Dec 23, 2014
- 8,591
- Dec 23, 2014
- 8,591
It's not a big deal for home users, because even simple drive by attacks are still successful. So, no one bothers to bypass SRP in the wild. Anyway, I am a little bit disappointed.
I tried to close this loophole by changing security level to DISSALLOWED and removing LNK from SRP protected extensions. And, what happened then? The EXE and MSI files, CMD scripts, and WHS scripts were protected, but CHM, CPL, HTA, MSC, and REG files were not. So it seems to me that SRP with DISSALLOWED setup must be also covered by blacklisting sponsors (hh.exe, control.exe, mshta.exe, mmc.exe, regedit.exe and maybe some others). It resembles blacklisting in Excubits Bouncer but is safer for Windows OS. Sponsors blacklisted in SRP can be still run by processes with Administrative or System Rights.
Of course, the simplest solution is not using shortcuts and blocking them in SRP.
I tried to close this loophole by changing security level to DISSALLOWED and removing LNK from SRP protected extensions. And, what happened then? The EXE and MSI files, CMD scripts, and WHS scripts were protected, but CHM, CPL, HTA, MSC, and REG files were not. So it seems to me that SRP with DISSALLOWED setup must be also covered by blacklisting sponsors (hh.exe, control.exe, mshta.exe, mmc.exe, regedit.exe and maybe some others). It resembles blacklisting in Excubits Bouncer but is safer for Windows OS. Sponsors blacklisted in SRP can be still run by processes with Administrative or System Rights.
Of course, the simplest solution is not using shortcuts and blocking them in SRP.
Last edited:
- Dec 23, 2014
- 8,591
Yes, that is true for normal shortcuts. But, in similar way WSH scripts, HTA, and CPL files can be run (3 files have to be dropped in the User Space). That is not good.
Windows_Security
Level 24
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
- Mar 13, 2016
- 1,298
Well that depends: Microsoft was so clever to protect the folders from which executables are allowed in basic user mode and they called it UAC. So for SRP to be bypassed by a drive by attack, you have to ignore both Smartscreen and UAC.
- Dec 23, 2014
- 8,591
@Windows_Security
I am not so sure about it, in many cases a drive by attack can gently ignore both UAC and Smartscreen. Both malware file and the shortcut can be dropped to the User Space (no copy alert) without 'Mark of the Web' (no Smartscreen check on the run), and executed without elevation (no UAC alert). Thanks to Microsoft, SRP will stop direct malware execution, but sadly, not indirect execution by the shortcut.
It is also interesting, that after copying the same shortcut to the System Space (for example C:\Windows) above trick does not work.
I would like the missing option in SRP to whitelist shortcuts by hash.
By the way, using SRP with something like Voodoo Shield may be a good idea.
@Av Gurus
My reply to your question was not correct, it should be:
Almost anywhere (except whitelisted folders).
I am not so sure about it, in many cases a drive by attack can gently ignore both UAC and Smartscreen. Both malware file and the shortcut can be dropped to the User Space (no copy alert) without 'Mark of the Web' (no Smartscreen check on the run), and executed without elevation (no UAC alert). Thanks to Microsoft, SRP will stop direct malware execution, but sadly, not indirect execution by the shortcut.
It is also interesting, that after copying the same shortcut to the System Space (for example C:\Windows) above trick does not work.
I would like the missing option in SRP to whitelist shortcuts by hash.
By the way, using SRP with something like Voodoo Shield may be a good idea.
@Av Gurus
My reply to your question was not correct, it should be:
Almost anywhere (except whitelisted folders).
Last edited:
Similar threads
