It’s Highly relevant… What your alert shows is Explorer.exe executing test.exe
This is by no means detecting this poc.
Indeed only the targeted application crash. Could you have a look at it and confirm the dynamic using notepad as a target?
I’ve tried using this test against a few programs, and I’m not quite sure that CIS actually protects itself against termination. This test seems to use a method that works only for some programs.
Works on:
Notepad
MS Paint
Windows Shell
Internet Explorer 6
Notepad++
RegSeeker
µTorrent
Doesn’t work on:
Firefox
Comodo Internet Security
7-Zip
AbiWord
Avi2dvd (does however flood the screen with ‘access violation’-messages)
Windows Task Manager
CCleaner
VLC media player (funny thing however, is that the volume is set 0%)
Kyle’s right, Josh. The alert reports the exe starting, not whatit is going to do. There are no alerts about the windows message floods into another app. That’s the worrying bit.
Is it bypassed
or
Is it just simply that CIS doesn’t give alert even though blocks it?
Melih
Oh. Very true…
I apologize Kylie!
Btw Melih: It’s bypassed. Egemen sent me an Email back, He is looking into it.
Cheers,
Josh
Hi Melih
It is bypassed ; it doesn’t block and the situation with alerts differs.
As you can see from some images and descriptions above we may or may not receive
Alerts (different CIS settings/different Operating systems etc., sure other circumstances)
But the main point – it’s not blocked and the behaviour of the targeted Application is different as a result too. In my case it didn’t hang - it either was closed (no crash) or could continue working.
Moreover as Endymion and Ragwing pointed and tested with a set of Applications compare to the initially mentioned Notepad the target matters too.
My regards
I am most curious to discover how hacker can steal info or take control of my PC using this POC.
They can’t… It’s just terminating an open application… I don’t think it’s too much to worry about it really.
Agree with Kyle.
This is more of a inconvenience then it is of a threat. Egemen’s first impression:
“it is probably a Windows Message based useless POC” And depending what’s out there in the wild that can utilize such a technique to perform further malicious actions, we will wait and see. Let’s see when COMODO have finished analyzing it. Seeing also how many HIPS Vendors have missed this threat, And how it can perform differently on different CIS settings/different Operating systems etc, I’m sure it’s nothing too SERIOUS, “Threat” wise based on this topics pictures and information of our own testing. But let’s not jump to any radical conclusions just yet… 
Cheers,
Josh
Hi Kyle,
In regard to “stealing info” …
You, are right about this test Application, but one of the side effects as in what I described in my test - you can continue input into Test Application as well despite CIS was ordered to block/remember access to the keyboard.
added I should’ve add this into my initial post:
The Defese+ policy was set just as “Custom” after “block/remember”
Sure, if the test would include the code for sending that info out – the Firewall’s Alert should be fired …at the same time since that is not a part of this particular test we may just hope that the latter will be stopped by the respective part of the Firewall.
Let's see when COMODO have finished analyzing it...Hi Josh ,
I have no doubts they will find the solution :-TU
Cheers!
Agreed - at this time. But is it possible for the code to be modified / added to in order to convey a more destructive or intrusive payload?
Who knows? The Comodo Devs are looking into it
Hi tsec,
True… and exactly what was indirectly pointed above 
It has to be addressed and sure developers will do their best & respond
Cheers!
Yep
No worries about my confidence here. CIS is a sound product, only because of those behind it
AFAIK keylogger get access to the keyboard even when other applications got the focus and the Keyboard alert are meant to prevent that possibility.
Thus assuming the test was actually able to grab the keyboard output of all applications regardless if they got the focus would be too far fetched whener it was confirmed that the test.exe was able to read only the keystrokes specifically meant for it.
This is another confusing aspect, so far there were two confirmation (1, 2) that the test trigger alerts when run against CIS whereas most of the reports are focused on the crashing sideffect toward other applications (eg notepad).
Hi Endymion,
Thank you for reply
What you wrote is correct, but if I got it right I never said that this particular test was a keylogger test at all and the Application (Test.exe) itself can be considered being keylogger (with the visible windows in addition).
I was saying the opposite answering the question and saying that the test is not a danger in this respect… but…
At the same time I did stress that the input abilities of the Test Application itself was not blocked despite users response to just to block and/or “block & remember”.
This is another confusing aspect, so far there were two confirmation (1, 2) that the test trigger alerts when run against CIS whereas most of the reports are focused on the crashing sideffect toward other applications (eg notepad).I don't know how confusing all this is, It is indeed. But when I ran the test all the talk was about “no alerts at all" and “Notepad hanging”. At the moment I ran it as you can see there was an alert and I never got hanging (just normal closing... and the ability restart Notepad) or I could continue working with the Notepad when block/remember was issued. Those were the only differences in scenarios and initial descriptions I posted at that time.
My regards
Thanks for your reply as you now seemingly clarified it was unintentional and was more like a digression unrelated to what test.exe is supposed to be attempting.
Although you are the one who introduced keylogging (and firewall) aspects in this topic, some of your comments seemingly leveraged on the assumption that even activities unrelated to keylogging (eg: grabbing keystrokes meant only for the focused app) should be blocked or at least induce confusion along with the consideration that a malicious keylogger would trigger Firewall alerts
or more specifically “Sure, if the test would include the code for sending that info out – the Firewall’s Alert should be fired …at the same time since that is not a part of this particular test we may just hope that the latter will be stopped by the respective part of the Firewall.”
Whenever you may have been already aware of what I mentioned, those keylogging aspects were the one I specifically addressed regardless of what you didn’t explicitly say.
I don’t know why you are not testing it against CIS whereas this does seemingly require less words than rephrasing you previous findings. ???
Whenever you feel inclined to claim it is not blocked the confusing aspect I mentioned was:
Thus I would really appreciate if you could be willing to test that (with windows message monitoring enabled) instead of rephrasing what you meant, since CIS itself can be considered a “targeted application” as well.
Endymion,
Thanks for your patients.
You added more and more (4 times) to your last post just in order to argue where there is no need to do that.
If you search for word “keylogger” you will find that I did not use it in my reply to axl about “stealing information” to Kyle and tsec.
So if the term was brought that was in your post where it was “introduced” as you posted.
Whether you like it or not what is shown and described in my initial post even if it’s not directly applies to the targeted Application will be left as my question to developers: one should not be able to continue entering anything into the Test input box as many times as possible after the user blocked/remember Test.exe accessing the keyboard.
I am not going to continue arguing with you – that doesn’t make sense to me concerning the main topic and the main question raised in this thread.
My regards
SiberLynx, for sure you mentioned your “keyboard related test” in relation to the “stealing info” reply, though I’m glad you confirmed again what you didn’t mean whenever I see you are more inclined to argue about what you didn’t explicitly say than to take a simple test relevant to what was addressed in this topic, and yep by now you could have tested that…
I’m glad you’re not willing to argue further and, though you approach doesn’t actually make sense to me, I thank you since your clarification will prevent anybody else from misunderstanding what you meant.
Whenever this question do not directly apply to the focus of this topic I hope developers will be able to lift your confusion in regard of direct Keyboard access whereas the reason for which that alert was thus far confirmed only on your PC could be more specifically addressed in a different topic.