Please provide comments and solutions that are helpful to the author of this topic.
I haven't seen a single firewall alert from EAM since I started using it.
There's no public list and it would be difficult to come up with one, as a lot depends. Think of it more as a point system where different actions and attributes of the application increase or lower the rating. There are some more specific rules that target specific exploits or behaviours (like Office applications trying to run script interpreters for example), but they aren't public. We do have plans to give users more insights into how the behaviour blocker came up with its decision, but there are more important things on the list for now.
AMSI is fully supported. So is IOfficeAntiVirus.
We kind of dropped out of them, mostly because we disagree with a lot of the politics and pricing going on. You can literally buy a Tesla Model 3 for what some of the test labs demand a year (~50k US). A lot of test labs also adhere to AMTSO, which is problematic on a completely different level. Again, lots of politics and general bullshit going on.
We don't have either, but you can continue to use both features when using EAM. In general we try not to duplicate features too much.
I can assure you BitDefender is not cheap.
We usually list reviews here:
blog.emsisoft.com
It does.
Who knows ...
That probably depends on who you ask. The metric we look at the most are numbers of infected customers. We track these numbers both via support requests but also through data that Microsoft makes available to their partners (MSRT but also through other telemetry they collect). Those numbers have been consistently low for us, much lower than the industry standard. I can't really share the exact numbers, due to NDAs, so feel free to dismiss this as marketing if you don't think I am a credible source or spin things a certain way. But you can check out all those malware removal communities (including our own forum) to look for users who had EAM installed at the time of their infection and you won't find many.
We are at the moment toying with the idea of allowing users to enable cloud lookups for all applications they run. So before an application is allowed to run, EAM would query our cloud backends to see if we know this file is good, bad, or is currently unknown. It's something a lot of users have requested over the years but we have been hesitant mostly because of privacy concerns. That being said, it would be a natural progression to have an option that allows you to limit the system to only run known good applications.
Obviously, we have our own drivers. That's just a requirement really because a lot of the interesting APIs to watch file system actions or filter network traffic only exist in kernel mode. We do limit ourselves to official APIs as much as possible, but that is not always possible (especially when it comes to some of the exploit mitigation stuff). We are a lot less hacky than most other products, which is probably the reason why we haven't bricked systems so far after a Windows update made some changes to undocumented kernel structures or threw assumptions about memory layout out the window. The number of undocumented thinks we use can probably be counted on one hand (mostly in relation to intercepting APCs).
Each component is configurable and you can finetune certain aspects. I think most people would probably criticise that how certain decisions came to be isn't always transparent to them. At the moment those insights into decisions are hidden behind labels. For example, the log may say Behaviour.CryptoMalware was the reason a certain file was quarantined by the behaviour blocker, which probably gives you an idea that the BB thinks the application looks like ransomware, but doesn't necessarily explain to you why it thinks that it is.
We do care more about prevention tests and real-life infection statistics than we do about simple detection tests, correct. That doesn't mean that we don't care about detection tests at all.
Trust me, it is:Doesn't sound to me like AMSI support is a core feature
[string] $EncodedEicar = 'WDVPIVAlQEFQWzRcUFpYNTQoUF4pN0NDKTd9JEVJQ0FSLVNUQU5EQVJELUFOVElWSVJVUy1URVNULUZJTEUhJEgrSCo='
$EicarCommand = [system.Text.Encoding]::Unicode.GetString([Convert]::FromBase64String($EncodedEicar))
Invoke-Expression $EicarCommandAMSI is unfortunately trivial to bypass. Not saying it is bad because of it, just making sure you are aware of its limitations.
I wouldn't go that far. But we are somewhat decent.So Emsisoft is the only product whose BB is not utterly broken
We have similar labels inside the log file.
Price has always been a big contention point, especially in some low income areas. Ultimately it is true that we aren't the cheapest option, but in return you actually get someone to talk to if you ever have any issues.
EAM doesn't issue firewall alerts on its own. It will only alert you if an application that is not trustworthy tries to mess with the Windows Firewall. Other alerts that may be the result of suspicious network acitivty will be masked as behaviour blocker alerts, as the behaviour blocker is essentially also an application based firewall that just makes decisions on its own.
Excessive reply incoming. I would say I am sorry, but I am not really.
There's no public list and it would be difficult to come up with one, as a lot depends. Think of it more as a point system where different actions and attributes of the application increase or lower the rating. There are some more specific rules that target specific exploits or behaviours (like Office applications trying to run script interpreters for example), but they aren't public. We do have plans to give users more insights into how the behaviour blocker came up with its decision, but there are more important things on the list for now.
AMSI is fully supported. So is IOfficeAntiVirus.
We kind of dropped out of them, mostly because we disagree with a lot of the politics and pricing going on. You can literally buy a Tesla Model 3 for what some of the test labs demand a year (~50k US). A lot of test labs also adhere to AMTSO, which is problematic on a completely different level. Again, lots of politics and general bullshit going on.
We don't have either, but you can continue to use both features when using EAM. In general we try not to duplicate features too much.
I can assure you BitDefender is not cheap.
We usually list reviews here:
Reviews & Awards - Emsisoft | Cybersecurity Blog
Browse the ever growing collection of reviews and awards that Emsisoft’s security solutions have received over the years.
It's mostly AVLab/CheckLab and VB100 at this point.
It does.
Who knows ...
That probably depends on who you ask. The metric we look at the most are numbers of infected customers. We track these numbers both via support requests but also through data that Microsoft makes available to their partners (MSRT but also through other telemetry they collect). Those numbers have been consistently low for us, much lower than the industry standard. I can't really share the exact numbers, due to NDAs, so feel free to dismiss this as marketing if you don't think I am a credible source or spin things a certain way. But you can check out all those malware removal communities (including our own forum) to look for users who had EAM installed at the time of their infection and you won't find many.
We are at the moment toying with the idea of allowing users to enable cloud lookups for all applications they run. So before an application is allowed to run, EAM would query our cloud backends to see if we know this file is good, bad, or is currently unknown. It's something a lot of users have requested over the years but we have been hesitant mostly because of privacy concerns. That being said, it would be a natural progression to have an option that allows you to limit the system to only run known good applications.
Obviously, we have our own drivers. That's just a requirement really because a lot of the interesting APIs to watch file system actions or filter network traffic only exist in kernel mode. We do limit ourselves to official APIs as much as possible, but that is not always possible (especially when it comes to some of the exploit mitigation stuff). We are a lot less hacky than most other products, which is probably the reason why we haven't bricked systems so far after a Windows update made some changes to undocumented kernel structures or threw assumptions about memory layout out the window. The number of undocumented thinks we use can probably be counted on one hand (mostly in relation to intercepting APCs).
Each component is configurable and you can finetune certain aspects. I think most people would probably criticise that how certain decisions came to be isn't always transparent to them. At the moment those insights into decisions are hidden behind labels. For example, the log may say Behaviour.CryptoMalware was the reason a certain file was quarantined by the behaviour blocker, which probably gives you an idea that the BB thinks the application looks like ransomware, but doesn't necessarily explain to you why it thinks that it is.
We do care more about prevention tests and real-life infection statistics than we do about simple detection tests, correct. That doesn't mean that we don't care about detection tests at all.
Trust me, it is:
View attachment 228463
I threw the Get-MpThreatDetection in there just so you can see that it wasn't the Windows Defender AMSI provider who blocked it.
Here are the commands in case you want to try it yourself:
This is essentially completely harmless code. All it does is put the EICAR test file into a string and tries to execute it. Every AV with AMSI support should block it, provided they detect EICAR. If they don't, PowerShell will throw an error that this isn't valid PowerShell code (which is true). Makes for a low risk test anyone can perform at home.Code:[string] $EncodedEicar = 'WDVPIVAlQEFQWzRcUFpYNTQoUF4pN0NDKTd9JEVJQ0FSLVNUQU5EQVJELUFOVElWSVJVUy1URVNULUZJTEUhJEgrSCo=' $EicarCommand = [system.Text.Encoding]::Unicode.GetString([Convert]::FromBase64String($EncodedEicar)) Invoke-Expression $EicarCommand
AMSI is unfortunately trivial to bypass. Not saying it is bad because of it, just making sure you are aware of its limitations.
I wouldn't go that far. But we are somewhat decent.
We have similar labels inside the log file.
Price has always been a big contention point, especially in some low income areas. Ultimately it is true that we aren't the cheapest option, but in return you actually get someone to talk to if you ever have any issues.
EAM doesn't issue firewall alerts on its own. It will only alert you if an application that is not trustworthy tries to mess with the Windows Firewall. Other alerts that may be the result of suspicious network acitivty will be masked as behaviour blocker alerts, as the behaviour blocker is essentially also an application based firewall that just makes decisions on its own.
.
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.
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.
Great news, looking forward to finally seeing this option!
