Advice Request What's good about Emsisoft?

[Burrito]

It's already been stated... but it's worth restating.

Emsisoft are the 'good guys' of the industry.

Many people talk about the importance of privacy.... and then use Avast or Qihoo 360 or other products with known histories of not caring about privacy in the least.

Customer service is impossible with some security software. You are on your own. Not with Emsisoft.

Here and at Wilders... vendor reps come and go. There have been many. But Fabian always comes back. And it's not like they get a ton of business from this tiny niche community. He's just doing the right thing.

There is value in all this.

 

[notabot]

Scripts are generally not high-entropy because they are text. It's difficult to create a high-entropy text file. The entire idea of AMSI in general is, that you don't have to deal with obfuscation or encryption at all, because every function that can evaluate scripts (think eval() in JavaScript/Python or IEX in PowerShell for example) will first pass the string they are about to evaluate/execute to AMSI for scanning.

Your questions kind of suggest that you may have not a clear idea what AMSI is. AMSI is just a standardised API that any interpreter can use to pass either a memory buffer (think the content of a file for example) or a string (think a line of script that is about to be interpreted) to an installed AV in a standardised manner. So instead of Python, for example, having to maintain different code to support scanning with Kaspersky, Windows Defender and Emsisoft for example, they can just use AMSI and whichever AV the user has installed will scan on Python's behalf, provided that the AV actually supports AMSI.

The key point to notice here is, that the interpreter has to use AMSI. So it is irrelevant if we "support Python" for example. Because Python's implementation is responsible to show us the code it is about to execute before it executes it. This also does include things like virtual environments and stuff like that. So whenever you do an "import" in Python, for example, Python would read the file you imported, whether from the global installation location or a virtual environment, and pass that as a string or buffer to AMSI to scan it. Whenever a Python script decrypts a string that contains malicious code for example and passes it into eval() to execute the string as Python code, Python is responsible to hand that string that is about to be eval'd over to AMSI so it can be scanned. That should also explain why blocking encrypted/obfuscated/high-entropy scripts as you called them is unnecessary. Because if the interpreter does things right, they will pass us the decrypted and deobfuscated code eventually, no matter how many layers of encryption and obfuscation have been applied. That is ultimately the true power of AMSI here.

So any question whether we support Python or node.js or any other scripting language with our AMSI module is kind of backwards. If an interpreter supports AMSI, then we support it as well. There is no extra work that an AMSI provider like EAM would have to take in order to support a certain interpreter specifically.


It's a necessity for us really. We are a small company, we don't want to maintain many products in parallel. In addition, pretty much every one of our employees (except maybe some of the marketing people) is also the personal computer technician for their entire extended family and friends, so they know the pain a lot of people who manage like a couple of family PCs feel. Just didn't feel right to us to lock such useful functionality behind a prohibitive paywall or some "minimum licenses required".


We do detect some anomalies with browsers, but we could probably detect more. The biggest issue is that a lot of these things can't effectively be monitored without injecting code into the browser, which browser vendors do not want you to do (Microsoft blocks it in Edge, Google and Firefox plan to as well). In fact, Chrome will outright tell users to uninstall their AV if they see an AV vendor injecting code into their browser. If the world's number one browser tells their users to uninstall your software and you have a minuscule userbase compared to them, you will have to evaluate whether or not risking your economic livelihood is worth it.

Thank you very much for this Fabian, both for the detailed response on how AMSI works, it makes sense. While it's clear form what you said that up to the interpreter to support AMSI,

"Python's implementation is responsible to show us the code it is about to execute before it executes it"

when the interpreter shows the code to the AMSI module, the AMSI module needs to understand the code, to determine if it malicious or not (?) in that sense the module needs to be able to understand the language.
Eg if I make my own simple scripting language and somehow make the interpreter work with AMSI, the AMSI module would not be able to decide if it is malicious or not (?) because it would not be able to even parse the code.

