SE Labs Test of Enterprise AV

[Sandbox Breaker]

Thanks, master.

Your welcome my Grand Master!

 

[Shadowra]

I see they're talking about me, so I'll answer

Basically, I don't read any company tests (apart from @Adrian Ścibor which I really like). Whether it's AV-Comparative, AV-Test etc, I don't read any.

Then, I don't like the word "competition" because for me, there isn't any. As much as I hate these test boxes, you really need to look at how the test was run (AV configured? recent malware sample? attacks used? etc ).
An AV can do 100% on EXEs and get screwed on .VBS , .JS , .HTA etc

Note that they didn't test DeepInstinct, Trend Micro's ApexOne and other big names...

(And I've been doing corporate AVs for a while now, and honestly, they're the ones I prefer to test )

 

[cruelsister]

An AV can do 100% on EXEs and get screwed on .VBS , .JS , .HTA etc

Tru dat (and they very frequently do).

 

[Andy Ful]

I see they're talking about me, so I'll answer

Only partially.
I appreciate your passion, kindness, and good work.

 

[Andy Ful]

Tru dat (and they very frequently do).

I remember your posts (with videos) from several years ago about the danger of scripts and scriptors, for example:

It seems that they are equally dangerous today, despite the big effort done by AV vendors.

 

[cartaphilus]

I remember your posts (with videos) from several years ago about the danger of scripts and scriptors, for example:

View attachment 277459

It seems that they are equally dangerous today, despite the big effort done by AV vendors.

They will always be an issue if script engines have admin rights and whole system access. In the end work smart and not hard.

 

[Andy Ful]

They will always be an issue if script engines have admin rights and whole system access. In the end work smart and not hard.

There are several techniques that make scripts dangerous without admin rights.

 

[mlnevese]

There are several techniques that make scripts dangerous without admin rights.

And before someone suggests it, getting rid of PowerShell, etc. is not always an option.

 

[Trident]

And before someone suggests it, getting rid of PowerShell, etc. is not always an option.

It is an option most of the time. I am not sure in this day and age which sysadmin will want to run complicated scripts on PowerShell when they can just log-in and do the job quickly, and more reliably.
Of course on a development environment, it may not be brilliant. If the developed software/software installer relies on PowerShell in a way. PowerShell is not the only danger though.

I’ve been living a PowerShell-less life for long time without any issues.

 

[Sandbox Breaker]

And before someone suggests it, getting rid of PowerShell, etc. is not always an option.

Wish it was haha

 

[cruelsister]

A well developed anti-malware application should have no issue with Scriptors of any type. The desire to have various things blocked (like PowerShell or vbs) is just catering to those products that are not as well coded.

The burden is that the developer should differentiate between the good and the bad, and not for the User to determine what should or should not be run.

 

[Sandbox Breaker]

A well developed anti-malware application should have no issue with Scriptors of any type. The desire to have various things blocked (like PowerShell or vbs) is just catering to those products that are not as well coded.

The burden is that the developer should differentiate between the good and the bad, and not for the User to determine what should or should not be run.

Agreed. But then again its not easy. Simple scripts can even breach these solutions. Even some of the betters ones always get bypassed. I guess its all about lowering damages and insurance payouts.

 

[Trident]

The burden is that the developer should differentiate between the good and the bad, and not for the User to determine what should or should not be run.

It’s easy to say what should and shouldn’t be done but when one attempts to do it, there is a whole load of challenges that come up.