Is it possible that an executable (theoretically) could drive by inject a Windows process or other common process and execute without being placed in the sandbox, i.e. appearing to be a trusted or non-malicious process? Most top anti-malware and a-v would catch this I assume, but, if not, what about the sandbox?
Anything is possible - nothing is perfect and full-proof because it's all engineered by humans and we are prone to make mistakes somewhere down the line. What works well today may not work well tomorrow, and malware is evolving all the time.
As for most top Anti-Malware and Anti-Virus products catching an exploit attack like this, I wouldn't be surprised if they failed actually - most AV vendors seem to still be struggling with integrating protection against unauthorised device drivers from being installed on the system, or don't even include basic anti-injection protection to prevent an unknown, untrusted program from injecting into a web browser like Chrome. With the exception of a few vendors of course, which take dynamic protection seriously (e.g. Emsisoft, Kaspersky, G-Data).
Moving back onto the topic a bit better, if your browser becomes exploited by malicious code being executed from a malicious URL and the exploit leads down to code execution coming from the browser itself (e.g. you visit a malicious webpage -> your browser becomes exploited and now malicious code is being executed on your host system from the browser itself) then it can just perform shell-code execution to inject code into a trusted, non-malicious process. That being said, unless the security product is protecting against injection attacks, then since the browser had become compromised by the malicious webpage to execute the shell-code (to inject into the trusted process already running on the system), no additional process is required since there was no new program download to be executed, therefore the security software wouldn't even become aware of the code execution.
Now speaking about Comodo Sandbox specifically, if the web browser isn't running under the sandbox and neither is the target running program to be injected into, well since there is no new program start-up, Comodo Sandbox wouldn't do anything I think. Since now code execution is coming from a non-sand-boxed trusted program, and there was no new program start-up for Comodo to put into the sandbox in it's own.
Of course such exploits may be very rare in themselves, it doesn't mean such attacks are impossible.
Believe it or not, old techniques used for injection such as the RtlCreateUserThread function (present in ntdll.dll) isn't even monitored properly in some AV products, let alone the more stealth injection techniques (such as manual mapping via LdrLoadDll - which is the loader function called low in Windows when a new DLL becomes loaded, or even direct code injection without requiring a DLL).
Speaking about more dangerous malware which may utilise device drivers, some AV products won't care less if an unknown program which is not white-listed (even if it has NEVER been seen before at all, ever), attempts to install a device driver... And of course once malware has an active kernel-mode component, say good-bye to any running protection you have, because it'll be KO'd and wiped off the system.
Honestly these days I just advise people to watch closely on what websites they visit and what they download and run, because even I am starting to lose hope in most AV products these days - some vendors are still focusing mainly on static detection methods even though they know that it is getting more and more obsolete, but people still pay for the products so the vendor stays rich anyway.