If the above is correct (?) which scripting languages does the Emsisoft's AMSI module support ( provided that their interpreters/runtimes do make use of AMSI ).

Understood what's the issue with behavioral blocking & browsers as well, then only isolation is a viable option, it's a shame out-of the box containerisation does not currently exist on Windows, something like snap apps would had been almost ideal for generic browsing (though with WSL2, running actual snap apps should be doable).

 

[plat]

I also think that the charm of emisi is that there are many opportunities to hear the opinions of developers directly.

It is also serving as reassurance that he is still alive and kicking it somewhere.

 

[MacDefender]

when the interpreter shows the code to the AMSI module, the AMSI module needs to understand the code, to determine if it malicious or not (?) in that sense the module needs to be able to understand the language.
Eg if I make my own simple scripting language and somehow make the interpreter work with AMSI, the AMSI module would not be able to decide if it is malicious or not (?) because it would not be able to even parse the code.

If the above is correct (?) which scripting languages does the Emsisoft's AMSI module support ( provided that their interpreters/runtimes do make use of AMSI ).

Just to point out: your malware can literally bundle its own Python or Lua or bash shell or any other interpreter that is compiled with zero AMSI support and there’s nothing that AMSI can do about that.

AMSI is great for use cases like malware attempting to use the system copy of Powershell to run obfuscated scripts because as it deobfuscates itself, chances are increased that your AV is shown enough by AMSI that it can recognize a malicious action.
For the myriad of cases that AMSI doesn’t cover, it falls back to the behavior blocker’s job to monitor how the whole black box is behaving. Script or no script, at the end of the day malware carries out malicious actions. And behavior blockers are supposed to look for that.

Long story short: it’s great to implement AMSI but it’s not really as critical or cool as the marketing materials make it out to be.

 

[Fabian Wosar]

Thank you for these extremely informative posts! Indeed I made a correction post (too late to edit) about this oversight as well -- it wasn't super obvious for me to look at the detection log versus trying to click something on the popup banner.

It isn't for most users.

Still having an active Emsisoft subscribtion and renewing it every year just for the hope, but not gona re-use it until they jump out of BitDefender train, didn't see nothing wrong with Ikarus engine, now, however good and polished is Emsisoft's behaviour blocker is, I find irrelevant to talk about it, when there's idiot-proof 90% BitDefender engine backing up.

Ikarus was cheaper than Bitdefender is. Avira is cheaper as well. Cyberreason is, too. It's not that we don't look at other engines but so far none of the engines is worth switching to. The biggest issue is, that those impressive detection results of those engines people constantly ask us to switch to are achieved by literally uploading those files to the AV vendor's cloud. We would have no idea what they are doing with the files except a piece of paper where they claim they delete them and don't do any tracking etc.. That's why we won't use them. If anything it is more likely we will ramp up the detection coverage of our own engine, which is perfectly capable of dealing with all forms of malware out there, and ditch a third-party engine entirely.

when the interpreter shows the code to the AMSI module, the AMSI module needs to understand the code, to determine if it malicious or not (?) in that sense the module needs to be able to understand the language.

We do have interpreters or "emulators" for certain scripting languages like JavaScript or Batch for example. However, once stuff is deobfuscated, which it is in case of AMSI, a simple regular expression is almost always enough to look for the relevant suspicious function calls and so on, ignoring formatting tricks and so on, in order to write even a good heuristic-based detection without actually understanding the script.

 

[notabot]

It isn't for most users.


Ikarus was cheaper than Bitdefender is. Avira is cheaper as well. Cyberreason is, too. It's not that we don't look at other engines but so far none of the engines is worth switching to. The biggest issue is, that those impressive detection results of those engines people constantly ask us to switch to are achieved by literally uploading those files to the AV vendor's cloud. We would have no idea what they are doing with the files except a piece of paper where they claim they delete them and don't do any tracking etc.. That's why we won't use them. If anything it is more likely we will ramp up the detection coverage of our own engine, which is perfectly capable of dealing with all forms of malware out there, and ditch a third-party engine entirely.


