Emsisoft Anti-Malware & Emsisoft Internet Security 10 available

Just wanna say congrats on a fine product. I took some time deliberating on what the right real-time AV was for Win7 and decided upon Emsisoft. Very light, on both resources and anti-bloat. Not a ton of useless features and modules. Could even go without the BB, but I'm really oldschool... I'd be happy with resident file protection only. But your product fit my criteria better than any other in this day & age. Please don't change much and just focus on improving what's already there.

 

+1.

 

The fact remains that the behavior blocker in the old version of Emsisoft Antimalware stops the malicious action from PowerShell, while the new version does nothing. That's what I find concerning.

 

Having booted into this [particular] snapshot [twice] since I initially reported this problem , and not getting a response from anyone from Emsisoft, I have after the last lot of updates a short time ago, got right click scanning again.

 

OK. This got my interest since I too have noticed subtle changes in the behavior blocker. So I did some testing.

Two questions need answering.

1. Is EAM/EIS monitoring PowerShell upon execution.
2. If EAM/EIS is monitoring, why didn't ver. 10 behavior blocker catch the malware.

As far as question 1 goes, below are two screens shots from Process Explorer showing that a2hooks.dll is indeed being injected and therefore monitoring PowerShell. The first screen shot is running Powershell from the command prompt. The second screen shot is running Powershell using this .vbs script:

Dim objShell
Set objShell = WScript.CreateObject( "WScript.Shell" )
objShell.Exec("C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Sta")
Set objShell = Nothing





So it can be assumed that monitoring of Powershell is not the issue.

That leaves the question as to why running in paranoid in ver. 9 would catch the malware and ver. 10 does not. Might be an issue with Word macros in general in ver. 10; like ver. 10 is not monitoring processes launched from macros in ver. 10? You can test this yourself by using Process Explorer like I did.

Or perhaps the macro launched a "zombie" Powershell process? Zombies can get by most security software. If it's a zombie and pre-ver. 10 paranoid mode can catch it, it indeed would be amazing.

The final possibility is that there are issues with detection of malware activities for normally safe system processes in ver.10.. PowerShell after all is a system process.

-EDIT-

I modified my .vbs script to simulate a zombie process. Powershell executes the command prompt which executes notepad.exe. If I kill PowerShell, notepad.exe is still running. Again a2hooks.dll was injected into notepad.exe.

Here's the script:

Dim objShell
Set objShell = WScript.CreateObject( "WScript.Shell" )
objShell.Exec("C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe cmd /c notepad.exe")
Set objShell = Nothing

Note that when I was doing all this, I had Eset HIPS rules set up to monitor Powershell. Below is a "sampling" of all the areas that Powershell effects. The log entries were actually much larger since I allowed Powershell to run w/o constant Eset monitoring.

 

There are no mysteries. I actually already explained exactly what is going on. He used to use "paranoid mode", which disabled any white listing of system processes. Therefore, all malicious activity done by PowerShell caused a popup if cloud lookups were disabled as well. Version 10 removed "paranoid mode". Therefore, all malicious activity done by PowerShell is allowed, as it counts as a system process.

Paranoid mode isn't coming back. As mentioned before, the actual fix is to attribute malicious activity performed by interpreters, VMs, system shells and host processes to the scripts, macros, code and DLLs that use them, not to just disable all whitelisting, causing tons of useless alerts. That feature will be available in one of the next updates. We won't wait until EAM/EIS 11 to roll it out.

 

I have just switched to another of my snapshots, and updated EIS. I mentioned yesterday, that the latest update to EAM brought back right click scanning.

However, just tried the right click scanning, but it still isn't working in EIS. Strange...must be a subtle difference, that makes it work in EAM, but not EIS, yet. I guess I will keep checking.

 

I don't think Emisoft want another beta tester, especially when I am still using XP, and which won't be supported for much longer by Emsisoft. Besides, I notice Fabian checks in regularly. So, I am sure he notices.

 

Must be notorious...

Combining beta software with outdated XP and tons of other security software, to complain....about malfunction...

 

You have beta enabled in EAM and not enabled in EIS. The bug is fixed in the current beta version.

 

Hi, Fabian. Thanks for the detailed explanation.

So in the behavior blocker's current state, it is pretty much functioning as a conventional HIPS. If someone wants to protect system processes, all they need to do is create a BB rule to monitor the process.

I think some of the current confusion is caused by the fact that ver. 10 is applying hidden default rules to processes it is monitoring i.e. those where the hook is injected into? Whereas in the past if a process was unknown by cloud determination or suspicious, the BB automatically created a monitoring rule for it. This was my concern since I have a least one unknown cloud determined process running for which no BB rule was automatically generated. I personally am not a big fan of cloud reputation analysis.

 

