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: 660074" data-attributes="member: 58090"><p>Hey, thanks for suggesting things <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite110" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /></p><p>As you know, the product version is clearly mentioned in the directly visible section of the posts, though a concern can be if the product is being tested without being upgraded (that can be known by just looking at the version mentioned in Product name testers mention).</p><p>Regarding sig updates, it will kindof be a muscle memory for the regular testers in case they've not set AV to auto-update. Overall, it sure will be a good thing to do but not everyone provides full screenshots (can't verify update time with system-shown time) and not all AVs show an "updated xx mins ago", leading to a partial loss of intended result. It will be better to provide the time difference between update time and report-posting time.</p><p> </p><p></p><p></p><p>Voodooshield and Avast Hardened Mode aren't tested for generality of testing. Regarding Comodo, sure if the sample is blocked immediately before execution (as you say - before reaching memory), the result<em> might be</em> considered as "clean". However, on paper and perhaps practically, there can be exceptions, known and unknown. That's what security policies, attack vectors and fixes are all revolving around.</p><p>Say a malware is carrying a certificate trusted by Comodo's "Trusted Vendor List". It executes without fear and one of the things it does is it forks two new malicious process, one is (trusted) signed process and the other is not signed. Say the unsigned child process has the same name as that of the original sample. The original sample terminates in msec already without you noticing (from what I've read, Windows processes are independent. Children may not be terminated even if the parent is unless made to do so). Say both child processes are set to autorun on reboot and not before. The unsigned one will be contained/sandboxed and the tester might (probably) interpret that the original sample was contained! However the signed trusted process will run after reboot. Your PE may not be opened at that time immediately on reboot (for inspecting) OR you might not be able to know that this malicious process (the trusted signed one) is running unless VT shows a detection score beside it.</p><p>The above was a basic example that may or may not be feasible. Regarding cloud, one cannot be sure that all AV clouds block the main executable process itself unless validated or unless deemed unsafe right? Some AVs might have a partially different policy. Or there can be some slip. All clouds may not ensure a 100% blocking of files before they are assigned memory blocks and begin running.</p><p>As I said, Comodo and anti-executables are a different case. Even then, some of those anti-exes might not monitor all kinds of vectors or execution locations in their default offerings.</p><p>There can be unknown or unexpected reasons causing incomprehensible system changes during testing. Comodo might show that the process is contained via GUI but there was some glitch or some bug (without an error message) failing proper implementation (rare chances though) ..</p><p>Scanning after dynamic testing is done to resolve any kind of possibilities of infection or presence of remnants, rare or not.</p></blockquote><p></p>
[QUOTE="Parsh, post: 660074, member: 58090"] Hey, thanks for suggesting things ;) As you know, the product version is clearly mentioned in the directly visible section of the posts, though a concern can be if the product is being tested without being upgraded (that can be known by just looking at the version mentioned in Product name testers mention). Regarding sig updates, it will kindof be a muscle memory for the regular testers in case they've not set AV to auto-update. Overall, it sure will be a good thing to do but not everyone provides full screenshots (can't verify update time with system-shown time) and not all AVs show an "updated xx mins ago", leading to a partial loss of intended result. It will be better to provide the time difference between update time and report-posting time. Voodooshield and Avast Hardened Mode aren't tested for generality of testing. Regarding Comodo, sure if the sample is blocked immediately before execution (as you say - before reaching memory), the result[I] might be[/I] considered as "clean". However, on paper and perhaps practically, there can be exceptions, known and unknown. That's what security policies, attack vectors and fixes are all revolving around. Say a malware is carrying a certificate trusted by Comodo's "Trusted Vendor List". It executes without fear and one of the things it does is it forks two new malicious process, one is (trusted) signed process and the other is not signed. Say the unsigned child process has the same name as that of the original sample. The original sample terminates in msec already without you noticing (from what I've read, Windows processes are independent. Children may not be terminated even if the parent is unless made to do so). Say both child processes are set to autorun on reboot and not before. The unsigned one will be contained/sandboxed and the tester might (probably) interpret that the original sample was contained! However the signed trusted process will run after reboot. Your PE may not be opened at that time immediately on reboot (for inspecting) OR you might not be able to know that this malicious process (the trusted signed one) is running unless VT shows a detection score beside it. The above was a basic example that may or may not be feasible. Regarding cloud, one cannot be sure that all AV clouds block the main executable process itself unless validated or unless deemed unsafe right? Some AVs might have a partially different policy. Or there can be some slip. All clouds may not ensure a 100% blocking of files before they are assigned memory blocks and begin running. As I said, Comodo and anti-executables are a different case. Even then, some of those anti-exes might not monitor all kinds of vectors or execution locations in their default offerings. There can be unknown or unexpected reasons causing incomprehensible system changes during testing. Comodo might show that the process is contained via GUI but there was some glitch or some bug (without an error message) failing proper implementation (rare chances though) .. Scanning after dynamic testing is done to resolve any kind of possibilities of infection or presence of remnants, rare or not. [/QUOTE]
Insert quotes…
Verification
Post reply
Top