HIPS doesn't block unknown keyloggers

[KeyLogger 11]

I am using a trial version of ESET Smart Security on Win7. Testing it. I've made a simple keylogger program using SetWindowsHookEx functionality. I am amused that Smart Security didn't block it. I've set HIPS mode to interactive. It is throwing huge number of errors and warning about signed system programs and didn't even bother to prevent my small unsigned unknown program from installing the keyboard hook. What am I doing wrong? How to set it up to block keyloggers?

Edited December 25, 2017 by KeyLogger

[Marcos 5,242]

We don't perform behavior blocking. In interactive mode, if you block all operations the application should not run.

You can submit it to samples[at]eset.com so that a detection can be added. If nobody else on the world will ever get the keylogger then it doesn't pose any risk to other users.

[KeyLogger 11]

It didn't ask me if I allow it to set up hook or not. It didn't ask me a single question about this program. Isn't HIPS suppose to block system wide keyboard hooks and wasn't designed to prevent unknown keyloggers from logging key presses?

[itman 1,743]

1 hour ago, KeyLogger said:

I've made a simple keylogger program using SetWindowsHookEx functionality. I am amused that Smart Security didn't block it.

It will block that API function if you open up a secured browser via Online Payment Protection. Most are only concerned with keylogging when doing on-line banking and the like.

If you want to block it in the browser overall, create a HIPS rule where the source app is all applications and the target app is the browser. Then under File Operations, select "Install global hook." Make the rule either an "ask" or "block" one.

Edited December 25, 2017 by itman

[KeyLogger 11]

1 hour ago, itman said:

It will block that API function if you open up a secured browser via Online Payment Protection. Most are only concerned with keylogging when doing on-line banking and the like.

If you want to block it in the browser overall, create a HIPS rule where the source app is all applications and the target app is the browser. Then under File Operations, select "Install global hook." Make the rule either an "ask" or "block" one.

I want it to work systemwide. There should be no keylogging allowed not only in the browser but also on system login, email clients etc.

Ok. I am trying to reproduce your recommendation and there is no "target app" option. If I select File Operation it asks me to select target files. How is Install global hook rule fell into the File operations category?

[itman 1,743]

3 minutes ago, KeyLogger said:

I want it to work systemwide. There should be no keylogging allowed not only in the browser but also on system login, email clients etc.

Ok. I am trying to reproduce your recommendation and there is no "target app" option. If I select File Operation it asks me to select target files. How is Install global hook rule fell into the File operations category?

To make the rule applicable to all apps, in the "Files" screen select "All files." Then click on "Finish." I would also make the rule an "ask" one instead of "block" lest you block the function for a valid app that might use it.

[KeyLogger 11]

14 minutes ago, itman said:

To make the rule applicable to all apps, in the "Files" screen select "All files." Then click on "Finish." I would also make the rule an "ask" one instead of "block" lest you block the function for a valid app that might use it.

I did the above. It doesn't block nor ask anything when I am running my small keylogger. I can make a screencap video of this.

[itman 1,743]

13 minutes ago, KeyLogger said:

It doesn't block nor ask anything when I am running my small keylogger.

Shut down the keylogger. Start it back up and see if you now get an Eset HIPS alert. If not, when you created the rule did you specify under the "HIPS Rule Settings" screen,

1. Enabled -> check marked

2. Logging severity -> Diagnostic

3. Notify user -> check marked

Also, re-verify that the "Action" setting is block or ask. Additionally, the "Rule name" should be formatted as;

User rule: block global hook setting for example

Edited December 25, 2017 by itman

[KeyLogger 11]

5 minutes ago, itman said:

Shut down the keylogger. Start it back up and see if you now get an Eset HIPS alert. If not, when you created the rule did you specify under the "HIPS Rule Settings" screen,

1. Enabled -> check marked

2. Logging severity -> Diagnostic

3. Notify user -> check marked

Also, re-verify that the "Action" setting is block or ask.

I've tried both block and ask. It doesn't work. No diagnostic is shown and logs are empty.

[itman 1,743]

Just now, KeyLogger said:

I've tried both block and ask. It doesn't work. No diagnostic is shown and logs are empty.

Reboot. If the keylogger is not set to run at boot time, then manually start it.

Also if you're dynamically injecting the hook into running processes; i.e. modifying memory, then Eset will only detect this activity if "Applications" is also selected. Then select, "Modify state of another application." Finally, one or more applications have to be selected. You can't select "All applications" since you will get an alert for almost all system processes since they perform this activity.

[KeyLogger 11]

That is how keyboard hooks are working on Windows. You must implement the hook function in dll and set it using the SetWindowsHookEx. And then the windows itself inject this dll into every other process running. There can't be any global hooks without a dll. What does this global hook rule means then? And what application should I ban from injecting dll into other processes if it is done by windows kernel? Should I ban the windows kernel itself?

I've rebooted my test VM and added the rule for "Modify state of another application" as well. It doesn't work. Here is the video attached.

nod.zip

[itman 1,743]

If your using a kernel mode keylogger, Eset HIPS is not going to detect it. Simply put, it is not designed for that type of activity. As far as I am aware of, there are a few specialized apps such as Zemana Anti-keylogger and SpyShelter that can. To employ a kernel mode keylogger, you need a kernel mode driver. Win x64 OSes have restrictions on creating and loading of such drivers. More so on Win 10 x64. Eset's HIPS for the most part allows all drivers to load.