We do have interpreters or "emulators" for certain scripting languages like JavaScript or Batch for example. However, once stuff is deobfuscated, which it is in case of AMSI, a simple regular expression is almost always enough to look for the relevant suspicious function calls and so on, ignoring formatting tricks and so on, in order to write even a good heuristic-based detection without actually understanding the script.

Thanks for this, one more question how does Emsisoft treat signed executables? does it auto whitelist them ? if so does it do so for any valid signature or the trusted list is trimmed down to high quality signers?

 

[Azure]

Scripts are generally not high-entropy because they are text. It's difficult to create a high-entropy text file. The entire idea of AMSI in general is, that you don't have to deal with obfuscation or encryption at all, because every function that can evaluate scripts (think eval() in JavaScript/Python or IEX in PowerShell for example) will first pass the string they are about to evaluate/execute to AMSI for scanning.

Your questions kind of suggest that you may have not a clear idea what AMSI is. AMSI is just a standardised API that any interpreter can use to pass either a memory buffer (think the content of a file for example) or a string (think a line of script that is about to be interpreted) to an installed AV in a standardised manner. So instead of Python, for example, having to maintain different code to support scanning with Kaspersky, Windows Defender and Emsisoft for example, they can just use AMSI and whichever AV the user has installed will scan on Python's behalf, provided that the AV actually supports AMSI.

The key point to notice here is, that the interpreter has to use AMSI. So it is irrelevant if we "support Python" for example. Because Python's implementation is responsible to show us the code it is about to execute before it executes it. This also does include things like virtual environments and stuff like that. So whenever you do an "import" in Python, for example, Python would read the file you imported, whether from the global installation location or a virtual environment, and pass that as a string or buffer to AMSI to scan it. Whenever a Python script decrypts a string that contains malicious code for example and passes it into eval() to execute the string as Python code, Python is responsible to hand that string that is about to be eval'd over to AMSI so it can be scanned. That should also explain why blocking encrypted/obfuscated/high-entropy scripts as you called them is unnecessary. Because if the interpreter does things right, they will pass us the decrypted and deobfuscated code eventually, no matter how many layers of encryption and obfuscation have been applied. That is ultimately the true power of AMSI here.

So any question whether we support Python or node.js or any other scripting language with our AMSI module is kind of backwards. If an interpreter supports AMSI, then we support it as well. There is no extra work that an AMSI provider like EAM would have to take in order to support a certain interpreter specifically.


It's a necessity for us really. We are a small company, we don't want to maintain many products in parallel. In addition, pretty much every one of our employees (except maybe some of the marketing people) is also the personal computer technician for their entire extended family and friends, so they know the pain a lot of people who manage like a couple of family PCs feel. Just didn't feel right to us to lock such useful functionality behind a prohibitive paywall or some "minimum licenses required".


We do detect some anomalies with browsers, but we could probably detect more. The biggest issue is that a lot of these things can't effectively be monitored without injecting code into the browser, which browser vendors do not want you to do (Microsoft blocks it in Edge, Google and Firefox plan to as well). In fact, Chrome will outright tell users to uninstall their AV if they see an AV vendor injecting code into their browser. If the world's number one browser tells their users to uninstall your software and you have a minuscule userbase compared to them, you will have to evaluate whether or not risking your economic livelihood is worth it.

Have you guys though of making browser injection an advance option that the user has to opt-in? You can also give the user a brief warning telling them that some browsers might not like this and prompt them to uninstall the AV but that they should not worry about it.

 

[oldschool]

Again, lots of politics and general bullshit going on.

You can say that again. And thank you for such a thoughtful, instructive reply. What other AV vendor would take the time to write such a detailed post.? If I didn't use Windows Defender I would smack my $$$ on the table for Emsi.

 

