Why Is Zemana Antilogger Free Dialing Out While I'm Browsing?

Well, it's weird, because in theory you could take control over some security tool, or at least make it malfunction. I never really thought of this, until people started to protect their security tools with MBAE and HMPA. I'm sure that self protection against dll/code injection must be possible.

 

Some software may employ whitelisting for known good dlls and reject anything else, which is also viable and I forgot this when I wrote #17.
But remember, a program have to have sufficient priv to inject dlls to another program and usually those security programs run in system priv. Once malware or sth got system priv, I don't trust any self-protection mechanisms much. Indeed, even I, who don't have technical knowledge, could disable some AV w/out turn off its self protection. Just scheduling MoveFileEx API for security software's driver can disable some AVs. Or more easily, early version of Driver Rader Pro which didn't have whitelist could disable some AVs. So don't expect too much for self protection, keeping least priv is more important.

 

First, I am not implying anything by what I am showing below.

But, this technique could be used not only by malware but by legit software to insert hidden spyware, etc. using AppInit_DLLs. Hence my strong stance that this feature should not be used and in fact should be disabled by Microsoft. They only presently allow it because the don't want to be hassled by software vendors crying the blues.

This is a simplified example injecting hidden .dlls using AppInit_DLLs. I believe most people should be able to follow this.

From University of Maryland ‘Revealing Stealth Malware UMD CMSC389M’ PowerPoint presentation found here:
https://www.google.com/url?sa=t&rct...P4eQpe59bnIYl2zUMHlzy3A&bvm=bv.83829542,d.eXY

Example use of AppInit_DLLs for XP DLL injection

Reference: http://www.codeproject.com/Articles/49319/Easy-way-to-set-up-global-API-hooks.

– This will hook NtQuerySystemInformation(), which is what taskmgr.exe uses in order to list the currently running processes. It will replace this with HookedNtQuerySystemInformation(), which will hide calc.exe.

– I modified that code to use IAT hooking rather than inline (which is much simpler actually)

• Steps:

– Compile AppInitHookIAT.dll​

– Place at C:\tmp\AppInitHookIAT.dll for simplicity​

– Use regedit.exe to add C:\tmp\AppInitHookIAT.dll as the value for the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT \CurrentVersion\Windows\AppInit_DLLs and set the other values from the previous slide​

– Start calc.exe, start taskmgr.exe, confirm that calc.exe doesn't show up in the list of running processes. Note: Neither Task Manager nor Process Explorer will show calc.exe.

– Remove C:\tmp\AppInitHookIAT.dll from AppInit_DLLs and restart taskmgr.exe.

– Confirm calc.exe shows up in the list of running processes.​

(This is a basic "userspace rootkit" technique. Because of this, all entries in this registry key should always be looked upon with suspicion.)

A much more detailed analysis of spyware injection here: http://www.codeproject.com/KB/system/api_spying_hack.aspx

 

Thanks everyone!

@FOXP2
You are right! He told us to be active in wilders several times but we were really busy with the new products so better late than never

@siketa
Thanks a lot! We are glad to hear that our technology has helped you.

@Rasheed187
Yes, our SSL logger simulator works by hooking SSL encryption functions in browser memory but SSL encrypted traffic can also be inspected without modifying browser memory, some banker Trojans uses SSL proxy and install a fake root certificate into the trusted certificate store; this way they trick the browser into believing that the proxy certificate is valid, and avoid displaying a warning.

Zemana SSL Intrusion Prevention have multiple protection mechanisms to secure data during high-value financial transactions. In order to monitor target process memory we are using dll-injection that's why Zemana is browser independent and covers all known MITB attacks without installing browser toolbars.

Zemana SSL Intrusion Prevention:

• Protects SSL (https) data pre-encryption.
• Prevents Man-in-the-Browser (MitB) and HTML injection attacks.
• Monitors the Trusted Root CA Store for fake root certificate installations.

@itman
I have read it over carefully, but unfortunately I do not understand your inquiry. Any malware with admin privilege can write to AppInit registry keys. And these keys are well documented (The AppInit_DLLs value has type "REG_SZ." This value has to specify a NULL-terminated string of DLLs that is delimited by spaces or by commas.) so any Antimalware or HIPS product can scan and parse every entry in this key like in many other start-up keys in Windows registry. Zemana AntiMalware also scan this ASEP entry and inspect every DLL separately. Many Intel drivers uses this key as well so it's not appropriate solution to detect just the ASEP entry itself as malicious.

