[Question] Create before Inject?

Hi, recently I start to execute some malware samples to test them. I find that, some malwares which would inject into system processes (like svchost.exe, explorer.exe, msiexec.exe), will first create the corresponding process, instead of directly injecting into the existing one.

I mean, when the malware is started, it will not directly inject into an existing system process. Instead, it execute the executable file corresponding to the system process to create a new process, then inject into the new process.

It seems that, this technique is being widely used by malwares. But why? If they are able to inject into a system process, why do not they directly inject into an existing one? Particularly, for malwares targeting svchost.exe or explorer.exe, they can always find an existing one that is active, right? I have little knowledge about security mechanisms and the operation system, please correct me if I make any mistakes here.

Conjecture: I guess, the reason why they prefer to inject into a new process rather than an existing one, is because as the parent process, injecting into a child process created by the malware itself is more difficult to be captured by security softwares, right?

The reason why I think so is because when I tested a ransomware which first created a new process of svchost.exe then injectd into it, I found that both Comodo Firewall (Proactive Security, HIPS in Paranoid Mode, Auto-Sandbox & VirusCope disabled) and Outpost Firewall (Higest level of Anti-Leak) cannot capture the step injection.

More specifically, they can only capture the step that the ransomware tries to execute system32/svchost.exe. After that, the ransomware will inject into the newly created process of svchost.exe, and svchost.exe will write to the start up folder, and encrypt the documents. All these steps (injection and encryption, especially the injection) cannot be captured by Comodo and Outpost. Furthermore, Outpost Firewall cannot prevent the operation of injection even if I predefine a rule which denies the activity of "Process memory injection" (the other options are kept default).

Only Spyshelter Firewall could detect these steps when it is running in a 32-bit OS.

I think the reason why Comodo and Outpost fail in this case maybe because they do not monitor the memory operation from the parent process to the child process, while this could be utilized by malwares.

This is just my own conjecture, and it could be totally wrong, because I have only tested quite a few samples, and I know little about security softwares. I would appreciate it if any experienced users could give some comments on this.

By the way, Comodo is still able to deal with this ransomware, though it cannot detect the injection. This could be done by changing the reputation of "svchost.exe" to unknown, then removing it from the file group "Windows System Applications", and finally adding the document folders into the Protected Files. The problem of this approach is that it would incur a lot of alerts...

Finally, this is some event logs generated by Spyshelter Firewall, which can prove that this ransomware is trying to inject into svchost.exe after creating a process of it: ~Log removed~


Here is the monitor log generated by Outpost Firewall:~Log removed~


Regarding Comodo, the only two D+ events corresponding to this ransomware are just explorer.exe tries to execute this malware, and this malware tries to execute svchost.exe. So I think there is no need to post them here.