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
Inactive Support Threads
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
Software
Security Apps
Other security for Windows, Mac, Linux
NoVirusThanks OSArmor
Message
<blockquote data-quote="AtlBo" data-source="post: 703229" data-attributes="member: 32547"><p>Appreciate the work all of you are doing on this. Just installed OSArmor 1.4 (15) and think I have it set up to work with some timed scripts.</p><p></p><p>Anyone have a quick/simple explanation of how the exploit protection works? I guess nothing can protect from a malicious browser extension, unless it tries to create files, so I am just curious about how far the anti-exploit protection goes.</p><p></p><p>First very crude look at the script monitoring is that it is most usefully monitoring scripts as if the application being used to create the script is of secondary importance. I have an installed app that runs a command that launches a series of script commands. OSA seems to be ignoring the original run command and focuses on the actual script. Yet, the secondary/Windows app being used to run the script, such as cscript.exe/wscript.exe is being still noted as important for the building of whitelist rules for scripts. In the mean time, the junk that happens before the danger is not considered important. I don't know, but this seems bare bones smart.</p><p></p><p>I am amazed at how open the rules creation is btw. For example, there is a rule for denying wscript or cscript from changing script engine via //E:. Yet the command line rules for whitelisting a command takes into account which application is being affected (cscript/wscript) and then allow for the whitelisting of this specific enablement that may come in a single command line. I can still keep the rule on, even if I whitelist a single command for the use of the script //E: behavior. No other script can use the tactic so to speak. WOW, this is amazing to me. As for the other rules, those look pretty amazing.</p><p></p><p>Don't want to force things, but I could see how an awesome set of system/Windows whitelist rules (exclusions) could be established/built for each of the new rules being monitored, even for the ones that are off by default. Talk about locking down a system. Maybe Andreas could add data collection as an option for this program while testers are getting on board. Testers could turn on the rules that are disabled by default and the try things on the system to generate some blocks...for building exclusion sets or whatever. Be happy to help with anything like this if I can...</p><p></p><p>BTW, anyone can explain how the presence of //E: in a script is innately dangerous? I have it in one script that is referenced by another, so that's why I am wondering. The referenced script is kind of a complicated script that I haven't been able to break down 100%, but it has to do with editing a line in a file or some specific text in a file. The script I created, interacts with that script, telling it what to edit and where and so on...</p></blockquote><p></p>
[QUOTE="AtlBo, post: 703229, member: 32547"] Appreciate the work all of you are doing on this. Just installed OSArmor 1.4 (15) and think I have it set up to work with some timed scripts. Anyone have a quick/simple explanation of how the exploit protection works? I guess nothing can protect from a malicious browser extension, unless it tries to create files, so I am just curious about how far the anti-exploit protection goes. First very crude look at the script monitoring is that it is most usefully monitoring scripts as if the application being used to create the script is of secondary importance. I have an installed app that runs a command that launches a series of script commands. OSA seems to be ignoring the original run command and focuses on the actual script. Yet, the secondary/Windows app being used to run the script, such as cscript.exe/wscript.exe is being still noted as important for the building of whitelist rules for scripts. In the mean time, the junk that happens before the danger is not considered important. I don't know, but this seems bare bones smart. I am amazed at how open the rules creation is btw. For example, there is a rule for denying wscript or cscript from changing script engine via //E:. Yet the command line rules for whitelisting a command takes into account which application is being affected (cscript/wscript) and then allow for the whitelisting of this specific enablement that may come in a single command line. I can still keep the rule on, even if I whitelist a single command for the use of the script //E: behavior. No other script can use the tactic so to speak. WOW, this is amazing to me. As for the other rules, those look pretty amazing. Don't want to force things, but I could see how an awesome set of system/Windows whitelist rules (exclusions) could be established/built for each of the new rules being monitored, even for the ones that are off by default. Talk about locking down a system. Maybe Andreas could add data collection as an option for this program while testers are getting on board. Testers could turn on the rules that are disabled by default and the try things on the system to generate some blocks...for building exclusion sets or whatever. Be happy to help with anything like this if I can... BTW, anyone can explain how the presence of //E: in a script is innately dangerous? I have it in one script that is referenced by another, so that's why I am wondering. The referenced script is kind of a complicated script that I haven't been able to break down 100%, but it has to do with editing a line in a file or some specific text in a file. The script I created, interacts with that script, telling it what to edit and where and so on... [/QUOTE]
Insert quotes…
Verification
Post reply
Top
