Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Security
Video Reviews - Security and Privacy
Windows Script Host, PowerShell, and Scriptors
Message
<blockquote data-quote="hjlbx" data-source="post: 427549"><p>Removing powershell and disabling wscript is not enough.</p><p></p><p>One has to realize that some apps include script hosting built-in - like Internet Explorer; such apps, if they are running, will allow scripts to run dependent upon what script shell they have incorporated ! VBS can also be a bit tricky because of msscript.ocx and mshta.exe, but the typical user need not be particularly OCD about nor monkey with those. Listen ! - if you start messing about with them you are going to break something ! Leave it alone ! Just be aware of them - that's all I'm suggesting...</p><p></p><p>You have to alert\block execution of all interpreters by default to protect against scriptors: cmd.exe, powershell.exe, powershell_ISE.exe, python.exe, cscript.exe, wscript.exe, java.exe, javaw.exe, javaws.exe, etc, etc, etc.</p><p></p><p>That can all be handled very easily and reliably using NoVirusThanks Exe Radar Pro. Simple enough...</p><p></p><p>Alternatively, one can use CIS which can be configured to alert\block execution of any interpreter. More importantly - and conveniently for the typical user - CIS will treat the script as an Unrecognized file in its own right by default and auto-sandbox the interpreter(s); in CIS no custom interpreter HIPS rules are required by default... just let CIS do its job.</p><p></p><p>Much of the time the scriptor will die-off in the sandbox since registry and file system access will be redirected to the virtual container, plus suspicious activities such as raw disk, raw memory, COM manipulation, etc will be blocked by default.</p></blockquote><p></p>
[QUOTE="hjlbx, post: 427549"] Removing powershell and disabling wscript is not enough. One has to realize that some apps include script hosting built-in - like Internet Explorer; such apps, if they are running, will allow scripts to run dependent upon what script shell they have incorporated ! VBS can also be a bit tricky because of msscript.ocx and mshta.exe, but the typical user need not be particularly OCD about nor monkey with those. Listen ! - if you start messing about with them you are going to break something ! Leave it alone ! Just be aware of them - that's all I'm suggesting... You have to alert\block execution of all interpreters by default to protect against scriptors: cmd.exe, powershell.exe, powershell_ISE.exe, python.exe, cscript.exe, wscript.exe, java.exe, javaw.exe, javaws.exe, etc, etc, etc. That can all be handled very easily and reliably using NoVirusThanks Exe Radar Pro. Simple enough... Alternatively, one can use CIS which can be configured to alert\block execution of any interpreter. More importantly - and conveniently for the typical user - CIS will treat the script as an Unrecognized file in its own right by default and auto-sandbox the interpreter(s); in CIS no custom interpreter HIPS rules are required by default... just let CIS do its job. Much of the time the scriptor will die-off in the sandbox since registry and file system access will be redirected to the virtual container, plus suspicious activities such as raw disk, raw memory, COM manipulation, etc will be blocked by default. [/QUOTE]
Insert quotes…
Verification
Post reply
Top