[Fabian Wosar]

Thanks for this, one more question how does Emsisoft treat signed executables? does it auto whitelist them ? if so does it do so for any valid signature or the trusted list is trimmed down to high quality signers?

The scan engine doesn't care about digital signatures at all. Well, technically we use digital signatures to create detections for PUPs a lot because most PUP companies are nice enough to sign all the crap they release using their certificates. The behaviour blocker does consider certificates to some extent and there are multiple levels to it. It also depends on the behaviour that is being observed.

In general, certificates build a reputation with us. The more good files we see that are signed using the same certificate, the higher it will rank. If we ever see any malicious or even questionable file (PUP) that is signed with a certain certificate, it will instantly lose all built up reputation. There is also some special treatment for digital signatures that belong to Microsoft (Windows components for example). So it's not a clear cut answer, unfortunately.

Have you guys though of making browser injection an advance option that the user has to opt-in? You can also give the user a brief warning telling them that some browsers might not like this and prompt them to uninstall the AV but that they should not worry about it.

This will ultimately just lead to escalation. If we circumvent the security features Microsoft put in place for processes to protect themselves from code injection, which is possible by manipulating undocumented process structures in kernel mode, and that Chrome or Edge, for example, use to prevent AVs from touching their processes, Microsoft will just add coverage for these structures to PatchGuard, release an update and we will bluescreen all systems. So we just don't do it, not even optionally.

 

[notabot]

The scan engine doesn't care about digital signatures at all. Well, technically we use digital signatures to create detections for PUPs a lot because most PUP companies are nice enough to sign all the crap they release using their certificates. The behaviour blocker does consider certificates to some extent and there are multiple levels to it. It also depends on the behaviour that is being observed.

In general, certificates build a reputation with us. The more good files we see that are signed using the same certificate, the higher it will rank. If we ever see any malicious or even questionable file (PUP) that is signed with a certain certificate, it will instantly lose all built up reputation. There is also some special treatment for digital signatures that belong to Microsoft (Windows components for example). So it's not a clear cut answer, unfortunately.


This will ultimately just lead to escalation. If we circumvent the security features Microsoft put in place for processes to protect themselves from code injection, which is possible by manipulating undocumented process structures in kernel mode, and that Chrome or Edge, for example, use to prevent AVs from touching their processes, Microsoft will just add coverage for these structures to PatchGuard, release an update and we will bluescreen all systems. So we just don't do it, not even optionally.

Thanks ! I think it makes sense, to use a scale to rank signatures based on how well the signed binaries have been behaving so far - but just one caveat, signed malware has so far come out of small companies which haven't released malware before, probably the malware authors stole their private keys and has never been signed by a non-revoked key from a big tech co, is this reflected in your certificate trust system ?
( I guess as the binaries by big tech cos are plenty & well behaving vs a smaller vendor whose binaries are fewer & well behaving, if you somehow account for sample size, you would heuristically catch this )

Do you know if Emsisoft works well with GPO hardening, eg Australian Cybersecurity Guides on GPO hardening (excluding the policies on having Windows Defender always on of course)?

Also, how well does Emsisoft work together with an anti-exe like Voodooshield or SecureAPlus? - the reason I ask is this is another complementary way, without using injections, to monitor parent-child processes for eg the browser ( though it leaves out the malware doing all the work in-process by loading dlls or querying COM interfaces ).
( Windows natively also offers WDAC so emsisoft could offer configs for that in the future ? )

I like a lot of Emsisoft's features, you do not intercept certificates when scanning https traffic, you seem quite privacy aware, I may bite the bullet - for me the most important features are A. the web dashboard as this way I can monitor all family machines from one place and B. the strength of your BB as I won't whitelist or blacklist runtimes & interpreters.

 

[MacDefender]

Symantec antivirus crashes something again. This time Chrome 78 browsers | ZDNET