The main subject of this thread is your false claims without any research that we are spying our users and damaging our brand so please open new thread for questions which are not related to this topic.

 

I never accused Zemana Antilogger of spying. I opened this thread over the issue of Antilogger's frequent Internet connections. You replied that it updates ever half an hour. I will leave it at that.

 

OK thanks for the info, I really appreciate it, because the Zemana support desk couldn't give me an answer. But like I said, why not release the testing tool to the public? It would be nice to test not only Zemana but also other tools that claim to protect against SSL-loggers.

You could even enhance the tool, with two options. The first option should test if HIPS can stop "code injection", and the second option should test if HIPS can stop or detect the "browser memory hooking" after code injection is allowed. BTW, which .dll file does the monitoring for Zemana?

 

To clarify, I also didn't think that Zemana is/was stealing private data, but my "possibly spying" comment was based on the fact that a lot of security tools nowadays don't respect users privacy as seen in this report:

http://www.av-comparatives.org/data-transmission-internet-security-products/

 

That separation doesn't make sense. For what malware injects code? In most case it is for hooking (though I'm not sure what "memory hooking" means.). But it will make sense that separate injection/hooking test from later part tests such as HTML injection detection or fake cert detection.
They explained the reason as because it is dangerous, I don't agree too. There're already many hacking tools and PoC (and even actual malware) easily available even w/out Tor, and with Tor and some bitcoin and registration, you can easily buy real latest malware or exploit kit (can be crime depending on your country's law). Not persuasive reason for us at all.

 

I will explain why it makes sense, it's because a lot of HIPS will pass this tool by simply blocking code-injection. However, code injection can also be legitimate. So you need to test if HIPS can stop or detect "browser memory hooking" (IAT/inline hooking). Zemana, SpyShelter and Trusteer all claim that they can stop SSL loggers even after code-injection. HMPA claims to be able to detect malicious hooks.

There is nothing dangerous about this testing tool, so I encourage Zemana to release it, hackers will also not learn a thing from it, because everyone already knows which techniques are being used by banking trojans like Zeus, SpyEye and Carberp for example.

 

Okay, I got it, but I see much more value in test I suggested cuz HTML injection can be done w/out any further hooking once browser was compromised (if it was in-mem malware, completely no hook is possible). I'm very curious what AV or HIPS can detect or block HTML injection (OTOH adding bad cert should be easily blocked by any decent HIPS).

 

Yes, the Zemana test should explain the difference between "code injection" and "memory/API hooking", and why injection must be allowed to let the second test (API hooking) work. And to be honest, I have to do some more reading, because I always thought that code injection was not only used for SSL connection spying, but also for HTML injection. And blocking malicious certificates should be possible by HIPS with registry monitor I assume.

 

If local malware on disk want to perform HTML injection, it needs to inject code into browser process. But in case of in-mem malware, it's just optional, as attacker already control target's thread.

 

OK I see, but luckily "in-mem" malware is not that common, at least not yet.

 

Is "Financial Malware Protection" a new feature in the free version?

http://www.zemana.com/product/antilogger-free/overview/

As far as I know the older free version only had the keyscrambler.

 

Yes, it was incorporated in a previous release. You can read about it here: http://zemana.com/product/antilogger/modules/secure-ssl.aspx. Best classified as man-in-the-browser protection since it's preventing a hijack prior to encryption. Does not prevent man-in-the-middle attacks from what I can determine.

 

I see, so it has basically the same protection as HitmanPro.Alert? Very nice.

 

This is not completely clear. Zemana claims to be able to block the infection, while HMPA only detects. The developers of HMPA have said that it's too difficult to block this stuff, without causing any system stability problems.

 

I'm planning to try out the latest ZAL Free version, has your opinion changed in recent months?

 

No. The fact they use AppInit_DLLs registry key to load their dlls is a security risk in my opinion. It is also obsolete and bad design technology.

 

OK I see, thanks.

 

Have they already changed this behaviour?

 

If I'm correct, they are working on a new version of ZAL Pro, and I would also encourage them to stop using this method.

 

Zemana? Comment??

 

As we mentioned before, we do not think using AppInit_DLLs method is bad design technology or create any risk.

MS does not recommend any injecting method but since this method was documented by them before, they are now commenting about it.

So most probably we will continue to use it since it's most stable method.