Advice Request I am head of research at Emsisoft. Ask me anything! :)

[Xtwillight]

Danke schön Fabian, ich habe es mit Absicht in zwei Sprachen geschrieben,
einmal ist hier die Standard Sprache Englisch .
Und zweitens sind hier auch einige aus dem Deutsch Sprachigen Raum z.b
Deutschland - Österreich - Schweiz .


Thank you Fabian, I intentionally wrote it in two languages,

once here is the default language English .
And secondly there are also some from the German-speaking area, e.g.
Germany - Austria - Switzerland

 

[Burrito]

Fabian,

Thanks for releasing a free decrypter for the BigBobRoss ransomware.

If you get hit with BigBobRoss.... you should choose the Emsisoft decrypter as the Avast decrypter will attempt to decrypt, gather your data and monetize it on its way out the door....

Just fyi, Bob Ross was a painter with a TV show.

 

[Fabian Wosar]

Both decrypters work and neither monetizes your data. From what I can tell, Avast missed a bit that can speed up the decryption considerably. So technically ours is a bit quicker. But both will get the job done and as long as it means the ransomware authors don't see a penny, we are fine with any decrypter you use.

 

[tsunami]

Since Emsisoft is using bitdefender's av engine. Does that include Bitdefender's web filtering database?

 

[ForgottenSeer 72227]

This is called "security fatigue", which subject I am surprised is not discussed much (or at all) on security forums. This is probably the biggest issue (aside from lack of PC skill/experience) that the average user faces. This is also why a set and forget AV is ideal for them. It may not protect them from all infection, but it will protect them against security fatigue - which, as you point out, is a cause.

This is casually overlooked or avoided with forum talk about this or that app, with its myriad of notifications.

Spot on!

Security in general is very much a balancing act. It's a balance between security and usability. Tip the scales more towards usability, chances are you have more security issues/gaps, on the other hand, tip the scales more towards security, then you will be lucky to do anything on the computer, if at all. I don't think there is a general set rule, IMO the balance will be difference for each person. That's why each person has to find their own solution that works best for them.

I also agree that security forums in general tend to forget this point. Sometimes, we tend to stress way to much about what if's and this or that, instead of focusing on a capable setup and teaching/practicing good, safe computing habits. I would hazard to guess, (maybe @Fabian Wosar can share his thoughts as well) that the vast majority of infection in the home environment are due to people following poor/unsafe habits (ie: opening email attachments from people they don't know, installing cracked software, ignoring security prompts because they want that particular program, etc...) than being subject to an advanced targeted attack.

Edit: I looked at OSArmor and I think we may be talking two different definitions of scripts here. It seems your definition of scripts is limited to Powershell and Windows Scripting Host related things (VBS, JS, WSH etc.). As those are the ones they block by default. You can probably get away with blocking those (or you know: Just uninstall the Powershell and Windows Scripting Host feature). A lot of the rules OSArmor has are already included in the behaviour blocker as well.

That's great to hear!

Since many of the rules in OSA are already covered by the BB in EAM, could one still run OSA along side EAM without any issues, or would it cause more issues/conflicts with the BB?

 

[Burrito]

6 Benefits Of Having An Entirely Virtual Global Team

When Christian Mairoll founded Emsisoft 15 years ago, he chose to make his global antivirus software company entirely virtual. Here, he and several of his employees share their insights into the benefits of running and working for a business whenever and from wherever you want.

www.forbes.com

Fabian,

When relatively small Emsisoft administered a spanking via AV-C to the behemoths of the industry.... Kaspersky, Microsoft, Symantec, McAfee... did that cause a spike in new subscriptions for service for Emsisoft?

Thanks,


Your Buddy,

-Burrito

 

[Harputlu]

Free license??? )))))

 

[ForgottenSeer 72227]

Free license??? )))))

This has been addressed by @Fabian Wosar a few times in this thread already, please read through the thread to see his responses on the matter.

Also as a side note: If you want a "free" licence for a year, this forum is having a giveaway as well as an "Egg" hunt for free Emsisoft licences, so maybe you can take part in those if you want to try to get one, but it's not guaranteed.

 

[Andy Ful]

None of them has an HP Printer? Lucky you. Their install packages are literally held together by a bunch of batch and VBS scripts.
...
Edit: I looked at OSArmor and I think we may be talking two different definitions of scripts here. It seems your definition of scripts is limited to Powershell and Windows Scripting Host related things (VBS, JS, WSH etc.). As those are the ones they block by default. You can probably get away with blocking those (or you know: Just uninstall the Powershell and Windows Scripting Host feature). A lot of the rules OSArmor has are already included in the behaviour blocker as well.

