Now I understandThe attack will be blocked on nearly 1/2 of computers. The attackers do not like the attack methods that can decrease the chances by 50% when there are several more promising methods (like some other LOLBins, etc.).
Of LoLBins, 0 Days, and ESET (Part 2)
- Thread starter cruelsister
- Start date
It is advised to take all reviews with a grain of salt. In extreme cases some reviews use dramatization for entertainment purposes.
I'm going to post a probably not popular view but none the less the double standards also set with not testing as designed as I already mentioned.
If CS were to test CIS against this, all of you would expect to see it done with CS's set up she uses, basically tweaking the settings. This is normal because CIS was designed to be tweaked. Yet the testing of this product also designed to be tweaked is tested at defaults and no one ever questions that. Eset is designed to be hardened by those that know how and are capable.
So again as stated, this is certainly not real world testing.
If CS were to test CIS against this, all of you would expect to see it done with CS's set up she uses, basically tweaking the settings. This is normal because CIS was designed to be tweaked. Yet the testing of this product also designed to be tweaked is tested at defaults and no one ever questions that. Eset is designed to be hardened by those that know how and are capable.
So again as stated, this is certainly not real world testing.
So it's not meant for end users?
- Jun 22, 2020
- 204
You can perfectly take this test as real life, you are wrong. AVs are tested under predetermined conditions.
I am sure that Eset configured to the maximum will not protect you from that malware, since it is a signature-dependent AV.
Ah wel let's all ignore the results of Cruel Sister's video. The result is irrelevant because it is not based on real world situations. It is like the car crash test! How often do you drive into a solid piece of concrete? Besides look at the driver, it is a doll, not even a human who can configure ESET's HIPS (sorry car) to brake and evade the collision easily.
Last edited by a moderator:
ESET is known for striving for balance: detection/FP, performance, user-friendliness.
That's why I think they will default to a "sure" setting that doesn't generate FP and customer support queries. On the other hand, the wide options of advanced settings allow to individually block single and more specific attack paths.
I would like the ability to set clickable "levels/modes" of protection: for example - basic, medium, hard. Where selecting it would harden the predefined settings of the individual software components - HIPS, firewall, etc. And in "hard" such behavior would be blocked on the firewall for example. This could generate trouble/FP, but that would be expected in "hard" mode.
That's why I think they will default to a "sure" setting that doesn't generate FP and customer support queries. On the other hand, the wide options of advanced settings allow to individually block single and more specific attack paths.
I would like the ability to set clickable "levels/modes" of protection: for example - basic, medium, hard. Where selecting it would harden the predefined settings of the individual software components - HIPS, firewall, etc. And in "hard" such behavior would be blocked on the firewall for example. This could generate trouble/FP, but that would be expected in "hard" mode.
I love how you try to derail and divert attention away from facts with irrelevant analogies on drivers that can not even keep their cars on the road "driving through facilities", let alone see where they are going with their fakeness, it's a no wonder they fail so often.
So for each test each software should be tweaked? But to what standard? For e.g kasperksy to NOT trust digitally signed software AND put all apps that can't be categorized into High Restricted as well as the apps that load prior to KTS?
For a normal software sold to end users I would expect it to be good at default settings since most user will never look into any settings at all.
As long as all software tests are done with the default settings I would expect from them all to protect me if files without MOTW show up on some way.
Finally a user in the thread that understands the product being tested. That is exactly it and why I posted what I did, besides your response the other ones demonstrate the comprehension of testing and product abilities, meaning they do not fully grasp.
Last edited by a moderator:
So you are saying CS should only test CIS on defaults from now on to keep things fair between product then ?
I apologize if I'm starting to make sense, at least I'm not doing this out of fanboy urges or other nefarious reasons other then pointing out reality so users are not mislead.
- Mar 2, 2023
- 1,237
At one time, BD used to offer something along that line, regarding the below. I don't remember what the the options for the Firewall were.
The fact that Lenny gave this reputation tells me much about the extent of knowledge either of you have of this product. It's exactly what I mean. You do understand this product has a Hips and you can creat custom rules for it and the firewall correct? You can actually create rules to allow, block or ask for applications, you can assign file operations, select target folders to protect, you can create rules to prevent modification of file directories, ect. It's a daunting task for those unaware of the products capabilities, the operating system, and ability to determine false positives. Definitely takes an advanced user to utilize its abilities.
Let alone your claim to predetermined conditions, I'm still laughing
So you are saying it's not meant for home users. Correct?
I'm saying if you want to squeeze all the capabilities out this product you must learn it. Which is exactly what that statement reads.
- Feb 7, 2023
- 2,356
They had a full blown HIPS in 2008. It covered startup items and a few other system points, BD would issue a prompt. The settings you are displaying were also offered for IDS under firewall (which is policy-based behavioural blocker, e.g. Adobe reader not allowed to create executables). IDS had 5 different levels. There was also a Data Loss Prevention feature that scanned the traffic for certain data, like credit card details (it did not support HTTPs and was killed).
They removed these settings in favour of more automated and user-friendly solution.
HIPS was removed from the product as well, because users should not be expected to take serious security decisions — it is the product’s job.
- Apr 13, 2013
- 3,225
To clarify things, the real reason behind the last 2 videos (and they were always intended to be a set) was to highlight the Clear and present Danger that Living off The Land techniques pose not just for the individual, but to Society at large (a point stressed by the FBI Director to Congress last week).
The concern over utilizing legitimate Windows binaries for foul purposes and the need to protect against them has been a major concern of Microsoft for a number of years and they have taken steps against LOL techniques (thus Defender easily fended off the attack in Video 1):
Example: Out of sight but not invisible: Defeating fileless malware with behavior monitoring, AMSI, and next-gen AV | Microsoft Security Blog
Governments are also concerned as they have reasons to believe Critical Infrastructure is at risk. From the NSA:
Combatting Cyber Threat Actors Perpetrating Living Off the Land Intrusions
In the statement it is noted that the Cybersecurity and Infrastructure Security Agency (CISA) urges software manufacturers to implement secure by design rules in their software, to reduce the prevalence of weak default configurations.
Finally, about the malware used in this video- the entry point was a LoLBin; this opened the door to fileless malware attack which would have not been successful if the product tested was aware of the initial entry, and in these times ignorance is sub-optimal (ESET- Knock, Knock).
The concern over utilizing legitimate Windows binaries for foul purposes and the need to protect against them has been a major concern of Microsoft for a number of years and they have taken steps against LOL techniques (thus Defender easily fended off the attack in Video 1):
Example: Out of sight but not invisible: Defeating fileless malware with behavior monitoring, AMSI, and next-gen AV | Microsoft Security Blog
Governments are also concerned as they have reasons to believe Critical Infrastructure is at risk. From the NSA:
Combatting Cyber Threat Actors Perpetrating Living Off the Land Intrusions
In the statement it is noted that the Cybersecurity and Infrastructure Security Agency (CISA) urges software manufacturers to implement secure by design rules in their software, to reduce the prevalence of weak default configurations.
Finally, about the malware used in this video- the entry point was a LoLBin; this opened the door to fileless malware attack which would have not been successful if the product tested was aware of the initial entry, and in these times ignorance is sub-optimal (ESET- Knock, Knock).
This would require a phishing attack or something of the nature to deploy, hence the route for infection stated many times through out this thread. Fileless malware are truly fileless or lack executable's? Would not scanners detect more then just executable's in a file. How would we know since the video is done half arse. Its just pure speculation because the product was not tested properly.
Knock-Knock Cruelsis.
P.S. you are correct that MS and the governments have known of these all the LOLBins and dll vulnerabilities for a very long time. Its nothing new as its made to sound. The attackers are just utilizing these more now days as it gets harder for them. It still requires social engineering ect regardless. Its not magic, they don't just appear on your desktop one day.
The was no malicious item in the first video, just a demo of the file bypass which of course worked because the product does not block these as they can be used for good or bad, and already explained its a security tool. Route of infection is very important for a product to work as designed. Notice I'm not putting emphasis on any particular product right now. The second video same demonstration of a modified to drop a infection but again, route of infection was not displayed. The product was not given a chance regardless if it could stop the infection or not.
Your first sentence said it all, real world testing almost all Avs score well, because guess what, they use route of infection testing.
As for @Shadowra this comes with no offense meant but because he threw you out there like this I have no choice but to comment.
This user tests URLS and files from a folder on a desktop, not true route of infection testing just like has been done here.
Your honor, I have nothing further to state to the jury, all facts have been presented.
- Dec 23, 2014
- 8,798
I think that there is too much talking about the Eset failure in both tests because Eset Internet Security was taken only as an example of a popular kind of protection. It can be summarized as follows:
Microsoft can also use sandboxing, but it works differently. The file execution is suspended for a short time (10-60 seconds) and some malware can infect the system before the analysis in the sandbox is finished. So, blocking the popular methods can be reasonable for Microsoft, but not necessary for Eset Protect Advanced.
Microsoft Defender in the non-default settings can block several popular attack methods (mostly via ASR rules).
- Detect only files or actions that are recognized as malicious.
- Keep the false positives rate very low.
Microsoft can also use sandboxing, but it works differently. The file execution is suspended for a short time (10-60 seconds) and some malware can infect the system before the analysis in the sandbox is finished. So, blocking the popular methods can be reasonable for Microsoft, but not necessary for Eset Protect Advanced.
Microsoft Defender in the non-default settings can block several popular attack methods (mostly via ASR rules).
Last edited:
Similar threads
