Before you close the topic, if I may add one thing about 2nd opinion scanners- there is an unfortunate presumption that running something like MB or HMP after testing the primary product and getting a clean bill of health is proof that the system is not infected.
This is far from the case! As I have shown previously the 2nd opinion scanners also have their deficiencies and are not 100%. So by running any of these after a test the best that can be said is that MB, HMP, Zemana, also did not find anything. This is a great deal different than stating that the system is actually clean.
Indeed.
I can't understand why people here don't agree with my points...
1) If all samples are detected statically (manual scan with realtime protection disabled) there is no chance that the system got infected, because the user hasn't even launched the malware
2) How can a sample whose execution has been negated be able to infect a system? (considering VodooShield, COMODO at default-deny, avast hardened mode, some cloud products with avira. This doesn't happen always but there may be cases in which the entire set of samples is detected by signatures+cloud (considering avira). Knowing how avira works, the cloud doesn't let the sample run at all, and immediatly quarantines it
These are the cases, in which, in my opinion, second opinion scanners are not needed. It was just to make the tester not waste time
Please consider that we never completely know the behavior of the sample we go for testing that could have fragmented code designed to act in a non-conventional way when we think it is detected and neutralized by the tested security product.
That's what I've been trying to convey. We cannot be sure just by observing that the product was able to perform 100% as it appeared to be, against say non-conventional attacks. Something could be missed, some bug/fault can occur. I'm not saying this arbitrarily by guessing. In tech, unexpected things can happen. Proven technology modules can fail in rare cases in what they intend to do.
True. Not disagreeable. However as I said earlier, you cannot always be 100% sure in all the cases that the malware was blocked before execution. In case of anti-exes, maybe 100% might be possible unless a non-apparent fault occurs in protection due to instability by system/malware or an unforeseen bug in the AV. Again, I'm only talking about chances.
if I may add one thing about 2nd opinion scanners- there is an unfortunate presumption that running something like MB or HMP after testing the primary product and getting a clean bill of health is proof that the system is not infected.
I wonder how many people do actually think of such cases as really clean (non-infected) systems. Hey, you missed NPE that might increase the chances of finding a few more nasties. Probably the use of RegShot/FolderChangeView can help more.
Hopefully some or many of us here are aware that sophisticated attacks cannot be simulated at testing hubs and that "no detections" does not always imply "no infection always".
How can a sample whose execution has been negated be able to infect a system? (considering VodooShield, COMODO at default-deny, avast hardened mode, some cloud products with avira. This doesn't happen always but there may be cases in which the entire set of samples is detected by signatures+cloud (considering avira). Knowing how avira works, the cloud doesn't let the sample run at all, and immediately quarantines it
On paper, we can agree with this in cases of VDS, Comodo, Avast Hardened Mode. But does Avira cloud just entirely block the executable sample from running OR does it happen that the sample might run (could have been found safe) but the sub-processes or other executables that the main sample process downloads are blocked? If the original sample itself is blocked from running (to be scanned by cloud to find malicious content) and quarantined, we might consider it as blocked from memory (if it is exactly so). But I earlier gave an example where a tester can perhaps misinterpret which process was blocked. The tester might see that the main sample was blocked (hence samples didn't touch memory at all), however actually the main sample process ran but a newly forked process (with the same name) was blocked from running. In the above case, the main sample could run but the tester couldn't grasp it. It seemed that the main sample was blocked.
The runtime hierarchies of processes etc. need to be observed well and not everything is visible in all cases as @Winter Soldier said.
I can't understand why people here don't agree with my points...
1) If all samples are detected statically (manual scan with realtime protection disabled) there is no chance that the system got infected, because the user hasn't even launched the malware
Who said we absolutely need scanning in this case? The way we collect and share samples for downloading by testers, we can fairly consider '100% static detection of samples' = 'clean'. However this is more of a convention followed for uniformity at MH & for the audience to see the state of the tester's system. Though not absolutely necessary.
Nice @Parsh , now we can talk. From the cases I've seen, Avira cloud blocks the samples from running on execution. The sample doesn't appear in memory. Here you can see one of my old avira tests. Even if one sample was missed, the other ones were detected by the cloud on execution, with no new process in memory https://malwaretips.com/threads/05-05-2016-14.59518/#post-506943
Some malware (fileless for ex ) inject their own code into the system's process "svchost.exe" by deleting the main binary file, and remaining active only in memory. These malware also attempt to delete other traces of the infection by erasing event logs and other information that can show the files created and executed on the machine.
The process "svchost.exe" containing the malicious code, executes the main function of the malware by infecting the system.
If you check for the memory activity, you don't see strange processes, but only "svchost.exe" that is a system file, but infected in this case.
That's why I say that often if you do not see malicious and strange active processes, this doesn't mean that your antivirus has fully resolved the infection and your system is really clean.
I agree with you, If your AV detects the malware code, its activity and this code injection...you're fine, but like I said, if you just see that the sample doesn't appear in memory, it is not a good indicator that your system is clean.
agree with you, If your AV detects the malware code, its activity and this code injection...you're fine, but like I said, if you just see that the sample doesn't appear in memory, it is not a good indicator that your system is clean.
It depends from the product.. If the sample doesn't appear in memory and we got an instant detection of it on execution, that's an high indicator that the sample wasn't able to run
It depends from the product.. If the sample doesn't appear in memory and we got an instant detection of it on execution, that's an high indicator that the sample wasn't able to run
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.
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).
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!
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.
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).
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!
Thanks for your input
Also by talking of a simple code injection on a remote process, if a malware wants to execute a custom function on a thread of the remote process, it can open the remote process, it can allocate a space for the custom function on the remote process writing the custom code on remote memory by calling CreateRemoteThread with the function address. If the custom code will use functions with different addresses, because it has been injected in a process with a different address space, the malware will write the entire image on the remote process, but first it needs to patch the relocation table, because when executables are compiled and linked, the PE Header contains an image base, an address space where the loader can load the image to execute. If this address space is not available, the loader reads the relocation table to know where it has to load the image and how to resolve all object code addresses.
Thanks for your input
Also by talking of a simple code injection on a remote process, if a malware wants to execute a custom function on a thread of the remote process, it can open the remote process, it can allocate a space for the custom function on the remote process writing the custom code on remote memory by calling CreateRemoteThread with the function address. If the custom code will use functions with different addresses, because it has been injected in a process with a different address space, the malware will write the entire image on the remote process, but first it needs to patch the relocation table, because when executables are compiled and linked, the PE Header contains an image base, an address space where the loader can load the image to execute. If this address space is not available, the loader reads the relocation table to know where it has to load the image and how to resolve all object code addresses.
CreateRemoteThread (from kernel32.dll) is commonly used however it won't be useful against a SYSTEM process (since SYSTEM is another user account), therefore you'll have to use at least RtlCreateUserThread (exported by ntdll.dll) if the target process is on another user account.
You can write your own GetProcAddress(A/W) and LoadLibraryA(A/W) replacement for usage after code injection, which is typically the approach people take AFAIK. However, if you are injecting code into a process (no dependencies) and you need to access a function from a DLL not currently loaded within the process, you could always manual map it for stealth (so the DLL the injected code is now using is not found as a module within the process via normal module listing methods) instead of just using a normal LoadLibraryA/W replacement.
You can also inject a structure containing addresses to functions if you are certain that the addresses are existent within the target process, and then access the addresses within the process you injected into.
CreateRemoteThread (from kernel32.dll) is commonly used however it won't be useful against a SYSTEM process (since SYSTEM is another user account), therefore you'll have to use at least RtlCreateUserThread (exported by ntdll.dll) if the target process is on another user account.
You can write your own GetProcAddress(A/W) and LoadLibraryA(A/W) replacement for usage after code injection, which is typically the approach people take AFAIK. However, if you are injecting code into a process (no dependencies) and you need to access a function from a DLL not currently loaded within the process, you could always manual map it for stealth (so the DLL the injected code is now using is not found as a module within the process via normal module listing methods) instead of just using a normal LoadLibraryA/W replacement.
You can also inject a structure containing addresses to functions if you are certain that the addresses are existent within the target process, and then access the addresses within the process you injected into.
can someone explain why downloading samples is so limited? i would like to check different security solutions how do they protect the system and so on but i have a feeling that if i try to become av tester then moders are going to deny that request
. Probably the use of RegShot/FolderChangeView can help more.