Anyone else has lag with EAM on widnows 10 ? With win 7 I had no lag but in win 10 there is lag

 

So to summon up, the behavior blocker in the latest version of Emsisoft Antimalware provides slightly less protection in it's default configuration. But on the plus side, if gives fewer pop-ups.
Please let me know if this should not be correct.

That's my understanding as well. So it's a blacklisting approach where you need to know what processes to add. And if the attacker uses a system process you did not specifically ask the behavior blocker to monitor, then the attack will not be stopped (at least not at this early stage of the attack).

I like several layers of protection. If I can stop an attack even before the malware is downloaded and executed on my machine, I would want to do so. That's why I like it when the old version of Emsisoft Antimalware would enable me to block the mentioned attack via PowerShell, even before it could download the actual payload.

As for reducing the number of pop-ups, some of us are both able and willing to deal with lots of them. I would applause it if Emsisoft adds an option to their program, that can give even better protection, even though it might give lots of pop-ups (and actually, the number of pop-ups from the old Paranoid Mode was not bad at all). Hide the option away in an advanced interface with lots of warnings so only geeks like I will find it and activate it. That way everyone should be happy.

 

The process is always monitored. You need the rule so the white-list isn't consulted in case of an event, so it isn't allowed automatically.

None of this is new. The BB has been trusting OS processes since version 1.7 when the BB was first introduced. Cloud lookups have no influence on it at all. As mentioned before, the rules whether a process is monitored haven't changed in almost a decade. The white-listing hasn't changed in almost a decade either. The only difference is that people are somehow suddenly obsessed with the Behavior Blocker screen and feel the need to pick apart every aspect of something they previously never cared about and in reality really shouldn't care about. We may actually remove the "Monitored" column because of that.

Paranoid mode was never a default option. So the default configuration continues to provide the identical protection compared to before. The default configuration is in theory weaker than a custom configuration, where users invest time and effort into fine tuning the system, which is kind of to be expected and has always been this way as well. Whether that is by turning of white-listing and dealing with a flood of constant senseless alerts ("Internet Explorer has changed the browser settings!" - No ****, Sherlock ...) or identifying high risk processes and creating manual rules for them is not much of a difference. The later may actually be preferable.

Which it still can, the option just changed. Create a rule that either blocks Power Shell or that limits its capabilities.

Not going to happen. Goal is and always will be to make less noise, not more. Even if it is optional. Advanced interfaces don't work either. Users who really shouldn't use them, tend to overestimate their abilities and turn it on even though they really shouldn't. People who are more knowledgeable tend to grasp how little they understand and shy away from turning it on, even though they may benefit from it. Not to mention that not putting the UI into advanced mode always feels like you are missing out, as you don't use all the features, which makes for a horrible experience overall.

 

The confusion in my opinion came about because the monitored column now relates to cloud determination status not whether the behavior blocker is monitoring the process.

Additionally, the unknown non-system process described previously does not have a2hooks.dll injected into it. Let's assume that this process on start up does not perform anything malicious to evade detection. It is perhaps a BOT waiting for instructions from its remote command center. Since there is no hook installed to monitor it's activities, I can't see how EAM behavior blocker can detect later malicious activities. An example of this type of activity was the recent Locker ransomware.

The bottom line here is if the Emisisoft cloud can't determine a process status, the behavior blocker should at least hook the process and create a rule for monitoring. Or at the bare minimum, post an alert so that the user can create a manual monitoring rule for the process.

 

As mentioned many times before, the monitored column does not relate to the reputation, white-list or cloud status in any way. The only aspect what determines whether the monitor column displays "Yes" or "No" is whether the process was started as part of a user session or not. The only influence the cloud has is when it comes to answering alerts.

The act of installing a new service is considered a malicious activity. So the only way to have a malicious service is if either EAM was disabled at the time or EAM was installed after the infection already took place. Both is not part of our threat model.

Even if you are creating a manual monitoring rule, the process will not be monitored, as whether or not a process is being monitored is solely determined based on whether or not it is part of the user session.

 

Thanks....that did the trick.

 

@Fabian
Thanks again for your comments and explanations. Also good points about why advanced interfaces don't work. Let's forget that old “Paranoid Mode”, I'm not asking for it to come back.

But here's an observation I think is relevant...
I just tried the macro/powershell attack again and this time, to my surprise, it went right through. No pop-up! The reason turned out to be, that there are several instances of PowerShell and I had failed to add all of them. Simply searching for PowerShell in Windows appear nor to show all instances of PowerShell, possibly due to the 64 bit windows architecture.

This is of course a potential issue, because to make sure PowerShell is protected by the behavior blocker, you need to start every single instance of PowerShell, and individually add them in the settings of the behavior blocker. Apparently this is harder than one would first think.
Having now added the specific instance of PowerShell that the script invokes, the behavior blocker is again able to prevent PowerShell from downloading the payload. So now it works.