When you said scripts without specifying which types of scripts, I assumed you wanted to block Batch, INF and CMD scripts as well, which will cause all hell to break loose.

Yes, the HP printer was one of the issues mentioned on OSArmor thread.
I mentioned in my first post what scripts could be blocked (VBS, VBA, JScript/JavaScript, and Powershell), but I should probably note it also in the following posts to avoid misunderstanding.
By blocking scripts I rather mean blocking such script Interpreters, like wscript.exe, cscript.exe, powershell.exe, powershell_ise.exe, mshta.exe, with medium integrity level to allow some system tasks, but with the possibility to whitelist some scripts like in the case of HP printer.
After the initial whitelisting, all other scripts could be blocked silently or with alert (no bypass). Blocking VBA is another problem, but it can be done by applying the proper settings in the Office applications (especially in MS Office).
There are some advantages of blocking over uninstalling/removing/renaming scripting engines. If I correctly remember the PowerShell can be uninstalled on Windows XP and Vista, but it is not possible on higher Windows versions, because of its integration with .NET Framework. Removing or renaming the Interpreter executables, can be reverted after Windows Updates.
Of course, blocking script Interpreters is only a partial solution, because the scripting functions are still available in DLLs. But in practice, blocking the script Interpreters is very effective.

 

[Fabian Wosar]

Since Emsisoft is using bitdefender's av engine. Does that include Bitdefender's web filtering database?

It does not.

I also agree that security forums in general tend to forget this point. Sometimes, we tend to stress way to much about what if's and this or that, instead of focusing on a capable setup and teaching/practicing good, safe computing habits. I would hazard to guess, (maybe @Fabian Wosar can share his thoughts as well) that the vast majority of infection in the home environment is due to people following poor/unsafe habits (ie: opening email attachments from people they don't know, installing cracked software, ignoring security prompts because they want that particular program, etc...) than being subject to an advanced targeted attack.

APTs are nothing any home users should worry about. I am serious. Nobody is going to blow six figures on an exploit to get your vacation pictures. If the stuff on your system is that valuable that someone would do it, you probably are well aware about it and received proper training by the company that data belongs to.

In my experience, the vast majority of victims run no anti-virus or any protection software really at all or they purposefully turned it off because it got in their way.

Since many of the rules in OSA are already covered by the BB in EAM, could one still run OSA along side EAM without any issues, or would it cause more issues/conflicts with the BB?

Probably depends on their implementation. If they implement it the way I think they do, using one of the official process creation callbacks, they are probably fine.

When relatively small Emsisoft administered a spanking via AV-C to the behemoths of the industry.... Kaspersky, Microsoft, Symantec, McAfee... did that cause a spike in new subscriptions for service for Emsisoft?

Depends on whether you are talking about the article or the test results. Test results have a surprisingly little influence on sales. We had absolutely excellent results as well as middle-of-the-road results and neither of them had any impact really. There are plenty companies out there that are hugely successful without ever getting tested or that get disastrous results in tests and they are growing rapidly with huge userbases (Webroot, Symantec, Malwarebytes, just to name a few).
The article, on the other hand, caused a significant surge of applications from people who would love to work for us. Not sure if it had any influence on sales. Again, I am not a sales person. Daily revenue figures aren't really something I am concerned with.

Free license??? )))))

Egg Hunt - Emsisoft Anti-Malware

 

[Fabian Wosar]

Of course, blocking script Interpreters is only a partial solution, because the scripting functions are still available in DLLs. But in practice, blocking the script Interpreters is very effective.

Until it becomes common practice and malware comes as an INF file or a Batch script, that copies wscript.exe to notwscript.exe and runs that, because it isn't blocked. You may laugh, but I know a couple of malware families who absolutely do that.

 

[shmu26]

one of them has an HP Printer? Lucky you. Their install packages are literally held together by a bunch of batch and VBS scripts.

HP printer junkie here. Installer packages of HP printers, VMWare, and most other major software will immediately ask for elevated privileges, so they can write to Program files folder. Therefore, blocking certain scripts at medium privileges should not be a problem. Cmd.exe will be a big problem even at medium privileges, but it is an exception to the rule.

HP printer software does use mshta to perform certain tasks, but rare is the user who (like me) wants to see their fax history on their PC monitor, so you will probably not get any complaints about it, except from me.

 

