Someone posted a new 0-day over at the Eset forum here: https://forum.eset.com/topic/13703-popup-951533118-blocked/ What this bugger did among many things was create multiple copies of wscript.exe in a %AppData%/Roaming subdirectory under different .exe names. Granted most are monitoring %AppData% directories for .exe startup but in this instance, any directory could have been used.
If execution from "not standard" locations is blocked, it probably wouldn't be able to run, wouldn't it? So SUA and SRP could stop it, with no problems. EDIT: also question about registry key that disables script engines: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings Would it also disable running it from other locations?
Well if your using whitelisting and only allowing those apps to run, then of course the malware wouldn't be able to execute.
According to the below, "UseWinSafer" blocks all scripts. I checked same in my Win 10 1703 build and it is indeed set to "1." So unless I am interpreting this wrong, all .ws and .js scripts are blocked from running. I will have to test this because I know in prior Win 10 builds, I could run scripts. However, I believe the below only applies to startups of wscript.exe not any renamed vers. of it. Will do a test. https://isc.sans.edu/forums/diary/Controlling JavaScript Malware Before it Runs/21171
The "UseWinSafer" key does not stop wscript.exe execution. I used the Hello World .js script from the above SANS article. It ran just fine per the below screen shot: -EDIT- Tried the "TrustPolicy" option. That didn't work either. -EDIT2- This might be the problem since "UseWinSafer" only applies if SRP set. Will play with these settings tomorrow:
Thnx. So setting Enabled key to 0 will add some more protection. I just have to remember to enable it each time I run PatchCleaner. Usually I have to run it twice
You can use bat, something like this. Code: reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v "ValidateAdminCodeSignatures" /t REG_DWORD /d "0" /f reg add "HKCU\Software\Microsoft\Windows Script Host\Settings" /v "Enabled" /t REG_DWORD /d "1" /f reg add "HKLM\Software\Microsoft\Windows Script Host\Settings" /v "Enabled" /t REG_DWORD /d "1" /f start "" "%ProgramFiles% (x86)\HomeDev\PatchCleaner\PatchCleaner.exe" pause reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v "ValidateAdminCodeSignatures" /t REG_DWORD /d "1" /f reg add "HKCU\Software\Microsoft\Windows Script Host\Settings" /v "Enabled" /t REG_DWORD /d "0" /f reg add "HKLM\Software\Microsoft\Windows Script Host\Settings" /v "Enabled" /t REG_DWORD /d "0" /f
The "TrustPolicy" setting does indeed work as noted by below screen shot. Note that TrustPolicy is a Dword value. I also set WinSAFER setting to "0" since is only applicable if SRP or AppContainer is active. For me this is a better alternative. If malware is running a renamed ver. of wscript.exe, it is unlikely it will be using a signed script. If it attempts to run, you will get an alert of the malware activity.
For me a simple solution. I someone copies any of the script engines to a different exe, name change or not, and drops it on any disk MZwritescanner announces and blocks it.
Found a better solution. Set "TrustPolicy" to a value of "1". This will alert you every time wscript.exe in any fashion is run and show you the signing status of the script. It will also allow you to run unsigned scripts if you so wish. A much better solution than always having to change registry settings each time you have an app that validity uses a wscript.exe script.
Also and predictably since nothing MS develops is 100% secure, TrustPolicy can be bypassed: https://msdn.microsoft.com/en-us/library/bb985985.aspx
