For those interested, I created a POC of the test tool DoublePulsar reflective injector bypassing both Eset's Online Payment Protection and IE11 AppContainer here: https://forum.eset.com/topic/12517-online-payment-protection-test-disappointing/ . Note: As indicated by my edited comment at the end of the Eset forum posting, Eset has since patched the OPP vulnerability. Also the above only applies to OPP. The test tool injection still works to bypass IE11 AppContainer outside of OPP. Hence, the need for HIPS rules to block like process memory modification in the browser.
@itman - Can you try it against Emsisoft IS or AM that now purport to protect against DoublePulsar ? "New in 2017.6: Double Pulsar Mitigation and Email Notifications... To mitigate these attacks, our lab has improved our advanced behavior blocker module of Emsisoft Anti-Malware and Emsisoft Internet Security, which can now detect and block any attempts to use the leak that allows Double Pulsar to enter your computer..." http://blog.emsisoft.com/2017/07/03/new-in-2017-6-double-pulsar-mitigation-email-notifications/
I don't have EAM installed, so can't test. When I did have EAM installed, it was completely effective against reflective .dll injection. Now the tool I was using at the time used process hollowing to do so. But I strongly suspect EAM behavior blocker would detect the this test tool's memory injection. The reason being that EAM would have flagged the test tool at execution startup as suspicious due to its low/unknown reputation status and started monitoring at that point. This fact was the point I made in my Eset POC. That is, Eset's rep scanner ranked the test tool as unknown and nothing more. In other words, other than a manually initiated display of process rep status, it is basically worthless. It will upload the .exe file for analysis upon initial in-the-wild detection but that obvious concluded that browser memory injection wasn't malicious. Or most likely, failed to detect the memory injection activities. -EDIT- Also the test tool .exe if uploaded to an external scanner would fail to run since it was injecting based on process id.
Actually, what I stated about EAM rep scanning was wrong. It first monitors for suspicious activity e.g. memory injection. It then does its rep scanning bit. Depending on the results of the rep scanning status, it then makes a finally determination to allow, block, alert, or to continue to monitor the process.
Thank You for the pointer to that. Discovery and sewing up loose ends a specialty on that end? There's likely others but you nailed it on that one for sure. That was some sharp study and findings there itman. Big kudos for solid determination. I vote YES
Let's say I "smelled a rat" for a while in OPP and decided it was time "to flush it out" with this test tool.
For what its worth: PPL'd (protected process-light) LSASS in Windows 10 S (Fall Creators Update) Source: https://twitter.com/dwizzzleMSFT/status/899780788803194880