- Apr 13, 2013
- 3,159
- Content source
- https://youtu.be/CJBi0EvE398
This is a good question based on the "generic detection" for suspicious behaviors that can detect "potentially malicious" files demonstrated by Microsoft.Usually, I see Microsoft Defender allowing Lobbins to connect and download files but nice to see that in this case it reacted promptly. But the main question is, was the downloaded file a true malware or is it a benign file and you just wanted to check if the mechanism of Lolbins connecting and downloading is blocked by MD & ESET?
Yes, in this case the mechanism was tested. The test files had the ability to connect to an external server and successfully download a file which could be benign or malicious- without a peep from E, but blocked by D.Usually, I see Microsoft Defender allowing Lobbins to connect and download files but nice to see that in this case it reacted promptly. But the main question is, was the downloaded file a true malware or is it a benign file and you just wanted to check if the mechanism of Lolbins connecting and downloading is blocked by MD & ESET?
Being a Kind and Gentle person, it felt it appropriate to give Defender a little love (Ophelia hissed at me for this).Also as you stated MS has been known to miss detection's
So basically your faulting Eset for not stopping what is most likely not malicious and giving defender credit for flagging something most likely not malicious. Am I following your logic correctly here?Yes, in this case the mechanism was tested. The test files had the ability to connect to an external server and successfully download a file which could be benign or malicious- without a peep from E, but blocked by D.
Being a Kind and Gentle person, it felt it appropriate to give Defender a little love (Ophelia hissed at me for this).
I think there are both upsides and downsides to this. To give an example of my own, I use an app and the easy way to download it is to paste the code on Terminal and it will use PowerShell to download/update the app and install it. With AVs like Kaspersky and Bitdefender, I have to turn off their protection to download this as they block the mechanism while with default MD and ESET I don't have to as MD allows downloading via powershell.exe and ESET doesn't usually detect malware unless their protection layers find suspicious/malicious code in them or web protection blocking blacklisted sites.Yes, in this case the mechanism was tested. The test files had the ability to connect to an external server and successfully download a file which could be benign or malicious- without a peep from E, but blocked by D.
This behavior by itself is suspicious enough IMO to block it (assuming it was not signed by a trusted vendor)Yes, in this case the mechanism was tested. The test files had the ability to connect to an external server and successfully download a file which could be benign or malicious
Actuslly just demonstrating how some products deal with common mechanism utilized by a typical trojan downloader. Such things can be coded to connect to legitimate websites and download legitimate things, whereas it could also connect out to the Darkness Beyond and download things that will yield No Joy to the user.your faulting Eset for not stopping what is most likely not malicious
Agreed. Running an unknown file to view its effects on a product protected system is indeed important, and that was what was done.but the method and legitimacy is important.
Did the mechanism happen to be the lolbin "BITS" which is used to download Windows updates ?Yes, in this case the mechanism was tested. The test files had the ability to connect to an external server and successfully download a file which could be benign or malicious- without a peep from E, but blocked by D.
If that's the case certutil is used by admin and developers and can be used to download files, it's part of the certificates service and it's used to display, configure and restore CA components.The detection of Microsoft Defender is acceptable, because the Certutil LOLBin was used in the attacks many times and people rarely use it to download files. However, the detection could be improved by allowing files with good reputations. In the case of the test, the file should be allowed (has a good reputation), but the file with an unknown reputation might be blocked.
The detection of Eset in the test is also acceptable because the downloaded file has a good reputation.
I think that @cruelsister's test can be extended as follows:
The extended test is based on the rational idea that potentially unwanted apps downloaded via suspicious methods should be prevented. It is possible, that Eset will fail such a test.
- Download the file that SmartScreen blocks in Edge (SmartScreen set to "Block potentially unwanted apps") by choosing "keep the file".
- Check if the file from point 1 is undetected by Eset.
- If points 1 and 2 are fulfilled, download the file again using the Certutil LOLBin.
The @cruelsister's test shows that Microsoft Defender detection can be improved. The extended test (if Eset fails) can show that Eset's detection can be improved.
If that's the case certutil is used by admin and developers and can be used to download files, it's part of the certificates service and it's used to display, configure and restore CA components.
Put an actual payload in it and run it through again. This time use real world route of infection as well.
I find you apply enterprise to a home users based forum often.It is not a common way. Admins usually download files by using PowerShell.
Such a test might hardly be done in practice. One should find many malicious payloads undetected by Eset and next download them via the Certutil to see how many files could be blocked. It is easier to do it with non-malicious files with unknown reputations.
The test with non-malicious files (proposed by me) can show if the AV uses aggressive behavior blocking or not. The people (including admins) can choose which AV is better for them
I find you apply enterprise to a home users based forum often.
If the file does not contain malicious code, it can not be detected by web filter protection, or upon post execution on the system by heuristics and behavioral not to mention HIPS based protection layers that monitor behaviors.
Wanting to see if a product is triggered by actions that mimic behaviors leading to what you have described is a false positive, it is certainly not the same as a benign file with no payload waltzing out and back into the front door initiated by the user. I was not exact in my wording and it appears loosely translated although my meaning I know you understand, as the file in this case is not performing a malicious action nor contains malicious code. It is being used to demonstrate a way that file could be used to carry that out, but not actually doing so.Home users do not use Certutil (and most of LOLBins) at all. It is a tool used mostly by developers and IT administrators. The Microsoft Defender detection of Certutil will be the same for home users and organizations.
This is not true. In many cases, the legal Administrative tools are detected as malware. For example, many installers of my applications are initially detected as malicious. The detection can survive for a long time until the developer reports it as a false positive (sometimes this will not help too). Also, SmartScreen in Edge can block many legal applications if they do not have a good reputation.
Another example can be the latest AVLab test, where most AVs detected two legal remote admin applications as malware. Microsoft left those tools undetected. Many PUAs can be detected as malicious, especially when they are abused as a part of an attack.
It can happen that the attack will be stopped by detecting/blocking legal PUA or by blocking the LOLBin which wants to download PUA. Such differences can be interesting for some people.
Anyway, you are right in saying that tests with POCs cannot say much about the overall AV protection. Such tests are often misinterpreted by people.
Are tests with POCs informative? Yes, some of them can show interesting differences between the AV detections.
Personally I would not want to use a security system that is so aggressive. Its like having a dog that barks at everything around your house, how would you know what is a legitimate threat or not, especially for those average users.
Eset much like CIS is not designed to be run out of the box "hence the elaborate settings" even though it has default settings for average users. Those are a mix of security and usability. Demonstrating if a product misses something legitimate, without demonstrating its capabilities, is pointless. Being advanced enough to use the product to its fullest capabilities is another matter altogether which is much like not testing it that way.Many AVs have such aggressive behaviors. Some can block legal tools, others can block LOLBins.
Some time ago I tested an AV that blocked by default the outbound Internet connections of PowerShell.
When I tested ZoneAlarm in the Challenge series, it blocked the shortcut with benign CmdLines containing cmd[.]exe.
Eset is known to have almost no false positives (on default settings), but its detection is not among top AVs. Of course, Eset has got HIPS that can strengthen the protection with a cost of false positives.
Edit.
Microsoft uses Machine Learning to decrease the number of false positives. The ML model probably recognized that using Certutil to download files is very uncommon among customers, so such behavior can be detected as malicious.
Bottom line here is not that the file could be used for something, it was not fitted with a malicious payload nor did it actually commit any malicious actions other then its not common to be used, but again, the detection by microsoft was a generic response to this "possibility" , so props up to it flagging a benign file, but it is not an indicator the other product failed.
Nor would I suggest users remove this product because they watched this test and think it failed.