Edited December 25, 2017 by itman

[KeyLogger 11]

See the video. I am not using a kernel mode keylogger. I explain how SetWindowsHook works. The kernel is injecting the dll you provide. If it is not designed to block keylogging activity then what this global hook rule is supposed to do? And why is it marketed as such?

[itman 1,743]

From your video, I see no proof that the keylogger injected a .dll into anything. Open Process Explorer, and show a process where the .dll was injected into another process.

[KeyLogger 11]

It seems that it really doesn't inject this dll. It was the case for XP and is not the case for Win7. Good. This explains why the second rule didn't trigger. But why the first rule "install global hook" didn't trigger too? The hook was obviously installed. It captured keypresses and logged the phrase I typed.

Edited December 26, 2017 by KeyLogger

[persian-boy 22]

21 hours ago, KeyLogger said:

didn't trigger too?

Probably bug! I think I found the same problem too...

[KeyLogger 11]

Admins, please file the bug report then

[itman 1,743]

13 hours ago, KeyLogger said:

But why the first rule "install global hook" didn't trigger too? The hook was obviously installed. It captured keypresses and logged the phrase I typed.

It pertains to the way .dlls are loaded into a process in Windows.

Shown in your video is that the keylogger executable plus the .dll it uses are in the same directory/folder. By default, the Win OS will load a called .dll from the same directory where the .exe is located when it cannot find the .dll in other directories it loads .dlls from.

Bottom line - the loading of the .dll used by the keylogger has nothing to do with the use of the SetWindowsHookEx API function call. Furthermore, this API was never executed since its purpose is to inject the .dll into other processes. Note that a 32 bit .dll cannot be injected into a 64 bit process. Nor can a 64 bit .dll be injected into a 32 bit process: 
 

Quote

If a 64-bit application installs a global hook on 64-bit Windows, the 64-bit hook is injected into each 64-bit process, while all 32-bit processes use a callback to the hooking application.

To hook all applications on the desktop of a 64-bit Windows installation, install a 32-bit global hook and a 64-bit global hook, each from appropriate processes, and be sure to keep pumping messages in the hooking application to avoid blocking normal functioning. If you already have a 32-bit global hooking application and it doesn't need to run in each application's context, you may not need to create a 64-bit version.

 https://msdn.microsoft.com/en-us/library/windows/desktop/ms644990(v=vs.85).aspx

Additionally note that the SetWindowsHook API function call is obsolete and deprecated since it only works for 16 bit processes: http://winapi.freetechsecrets.com/win32/WIN32SetWindowsHook.htm

Edited December 26, 2017 by itman

[Daedalus 16]

3 minutes ago, KeyLogger said:

Admins, please file the bug report then

https://www.eset.com/int/security-vulnerability-reporting/

[persian-boy 22]

https://browser.yandex.com/beta/ try your hacks against this browser.
I'm using it! it has an anti-keylogger and anti screen recorder install it then enable the protect and run your keylogger after that open the browser and start typing! report what you see:D
I use this combo: Yandex beta+Ghostpress+Eset! good combo! 

Edited December 26, 2017 by persian-boy

[persian-boy 22]

On 12/25/2017 at 10:44 AM, Marcos said:

We don't perform behavior blocking

That's bad  

[KeyLogger 11]

49 minutes ago, itman said:

.dll used by the keylogger has nothing to do with the use of the SetWindowsHookEx API function call. Furthermore, this API was never executed

Stop this speculations pleas. I am the author of this program. It does call SetWindowsHookEx, the program was written by me 15 years ago. It was demanded to put hook function into dll back then. It is still required according to MSDN though it doesn't inject anything in Win7 and later. The program doesn't install any drivers. It just call SetWindowsHookEx and log keypresses. See the video. It worked. And NOD didn't stop it. It can even be run from unprivileged user and still able to log keypresses systemwide. The advertised keylogger detection feature is broken and the rule "Install global hook" doesn't work.

Edited December 26, 2017 by KeyLogger

[itman 1,743]

6 minutes ago, KeyLogger said:

And NOD didn't stop it. It can even be run from unprivileged user and still able to log keypresses systemwide. The rule "Install global hook" is broken.

Until you show proof that the SetWindowsHookEx API was successful in injecting the .dll into another process, you are the one doing the speculation. With that statement I am done with this discussion.

[KeyLogger 11]

31 minutes ago, itman said:

Until you show proof

I have posted a video in wich keylogger logged keypresses made in another application. What other proofs do you want?

I have already told you that it doesn't inject dll on Win7. It do install hook and log keypresses though. The advertised keylogger detection feature is broken and the rule "Install global hook" doesn't work.

[KeyLogger 11]

I've tested them on Win 10 too. Neither ESET nor Yandex were able to catch my simple keylogger. 

Ghostpress is working, only if it is started before the keylogger and it doesn't report it. Keylogger will still be present in the system undiscovered but Ghostpress overwrite virtual key codes reported to hooks down the chain so the keylogger is not able to log characters.

I see that admins aren't interested in reporting the bug and no developers have come. Ok then. Bye.