From detailed analysis here: https://www.welivesecurity.com/wp-content/uploads/2017/08/eset-gazer.pdf, this is one nasty bugger. Note that in the writeup the payload was named explorer.exe. Technique is similar to DoublePulsar APC .dll code injection.
Seems like it's using "thread execution hijacking", which was mentioned over here (number 4), it's not the same one as DP: https://www.endgame.com/blog/techni...-technical-survey-common-and-trending-process
No, DP didn't do this: DP used reflective injection of a non-reflective .dll into the hijacked process w/o suspending/resuming it. It then proceeded to execute that .dll via APC from the malware process.
That's exactly my point, it didn't use "thread execution hijacking", while Gazer did. I'm not sure if this is easy to block, without causing too many alerts with HIPS.
I guess you forgot about my postings in this thread: https://www.wilderssecurity.com/threads/wannacry-exploit-could-infect-windows-10.394550/page-3 ? If you run the test tool which is the actual reflective loader used by DoublePulsar, you will see the actual thread hijacking taking place. The non-reflective .dll method does not appear to work on Win 10. Not because it blocked the thread hijacking but because of the enhanced DEP memory protection in Win 10. On the other hand, as I posted in the thread, when I used a reflective .dll, the dll injection worked perfectly.
It's not the same as method 4. I believe DB used method 7, namely APC Injection. https://github.com/countercept/doublepulsar-usermode-injector
