Hi,
@WiseVector
Thanks for your reply to the reply of your reply.
For now, my point of view is that WiseVector still has a bad underlying design for on-execution scanning support, and the second bad justification attempt has done nothing in regards to changing this.
1. I've told you several times that there's an officially supported and documented mechanism for filtering process creation which has a well-tested use case of on-execution scanning. It wouldn't be used by Microsoft themselves in Windows Defender as well as a dozen well-established, reputable and wide-spread vendors who have a good stance in the enterprise market if it wasn't as good as the idea you've been proposing and using in WiseVector.
2. WiseVector's on-execution scanning will only be supported when the process creation operation is performed by a process which has been injected into, which isn't reliable when you remember that WiseVector's relying on AppInit_DLLs that only supports processes which load USER32.DLL, does not support Secure Boot systems, and can be blocked with process mitigation policies. Last but not least for this point, in the event of a vulnerability being exploited to cause arbitrary code execution, all you need to do is manually perform a system call, and WiseVector's on-execution scanning will be oblivious.
3. Vendors like Google Chrome have started fighting back against people injecting into their processes. How will you monitor process creation from users opening downloads on Google Chrome when they start blocking your DLL injection? Even if you have fall-back plans for this, you can just eliminate the problem instead of masking it by using what everyone else in the real world is using. You know, the ones who have 100x more market share than you and cater to millions worldwide when the numbers are combined?
4. Why would you hook SetWindowsHookEx? At the least, if you're going to do that, target NtUserSetWindowsHookEx instead. Also, there's other ways to log the user's keystrokes other than NtUserSetWindowsHookEx. One minute your focus is on prevention, now it is post-compromisation? You are focusing on way too much at once. Calm it down and improve what you already have before you end up doing a Microsoft... (this is the part where the borked update gets released).
Bottom line: use a kernel-mode callback when there's a suitable one available for you because it is officially supported, documented, and reliable. Your little hack tricks do not make you a security magician, they make you a security fool... use officially supported when there's sufficient documentation and more than enough use of the feature in question to know it is robust to a reasonable extent.
Roses are Red,
Violets are Blue,
WiseVector's on-execution scanning belongs down the loo,
With the funding you have you could do something great and following the documentation for on-execution scanning is as easy as baking a cake,
If you do not understand what I've said then you probably never will and there's samples online which outline what you need to do,
It looks like the market share doesn't want WiseVector but you gave it a shot and it's about the taking part that counts,
If it makes you feel better you can dress up and cuddle your WiseVector in bed but...
It's evident that I don't recommend WiseVector and if you've already installed it, I'd uninstall it quick!
My conclusion of this debate is:
I think that WiseVector are just another "latest and greatest" hype vendor jumping onto the "Artificial Intelligence" bandwagon for the computer geek teens on the block and would advise for anyone to avoid them at all costs.
I REALLY wanted to avoid hostility on this thread... either way, maybe this time you'll get the memo.
Kind Regards,
in2an3_PpG