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
Community
Community Feedback
Suggestions for Malware Vault testers
Message
<blockquote data-quote="Parsh" data-source="post: 660097" data-attributes="member: 58090"><p>Okay, to rectify, the example will be modified to say that the child processes try to execute <em>without requiring a reboot</em>. </p><p>I indicated a case where the parent process terminates fast.. and one of its child processes is not signed and carries the same name as the main sample (while the other child process being trusted and signed may be allowed to run). This unsigned child process has the same name as the main sample name and hence the tester might (probably) interpret that the original sample was contained, however actually a child process was contained and another child process could run. </p><p>Non-automated testing can not be perfect in documenting actions.</p><p></p><p>I just mean that undocumented and unknown situations can occur in the security paradigm that we might not expect to be valid at the present moment. This is on paper, but can be made practical. </p><p>The above example was a trick, there can be sophisticated modifications of ways of attack to challenge the modeled way of working of the AV technologies.</p><p></p><p>Yes. It might hold true for many but not necessarily for all cloud AVs you know. Also if there's some kind of bug or some mis-implementation occurs due to X unexpected technical reason, the normal way of working of an AV component might be hampered in exceptional cases. Practical? Cannot bet.</p><p>Avira might not exactly have a dedicated BB but they say that their so called 'sensor rules' are equivalent to comparing the activity of processes to those known as dangerous. This can be taken as a variation of BB, strong enough or not.</p></blockquote><p></p>
[QUOTE="Parsh, post: 660097, member: 58090"] Okay, to rectify, the example will be modified to say that the child processes try to execute [I]without requiring a reboot[/I]. I indicated a case where the parent process terminates fast.. and one of its child processes is not signed and carries the same name as the main sample (while the other child process being trusted and signed may be allowed to run). This unsigned child process has the same name as the main sample name and hence the tester might (probably) interpret that the original sample was contained, however actually a child process was contained and another child process could run. Non-automated testing can not be perfect in documenting actions. I just mean that undocumented and unknown situations can occur in the security paradigm that we might not expect to be valid at the present moment. This is on paper, but can be made practical. The above example was a trick, there can be sophisticated modifications of ways of attack to challenge the modeled way of working of the AV technologies. Yes. It might hold true for many but not necessarily for all cloud AVs you know. Also if there's some kind of bug or some mis-implementation occurs due to X unexpected technical reason, the normal way of working of an AV component might be hampered in exceptional cases. Practical? Cannot bet. Avira might not exactly have a dedicated BB but they say that their so called 'sensor rules' are equivalent to comparing the activity of processes to those known as dangerous. This can be taken as a variation of BB, strong enough or not. [/QUOTE]
Insert quotes…
Verification
Post reply
Top