HIPS doesn't block unknown keyloggers

[itman 1,659]

To get to the bottom of this, I decided to do my own testing.

I am using a nifty test Powershell based keylogger described here: https://hinchley.net/articles/creating-a-key-logger-via-a-global-system-hook-using-powershell/ . If one decides to use this code, you have to add -ExecutionPolicy Bypass parameter to the Powershell execution command as shown below to bypass the default Windows script execution blocking;

powershell.exe -ExecutionPolicy Bypass -file Logger.ps1

If one examines the code in the Logger.ps1 script, you will note that a global keyboard hook is being set in user32.dll using SetWindowsHookEx API function call. User32.dll is one of the common .dlls loaded into a corresponding kernel space global root table at boot time. Dlls in this table are common to all processes and are loaded on demand into the process at process startup time.  

It appears that Eset's HIPS SetWindowsHookEx API function call monitoring is non-applicable to .dlls loaded from the kernel space global root table. This makes sense to me since Eset's kernel process does not have access to the kernel space global root common dll table.

-EDIT-

I forgot to mention that I did test Eset 's Online Payment Protection using this keylogger and all it recorded in a .txt file it creates to record keystrokes was scrambled characters. So OPP passed with "flying colors."

As far as anything using behavior analysis, I doubt its activities would have been detected. It was created via Powershell, a trusted process. Also any script scanning via Win 10 AMSI facility would have been negative since the code would have not matched any existing signatures.

However, setting Powershell to "Constained Language" mode will block its execution.

Edited December 26, 2017 by itman

[jdashn 12]

Are you saying that keyloggers of this type will be undetectable by eset? Seems like a big hole if that's the case.

[itman 1,659]

29 minutes ago, jdashn said:

Are you saying that keyloggers of this type will be undetectable by eset? Seems like a big hole if that's the case.

See my edited posting. All that matters is that the keylogging activity was thwarted in Online Payment Protection.

[KeyLogger 11]

itman, from your comments I come to conclusion that you either not a programmer or trying hard to divert conversation from the actual issue by spamming in the thread.

Debunking user32.dll BS: HIPS is able to catch file accesses. File accesses are done through even more core dll then user32, through kernel32.dll. Eset HIPS module is able to detect it. Also the term "kernel space global root table" was just made up by you, there is no such term in system programming. Actually this is done through a very different mechanism, it is not achieved by dll function calls instrumentation, because malicious program would be able to remove this instrumentation from its address space then.

Debunking Powershell BS: Powershell is just a script language interpreter. Just like JavaScript running in a browser. How its extension and syntax are even relevant to the issue? All native programs running on the system are able to call this standard SetWindowsHookEx API. Even those started by unprivileged user.

Debunking Online Payment Protection: I've tested it and indeed keylogger isn't able to log text entered in the browser that it launches. I am really curious how it is achieved and why this is not system wide. But passwords are also entered during Skype logins, windows logins, in bitcoin wallets, any text entered by user in a standalone app may be interesting to attacker.

Now back to the issue. Eset is marketing Internet Security product as a tool that blocks keyloggers. It has the rule in HIPS that suppose to block hooks. This feature is not working and the rule is never signalled.

Sorry if this sounds harsh, but please if you have something meaningful to add then go on and add, otherwise please stop distracting us from the actual issue. I have no intention to argue with you and debunk your misleading comments with all this made up terms and exercises in powershell scripting. I've started the thread to receive comments from actual developers or support staff. If it is a bug then open it in bugtracker and inform us here when it will be fixed. Other users may also be interested.

Edited December 26, 2017 by KeyLogger

[itman 1,659]

1 hour ago, KeyLogger said:

Debunking user32.dll BS: HIPS is able to catch file accesses. File accesses are done through even more core dll then user32, through kernel32.dll. Eset HIPS module is able to detect it. Also the term "kernel space global root table" was just made up by you, there is no such term in system programming. Actually this is done through a very different mechanism, it is not achieved by dll function calls instrumentation, because malicious program would be able to remove this instrumentation from its address space then.