But could there be more PowerShell instances that I do not know of? If so, I am still not secured in this area. And of course there could also be other Windows components that I have just not considered to add, and hence could still be used to compromise my PC.

Just in case that comment was intended for people like me:
I have cared about behavior blocking for years. Yes, I need to know the technology before I can recommend it to other, no excuses for that. And yes, we SHOULD care about behavior blocking now that signature-based AV is just too easily fooled. We need better technologies to defend against malware. And behavior blocking (when done right, as generally is the case in Emsisoft Antimalware) could be an important part of such a solution.

I think that is a great idea, because it currently seems that several of us have misinterpreted what it means when a process is monitored.

You're right! Well except that if we need to manually add all potentially exposed windows components to have them excluded from the whitelist, we can easily forget some processes such as PowerShell.
Issue 1: It's time-consuming.
Issue 2: If mistakes are made during fine-tuning, such as what just happened to me, or if the user does not add all processes that could be used by an attacker, then the user will end up with less security than expected.

I believe having a check in the options to disable the whitelist would solve both issues.

 

Look in PowerShell folder with System32 folder for all instances of PowerShell. If you have x64 OS, also check PowerShell folder within SysWOW64 folder. Normally, only ver. 1.0 Powershell exists but I believe there are up to three versions of PowerShell.

Note: The malware macro could be downloading/creating an instance of PowerShell to C:\Users\xxxx\AppData\Local or Roaming directories\subdirectories(i.e. Temp) or elsewhere and running it from there to evade detection.

Important! Scan your C: drive for all instances of powershell.exe. If any exist other than in subdirectories under System32 or SysWOW64, those are definitely the instances used by the malware. Take note of which other directories powershell.exe exist in and post them.

-EDIT- Basically the safest way to prevent this is to disable macros from running or at least prompt for running: http://www.wikihow.com/Enable-Macros-in-Microsoft-Word . Actually, this should be done for all Office apps.

I just checked my MS Office 2010 Word settings. Default settings are macros are disabled with prompt. Oops, referred to your original posting. You were running Excel. Same default settings; macros are disabled with prompt.

Perhaps you allowed the macro to run when prompted. Or you changed Excel's default settings? Or finally, this malware also downloaded a bogus version of Excel with macro settings altered?

OK, the "light" finally switched on in my head. The malware used PowerShell to alter the MS Office registry settings: http://blogs.technet.com/b/deployme...custom-registry-settings-for-office-2010.aspx . What are your UAC settings? Setting UAC to max. level would have prevented this I would think. Although PowerShell could also change UAC settings but a reboot would be necessary before the change would be effective. Also ditto for any registry changes; they wouldn't be in effect until a reboot.

-EDIT2-
In theory, Powershell's execution policy is set by default to "restricted" meaning it can't run scripts and only in interactive mode. However, getting around execution policy is trivial: https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/

-EDIT3-
I just noticed something that is interesting. Is not the default setting for EAM realtime file scanner to only scan specific file extensions? Are you using the default setting? If so, none of the following Word or Excel extensions that use/can contain macros are being scanned; .docm, .xlm, .xltm, .xlsm, or .xlam.

 

I have just gotten the update to EAM v10.0.0.5601 with beta updates. Required application restart, only.

 

The update for EAM is essentially just a version number bump. For EIS however, it introduces a new set of firewall drivers that are fully Windows 10 compatible. It also includes a few fixes for the firewall on Vista and later. I am pretty sure people will enjoy the next update after the Windows 10 compatibility patch went online though .

 

Running Windows 10 32bit. Installed EIS and updated to the latest 5601 beta.
I'm having problems with qBittorrent 3.2.3 and EIS. When I start qBittorrent for the first time EIS would show a Behavioral protection popup about Spyware behavior, and after allowing it every user started application cannot access the internet, including qBit which never appears in the tray and is pretty much a dead process running in RAM (CPU time/activity doesn't increase). When attempting to refresh pages or play streams via foobar2000 nothing happens, no connection errors (network tray icon shows me as connected). When qBit is completely whitelisted I'm not getting the issue. Looking at the processes I can see Windows error reporting creates a WinsockAFD dump when this happens, so I can only assume it's related to EIS networking filter. Also, when this happens, I can't seem to exit/terminate processes which are functional (except internet related functions) but are stuck in RAM.
If it helps I can upload the dumps if they're of any relevance. No other security applications installed.

 

The dump would be quite helpful. Feel free to send it or a link to it to fw@emsisoft.com.

 

To add to the previous report, EIS uses an increased amount of CPU (now, it's a lowly Pentium D FWIW), caused by fw32.dll thread. (normal CPU usage when I exited qBittorrent in the middle)

(P.S I've sent the dumps via email)