0xDEADBEEF

@Marcos I've PM-ed you the PoC sample. Could you evaluate if it is indeed a vulnerability?

Nope, I think I've found some issues already. But will not post here for now...

Sometimes I got batches of samples (in zip) for analysis. I agree that it is slightly different from web download distribution. Anyway, I've recorded the case I was mentioning here: https://imgur.com/a/hGcPdsl Note the two zip files have exactly the same file, except that the one with _ps1 contains .ps1 extension

This is very weird. I am running on latest EES with all settings set to default (except for the exclusion list). This has been reproduced on more than one machines on my side (I've not tested EIS but itman confirmed it) This is not the first time I've experienced this. Previously another javascript malware sample has the same issue (it lost its .js extension hence ESET on-demand didn't detect it, though it could if the extension was correct) Other users are welcome to try and see if this is reproduce-able on their side, however I don't think I can provide a sample link for them to download here... Another thing to note is that even though such case may "slip through" the realtime protection, when actually executing it, the engine will anyway inspect it again. So if this is indeed something unexpected, at least it is not something really bad so far. I will try some other types of scripts and see how it goes.

yes. So if the script is landed on disk as .txt file for the first time, the realtime protection won't detect it, neither does on-demand scan. If I later rename it to .ps1 the on-demand scan still does not detect it. However if the script is landed on disk as .ps1 file for the first time, the realtime protection will immediately detect and quarantine it. It is very likely that in the first case the file is cached as "benign" due to .txt extension initially, and later got exempted from being scanned again by the right-click scanner even with .ps1 extension. The attached sample's password is "infected" sample.zip

yes it is obfuscated

Something I've noticed is that seems ESET is spending a huge effort since last year to optimize the real-time monitoring performance. A side indicator is that its performance score in AV-TEST has improved significantly (5.5/6.0 recently in business test, in the past it was usually 3~4 out of 6.0 for home products). I can feel the real-time monitoring has become less sensitive (not in a bad way, though) Still I was wondering why the scanner is detecting some files solely by extension. Though detecting a text file and infer its language/content may not be straightforward, many other vendors do. I am not seeing a vulnerability in doing so, but sometimes it is a bit confusing

The EES version is 7.1.2045.5 There is a malicious powershell script sample that is detected by ESET's database for some time. It originally has .txt extension. By default it doesn't seem that ESET realtime/on-demand scan will detect the sample when the extension name is .txt (same for javascript and CAD files, if the extension of .js is missing the scan engine won't detect it). Now that since the scan engine shows clean, I rename the file extension from .txt to .ps1, and I rescan it, the result is still clean. However, if I open the script, add a white space, and save it, it is immediately detected and quarantined by the scan engine. Later I found that even I don't modify the file, upon the next signature update the file that was once marked as clean will be detected. Therefore I assume this is due to ESET scan's caching mechanism, as changing the filename doesn't change the file hash, the clean result will be cached and the scan will be directly skipped the next time. Upon the next update, the cache will be invalidated so the file is redetected again. Just wondering if this is expected. I can see this is effective as a performance enhancement trick, because even the right click scan may "trust" such malicious file, executing it will anyway trigger the inspection again and detect it. A side question: why is ESET's context menu scan still single threaded? Any plan to extend it to multi-thread scan (I mean emulate multiple files at a time)

yeah I was referring to this new module in the module list (though I believe it is in v12 for quite some time, just was not shown in the module list). So generally I am curious about this newly added detection module. Will it be also detecting things during ordinary scanning and monitoring? Is it static engine? Will there be new detection names? etc.

Just wondering if the newly added machine learning module has been integrated to the scanner and realtime file monitoring or it is just effective for some of the protection layer?

I have nearly everything in the ESMC set to default values except that I use my own cert for the webconsole. I will try to modify those timeout knobs and see if the issue can get resolved.

Hmm.. However I am sure it is the default Admin account. The upper right corner is showing >9MIN. Also I've verified the autologout for the default admin is set to 10min

Currently using the latest ESMC with Chrome 75.0.3770.100 The Admin user by default will logout 10 min after the last activity in the session. However it seems it is always auto logging out much sooner (less than 3 minutes). The setting is showing 10min logout. Is this a bug?

Wow I didn't know that MS made such report. Thanks for sharing.

Noticed that the pre-release has added a new machine learning module in the module list. Is that local Augur integration?

The only reason I was mentioning this is because web protection has more sensitive heuristics than on-demand scan or realtime scan, as Marcos has stated in this thread. This means though the realtime scan or AMS will anyway catch the malware if the file is extracted to disk or memory, it might missed the more sensitive heuristic in the web protection layer, if my understanding is correct. As for how much more sensitive the web protection is compared to normal scanner, I've no idea

Agree with the VPN part. the only reason I am asking is because of the more sensitive download heuristic ESET has in the web protection. For differentiating encrypted archive, common file format should be handled (ESET scan log will show such detail)

It depends on where ESET intercepts the traffic. Essentially when the file is landed on the disk, it is not encrypted, so ESET will have a chance to inspect it using more aggressive heuristic. However I guess so far because this is handled by realtime monitoring and it doesn't scan archives by default, such more sensitive detection won't be activated. The way ESET scans SSL traffic seems to be different from some other vendors (e.g. bitdefender). ESET will install its own CA to intercept the traffic (thus the https website in the browser shows ESET CA). I am not sure at this level will ESET be able to inspect the traffic. I guess it should because the data received is likely to be decrypted by VPN first and then decrypted by HTTPS, so inspecting at HTTPS will not be affected. Also I've heard other people saying ESET won't inspect archives downloaded by IDM or other download software.

Wondering if you have confirmed my observation. If so, is there a plan to fix it? (along with VPN plugin issue)

if this is the case, it seems to be a security vulnerability that can bypass the web protection heuristics.

For this kind of detection, will it be shown as some specific malware name? or it will just redirect the browser to the ESET warning page? BTW, I am not a web dev pro, but I suspect the reason why ESET cannot detect firefox send is due to its HTML5-based download system (similar to mega.co.nz). I did the same test on mega.co.nz and ESET cannot detect it as expected.

does this mean web protection may detect something that on-demand scan cannot detect?

After some more tests, I feel like this is website dependent. For the same archive that contains malware, downloading from dropbox is fine (ESET detects it), but downloading from firefox send doesn't work. My test results (On windows 10 1903 Edge + EES 7.1.2045) Dropbox Firefox Send Eicar zip: detected detected (after some delay) malware zip: detected not detected I've sent u the zip I used to test this through private msg BTW, VPN plugin also affect this. For example my main browser is Chrome + surfshark VPN plugin. When the VPN plugin is enabled, the zip won't be detected. Disabling the plugin will have ESET detect it. I don't know if this is considered a bug... The test I had on Edge is orthogonal to this though, it is a barebone Edge browser with no plugin

Does ESET web protection/realtime scan malware inside an archive (e.g. zip)? The reason I am asking this is because in most cases the zip containing malware (no password) I downloaded doesn't trigger any detection from ESET until I unzip it. These archives are small (<512KB). However, for the eicar test zip file ESET will detect it immediately. This is a bit confusing. I tried both on Edge and Chrome, and the results are the same.

OK I think I find out how to reproduce it precisely. In normal case it won't happen, it only happens when you have a manual scan result in the Computer scan tab (see below) in such case a popup trigger will bring up the main GUI. If I click dismiss, this issue will disappear. Guess there is a logic bug in the code.