I was going to explain further what this keylogger does and how it was able to do so.

First, C#  program was created on the fly. PowerShell called .Net to execute it. .NET gave it the privileges to hook into user32.dll that was loaded into kernel space.  Note that the PowerShell script runs just fine from a non-admin level command prompt. To my best knowledge, most conventional AV solutions would not be able to stop this activity. I am curious if something like Zemana Anti-logger or Spyshelter can. 

[itman 1,659]

1 hour ago, KeyLogger said:

Eset is marketing Internet Security product as a tool that blocks keyloggers. It has the rule in HIPS that suppose to block hooks. This feature is not working and the rule is never signaled

I have no idea what your keylogging program does. You already admitted that it doesn't run on Win 7.

[KeyLogger 11]

7 minutes ago, itman said:

I have no idea what your keylogging program does. You already admitted that it doesn't run on Win 7.

WAT? The video of its action was recorded on Win7. I've tested it on Win10 too. I have already written about this. The video was downloaded and watched by you. Stop spamming the thread please.

Edited December 27, 2017 by KeyLogger

[itman 1,659]

2 hours ago, KeyLogger said:

Eset is marketing Internet Security product as a tool that blocks keyloggers.

As far as I am aware of, the only public statement made by Eset in regards to keyloggers is:

Quote

ESET Smart Security, ESET Internet Security, or ESET Smart Security Premium contain a built-in list of pre-defined websites that will trigger the ESET protected browser. The secured browser encrypts the communication between your keyboard and browser to provide additional security against keyloggers for banking transactions, credit card numbers and other sensitive personal data.

https://support.eset.com/kb5657/?locale=en_US

[KeyLogger 11]

And the HIPS Install global hook rule is just a do nothing checkbox. Right?

[itman 1,659]

15 minutes ago, KeyLogger said:

And the HIPS Install global hook rule is just a do nothing checkbox. Right?

Create a HIPS rule for SetWindowsHookEx where the "Files" section specifies .exe for your browser. Open the browser. Run your keylogging program an see if an alert is generated.

Note: there also needs to be some proof that the hook was set in a .dll the browser is using.

[KeyLogger 11]

I've tested it with notepad application in the video. I've tried to add notepad.exe in files section. It didn't work. Probably because "all files" option already covers "notepad.exe" right?

Edited December 27, 2017 by KeyLogger

[itman 1,659]

19 hours ago, KeyLogger said:

I've tested it with notepad application in the video. I've tried to add notepad.exe in files section. It didn't work. Probably because "all files" option already covers "notepad.exe" right?

I did some further testing.

In regards to the Powershell based keylogger if you review the code, the hook is being set into kernel32.dll. I modified my Eset HIPS rule for SetWindowsHooksEx - files - for C:\Windows\ System32\kernel32.dll and C:\Windows\SysWOW64\kernel32.dll. The rule didn't trigger. There are a number of possible reasons for this, the first begin that the PowerShell based global keylogger is running under .Net control. I'll get into the other reasons after you retest with your global keylogger program.

What you need to do is specify the .dll you are setting the hook into for your existing Eset HIPS rule for SetWindowsHooksEx - files section. Retest and post your results.

Edited December 27, 2017 by itman

[KeyLogger 11]

itman, keeps learning programming. First, the function SetWindowsHooksEx is from user32.dll not kernel32, it hooks windows messages infrastructure. Second, these dlls are just wraps or proxies for system calls and interprocess communications. You can statically link all its code into your exe file and make a nonportable program completely independent from any dll. The actual system calls are done through INT and SYSCALL instructions on x86 processors.

Have developers ever come to this forum? Admins, have you reported the bug?

[itman 1,659]

I have tried everything to stop the Powershell global keylogger with no success. Best I can determine is the SetWindowsHooksEx Eset HIPS option only applies to program specific hooking.

And again, Eset has never publically stated that it has global hooking protection. So I believe that you will have a very very long wait in this thread for a reply from Eset.

[KeyLogger 11]

Again. They have this feature in settings. The "Install global hook " checkbox This feature is broken. It's a bug. 