[Fabian Wosar]

HP printer software does use mshta to perform certain tasks, but rare is the user who (like me) wants to see their fax history on their PC monitor, so you will probably not get any complaints about it, except from me.

Trust me, we do. We had to add special handling for HP stuff more than once. Whenever you think you have it all covered, someone comes along with another driver package for some obscure scanner or printer and you start all over again. Plus, their developers come up with even more creative ways to abuse stuff on the system to do what they want even though just doing what they want in their installer or in the code would be way, way easier.

 

[Cortex]

This is called "security fatigue", which subject I am surprised is not discussed much (or at all) on security forums. This is probably the biggest issue (aside from lack of PC skill/experience) that the average user faces. This is also why a set and forget AV is ideal for them. It may not protect them from all infection, but it will protect them against security fatigue - which, as you point out, is a cause.

This is casually overlooked or avoided with forum talk about this or that app, with its myriad of notifications.

We had a similar situation in deep mining where to start a series of events a large red button (we only had large red ones btw) had to be depressed after a previous event to start huge machinery with potential catastrophic results - After a near fatal miss caused by pure habit, a (changing) sequence of buttons had to be pressed by both users of the machine though still not infallible better - This is why I doubt greatly the validity of MS UAC system, people just press yes after X amount of prompts, we proved it with a placebo system.

 

[Ink]

@Fabian Wosar
I understand that you want to keep EAM features equal across all Windows OS, but is there a possbility for "Emsiosft Anti-Malware for macOS"?

 

[Fabian Wosar]

I understand that you want to keep EAM features equal across all Windows OS, but is there a possbility for "Emsiosft Anti-Malware for macOS"?

It's unlikely. While we could port our scan engine to macOS quite easily, there is just not a lot of reason to do so as the market share is so small. If anything, it may become a reality once business customers start asking for it on a more regular basis.

 

[Andy Ful]

Until it becomes common practice and malware comes as an INF file or a Batch script, that copies wscript.exe to notwscript.exe and runs that, because it isn't blocked. You may laugh, but I know a couple of malware families who absolutely do that.

Good point - this can be a problem for the software like SysHardener or OSArmor. But it is also a good example of why the script Interpreters (except cmd.exe) should be blocked by AVs. Simply, any AV can block script Interpreters by signatures. Nowadays, the AV can block Interpreters, even when they are modified, similarly to the techniques used to block malware.
Furthermore, the INF, CMD, BAT scripts can be blocked in user profile by the file extension, so the user will not be fooled to run them accidentally. This does not block cmd.exe from running BAT or CMD scripts via command line, so those files can still be run with Windows (like some Intel scripts). In user profile, the home users usually open documents, media files, photos, or application installers (EXE, MSI), and do not run INF, CMD, BAT scripts.
Of course, this is not a default-deny setup so some attack vectors are not covered, but it is far safer anyway than fighting with scripts by detection.

 

[Fabian Wosar]

Good point - this can be a problem for the software like SysHardener or OSArmor. But it is also a good example of why the script Interpreters (except cmd.exe) should be blocked by AVs. Simply, any AV can block script Interpreters by signatures. Nowadays, the AV can block Interpreters, even when they are modified, similarly to the techniques used to block malware.

EAM actually already does that. It doesn't matter for EAM whether you copy the interpreter or not. Some malware was using that for rundll32.exe as a bypass for some AV in the past and we decided to handle this type of behaviour for all "host processes" as we call them internally. You can obviously still copy the file and break the signature so EAM no longer detects it, but by doing so you also cause EAM to no longer trust it.

Other than that messing with INF is a very, very bad idea. Every single hardware driver (including Windows Update) relies on it. In most cases, they will probably invoke the Setup API directly, but you never know. At the very least INF files don't get executed automatically on double click.

 

[Paul.R]

@Fabian Wosar

I put the question in the wrong topic:

Some love for the macOS version or a better question will be a version for this operating system?

 

[Fabian Wosar]

Some love for the macOS version or a better question will be a version for this operating system?

That was literally asked and answered just a couple of posts ago. You can find it here:

Advice Request - I am head of research at Emsisoft. Ask me anything! :)

Danke schön Fabian, ich habe es mit Absicht in zwei Sprachen geschrieben, einmal ist hier die Standard Sprache Englisch . Und zweitens sind hier auch einige aus dem Deutsch Sprachigen Raum z.b Deutschland - Österreich - Schweiz . Thank you Fabian, I intentionally wrote it in two languages...

malwaretips.com