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
Community
Community Feedback
Suggestions for Malware Vault testers
Message
<blockquote data-quote="Deleted member 65228" data-source="post: 663157"><p>I've read through this entire thread three times, let me help out a bit.</p><p></p><p>1. Any decent security solution which scans process execution as part of the real-time protection does not wait for the process to actually spawn and start executing code prior to the scan. Kernel-mode callbacks are cleverly used by all top AV/AM products and the callback PsSetCreateProcessNotifyRoutine(Ex) is triggered before the main thread of the process starting up is resumed (when a process starts up the threads are not active until all initialization is complete), therefore the security solution is able to scan and decide if the program should be allowed to run or not before the spawning process is actually capable of running any code.</p><p></p><p>[SPOILER]</p><p>When a program is run and it has a process for it spawned, the process is just the "container". Within the process are threads, and the threads are like the seed within a fruit... The threads are responsible for executing the programs code, and the process itself is just a container to hold everything together (the way the outside of a fruit protects the seed).</p><p></p><p>If a security product can intercept process execution and scan before allowing the main thread to be resumed (because on Windows the threads are not actually used to execute code until the final stages of the process start-up) and block it based on scan results, then that sample never had a chance to actually perform an action on the system (regardless of whatever its payload actually was).</p><p>[/SPOILER]</p><p></p><p>If you are using a security solution which scans processes after they have actually been allowed to execute code then maybe you should re-decide on which solution you are using... Even if it suspends a process manually (which means the threads are suspended) after it has detected it, it still isn't as good as scanning prior to the main thread being resumed (like popular security solutions do), and can be harsher on system resources (CPU to be precise - constantly looping to find new processes which weren't already in a log).</p><p></p><p>2. It does not matter if the sample you are testing will perform code injection into another process and then have the injected code delete the initial launcher off the disk (someone mentioned this)... If the sample was blocked by the security solution, as long as it is a decent product and does its scan before the process is allowed to use its threads to execute any code (e.g. kernel-mode callback which is the stable and documented way or an alternate way of intercepting process execution to perform scanning before the process can run its code), then no action has been completed by the sample. </p><p></p><p>If you have a sample called abc.exe and you are testing it, and you run it but the execution is blocked (the sample does not actually get to execute any code), then no on-demand scan is required because the system state will not have been affected by the sample you tried to run. However, if you run a sample and it does not get blocked (or it gets blocked after it has been allowed to execute code -> bad real-time scanning/cloud mechanism, or a BB/HIPS component for example), then it would make perfect sense to perform an on-demand scan.</p><p></p><p>Although, if someone is ignoring static detection (signatures or static heuristics) and wishes to pursue testing of dynamic components only, then they will let the sample run regardless of detection on its start-up before it can execute any code. In this case also, an on-demand scan is a good idea because the sample actually managed to execute code.</p><p></p><p>To long didn't read:</p><p>1. If any samples actually managed to run without being blocked (or if you manually allowed a sample to run) then an on-demand scan is not a waste of time because the sample had a chance (either it was blocked later on by another component but after it had been running code, or it wasn't detected at all and will continue to perform actions on the system).</p><p>2. If no samples actually managed to execute any code (e.g. blocked on start-up but before the process could actually be used for code execution) then it would be a waste of time to perform an on-demand scan. It would be the same as if you had have performed the scan before trying to run the sample. Feel free to do an on-demand scan anyway though, you are your own boss.</p><p></p><p>Hit me up if you have any questions.</p><p></p><p>Hopefully this clears some things up for everyone. Happy malware testing! <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite109" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p></blockquote><p></p>
[QUOTE="Deleted member 65228, post: 663157"] I've read through this entire thread three times, let me help out a bit. 1. Any decent security solution which scans process execution as part of the real-time protection does not wait for the process to actually spawn and start executing code prior to the scan. Kernel-mode callbacks are cleverly used by all top AV/AM products and the callback PsSetCreateProcessNotifyRoutine(Ex) is triggered before the main thread of the process starting up is resumed (when a process starts up the threads are not active until all initialization is complete), therefore the security solution is able to scan and decide if the program should be allowed to run or not before the spawning process is actually capable of running any code. [SPOILER] When a program is run and it has a process for it spawned, the process is just the "container". Within the process are threads, and the threads are like the seed within a fruit... The threads are responsible for executing the programs code, and the process itself is just a container to hold everything together (the way the outside of a fruit protects the seed). If a security product can intercept process execution and scan before allowing the main thread to be resumed (because on Windows the threads are not actually used to execute code until the final stages of the process start-up) and block it based on scan results, then that sample never had a chance to actually perform an action on the system (regardless of whatever its payload actually was). [/SPOILER] If you are using a security solution which scans processes after they have actually been allowed to execute code then maybe you should re-decide on which solution you are using... Even if it suspends a process manually (which means the threads are suspended) after it has detected it, it still isn't as good as scanning prior to the main thread being resumed (like popular security solutions do), and can be harsher on system resources (CPU to be precise - constantly looping to find new processes which weren't already in a log). 2. It does not matter if the sample you are testing will perform code injection into another process and then have the injected code delete the initial launcher off the disk (someone mentioned this)... If the sample was blocked by the security solution, as long as it is a decent product and does its scan before the process is allowed to use its threads to execute any code (e.g. kernel-mode callback which is the stable and documented way or an alternate way of intercepting process execution to perform scanning before the process can run its code), then no action has been completed by the sample. If you have a sample called abc.exe and you are testing it, and you run it but the execution is blocked (the sample does not actually get to execute any code), then no on-demand scan is required because the system state will not have been affected by the sample you tried to run. However, if you run a sample and it does not get blocked (or it gets blocked after it has been allowed to execute code -> bad real-time scanning/cloud mechanism, or a BB/HIPS component for example), then it would make perfect sense to perform an on-demand scan. Although, if someone is ignoring static detection (signatures or static heuristics) and wishes to pursue testing of dynamic components only, then they will let the sample run regardless of detection on its start-up before it can execute any code. In this case also, an on-demand scan is a good idea because the sample actually managed to execute code. To long didn't read: 1. If any samples actually managed to run without being blocked (or if you manually allowed a sample to run) then an on-demand scan is not a waste of time because the sample had a chance (either it was blocked later on by another component but after it had been running code, or it wasn't detected at all and will continue to perform actions on the system). 2. If no samples actually managed to execute any code (e.g. blocked on start-up but before the process could actually be used for code execution) then it would be a waste of time to perform an on-demand scan. It would be the same as if you had have performed the scan before trying to run the sample. Feel free to do an on-demand scan anyway though, you are your own boss. Hit me up if you have any questions. Hopefully this clears some things up for everyone. Happy malware testing! :) [/QUOTE]
Insert quotes…
Verification
Post reply
Top