Seems like to Fabian’s point, messing with browsers is risky business

 

[ForgottenSeer 823865]

Also, how well does Emsisoft work together with an anti-exe like Voodooshield or SecureAPlus? - the reason I ask is this is another complementary way, without using injections, to monitor parent-child processes for eg the browser ( though it leaves out the malware doing all the work in-process by loading dlls or querying COM interfaces ).
( Windows natively also offers WDAC so emsisoft could offer configs for that in the future ? )

you won't need any of them; a BB already does what they do. Anti-exe dont monitor dlls or drivers, BB does.

in term of monitoring/blocking: HIPS > BB or SRP > anti-exe > AV

 

[Solarquest]

@notabot,
I have voodooshield with Emsi on one laptop since a long time and never had any problems.
On my son's laptop I tried voodooshield with Bitdefender and I got BSOD (bddci.sys).

 

[Azure]

@notabot,
I have voodooshield with Emsi on one laptop since a long time and never had any problems.
On my son's laptop I tried voodooshield with Bitdefender and I got BSOD (bddci.sys).

Did you tried leaving VoodooShield on learning mode for a while then rebooting so that it whitelist all processes during boot-up?

 

[ForgottenSeer 823865]

@notabot,
I have voodooshield with Emsi on one laptop since a long time and never had any problems.
On my son's laptop I tried voodooshield with Bitdefender and I got BSOD (bddci.sys).

Stop using VS on top of other default-deny security mechanism.
Either you trust VS, and use it alone beside a simple AV (like WD) ; or you don't so don't use it.

 

[oldschool]

Either you trust VS, and use it alone beside a simple AV (like WD) ; or you don't so don't use it.

I'm agreeing with you quite often lately. Some of the "layered" setups I see on other forum(s) are absolute overkill+. Incredible!

 

[ForgottenSeer 823865]

I'm agreeing with you quite often lately. Some of the "layered" setups I see on other forum(s) are absolute overkill+. Incredible!

yes i saw that, glad to see.
i can understand the use of layered setup (i even made a guide here in the past) but the system resource cost is too heavy for a low benefit.
If people like to do it in short term for learning/testing purpose, it is fine. but if for security (aka paranoia) reasons, it is a waste of time.
Most members here have safe habits and basic knowledge of security, they can handle tightly setting up a security soft by themselves, so they don't need 3-4 apps running at same time, they should learn to master one to the bone. I prefer being a specialist of one rather than a master of none.

 

[oldschool]

yes i saw that, glad to see.
i can understand the use of layered setup (i even made a guide here in the past) but the system resource cost is too heavy for a low benefit.
If people like to do it in short term for learning/testing purpose, it is fine. but if for security (aka paranoia) reasons, it is a waste of time.
Most members here have safe habits and basic knowledge of security, they can handle tightly setting up a security soft by themselves, so they don't need 3-4 apps running at same time, they should learn to master one to the bone. I prefer being a specialist of one rather than a master of none.

By "layered" I meant really, heavily, over-the-top, way overboard layered. I saw a couple today and I honestly couldn't believe it.

 

[Solarquest]

I use one on the laptop I use for online payments and online trading, the other on my young kid's laptop.
It's probably a partial overkill but in both cases I prefer to be on the overkill and extra safe side than on a less safe one.
BTW I'm just trying Bitdefender since they kindly offered a 6 months trial.
As usual, different configurations are possible as different opinions.

 

[omidomi]

Em due to BD Engine is not cheap , why not Avira?
I See F-Secure also removed Bug Defender Engine & change it with Avira (All of us know F-Secure is one of the Well Respected company[in level of privacy I mean] around the world) if this Engine is good? why they change it?
BD Engine is one the bad cons of Emsisoft & this is why I do't use it (I mean BD FPs) you may know it.
and another one , we see that these days BD Engine detection rates is fallen ....(HuB memebers confirmed it)