[Marcos 5,074]

On 12/28/2017 at 2:11 AM, KeyLogger said:

Again. They have this feature in settings. The "Install global hook " checkbox This feature is broken. It's a bug. 

According to the developers, it's implemented only for older oper. systems (Windows XP, Windows Server 2003). Next year we plan to make substantial improvements in HIPS re. this.

[persian-boy 22]

On 12/29/2017 at 4:10 AM, Marcos said:

Next year we plan to make substantial improvements in HIPS

Happy to hear that:D keep up the good work.

[itman 1,659]

I was reviewing other commercial HIPS solutions on how they handle .dll hooking. Of note is any .dll can be hooked. Below is an example of a rule in McAfee's HIPS to monitor hooking in the commonly used browsers. You have to specify all .dlls to exclude from hook monitoring. Assumed is these .dlls are hooked by other valid app and system processes:
 

Quote

Hooking (SetWindowsHookEx)

SetWindowsHookEx can be used nefariously for both DLL injection and hooking (interception of function calls, events or messages within a process). There's a great explanation on the Volatility blog here: https://volatility-labs.blogspot.com/2012/09/movp-31-detecting-malware-hooks-in.html

McAfee HIPS supports monitoring of SetWindowsHookEx usage and can alert you to potential dll injection/hooking attempts. To detect browser keylogging we can use a rule like the following:

Rule {
 tag browser_hook
 Class Hook
 Id 4005
 level 3
 attributes -no_trusted_apps
 Executable { Include { -path "C:\\PROGRAM FILES (X86)\\INTERNET EXPLORER\\IEXPLORE.EXE" } { -path "C:\\PROGRAM FILES\\INTERNET EXPLORER\\IEXPLORE.EXE" } { -path "C:\\PROGRAM FILES\\GOOGLE\\CHROME\\APPLICATION\\CHROME.EXE" } { -path "C:\\PROGRAM FILES (X86)\\GOOGLE\\CHROME\\APPLICATION\\CHROME.EXE" } { -path "C:\\PROGRAM FILES\\MOZILLA FIREFOX\\FIREFOX.EXE" } { -path "C:\\PROGRAM FILES (X86)\\MOZILLA FIREFOX\\FIREFOX.EXE" }}
 Executable { Exclude { -path "C:\\example\\exclude" } }
 Handler_Module { Exclude { -path "C:\\WINDOWS\\SYSTEM32\\MSHTML.DLL" } { -path "C:\\WINDOWS\\SYSTEM32\\IEFRAME.DLL"} { -path "C:\\WINDOWS\\SYSTEM32\\MSCTF.DLL"} { -path "C:\\WINDOWS\\SYSTEM32\\EXPLORERFRAME.DLL"} { -path "C:\\PROGRAM FILES (X86)\\INTERNET EXPLORER\\IEDVTOOL.DLL"} { -path "C:\\WINDOWS\\SYSWOW64\\SHELL32.DLL"} { -path "C:\\WINDOWS\\SYSTEM32\\SHELL32.DLL"} { -path "C:\\PROGRAM FILES (X86)\\INTERNET EXPLORER\\IEXPLORE.EXE"} { -path "C:\\PROGRAM FILES\\MICROSOFT\\INTERNET EXPLORER DEVELOPER TOOLBAR\\IEDEVTOOLBAR.DLL"} { -path "C:\\PROGRAM FILES\\GOOGLE\\CHROME\\APPLICATION\\CHROME.EXE"} }
 user_name { Include "*" }
 directives hook:set_windows_hook
}

You'll likely see DLL's being loaded for all kinds of different browser extensions and toolbars.

Ref.: http://pwndizzle.blogspot.com/2014/03/custom-mcafee-hips-rules-that-actually.html

My own opinion is if you're paranoid about global hooking to intercept keystrokes, you are better served using a product designed to protect keystroke interception by encryption methods for any app executing. SpyShelter's Antilogger does this and is currently on sale for 6 Euros: https://www.spyshelter.com/silent-anti-keylogger/ .

Edited December 30, 2017 by itman